Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7542 FreeRADIUS
Obsoletes: 4282 May 2015
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7542 FreeRADIUS
Obsoletes: 4282 May 2015
Category: Standards Track
ISSN: 2070-1721
The Network Access Identifier
网络访问标识符
Abstract
摘要
In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.
为了提供域间身份验证服务，需要有一种标准化的方法，域可以使用该方法来识别彼此的用户。本文档定义了网络访问标识符（NAI）的语法，NAI是客户端在访问资源之前提交的用户标识符。本文件是RFC 4282的修订版。它解决了国际字符集的问题，并对RFC 4282进行了许多其他更正。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7542.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7542.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Requirements Language ......................................7
1.3. Purpose ....................................................7
1.4. Motivation .................................................9
2. NAI Definition .................................................10
2.1. UTF-8 Syntax and Normalization ............................10
2.2. Formal Syntax .............................................11
2.3. NAI Length Considerations .................................11
2.4. Support for Username Privacy ..............................12
2.5. International Character Sets ..............................13
2.6. The Normalization Process .................................14
2.6.1. Issues with the Normalization Process ..............15
2.7. Use in Other Protocols ....................................16
2.8. Using the NAI Format for Other Identifiers ................17
3. Routing inside of AAA Systems ..................................18
3.1. Compatibility with Email Usernames ........................19
3.2. Compatibility with DNS ....................................20
3.3. Realm Construction ........................................20
3.3.1. Historical Practices ...............................21
3.4. Examples ..................................................22
4. Security Considerations ........................................23
4.1. Correlation of Identities over Time and Protocols .........23
4.2. Multiple Identifiers ......................................24
5. Administration of Names ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................26
Appendix A. Changes from RFC 4282 .................................29
Acknowledgments ...................................................30
Author's Address ..................................................30
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Requirements Language ......................................7
1.3. Purpose ....................................................7
1.4. Motivation .................................................9
2. NAI Definition .................................................10
2.1. UTF-8 Syntax and Normalization ............................10
2.2. Formal Syntax .............................................11
2.3. NAI Length Considerations .................................11
2.4. Support for Username Privacy ..............................12
2.5. International Character Sets ..............................13
2.6. The Normalization Process .................................14
2.6.1. Issues with the Normalization Process ..............15
2.7. Use in Other Protocols ....................................16
2.8. Using the NAI Format for Other Identifiers ................17
3. Routing inside of AAA Systems ..................................18
3.1. Compatibility with Email Usernames ........................19
3.2. Compatibility with DNS ....................................20
3.3. Realm Construction ........................................20
3.3.1. Historical Practices ...............................21
3.4. Examples ..................................................22
4. Security Considerations ........................................23
4.1. Correlation of Identities over Time and Protocols .........23
4.2. Multiple Identifiers ......................................24
5. Administration of Names ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................26
Appendix A. Changes from RFC 4282 .................................29
Acknowledgments ...................................................30
Author's Address ..................................................30
Considerable interest exists for a set of features that fit within the general category of inter-domain authentication, or "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications.
人们对域间身份验证或网络访问的“漫游能力”这一一般类别中的一组功能非常感兴趣，包括拨号Internet用户、虚拟专用网络（VPN）使用、无线LAN身份验证和其他应用程序。
By "inter-domain authentication", this document refers to situations where a user has authentication credentials at one "home" domain but is able to present them at a second "visited" domain to access certain services at the visited domain. The two domains generally have a pre-existing relationship, so that the credentials can be passed from the visited domain to the home domain for verification. The home domain typically responds with a permit/deny response, which may also include authorization parameters that the visited domain is expected to enforce on the user.
通过“域间身份验证”，本文档指的是这样的情况：用户在一个“主”域中拥有身份验证凭据，但能够在第二个“已访问”域中提供这些凭据，以访问已访问域中的某些服务。这两个域通常具有预先存在的关系，因此可以将凭据从访问的域传递到主域进行验证。归属域通常使用许可/拒绝响应进行响应，该响应还可能包括访问域预期对用户实施的授权参数。
That is, the "roaming" scenario involves a user visiting, or "roaming" to, a non-home domain and requesting the use of services at that visited domain.
也就是说，“漫游”场景涉及用户访问或“漫游”到非归属域，并请求使用该访问域中的服务。
Interested parties have included the following:
有兴趣的人士包括：
* Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area.
* 区域互联网服务提供商（ISP）在特定州或省内运营，希望与其他区域提供商合作，在更大范围内提供拨号服务。
* Telecommunications companies who wish to combine their operations with those of one or more companies in other areas or nations, in order to offer more comprehensive network access service in areas where there is no native service (e.g., in another country).
* 电信公司希望将其业务与其他地区或国家的一家或多家公司的业务相结合，以便在没有本地服务的地区（例如，在另一个国家）提供更全面的网络接入服务。
* Wireless LAN hotspots providing service to one or more ISPs.
* 向一个或多个ISP提供服务的无线LAN热点。
* Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301].
* 希望在全球范围内为员工提供全面的拨号服务的企业。这些服务可包括因特网接入以及通过VPN对公司内部网的安全接入，该VPN由隧道协议（例如点对点隧道协议（PPTP）[RFC2637]、第二层转发（L2F）协议[RFC2341]、第二层隧道协议（L2TP）[RFC2661]和IPsec隧道模式[RFC4301]启用。
* Other protocols that are interested in leveraging the users' credentials in order to take advantage of an existing authentication framework.
* 有兴趣利用用户凭据以利用现有身份验证框架的其他协议。
In order to enhance the interoperability of these services, it is necessary to have a standardized method for identifying users. This document defines syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [RFC2194].
为了增强这些服务的互操作性，有必要采用标准化的方法来识别用户。本文档定义了网络访问标识符（NAI）的语法。使用NAI的实现示例及其语义描述见[RFC2194]。
When the NAI was defined for network access, it had the side effect of defining an identifier that could be used in non-AAA systems. Some non-AAA systems defined identifiers that were compatible with the NAI, and deployments used the NAI. This process simplified the management of credentials, by reusing the same credential in multiple situations. Protocols that reuse the same credential or the same identifier format can benefit from this simplified management. The alternative is to have protocol-specific credentials or identifier formats, which increases cost to both the user and the administrator.
当NAI被定义为网络访问时，它的副作用是定义一个可用于非AAA系统的标识符。一些非AAA系统定义了与NAI兼容的标识符，部署使用了NAI。此过程通过在多种情况下重用同一凭证简化了凭证的管理。重用相同凭证或相同标识符格式的协议可以从这种简化的管理中获益。另一种选择是使用特定于协议的凭据或标识符格式，这会增加用户和管理员的成本。
There are privacy implications to using one identifier across multiple protocols. See Sections 2.7 and 4 for further discussion of this topic.
跨多个协议使用一个标识符会涉及隐私问题。有关此主题的进一步讨论，请参见第2.7节和第4节。
The goal of this document is to define the format of an identifier that can be used in many protocols. A protocol may transport an encoded version of the NAI (e.g., '.' as %2E). However, the definition of the NAI is protocol independent. The goal of this document is to encourage the widespread adoption of the NAI format. This adoption will decrease the work required to leverage identification and authentication in other protocols. It will also decrease the complexity of non-AAA systems for end users and administrators.
本文档的目标是定义可在许多协议中使用的标识符的格式。协议可以传输NAI的编码版本（例如，“.”作为%2E）。然而，NAI的定义与协议无关。本文件的目标是鼓励广泛采用NAI格式。这种采用将减少在其他协议中利用标识和身份验证所需的工作。它还将为最终用户和管理员降低非AAA系统的复杂性。
This document only suggests that the NAI format be used; it does not require such use. Many protocols already define their own identifier formats. Some of these are incompatible with the NAI, while others allow the NAI in addition to non-NAI identifiers. The definition of the NAI in this document has no requirements on protocol specifications, implementations, or deployments.
本文件仅建议使用NAI格式；它不需要这样的使用。许多协议已经定义了自己的标识符格式。其中一些与NAI不兼容，而另一些则允许NAI和非NAI标识符。本文档中NAI的定义对协议规范、实现或部署没有任何要求。
However, this document suggests that using one standard identifier format is preferable to using multiple incompatible identifier formats. Where identifiers need to be used in new protocols and/or specifications, it is RECOMMENDED that the format of the NAI be used. That is, the interpretation of the identifier is context specific, while the format of the identifier remains the same. These issues are discussed in more detail in Section 2.8, below.
但是，本文件建议使用一种标准标识符格式比使用多种不兼容的标识符格式更可取。如果需要在新协议和/或规范中使用标识符，建议使用NAI的格式。也就是说，标识符的解释是特定于上下文的，而标识符的格式保持不变。下文第2.8节将更详细地讨论这些问题。
The recommendation for a standard identifier format is not a recommendation that each user have one universal identifier. In contrast, this document allows for the use of multiple identifiers and recommends the use of anonymous identifiers where those identifiers are publicly visible.
标准标识符格式的建议不是每个用户都有一个通用标识符的建议。相反，本文件允许使用多个标识符，并建议在这些标识符公开的情况下使用匿名标识符。
This document is a revised version of [RFC4282], which originally defined internationalized NAIs. Differences and enhancements compared to that document are listed in Appendix A.
本文件是[RFC4282]的修订版，最初定义了国际化NAI。附录A中列出了与该文件相比的差异和改进。
This document frequently uses the following terms:
本文件经常使用以下术语：
"Local" or "Localized" Text
“本地”或“本地化”文本
"Local" or "localized" text is text that is in either non-UTF-8 or non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. The client that "knows" the locale may have a different concept of this text than other AAA entities, which do not know the same locale.
“本地”或“本地化”文本是非UTF-8或非规范化形式的文本。身份验证、授权和记帐（AAA）网络协议（通常）不知道字符集、编码和区域设置。“知道”区域设置的客户端可能与不知道相同区域设置的其他AAA实体具有不同的文本概念。
Network Access Identifier
网络访问标识符
The Network Access Identifier (NAI) is a common format for user identifiers submitted by a client during authentication. The purpose of the NAI is to allow a user to be associated with an account name, as well as to assist in the routing of the authentication request across multiple domains. Please note that the NAI may not necessarily be the same as the user's email address or the user identifier submitted in an application-layer authentication.
网络访问标识符（NAI）是客户端在身份验证期间提交的用户标识符的通用格式。NAI的目的是允许用户与帐户名关联，以及帮助跨多个域路由身份验证请求。请注意，NAI不一定与应用层身份验证中提交的用户电子邮件地址或用户标识符相同。
Network Access Server
网络访问服务器
The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
网络访问服务器（NAS）是客户端连接以访问网络的设备。在PPTP术语中，这被称为PPTP接入集中器（PAC），在L2TP术语中，它被称为L2TP接入集中器（LAC）。在IEEE 802.11中，它被称为接入点。
Roaming Capability
漫游能力
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
漫游能力可以粗略地定义为能够使用多个互联网服务提供商（ISP）中的任何一个，同时只与一个ISP保持正式的客户-供应商关系。可能需要漫游功能的案例包括ISP“联盟”和ISP提供的公司网络访问支持。
Normalization or Canonicalization
规范化还是规范化
These terms are defined in Section 4 of [RFC6365]; those definitions are incorporated here by reference.
[RFC6365]第4节对这些术语进行了定义；这些定义通过引用并入此处。
Locale
场所
This term is defined in [RFC6365], Section 8; that definition is incorporated here by reference.
[RFC6365]第8节对该术语进行了定义；该定义通过引用并入此处。
Tunneling Service
隧道服务
A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One example of a tunneling service is secure access to corporate intranets via a Virtual Private Network (VPN).
隧道服务是通过隧道协议（如PPTP、L2F、L2TP和IPsec隧道模式）启用的任何网络服务。隧道服务的一个示例是通过虚拟专用网络（VPN）安全访问公司内部网。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
As described in [RFC2194], there are a number of providers offering network access services, and essentially all Internet Service Providers are involved in roaming consortia.
如[RFC2194]所述，有许多提供商提供网络接入服务，基本上所有互联网服务提供商都参与了漫游联盟。
In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the Network Access Identifier (NAI) submitted by the user to the NAS in the initial network authentication. It is also expected that NASes will use the NAI as part of the process of opening a new tunnel, in order to determine the tunnel endpoint.
为了能够提供漫游功能，其中一个要求是能够识别用户的家庭身份验证服务器。对于漫游，此功能通过用户在初始网络身份验证中提交给NAS的网络访问标识符（NAI）实现。此外，预计NASes将使用NAI作为打开新隧道过程的一部分，以确定隧道终点。
This document suggests that other protocols can take advantage of the NAI format. Many protocols include authentication capabilities, including defining their own identifier formats. These identifiers can then end up being transported in AAA protocols, so that the originating protocols can leverage AAA for user authentication. There is therefore a need for a definition of a user identifier that can be used in multiple protocols.
本文件建议其他协议可以利用NAI格式。许多协议包括身份验证功能，包括定义自己的标识符格式。然后，这些标识符可以在AAA协议中传输，以便原始协议可以利用AAA进行用户身份验证。因此，需要定义可在多个协议中使用的用户标识符。
While the NAI is defined herein, it should be noted that existing protocols and deployments do not always use it. AAA systems MUST therefore be able to handle user identifiers that are not in the NAI format. The process by which that is done is outside of the scope of this document.
虽然本文定义了NAI，但应注意，现有协议和部署并不总是使用它。因此，AAA系统必须能够处理非NAI格式的用户标识符。该过程不在本文件范围内。
Non-AAA systems can accept user identifiers in forms other than the NAI. This specification does not forbid that practice. It only codifies the format and interpretation of the NAI. This document cannot change existing protocols or practices. It can, however, suggest that using a consistent form for a user identifier is of benefit to the community.
非AAA系统可以接受非NAI形式的用户标识符。本规范并不禁止这种做法。它只编纂了NAI的格式和解释。本文件不能更改现有的协议或实践。然而，它可以建议对用户标识符使用一致的表单对社区有益。
This document does not make any protocol-specific definitions for an identifier format, and it does not make changes to any existing protocol. Instead, it defines a protocol-independent form for the NAI. It is hoped that the NAI is a user identifier that can be used in multiple protocols.
本文档不会对标识符格式进行任何特定于协议的定义，也不会对任何现有协议进行更改。相反，它为NAI定义了独立于协议的形式。人们希望NAI是一种可以在多种协议中使用的用户标识符。
Using a common identifier format simplifies protocols requiring authentication, as they no longer need to specify a protocol-specific format for user identifiers. It increases security, as multiple identifier formats allow attackers to make contradictory claims without being detected (see Section 4.2 for further discussion of this topic). It simplifies deployments, as a user can have one identifier in multiple contexts, which allows them to be uniquely identified, so long as that identifier is itself protected against unauthorized access.
使用公共标识符格式简化了需要身份验证的协议，因为它们不再需要为用户标识符指定特定于协议的格式。它提高了安全性，因为多种标识符格式允许攻击者在不被检测的情况下提出相互矛盾的声明（有关本主题的进一步讨论，请参阅第4.2节）。它简化了部署，因为一个用户可以在多个上下文中拥有一个标识符，这允许对其进行唯一标识，只要该标识符本身能够防止未经授权的访问。
In short, having a standard is better than having no standard at all.
简言之，有标准总比没有标准好。
The changes from [RFC4282] are listed in detail in Appendix A. However, some additional discussion is appropriate to motivate those changes.
附录A中详细列出了[RFC4282]的变更。但是，一些额外的讨论适合于推动这些变更。
The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms and limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with the Punycode [RFC3492] encoding form as described in [RFC5891]. There are a number of problems with this approach:
修订[RFC4282]的动机始于[EDUROAM]背景下提出的国际化问题。[RFC4282]第2.1节定义了领域的ABNF，并将领域语法限制为英文字母、数字和连字符“-”字符。其目的似乎是使用[RFC5891]中描述的Punycode[RFC3492]编码形式对领域进行编码、比较和传输。这种方法存在许多问题：
* The [RFC4282] ABNF is not aligned with internationalization of DNS.
* [RFC4282]ABNF与DNS的国际化不一致。
* The requirement in Section 2.1 of [RFC4282] that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) as defined in [RFC3748], and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identifiers.
* [RFC4282]第2.1节中关于领域为ASCII的要求与[RFC3748]中定义的可扩展身份验证协议（EAP）和RADIUS冲突，后者都是8位干净的，并且都建议对标识符使用UTF-8。
* Section 2.4 of [RFC4282] required mappings that are language specific and that are nearly impossible for intermediate nodes to perform correctly without information about that language.
* [RFC4282]第2.4节要求映射是特定于语言的，如果没有关于该语言的信息，中间节点几乎不可能正确执行映射。
* Section 2.4 of [RFC4282] requires normalization of usernames, which may conflict with local system or administrative requirements.
* [RFC4282]第2.4节要求规范用户名，这可能与本地系统或管理要求冲突。
* The recommendations in Section 2.4 of [RFC4282] for treatment of bidirectional characters have proven to be unworkable.
* [RFC4282]第2.4节中关于处理双向字符的建议已被证明是行不通的。
* The prohibition of the use of unassigned code points in Section 2.4 of [RFC4282] effectively prohibits support for new scripts.
* [RFC4282]第2.4节中禁止使用未分配的代码点实际上禁止支持新脚本。
* No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in Section 2.4 of [RFC4282], among other sections.
* 除其他章节外，认证、授权和计费（AAA）客户端、代理或服务器均未实现[RFC4282]第2.4节中的任何要求。
With international roaming growing in popularity, it is important for these issues to be corrected in order to provide robust and interoperable network services.
随着国际漫游的日益普及，纠正这些问题以提供健壮且可互操作的网络服务非常重要。
Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format.
此外，本文件的动机是编纂与NAI格式使用相关的现有实践，并鼓励广泛使用该格式。
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF-8字符可以使用取自[RFC3629]的以下ABNF[RFC5234]以八位字节定义：
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2( UTF8-tail )
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF
UTF8-tail = %x80-BF
These are normatively defined in [RFC3629] but are repeated in this document for reasons of convenience.
[RFC3629]中对其进行了规范性定义，但为了方便起见，本文件中重复了这些定义。
See [RFC5198] and Section 2.6 of this specification for a discussion of normalization. Strings that are not Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations that expect to receive an NAI but that instead receive non-normalized (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be used for local processing. This local version of the identifier MUST NOT be used outside of the local context.
有关规范化的讨论，请参见[RFC5198]和本规范第2.6节。非标准格式组合（NFC）的字符串是无效的NAI，不应如此对待。期望接收NAI但接收非规范化（但在其他方面有效）UTF-8字符串的实现应尝试创建NAI的本地版本，该版本根据输入标识符进行规范化。然后，此本地版本可用于本地处理。标识符的本地版本不得在本地上下文之外使用。
Where protocols carry identifiers that are expected to be transported over a AAA protocol, it is RECOMMENDED that the identifiers be in NAI format. Where the identifiers are not in the NAI format, it is up to the AAA systems to discover this and to process them. This document does not suggest how that is done. However, existing practice indicates that it is possible.
如果协议携带预期通过AAA协议传输的标识符，建议标识符采用NAI格式。如果标识符不是NAI格式，则由AAA系统发现并处理它们。本文件并未建议如何做到这一点。然而，现有的实践表明这是可能的。
As internationalized domain names become more widely used, existing practices are likely to become inadequate. This document therefore defines the NAI, which is a user identifier format that can correctly deal with internationalized identifiers.
随着国际化域名的使用越来越广泛，现有的做法可能会变得不充分。因此，本文档定义了NAI，它是一种用户标识符格式，可以正确处理国际化标识符。
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC5234].
NAI的语法如下所示，如[RFC5234]中所述，以增广的巴科斯诺尔形式（ABNF）进行描述。
nai = utf8-username
nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm
nai = utf8-username
nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm
utf8-username = dot-string
utf8-username = dot-string
dot-string = string *("." string)
string = 1*utf8-atext
dot-string = string *("." string)
string = 1*utf8-atext
utf8-atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-realm = 1*( label "." ) label
utf8-realm = 1*( label "." ) label
label = utf8-rtext *(ldh-str)
ldh-str = *( utf8-rtext / "-" ) utf8-rtext
utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char
label = utf8-rtext *(ldh-str)
ldh-str = *( utf8-rtext / "-" ) utf8-rtext
utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char
Devices handling NAIs MUST support an NAI length of at least 72 octets. Devices SHOULD support an NAI length of 253 octets. However, the following implementation issues should be considered:
处理NAI的设备必须支持至少72个八位字节的NAI长度。设备应支持253个八位字节的NAI长度。但是，应考虑以下实施问题：
* NAI octet length constraints may impose a more severe constraint on the number of UTF-8 characters.
* NAI八位字节长度约束可能会对UTF-8字符的数量施加更严格的约束。
* NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, [RFC2865], Section 5.1 states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may
* NAI通常在远程身份验证拨入用户服务（RADIUS）协议的用户名属性中传输。不幸的是，[RFC2865]第5.1节指出“建议至少处理63个八位字节的能力”。因此，可能无法通过所有设备传输超过63个八位字节的NAI。此外，由于只能使用单个用户名属性
be included in a RADIUS message and the maximum attribute length is 253 octets, RADIUS is unable to support NAI lengths beyond 253 octets.
要包含在RADIUS消息中，且最大属性长度为253个八位字节，RADIUS无法支持超过253个八位字节的NAI长度。
* NAIs can also be transported in the User-Name attribute of Diameter [RFC6733], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. However, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations will apply.
* NAI还可以在Diameter[RFC6733]的用户名属性中传输，该属性支持最长为2^24-9个八位字节的内容长度。因此，仅由直径节点处理的NAI可能非常长。然而，通过直径传输的NAI最终可能转化为半径，在这种情况下，上述限制将适用。
* NAIs may be transported in other protocols. Each protocol can have its own limitations on maximum NAI length.
* NAI可以在其他协议中传输。每个协议在最大NAI长度上都有自己的限制。
The above criteria should permit the widest use and widest possible interoperability of the NAI.
上述标准应允许NAI的最广泛使用和尽可能广泛的互操作性。
Interpretation of the username part of the NAI depends on the realm in question. Therefore, the utf8-username portion SHOULD be treated as opaque data when processed by nodes that are not a part of the home domain for that realm.
NAI用户名部分的解释取决于所讨论的领域。因此，当utf8用户名部分由不属于该领域的主域的节点处理时，应将其视为不透明数据。
That is, the only domain that is capable of interpreting the meaning of the utf8-username portion of the NAI is the home domain. Any third-party domains cannot form any conclusions about the utf8-username and cannot decode it into subfields. For example, it may be used as "firstname.lastname", or it may be entirely digits, or it may be a random hex identifier. There is simply no way (and no reason) for any other domain to interpret the utf8-username field as having any meaning whatsoever.
也就是说，唯一能够解释NAI的utf8用户名部分含义的域是主域。任何第三方域都无法对utf8用户名形成任何结论，也无法将其解码为子字段。例如，它可以用作“firstname.lastname”，也可以完全是数字，也可以是随机十六进制标识符。任何其他域都无法（也没有理由）将utf8用户名字段解释为具有任何意义。
In some situations, NAIs are used together with a separate authentication method that can transfer the username part in a more secure manner to increase privacy. In this case, NAIs MAY be provided in an abbreviated form by omitting the username part. Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since including a fixed username part is ambiguous as to whether or not the NAI refers to a single user. However, current practice is to use the username "anonymous" instead of omitting the username part. This behavior is also permitted.
在某些情况下，NAI与单独的身份验证方法一起使用，该方法可以以更安全的方式传输用户名部分，以增加隐私。在这种情况下，可以通过省略用户名部分以缩写形式提供NAI。与使用固定用户名部分（如“匿名”）相比，建议省略用户名部分，因为包括固定用户名部分对于NAI是否指单个用户来说是不明确的。然而，目前的做法是使用用户名“匿名”，而不是省略用户名部分。这种行为也是允许的。
The most common use case of omitting or obfuscating the username part is with TLS-based EAP methods such as Tunneled Transport Layer Security (TTLS) [RFC5281]. Those methods allow for an "outer" identifier, which is typically an anonymous "@realm". This outer identifier allows the authentication request to be routed from a
省略或混淆用户名部分的最常见用例是基于TLS的EAP方法，如隧道传输层安全（TTLS）[RFC5281]。这些方法允许使用“外部”标识符，通常是匿名的“@realm”。此外部标识符允许从服务器路由身份验证请求
visited domain to a home domain. At the same time, the username part is kept confidential from the visited network. The protocol provides for an "inner" authentication exchange, in which a full identifier is used to authenticate a user.
访问的域到主域。同时，用户名部分对访问的网络保密。该协议提供了“内部”身份验证交换，其中使用完整标识符对用户进行身份验证。
That scenario offers the best of both worlds. An anonymous NAI can be used to route authentication to the home domain, and the home domain has sufficient information to identify and authenticate users.
这种情况提供了两全其美的结果。匿名NAI可用于将身份验证路由到主域，并且主域具有足够的信息来识别和验证用户。
However, some protocols do not support authentication methods that allow for "inner" and "outer" exchanges. Those protocols are limited to using an identifier that is publicly visible. It is therefore RECOMMENDED that such protocols use ephemeral identifiers. We recognize that this practice is not currently used and will likely be difficult to implement.
但是，有些协议不支持允许“内部”和“外部”交换的身份验证方法。这些协议仅限于使用公开可见的标识符。因此，建议此类协议使用临时标识符。我们认识到，目前尚未采用这种做法，很可能难以实施。
Similar to the anonymous user, there may be situations where portions of the realm are sensitive. For those situations, it is RECOMMENDED that the sensitive portion of the realm also be omitted (e.g., to use "@example.com" instead of "@sensitive.example.com", or "anonymous@sensitive.example.com"). The home domain is authoritative for users in all subdomains and can (if necessary) route the authentication request to the appropriate subsystem within the home domain.
与匿名用户类似，可能存在领域部分敏感的情况。对于这些情况，建议也省略领域的敏感部分（例如，使用“@example.com”而不是“@sensitive.example.com”，或”anonymous@sensitive.example.com"). 主域对所有子域中的用户具有权威性，并且可以（如果需要）将身份验证请求路由到主域中的适当子系统。
For roaming purposes, it is typically necessary to locate the appropriate backend authentication server for the given NAI before the authentication conversation can proceed. As a result, authentication routing is impossible unless the realm portion is available and is in a well-known format.
出于漫游目的，通常需要为给定NAI找到适当的后端身份验证服务器，然后才能继续身份验证对话。因此，除非领域部分可用并且是众所周知的格式，否则身份验证路由是不可能的。
This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8. Internationalization of the username portion of the NAI is based on the "Internationalized Email Headers" [RFC6532] extensions to the "local-part" portion of email addresses [RFC5322].
此规范允许使用国际用户名和领域。国际用户名基于Unicode字符的使用，编码为UTF-8。NAI用户名部分的国际化基于电子邮件地址[RFC5322]的“本地部分”的“国际化电子邮件头”[RFC6532]扩展。
In order to ensure a canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. In practice, these requirements consist of the following item:
为了确保规范化表示，NAI中领域部分的字符必须与本规范中的ABNF以及[RFC5891]中规定的要求相匹配。实际上，这些要求包括以下各项：
* Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS.
* 域的形式必须可以在DNS中注册为完全限定域名（FQDN）。
This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended on intermediate nodes performing canonicalizations based on insufficient information, which meant that the form was not canonical.
该列表比[RFC4282]第2.4节中的列表短得多，也简单得多。[RFC4282]中建议的表单依赖于中间节点根据不充分的信息执行规范化，这意味着表单不是规范的。
Specifying the realm requirement as above means that the requirements depend on specifications that are referenced here, rather than copied here. This allows the realm definition to be updated when the referenced documents change, without requiring a revision of this specification.
如上所述指定领域需求意味着需求依赖于此处引用的规范，而不是此处复制的规范。这允许在引用文档发生更改时更新领域定义，而无需修订本规范。
One caveat on the above recommendation is the issues noted in [RFC6912]. That document notes that there are additional restrictions around DNS registration that forbid some code points from being valid in a DNS U-label. These restrictions cannot be expressed algorithmically.
上述建议的一个警告是[RFC6912]中指出的问题。该文件指出，DNS注册有其他限制，禁止某些代码点在DNS U标签中有效。这些限制不能用算法来表示。
For this specification, that caveat means the following: Realms not matching the above ABNF are not valid NAIs. However, some realms that do match the ABNF are still invalid NAIs. That is, matching the ABNF is a necessary, but not sufficient, requirement for an NAI.
对于本规范，该警告意味着：与上述ABNF不匹配的领域是无效的NAI。然而，一些与ABNF匹配的领域仍然是无效的NAI。也就是说，匹配ABNF是NAI的必要条件，但还不够。
In general, the above requirement means following the requirements specified in [RFC5891].
通常，上述要求意味着遵循[RFC5891]中规定的要求。
Conversion to Unicode as well as normalization SHOULD be performed by edge systems (e.g., laptops, desktops, smart phones, etc.) that take "local" text as input. These edge systems are best suited to determine the user's intent and can best convert from "local" text to a normalized form.
转换为Unicode以及标准化应由采用“本地”文本作为输入的边缘系统（例如笔记本电脑、台式机、智能手机等）执行。这些边缘系统最适合确定用户的意图，并且可以最好地将“本地”文本转换为规范化形式。
Other AAA systems such as proxies do not have access to locale and character set information that is available to edge systems. Therefore, they may not always be able to convert local input to Unicode.
其他AAA系统（如代理）无法访问边缘系统可用的区域设置和字符集信息。因此，他们可能并不总是能够将本地输入转换为Unicode。
That is, all processing of NAIs from "local" character sets and locales to UTF-8 SHOULD be performed by edge systems, prior to the NAIs entering the AAA system. Inside of a AAA system, NAIs are sent over the wire in their canonical form, and this canonical form is used for all NAI and/or realm comparisons.
也就是说，在NAI进入AAA系统之前，所有从“本地”字符集和地区到UTF-8的NAI处理都应由边缘系统执行。在AAA系统内部，NAI以其规范形式通过网络发送，该规范形式用于所有NAI和/或领域比较。
Copying of localized text into fields that can subsequently be placed into the RADIUS User-Name attribute is problematic. This practice can result in a AAA proxy encountering non-UTF-8 characters within what it expects to be an NAI. An example of this requirement is Section 2.1 of [RFC3579], which states:
将本地化文本复制到随后可以放入RADIUS用户名属性的字段中是有问题的。这种做法可能导致AAA代理在其预期的NAI中遇到非UTF-8字符。该要求的一个例子是[RFC3579]第2.1节，其中规定：
the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute
NAS必须将从对等方接收的EAP响应/标识的类型数据字段的内容复制到用户名属性中
As a result, AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to consist of UTF-8 characters, not localized text. Using localized text in AAA username or identity fields means that realm routing becomes difficult or impossible.
因此，AAA代理期望EAP请求者发送的EAP响应/标识的内容由UTF-8字符组成，而不是本地化文本。在AAA用户名或标识字段中使用本地化文本意味着领域路由变得困难或不可能。
In contrast to Section 2.4 of [RFC4282], AAA systems are now expected to perform NAI comparisons, matching, and AAA routing based on the NAI as it is received. This specification provides a canonical representation, ensures that intermediate AAA systems such as proxies are not required to perform translations, and can be expected to work through AAA systems that are unaware of international character sets.
与[RFC4282]的第2.4节不同，AAA系统现在需要根据收到的NAI执行NAI比较、匹配和AAA路由。本规范提供了规范表示，确保中间AAA系统（如代理）不需要执行翻译，并且可以预期通过不知道国际字符集的AAA系统工作。
In an ideal world, the following requirements would be widely implemented:
在理想情况下，将广泛实施以下要求：
* Edge systems using "localized" text SHOULD normalize the NAI prior to it being used as an identifier in an authentication protocol.
* 使用“本地化”文本的边缘系统应在将NAI用作身份验证协议中的标识符之前对其进行规范化。
* AAA systems SHOULD NOT normalize the NAI, as they may not have sufficient information to perform the normalization.
* AAA系统不应规范化NAI，因为它们可能没有足够的信息来执行规范化。
There are issues with this approach, however.
然而，这种方法存在一些问题。
The requirements in the preceding section are not implemented today. For example, most EAP implementations use a user identifier that is passed to them from some other local system. This identifier is treated as an opaque blob and is placed as is into the EAP Identity field. Any subsequent system that receives that identifier is assumed to be able to understand and process it.
上一节中的要求今天未实施。例如，大多数EAP实现使用从其他本地系统传递给它们的用户标识符。此标识符被视为不透明的blob，并按原样放置在EAP标识字段中。任何接收到该标识符的后续系统都假定能够理解和处理该标识符。
This opaque blob unfortunately can contain localized text, which means that the AAA systems have to process that text.
不幸的是，这个不透明的blob可能包含本地化文本，这意味着AAA系统必须处理该文本。
These limitations have the following theoretical and practical implications:
这些限制具有以下理论和实践意义：
* Edge systems used today generally do not normalize the NAI.
* 目前使用的边缘系统通常不规范NAI。
* Therefore, AAA systems SHOULD attempt to normalize the NAI.
* 因此，AAA系统应尝试使NAI正常化。
The suggestions above contradict the suggestions in the previous section. This is the reality of imperfect protocols.
上述建议与上一节中的建议相矛盾。这是不完美协议的现实。
Where the user identifier can be normalized, or determined to be in normal form, the normal form MUST be used as the NAI. In all other circumstances, the user identifier MUST NOT be treated as an NAI. That data is still, however, a user identifier. AAA systems MUST NOT fail authentication simply because the user identifier is not an NAI.
如果用户标识符可以规范化，或确定为标准形式，则标准形式必须用作NAI。在所有其他情况下，用户标识符不得被视为NAI。然而，该数据仍然是用户标识符。AAA系统不能仅仅因为用户标识符不是NAI而导致身份验证失败。
That is, when the realm portion of the NAI is not recognized by a AAA server, it SHOULD try to normalize the NAI into NFC form. That normalized form can then be used to see if the realm matches a known realm. If no match is found, the original form of the NAI SHOULD be used in all subsequent processing.
也就是说，当AAA服务器无法识别NAI的领域部分时，它应该尝试将NAI规范化为NFC形式。然后，可以使用该规范化表单查看领域是否与已知领域匹配。如果未找到匹配项，则应在所有后续处理中使用原始形式的NAI。
The AAA server may also convert realms to Punycode and perform all realm comparisons on the resulting Punycode strings. This conversion follows the recommendations above but may have different operational effects and failure modes.
AAA服务器还可以将领域转换为Punycode，并对生成的Punycode字符串执行所有领域比较。此转换遵循上述建议，但可能具有不同的操作效果和故障模式。
As noted earlier, the NAI format can be used in other, non-AAA protocols. It is RECOMMENDED that the definition given here be used unchanged. Using other definitions for user identifiers may hinder interoperability, along with the user's ability to authenticate successfully. It is RECOMMENDED that protocols requiring the use of a user identifier use the NAI format.
如前所述，NAI格式可用于其他非AAA协议。建议此处给出的定义原封不动地使用。对用户标识符使用其他定义可能会妨碍互操作性以及用户成功进行身份验证的能力。建议需要使用用户标识符的协议使用NAI格式。
This document cannot require other protocols to use the NAI format for user identifiers. Their needs are unknown and, at this time, unknowable. This document suggests that interoperability and inter-domain authentication are useful and should be encouraged.
本文件不能要求其他协议对用户标识符使用NAI格式。他们的需求是未知的，在这个时候，是未知的。本文件表明，互操作性和域间身份验证是有用的，应予以鼓励。
Where a protocol is 8-bit clean, it can likely transport the NAI as is, without further modification.
如果协议是8位干净的，那么它可能可以按原样传输NAI，而无需进一步修改。
Where a protocol is not 8-bit clean, it cannot transport the NAI as is. Instead, this document presumes that a protocol-specific transport layer takes care of encoding the NAI on input to the protocol and decoding it when the NAI exits the protocol. The encoded or escaped version of the NAI is not a valid NAI and MUST NOT be presented to the AAA system.
如果协议不是8位干净的，则不能按原样传输NAI。相反，本文假定特定于协议的传输层负责在协议的输入上对NAI进行编码，并在NAI退出协议时对其进行解码。NAI的编码或转义版本不是有效的NAI，不得提交给AAA系统。
For example, HTTP carries user identifiers but escapes the '.' character as "%2E" (among others). When HTTP is used to transport the NAI "fred@example.com", the data as transported will be in the form "fred@example%2Ecom". That data exists only within HTTP and has no relevance to any AAA system.
例如，HTTP携带用户标识符，但将“.”字符转义为“%2E”（以及其他字符）。使用HTTP传输NAI时“fred@example.com，传输的数据将采用以下格式fred@example%2Ecom”。该数据仅存在于HTTP中，与任何AAA系统都没有关联。
Any comparison, validation, or use of the NAI MUST be done on its unescaped (i.e., utf8-clean) form.
NAI的任何比较、验证或使用都必须在其未扫描（即utf8清洁）表格上完成。
As discussed in Section 1, above, it is RECOMMENDED that the NAI format be used as the standard format for user identifiers. This section discusses that use in more detail.
如上文第1节所述，建议将NAI格式用作用户标识符的标准格式。本节将更详细地讨论该用法。
It is often useful to create new identifiers for use in specific contexts. These identifiers may have a number of different properties, most of which are unimportant to this document. The goal of this document is to create identifiers that are to be in a well-known format and that will have namespaces. The NAI format fits these requirements.
创建用于特定上下文的新标识符通常很有用。这些标识符可能有许多不同的属性，其中大多数对本文档不重要。本文档的目标是创建标识符，这些标识符将采用众所周知的格式，并且将具有名称空间。NAI格式符合这些要求。
One example of such use is the "private user identity", which is an identifier defined by the 3rd Generation Partnership Project (3GPP). That identifier is used to uniquely identify the user to the network. The identifier is used for authorization, authentication, accounting, administration, etc. The "private user identity" is globally unique and is defined by the home network operator. The format of the identifier is explicitly the NAI, as stated by Section 13.3 of [3GPP]:
这种使用的一个例子是“私人用户身份”，它是由第三代合作伙伴关系项目（3GPP）定义的标识符。该标识符用于向网络唯一标识用户。标识符用于授权、身份验证、记帐、管理等。“私人用户标识”是全局唯一的，由家庭网络运营商定义。标识符的格式明确为NAI，如[3GPP]第13.3节所述：
The private user identity shall take the form of an NAI, and shall have the form username@realm as specified in clause 2.1 of IETF RFC 4282
私人用户身份应采用NAI的形式，并应具有username@realm按照IETF RFC 4282第2.1条的规定
For 3GPP, the "username" portion is a unique identifier that is derived from device-specific information. The "realm" portion is composed of information about the home network, followed by the base string "3gppnetwork.org" (e.g., 234150999999999@ims.mnc015.mcc234.3gppnetwork.org).
对于3GPP，“用户名”部分是从设备特定信息派生的唯一标识符。“领域”部分由关于家庭网络的信息组成，后跟基本字符串“3gppnetwork.org”（例如。，234150999999999@ims.mnc015.mcc234.3gppnetwork.org).
This format as defined by 3GPP ensures that the identifier is globally unique, as it is based on the "3gppnetwork.org" domain. It ensures that the "realm" portion is specific to a particular home network (or organization), via the "ims.mnc015.mcc234" prefix to the realm. Finally, it ensures that the "username" portion follows a well-known format.
3GPP定义的这种格式确保标识符是全局唯一的，因为它基于“3gppnetwork.org”域。它通过域的“ims.mnc015.mcc234”前缀确保“域”部分特定于特定的家庭网络（或组织）。最后，它确保“用户名”部分遵循众所周知的格式。
This document suggests that the NAI format be used for all new specifications and/or protocols where a user identifier is required. Where the username portions need to be created with subfields, a well-known and documented method, as has been done with 3GPP, is preferred to ad hoc methods.
本文件建议，所有需要用户标识符的新规范和/或协议均应使用NAI格式。在需要使用子字段创建用户名部分的情况下，与特别方法相比，如3GPP所做的那样，优选众所周知且有文档记录的方法。
Many AAA systems use the "utf8-realm" portion of the NAI to route requests within a AAA proxy network. The semantics of this operation involves a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers.
许多AAA系统使用NAI的“utf8领域”部分在AAA代理网络内路由请求。此操作的语义涉及逻辑AAA路由表，其中“utf8领域”部分充当密钥，表中存储的值是一个或多个“下一跳”AAA服务器。
Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to perform this lookup. As noted earlier, intermediate nodes may not have access to the same locale information as the system that injected the NAI into the AAA routing systems. Therefore, almost all "case insensitive" comparisons can be wrong. Where the "utf8-realm" is entirely ASCII, current AAA systems sometimes perform case-insensitive matching on realms. This method MAY be continued, as it has been shown to work in practice.
中间节点必须使用NAI的“utf8领域”部分，无需修改即可执行此查找。如前所述，中间节点可能无法访问与将NAI注入AAA路由系统的系统相同的区域设置信息。因此，几乎所有“不区分大小写”的比较都可能是错误的。在“utf8领域”完全是ASCII的情况下，当前AAA系统有时会在领域上执行不区分大小写的匹配。这种方法可以继续使用，因为实践证明它是有效的。
Many existing non-AAA systems have user identifiers that are similar in format to the NAI but that are not compliant with this specification. For example, they may use non-NFC form, or they may have multiple "@" characters in the user identifier. Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking up the "utf8-realm" in the logical routing table. Intermediate nodes MUST NOT modify the identifiers that they forward. The data as entered by the user is inviolate.
许多现有的非AAA系统具有与NAI格式相似但不符合本规范的用户标识符。例如，它们可能使用非NFC形式，或者在用户标识符中可能有多个“@”字符。在逻辑路由表中查找“utf8领域”之前，中间节点应该将非NFC标识符规范化为NFC。中间节点不得修改它们转发的标识符。用户输入的数据不受侵犯。
The "utf8-realm" provisioned in the logical AAA routing table SHOULD be provisioned to the proxy prior to it receiving any AAA traffic. The "utf8-realm" SHOULD be supplied by the "next hop" or "home" system that also supplies the routing information necessary for packets to reach the next hop.
逻辑AAA路由表中设置的“utf8领域”应在代理接收任何AAA流量之前设置到代理。“utf8领域”应由“下一跳”或“主”系统提供，该系统还提供数据包到达下一跳所需的路由信息。
This "next hop" information may be any of, or all of, the following information: IP address, port, RADIUS shared secret, TLS certificate, DNS host name, or instruction to use dynamic DNS discovery (i.e., look up a record in the "utf8-realm" domain). This list is not exhaustive and may be extended by future specifications.
此“下一跳”信息可以是以下信息中的任何一个或全部：IP地址、端口、RADIUS共享机密、TLS证书、DNS主机名或使用动态DNS发现的指令（即，在“utf8领域”域中查找记录）。此列表并非详尽无遗，可能会在未来的规范中扩展。
It is RECOMMENDED to use the entirety of the "utf8-realm" for the routing decisions. However, AAA systems MAY use a portion of the "utf8-realm" portion, so long as that portion is a valid "utf8-realm" and is handled as above. For example, routing "fred@example.com" to a "com" destination is forbidden, because "com" is not a valid "utf8-realm". However, routing "fred@sales.example.com" to the "example.com" destination is permissible.
建议使用整个“utf8领域”进行路由决策。但是，AAA系统可以使用“utf8领域”部分的一部分，只要该部分是有效的“utf8领域”，并按上述方式处理。例如，路由“fred@example.com由于“com”不是有效的“utf8领域”，因此禁止向“com”目标发送。然而，路由”fred@sales.example.com到“example.com”目的地是允许的。
Another reason to forbid the use of a single label (e.g., "fred@sales") is that many non-AAA systems treat a single label as being a local identifier within their realm. That is, a user logging in as "fred@sales" to a domain "example.com" would be treated as if the NAI was instead "fred@sales.example.com". Permitting the use of a single label would mean changing the interpretation and meaning of a single label, which cannot be done.
禁止使用单一标签的另一个原因（例如“fred@sales）是指许多非AAA系统将单个标签视为其领域内的本地标识符。也就是说，用户以“身份登录”fred@sales对域“example.com”的访问将被视为NAIfred@sales.example.com". 允许使用单一标签将意味着改变单一标签的解释和含义，这是不可能做到的。
As proposed in this document, the Network Access Identifier is of the form "user@realm". Please note that while the user portion of the NAI is based on the "Internet Message Format" [RFC5322] "local-part" portion of an email address as extended by "Internationalized Email Headers" [RFC6532], it has been modified for the purposes of Section 2.2. It does not permit quoted text along with "folding" or "non-folding" whitespace that is commonly used in email addresses. As such, the NAI is not necessarily equivalent to usernames used in email.
如本文件所述，网络访问标识符的形式为“user@realm". 请注意，虽然NAI的用户部分基于电子邮件地址的“互联网消息格式”[RFC5322]“本地部分”部分，并通过“国际化电子邮件头”[RFC6532]进行扩展，但出于第2.2节的目的，已对其进行了修改。它不允许引用文本以及电子邮件地址中常用的“折叠”或“非折叠”空格。因此，NAI不一定等同于电子邮件中使用的用户名。
However, it is a common practice to use email addresses as user identifiers in AAA systems. The ABNF in Section 2.2 is defined to be close to the "addr-spec" portion of [RFC5322] as extended by [RFC6532], while still being compatible with [RFC4282].
然而，在AAA系统中，通常使用电子邮件地址作为用户标识符。第2.2节中的ABNF定义为接近[RFC5322]的“addr spec”部分（由[RFC6532]扩展），同时仍与[RFC4282]兼容。
In contrast to Section 2.5 of [RFC4282], this document states that the internationalization requirements for NAIs and email addresses are substantially similar. The NAI and email identifiers may be the same, and both need to be entered by the user and/or the operator supplying network access to that user. There is therefore good reason for the internationalization requirements to be similar.
与[RFC4282]第2.5节不同，本文件规定NAI和电子邮件地址的国际化要求基本相似。NAI和电子邮件标识符可以相同，并且两者都需要由用户和/或向该用户提供网络访问的运营商输入。因此，国际化要求类似是有充分理由的。
The "utf8-realm" portion of the NAI is intended to be compatible with Internationalized Domain Names (IDNs) [RFC5890]. As defined above, the "utf8-realm" portion as transported within an 8-bit clean protocol such as RADIUS and EAP can contain any valid UTF-8 character. There is therefore no reason for a NAS to convert the "utf8-realm" portion of an NAI into Punycode encoding form [RFC3492] prior to placing the NAI into a RADIUS User-Name attribute.
NAI的“utf8领域”部分旨在与国际化域名（IDN）兼容[RFC5890]。如上所述，在8位干净协议（如RADIUS和EAP）中传输的“utf8领域”部分可以包含任何有效的UTF-8字符。因此，NAS没有理由在将NAI放入RADIUS用户名属性之前将NAI的“utf8领域”部分转换为Punycode编码形式[RFC3492]。
The NAI does not make a distinction between A-labels and U-labels, as those are terms specific to DNS. It is instead an IDNA-valid label, as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in that section, the term "IDNA-valid label" encompasses both "A-label" and "U-label".
NAI没有对a标签和U标签进行区分，因为这些是特定于DNS的术语。根据[RFC5890]第2.3.2.1节中的第一项，它是IDNA有效标签。如该节所述，“IDNA有效标签”一词包括“A标签”和“U标签”。
When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to Punycode [RFC3492] encoding form as described in [RFC5891]. As noted in Section 2 of [RFC6055], resolver Application Programming Interfaces (APIs) are not necessarily DNS specific, so conversion to Punycode needs to be done carefully:
当NAI的领域部分用作名称解析的基础时，可能需要将国际化领域名称转换为Punycode[RFC3492]编码形式，如[RFC5891]所述。如[RFC6055]第2节所述，解析器应用程序编程接口（API）不一定是特定于DNS的，因此需要小心地转换为Punycode：
Applications that convert an IDN to A-label form before calling (for example) getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. Having libraries or protocols to convert from A-labels to the encoding scheme defined by the protocol (e.g., UTF-8) would require changes to APIs and/or servers, which Internationalized Domain Names for Applications (IDNA) was intended to avoid.
如果在调用（例如）getaddrinfo（）之前将IDN转换为A标签形式的应用程序在此类协议中直接使用Punycode名称，则会导致名称解析失败。要使库或协议从A标签转换为协议（如UTF-8）定义的编码方案，需要对API和/或服务器进行更改，而国际化应用程序域名（IDNA）就是为了避免这种情况。
As a result, applications SHOULD NOT assume that non-ASCII names are resolvable using the public DNS and blindly convert them to A-labels without knowledge of what protocol will be selected by the name resolution library.
因此，应用程序不应假设非ASCII名称可以使用公共DNS解析，并在不知道名称解析库将选择什么协议的情况下盲目地将其转换为a标签。
The home realm usually appears in the "utf8-realm" portion of the NAI, but in some cases a different realm can be used. This may be useful, for instance, when the home realm is reachable only via intermediate proxies.
主领域通常出现在NAI的“utf8领域”部分，但在某些情况下，可以使用不同的领域。例如，当只能通过中间代理访问主域时，这可能很有用。
Such usage may prevent interoperability unless the parties involved have a mutual agreement that the usage is allowed. In particular, NAIs MUST NOT use a different realm than the home realm unless the sender has explicit knowledge that (a) the specified other realm is available and (b) the other realm supports such usage. The sender
这种使用可能会妨碍互操作性，除非相关各方相互同意允许使用。特别是，NAI不得使用与主域不同的域，除非发送方明确知道（a）指定的其他域可用，并且（b）其他域支持此类使用。发送者
may determine the fulfillment of these conditions through a database, dynamic discovery, or other means not specified here. Note that the first condition is affected by roaming, as the availability of the other realm may depend on the user's location or the desired application.
可以通过数据库、动态发现或此处未指定的其他方式确定这些条件的满足情况。请注意，第一个条件受漫游的影响，因为其他领域的可用性可能取决于用户的位置或所需的应用程序。
The use of the home realm MUST be the default unless otherwise configured.
除非另有配置，否则必须默认使用主域。
Some AAA systems have historically used NAI modifications with multiple "prefix" and "suffix" decorations to perform explicit routing through multiple proxies inside of a AAA network.
一些AAA系统历史上使用NAI修改和多个“前缀”和“后缀”修饰，通过AAA网络内的多个代理执行显式路由。
In RADIUS-based environments, the use of decorated NAI is NOT RECOMMENDED for the following reasons:
在基于RADIUS的环境中，不建议使用装饰NAI，原因如下：
* Using explicit routing paths is fragile and is unresponsive to changes in the network due to servers going up or down or to changing business relationships.
* 使用显式路由路径是很脆弱的，并且对由于服务器上升或下降或业务关系变化而导致的网络变化没有响应。
* There is no RADIUS routing protocol, meaning that routing paths have to be communicated "out of band" to all intermediate AAA nodes, and also to all edge systems (e.g., supplicants) expecting to obtain network access.
* 没有RADIUS路由协议，这意味着路由路径必须“带外”通信到所有中间AAA节点，以及所有希望获得网络访问的边缘系统（例如，请求者）。
* Using explicit routing paths requires thousands, if not millions, of edge systems to be updated with new path information when a AAA routing path changes. This adds huge expense for updates that would be better done at only a few AAA systems in the network.
* 使用显式路由路径需要在AAA路由路径更改时使用新路径信息更新数千（如果不是数百万）个边缘系统。这增加了更新的巨大费用，而这些更新最好只在网络中的几个AAA系统上完成。
* Manual updates to RADIUS paths are expensive, time-consuming, and prone to error.
* 对RADIUS路径的手动更新成本高昂、耗时且容易出错。
* Creating compatible formats for the NAI is difficult when locally defined "prefixes" and "suffixes" conflict with similar practices elsewhere in the network. These conflicts mean that connecting two networks may be impossible in some cases, as there is no way for packets to be routed properly in a way that meets all requirements at all intermediate proxies.
* 当本地定义的“前缀”和“后缀”与网络中其他地方的类似实践发生冲突时，为NAI创建兼容格式是很困难的。这些冲突意味着在某些情况下连接两个网络可能是不可能的，因为无法以满足所有中间代理的所有要求的方式正确路由数据包。
* Leveraging the DNS name system for realm names establishes a globally unique namespace for realms.
* 利用域名系统的域名为域名建立一个全局唯一的域名空间。
In summary, network practices and capabilities have changed significantly since NAIs were first overloaded to define AAA routes through a network. While manually managed explicit path routing was once useful, the time has come for better methods to be used.
总之，自从NAI首次过载以定义通过网络的AAA路由以来，网络实践和能力发生了重大变化。虽然手动管理的显式路径路由曾经很有用，但现在是使用更好方法的时候了。
Notwithstanding the above recommendations, the above practice is widely used for Diameter routing [RFC5729]. The routes described there are managed automatically, for both credential provisioning and routing updates. Those routes also exist within a particular framework (typically 3G), where membership is controlled and system behavior is standardized. There are no known issues with using explicit routing in such an environment.
尽管有上述建议，上述实践广泛用于直径布线[RFC5729]。其中描述的路由是自动管理的，用于凭据设置和路由更新。这些路由也存在于特定的框架内（通常为3G），在该框架内，成员资格受到控制，系统行为标准化。在这样的环境中使用显式路由没有已知的问题。
However, if decorated identifiers are used, such as:
但是，如果使用修饰标识符，例如：
homerealm.example.org!user@otherrealm.example.net
homerealm.example.org！user@otherrealm.example.net
then the part before the (non-escaped) '!' MUST be a "utf8-realm" as defined in the ABNF in Section 2.2. When receiving such an identifier, the "otherrealm.example.net" system MUST convert the identifier to "user@homerealm.example.org" before forwarding the request. The forwarding system MUST then apply normal AAA routing for the transaction, based on the updated identifier.
然后是（非转义）“”之前的部分必须是第2.2节ABNF中定义的“utf8领域”。当接收到这样的标识符时，“otherrealm.example.net”系统必须将标识符转换为user@homerealm.example.org“在转发请求之前。然后，转发系统必须基于更新的标识符为事务应用正常AAA路由。
Examples of valid Network Access Identifiers include the following:
有效网络访问标识符的示例包括：
bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.net
bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.net
An additional valid NAI is the following -- shown here as a hex string, as this document can only contain ASCII characters:
另一个有效的NAI如下所示——此处显示为十六进制字符串，因为此文档只能包含ASCII字符：
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
Examples of invalid Network Access Identifiers include the following:
无效网络访问标识符的示例包括：
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.net
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.net
One example given in [RFC4282] is still permitted by the ABNF, but it is NOT RECOMMENDED because of the use of the Punycode [RFC3492] encoding form for what is now a valid UTF-8 string:
ABNF仍然允许[RFC4282]中给出的一个示例，但不建议使用[RFC3492]Punycode编码形式，因为它现在是一个有效的UTF-8字符串：
alice@xn--tmonesimerkki-bfbb.example.net
alice@xn--tmonesimerkki-bfbb.example.net
Since an NAI reveals the home affiliation of a user, it may assist an attacker in further probing the username space. Typically, this problem is of most concern in protocols that transmit the username in clear-text across the Internet, such as in RADIUS [RFC2865] [RFC2866]. In order to prevent snooping of the username, protocols may use confidentiality services provided by protocols transporting them, such as RADIUS protected by IPsec [RFC3579] or Diameter protected by TLS [RFC6733].
由于NAI揭示了用户的家庭从属关系，因此它可能有助于攻击者进一步探测用户名空间。通常，在通过互联网以明文形式传输用户名的协议中，如RADIUS[RFC2865][RFC2866]中，这个问题是最受关注的。为了防止窥探用户名，协议可以使用传输它们的协议提供的保密服务，例如受IPsec[RFC3579]保护的RADIUS或受TLS[RFC6733]保护的Diameter。
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.4, this is possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. In some cases, application-specific privacy mechanisms have also been used with NAIs. For instance, some EAP methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. While neither of these approaches can protect the realm part, their advantage over transport protection is that the privacy of the username is protected, even through intermediate nodes such as NASes.
该规范通过省略用户名部分，增加了在NAI中隐藏用户名部分的可能性。如第2.4节所述，只有当NAI与能够以安全方式传输用户名的单独身份验证方法一起使用时，这才可能实现。在某些情况下，NAI还使用了特定于应用程序的隐私机制。例如，一些EAP方法在NAI[RFC3748]的用户名部分应用特定于方法的假名。虽然这两种方法都不能保护领域部分，但它们相对于传输保护的优势在于用户名的隐私得到保护，即使是通过NASE等中间节点。
The recommendations in Sections 2.7 and 2.8 for using the NAI in other protocols have implications for privacy. Any attacker who is capable of observing traffic containing the NAI can track the user and can correlate his activity across time and across multiple protocols. The authentication credentials therefore SHOULD be
第2.7节和第2.8节中关于在其他协议中使用NAI的建议对隐私有影响。任何能够观察包含NAI的流量的攻击者都可以跟踪用户，并跨时间和跨多个协议关联其活动。因此，身份验证凭据应该是
transported over channels that permit private communications, or multiple identifiers SHOULD be used, so that user tracking is impossible.
通过允许私人通信的信道传输，或应使用多个标识符，因此用户跟踪是不可能的。
It is RECOMMENDED that user privacy be enhanced by configuring multiple identifiers for one user. These identifiers can be changed over time, in order to make user tracking more difficult for a malicious observer. However, provisioning and management of the identifiers may be difficult to do in practice -- a likely reason why multiple identifiers are rarely used today.
建议通过为一个用户配置多个标识符来增强用户隐私。这些标识符可以随着时间的推移而改变，以便使恶意观察者更难跟踪用户。然而，标识符的供应和管理在实践中可能很难做到——这可能是今天很少使用多个标识符的原因。
Section 1.3 states that multiple identifier formats allow attackers to make contradictory claims without being detected. This statement deserves further discussion.
第1.3节指出，多种标识符格式允许攻击者在未被检测到的情况下提出相互矛盾的声明。这一声明值得进一步讨论。
Section 2.4 discussed "inner" and "outer" identifiers in the context of TTLS [RFC5281]. A close reading of that specification shows there is no requirement that the inner and outer identifiers be in any way related. That is, it is perfectly valid to use "@example.com" for an outer identifier and "user@example.org" as an inner identifier. The authentication request will then be routed to "example.com", which will likely be unable to authenticate "user@example.org".
第2.4节讨论了TTL上下文中的“内部”和“外部”标识符[RFC5281]。仔细阅读该规范表明，内部标识符和外部标识符不需要以任何方式相关。也就是说，使用“@example.com”作为外部标识符和user@example.org“作为内部标识符。然后，身份验证请求将被路由到“example.com”，而“example.com”可能无法进行身份验证user@example.org".
Even worse, a misconfiguration of "example.com" means that it may in turn proxy the inner authentication request to the "example.org" domain. Such cross-domain authentication is highly problematic, and there are few good reasons to allow it.
更糟糕的是，“example.com”的错误配置意味着它可能反过来将内部身份验证请求代理到“example.org”域。这种跨域身份验证存在很大问题，并且没有什么好的理由允许它。
It is therefore RECOMMENDED that systems that permit anonymous "outer" identifiers require that the "inner" domain be the same as, or a subdomain of, the "outer" domain. An authentication request using disparate realms is a security violation, and the request SHOULD be rejected.
因此，建议允许匿名“外部”标识符的系统要求“内部”域与“外部”域相同，或是“外部”域的子域。使用不同领域的身份验证请求违反了安全性，应拒绝该请求。
The situation gets worse when multiple protocols are involved. The TTLS protocol permits Microsoft CHAP (MS-CHAP) [RFC2433] to be carried inside of the TLS tunnel. MS-CHAP defines its own identifier, which is encapsulated inside of the MS-CHAP exchange. That identifier is not required to be any particular format, is not required to be in UTF-8, and, in practice, can be one of many unknown character sets. There is no way in practice to determine which character set was used for that identifier.
当涉及多个协议时，情况会变得更糟。TTLS协议允许在TLS隧道内携带Microsoft CHAP（MS-CHAP）[RFC2433]。MS-CHAP定义了自己的标识符，该标识符封装在MS-CHAP交换中。该标识符不需要是任何特定的格式，也不需要是UTF-8格式，而且实际上可以是许多未知字符集中的一个。实际上，无法确定该标识符使用了哪个字符集。
The result is that the "outer" EAP Identity carried by TTLS is likely to not even share the same character set as the "inner" identifier used by MS-CHAP. The two identifiers are entirely independent and fundamentally incomparable.
结果是TTLS携带的“外部”EAP标识甚至可能与MS-CHAP使用的“内部”标识不共享相同的字符集。这两个标识完全独立，从根本上说是不可比较的。
Such a protocol design is NOT RECOMMENDED.
不建议采用这种协议设计。
In order to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace.
为了避免创建任何新的管理过程，NAI领域名称空间的管理依赖于DNS名称空间的管理。
NAI realm names are required to be unique, and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Those wishing to use an NAI realm name should first acquire the rights to use the corresponding FQDN. Administrators MUST NOT publicly use an NAI realm without first owning the corresponding FQDN. Private use of unowned NAI realms within an administrative domain is allowed, though it is RECOMMENDED that example names be used, such as "example.com".
NAI领域名称必须是唯一的，在获得使用特定完全限定域名（FQDN）的权利的同时，还可以获得为漫游目的使用给定NAI领域的权利。希望使用NAI领域名称的用户应首先获得使用相应FQDN的权限。管理员在不首先拥有相应FQDN的情况下，不得公开使用NAI域。允许在管理域内私人使用无主NAI领域，但建议使用示例名称，如“example.com”。
Note that the use of an FQDN as the realm name does not require use of the DNS for location of the authentication server. While Diameter [RFC6733] supports the use of DNS for location of authentication servers, existing RADIUS implementations typically use proxy configuration files in order to locate authentication servers within a domain and perform authentication routing. The implementations described in [RFC2194] did not use DNS for location of the authentication server within a domain. Similarly, existing implementations have not found a need for dynamic routing protocols or propagation of global routing information. Note also that there is no requirement that the NAI represent a valid email address.
请注意，使用FQDN作为域名称并不需要使用DNS作为身份验证服务器的位置。虽然Diameter[RFC6733]支持使用DNS来定位身份验证服务器，但现有RADIUS实现通常使用代理配置文件来定位域内的身份验证服务器并执行身份验证路由。[RFC2194]中描述的实现没有使用DNS来定位域中的身份验证服务器。类似地，现有的实现没有发现对动态路由协议或全局路由信息传播的需求。还要注意的是，没有要求NAI代表有效的电子邮件地址。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008, <http://www.rfc-editor.org/info/rfc5198>.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月<http://www.rfc-editor.org/info/rfc5198>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月<http://www.rfc-editor.org/info/rfc5891>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 63652011年9月<http://www.rfc-editor.org/info/rfc6365>.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997, <http://www.rfc-editor.org/info/rfc2194>.
[RFC2194]Aboba，B.，Lu，J.，Alsop，J.，Ding，J.，和W.Wang，“漫游实施的回顾”，RFC 21941997年9月<http://www.rfc-editor.org/info/rfc2194>.
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998, <http://www.rfc-editor.org/info/rfc2341>.
[RFC2341]Valencia，A.，Littlewood，M.，和T.Kolar，“思科第二层转发（协议）“L2F”，RFC 23411998年5月<http://www.rfc-editor.org/info/rfc2341>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998, <http://www.rfc-editor.org/info/rfc2433>.
[RFC2433]Zorn，G.和S.Cobb，“微软PPP CHAP扩展”，RFC 2433，1998年10月<http://www.rfc-editor.org/info/rfc2433>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999, <http://www.rfc-editor.org/info/rfc2637>.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月<http://www.rfc-editor.org/info/rfc2637>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999, <http://www.rfc-editor.org/info/rfc2661>.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议”L2TP“，RFC 26611999年8月<http://www.rfc-editor.org/info/rfc2661>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月<http://www.rfc-editor.org/info/rfc2866>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003, <http://www.rfc-editor.org/info/rfc3492>.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月<http://www.rfc-editor.org/info/rfc3492>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月<http://www.rfc-editor.org/info/rfc3579>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展身份验证协议（EAP）”，RFC 37482004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005, <http://www.rfc-editor.org/info/rfc4282>.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月<http://www.rfc-editor.org/info/rfc4282>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008, <http://www.rfc-editor.org/info/rfc5281>.
[RFC5281]Funk，P.和S.Blake Wilson，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 52812008年8月<http://www.rfc-editor.org/info/rfc5281>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC5222008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5335] Yang, A., Ed., "Internationalized Email Headers", RFC 5335, September 2008, <http://www.rfc-editor.org/info/rfc5335>.
[RFC5335]Yang，A.，Ed.，“国际化电子邮件头”，RFC 53352008年9月<http://www.rfc-editor.org/info/rfc5335>.
[RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009, <http://www.rfc-editor.org/info/rfc5729>.
[RFC5729]Korhonen，J.，Ed.，Jones，M.，Morand，L.，和T.Tsou，“基于用户名和领域的Diameter请求路由的澄清”，RFC 57292009年12月<http://www.rfc-editor.org/info/rfc5729>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011, <http://www.rfc-editor.org/info/rfc6055>.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月<http://www.rfc-editor.org/info/rfc6055>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 65322012年2月<http://www.rfc-editor.org/info/rfc6532>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基础协议”，RFC 67332012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, April 2013, <http://www.rfc-editor.org/info/rfc6912>.
[RFC6912]Sullivan，A.，Thaler，D.，Klensin，J.，和O.Kolkman，“DNS标签中包含Unicode码点的原则”，RFC 6912013年4月<http://www.rfc-editor.org/info/rfc6912>.
[EDUROAM] "eduroam (EDUcation ROAMing)", <http://eduroam.org>.
[EDUROAM]“EDUROAM（教育漫游）”<http://eduroam.org>.
[3GPP] 3GPP, "Numbering, addressing and Identification", 3GPP TS 23.003, Release 12, July 2014, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[3GPP]3GPP，“编号、寻址和标识”，3GPP TS 23.003，第12版，2014年7月<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
This document contains the following updates with respect to the previous NAI definition in RFC 4282 [RFC4282]:
本文档包含以下关于RFC 4282[RFC4282]中先前NAI定义的更新：
* The formal syntax in Section 2.1 has been updated to forbid non-UTF-8 characters (e.g., characters with the "high bit" set).
* 第2.1节中的正式语法已更新，以禁止非UTF-8字符（例如，具有“高位”集的字符）。
* The formal syntax in Section 2.1 of [RFC4282] has been updated to allow UTF-8 in the "realm" portion of the NAI.
* [RFC4282]第2.1节中的正式语法已经更新，允许在NAI的“领域”部分使用UTF-8。
* The formal syntax in Section 2.1 of [RFC4282] applied to the NAI after it was "internationalized" via the ToAscii function. The contents of the NAI before it was "internationalized" were left indeterminate. This document updates the formal syntax to define an internationalized form of the NAI and forbids the use of the ToAscii function for NAI "internationalization".
* [RFC4282]第2.1节中的正式语法在NAI通过ToAscii函数“国际化”后应用于NAI。NAI在“国际化”之前的内容是不确定的。本文档更新了形式语法，以定义NAI的国际化形式，并禁止将ToAscii函数用于NAI“国际化”。
* The grammar for the user and realm portion is based on a combination of the "nai" defined in Section 2.1 of [RFC4282] and the "utf8-addr-spec" defined in Section 4.4 of [RFC5335].
* 用户和领域部分的语法基于[RFC4282]第2.1节中定义的“nai”和[RFC5335]第4.4节中定义的“utf8地址规范”的组合。
* All use of the ToAscii function has been moved to normal requirements on DNS implementations when realms are used as the basis for DNS lookups. This involves no changes to the existing DNS infrastructure.
* 当领域用作DNS查找的基础时，ToAscii功能的所有使用都已转移到DNS实现的正常要求。这不涉及对现有DNS基础结构的更改。
* The discussions on internationalized character sets in Section 2.4 of [RFC4282] have been updated. The suggestion to use the ToAscii function for realm comparisons has been removed. No AAA system has implemented these suggestions, so this change should have no operational impact.
* [RFC4282]第2.4节中关于国际化字符集的讨论已经更新。删除了使用ToAscii函数进行领域比较的建议。没有AAA系统实施了这些建议，因此这一变化应该不会对运营产生影响。
* The "Routing inside of AAA Systems" section is new in this document. The concept of a "local AAA routing table" is also new, although it accurately describes the functionality of widespread implementations.
* “AAA系统内部路由”部分在本文档中是新的。“本地AAA路由表”的概念也是新的，尽管它准确地描述了广泛实现的功能。
* The "Compatibility with EMail Usernames" and "Compatibility with DNS" sections have been revised and updated. The Punycode transformation is suggested to be used only when a realm name is used for DNS lookups, and even then the function is only used by a resolving API on the local system, and even then it is recommended that only the home network perform this conversion.
* “与电子邮件用户名的兼容性”和“与DNS的兼容性”部分已经修订和更新。建议仅当域名用于DNS查找时才使用Punycode转换，即使如此，该函数也仅由本地系统上的解析API使用，即使如此，建议仅由家庭网络执行此转换。
* The "Realm Construction" section has been updated to note that editing of the NAI is NOT RECOMMENDED.
* “领域构造”部分已经更新，注意不建议编辑NAI。
* The "Examples" section has been updated to remove the instance of the IDN being converted to ASCII. This behavior is now forbidden.
* “示例”部分已更新，以删除正在转换为ASCII的IDN实例。这种行为现在是被禁止的。
Acknowledgments
致谢
The initial text for this document was [RFC4282], which was then heavily edited. The original authors of [RFC4282] were Bernard Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
本文件的初始文本为[RFC4282]，随后进行了大量编辑。[RFC4282]的原始作者是伯纳德·阿博巴、马克·A·比德尔、贾里·阿尔科和帕西·埃隆。
Author's Address
作者地址
Alan DeKok The FreeRADIUS Server Project
Alan DeKok FreeRADIUS服务器项目
EMail: aland@freeradius.org
EMail: aland@freeradius.org