Network Working Group B. Aboba
Request for Comments: 4282 Microsoft
Obsoletes: 2486 M. Beadles
Category: Standards Track ENDFORCE
J. Arkko
Ericsson
P. Eronen
Nokia
December 2005
Network Working Group B. Aboba
Request for Comments: 4282 Microsoft
Obsoletes: 2486 M. Beadles
Category: Standards Track ENDFORCE
J. Arkko
Ericsson
P. Eronen
Nokia
December 2005
The Network Access Identifier
网络访问标识符
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may 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 where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC.
为了提供漫游服务，必须有一种标准化的用户识别方法。本文档定义了网络访问标识符（NAI）的语法，NAI是客户端在网络身份验证期间提交的用户标识。“漫游”可以粗略地定义为能够使用多个互联网服务提供商（ISP）中的任何一个，同时只与一个ISP保持正式的客户-供应商关系。可能需要漫游功能的示例包括ISP“联盟”和ISP提供的公司网络访问支持。本文件是RFC 2486的修订版，最初定义了NAIs。增强功能包括国际字符集和隐私支持，以及对原始RFC的一些更正。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................4
1.3. Purpose ....................................................4
2. NAI Definition ..................................................4
2.1. Formal Syntax ..............................................4
2.2. NAI Length Considerations ..................................6
2.3. Support for Username Privacy ...............................6
2.4. International Character Sets ...............................7
2.5. Compatibility with E-Mail Usernames ........................8
2.6. Compatibility with DNS .....................................8
2.7. Realm Construction .........................................8
2.8. Examples ..................................................10
3. Security Considerations ........................................10
4. IANA Considerations ............................................11
5. References .....................................................11
5.1. Normative References ......................................11
5.2. Informative References ....................................12
Appendix A. Changes from RFC 2486 ................................14
Appendix B. Acknowledgements .....................................14
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................4
1.3. Purpose ....................................................4
2. NAI Definition ..................................................4
2.1. Formal Syntax ..............................................4
2.2. NAI Length Considerations ..................................6
2.3. Support for Username Privacy ...............................6
2.4. International Character Sets ...............................7
2.5. Compatibility with E-Mail Usernames ........................8
2.6. Compatibility with DNS .....................................8
2.7. Realm Construction .........................................8
2.8. Examples ..................................................10
3. Security Considerations ........................................10
4. IANA Considerations ............................................11
5. References .....................................................11
5.1. Normative References ......................................11
5.2. Informative References ....................................12
Appendix A. Changes from RFC 2486 ................................14
Appendix B. Acknowledgements .....................................14
Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included the following:
人们对适合网络访问的“漫游能力”这一一般类别的一组功能非常感兴趣，包括拨号Internet用户、虚拟专用网络（VPN）使用、无线LAN身份验证和其他应用程序。有兴趣的人士包括：
o 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.
o 区域互联网服务提供商（ISP）在特定州或省内运营，希望与其他区域提供商合作，在更大范围内提供拨号服务。
o National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent.
o 希望将其业务与另一个国家的一家或多家ISP的业务结合起来，以便在一组国家或一个大陆上提供更全面的拨号服务的国家ISP。
o Wireless LAN hotspots providing service to one or more ISPs.
o 向一个或多个ISP提供服务的无线LAN热点。
o 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
o 希望在全球范围内为员工提供全面的拨号服务的企业。这些服务可能包括互联网访问以及通过VPN安全访问公司内部网，通过隧道协议（如
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 [RFC2401].
点对点隧道协议（PPTP）[RFC2637]、第二层转发（L2F）协议[RFC2341]、第二层隧道协议（L2TP）[RFC2661]和IPsec隧道模式[RFC2401]。
In order to enhance the interoperability of roaming 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]。
This document is a revised version of RFC 2486 [RFC2486], which originally defined NAIs. Differences and enhancements compared to RFC 2486 are listed in Appendix A.
本文件是RFC 2486[RFC2486]的修订版，最初定义了NAIs。附录A中列出了与RFC 2486相比的差异和增强。
This document frequently uses the following terms:
本文件经常使用以下术语：
Network Access Identifier
网络访问标识符
The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity 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提供的公司网络访问支持。
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）安全访问公司内部网。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”应按照[RFC2119]中所述进行解释。
As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.
如[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作为打开新隧道过程的一部分，以确定隧道终点。
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC4234]. The grammar for the username is based on [RFC0821], and the grammar for the realm is an updated version of [RFC1035].
NAI的语法如下所示，如[RFC4234]中所述，以增广的巴科斯诺尔形式（ABNF）描述。用户名的语法基于[RFC0821]，领域的语法是[RFC1035]的更新版本。
nai = username
nai =/ "@" realm
nai =/ username "@" realm
nai = username
nai =/ "@" realm
nai =/ username "@" realm
username = dot-string
dot-string = string
dot-string =/ dot-string "." string
string = char
string =/ string char
char = c
char =/ "\" x
username = dot-string
dot-string = string
dot-string =/ dot-string "." string
string = char
string =/ string char
char = c
char =/ "\" x
c = %x21 ; '!' allowed
; '"' not allowed
c =/ %x23 ; '#' allowed
c =/ %x24 ; '$' allowed
c =/ %x25 ; '%' allowed
c =/ %x26 ; '&' allowed
c =/ %x27 ; ''' allowed
; '(', ')' not allowed
c =/ %x2A ; '*' allowed
c =/ %x2B ; '+' allowed
; ',' not allowed
c =/ %x2D ; '-' allowed
; '.' not allowed
c =/ %x2F ; '/' allowed
c =/ %x30-39 ; '0'-'9' allowed
; ';', ':', '<' not allowed
c =/ %x3D ; '=' allowed
; '>' not allowed
c =/ %x3F ; '?' allowed
; '@' not allowed
c =/ %x41-5a ; 'A'-'Z' allowed
; '[', '\', ']' not allowed
c =/ %x5E ; '^' allowed
c =/ %x5F ; '_' allowed
c =/ %x60 ; '`' allowed
c =/ %x61-7A ; 'a'-'z' allowed
c =/ %x7B ; '{' allowed
c =/ %x7C ; '|' allowed
c =/ %x7D ; '}' allowed
c =/ %x7E ; '~' allowed
; DEL not allowed
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
c = %x21 ; '!' allowed
; '"' not allowed
c =/ %x23 ; '#' allowed
c =/ %x24 ; '$' allowed
c =/ %x25 ; '%' allowed
c =/ %x26 ; '&' allowed
c =/ %x27 ; ''' allowed
; '(', ')' not allowed
c =/ %x2A ; '*' allowed
c =/ %x2B ; '+' allowed
; ',' not allowed
c =/ %x2D ; '-' allowed
; '.' not allowed
c =/ %x2F ; '/' allowed
c =/ %x30-39 ; '0'-'9' allowed
; ';', ':', '<' not allowed
c =/ %x3D ; '=' allowed
; '>' not allowed
c =/ %x3F ; '?' allowed
; '@' not allowed
c =/ %x41-5a ; 'A'-'Z' allowed
; '[', '\', ']' not allowed
c =/ %x5E ; '^' allowed
c =/ %x5F ; '_' allowed
c =/ %x60 ; '`' allowed
c =/ %x61-7A ; 'a'-'z' allowed
c =/ %x7B ; '{' allowed
c =/ %x7C ; '|' allowed
c =/ %x7D ; '}' allowed
c =/ %x7E ; '~' allowed
; DEL not allowed
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
realm = 1*( label "." ) label
label = let-dig *(ldh-str)
realm = 1*( label "." ) label
label = let-dig *(ldh-str)
ldh-str = *( alpha / digit / "-" ) let-dig
let-dig = alpha / digit
alpha = %x41-5A ; 'A'-'Z'
alpha =/ %x61-7A ; 'a'-'z'
digit = %x30-39 ; '0'-'9'
ldh-str = *( alpha / digit / "-" ) let-dig
let-dig = alpha / digit
alpha = %x41-5A ; 'A'-'Z'
alpha =/ %x61-7A ; 'a'-'z'
digit = %x30-39 ; '0'-'9'
Devices handling NAIs MUST support an NAI length of at least 72 octets. Support for an NAI length of 253 octets is RECOMMENDED. However, the following implementation issues should be considered:
处理NAI的设备必须支持至少72个八位字节的NAI长度。建议支持253个八位字节的NAI长度。但是，应考虑以下实施问题：
o NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, RFC 2865 [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 be included in a RADIUS message and the maximum attribute length is 253 octets; RADIUS is unable to support NAI lengths beyond 253 octets.
o NAI通常在远程身份验证拨入用户服务（RADIUS）协议的用户名属性中传输。不幸的是，RFC 2865[RFC2865]第5.1节规定“建议至少处理63个八位字节的能力”。因此，可能无法通过所有设备传输超过63个八位字节的NAI。此外，由于RADIUS消息中仅可包括单个用户名属性，且最大属性长度为253个八位字节；RADIUS无法支持NAI长度超过253个八位字节。
o NAIs can also be transported in the User-Name attribute of Diameter [RFC3588], which supports content lengths up to 2^24 - 9 octets. As a result, NAIs processed only by Diameter nodes can be very long. Unfortunately, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations apply.
o NAI还可以在Diameter[RFC3588]的用户名属性中传输，该属性支持最长为2^24-9个八位字节的内容长度。因此，仅由直径节点处理的NAI可能非常长。不幸的是，通过直径传输的NAI最终可能转换为半径，在这种情况下，上述限制适用。
Interpretation of the username part of the NAI depends on the realm in question. Therefore, the "username" part SHOULD be treated as opaque data when processed by nodes that are not a part of the authoritative domain (in the sense of Section 4) for that realm.
NAI用户名部分的解释取决于所讨论的领域。因此，当由不属于该领域的权威域（在第4节的意义上）的节点处理时，“用户名”部分应被视为不透明数据。
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 it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user.
在某些情况下，NAI与单独的身份验证方法一起使用，该方法可以以更安全的方式传输用户名部分，以增加隐私。在这种情况下，可以通过省略用户名部分以缩写形式提供NAI。与使用固定用户名部分（如“匿名”）相比，建议省略用户名部分，因为它提供了一种明确的方法来确定用户名是否用于唯一标识单个用户。
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, the realm
出于漫游目的，通常需要为给定NAI找到适当的后端身份验证服务器，然后才能继续身份验证对话。因此，该领域
portion is typically required in order for the authentication exchange to be routed to the appropriate server.
部分通常是必需的，以便将身份验证交换路由到适当的服务器。
This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8 and processed with a certain algorithm to ensure a canonical representation. Internationalization of the realm portion of the NAI is based on "Internationalizing Domain Names in Applications (IDNA)" [RFC3490].
此规范允许使用国际用户名和领域。国际用户名基于Unicode字符的使用，编码为UTF-8，并使用特定算法进行处理，以确保规范化表示。NAI领域部分的国际化基于“应用程序中的域名国际化（IDNA）”[RFC3490]。
In order to ensure a canonical representation, characters of the username portion in an NAI MUST fulfill the ABNF in this specification as well as the requirements specified in [RFC4013]. These requirements consist of the following:
为了确保规范表示，NAI中用户名部分的字符必须满足本规范中的ABNF以及[RFC4013]中规定的要求。这些要求包括以下内容：
o Mapping requirements, as specified in Section 2.1 of [RFC4013]. Mapping consists of mapping certain characters to others (such as SPACE) in order to increase the likelihood of correctly performed comparisons.
o [RFC4013]第2.1节规定的制图要求。映射包括将某些字符映射到其他字符（如空格），以增加正确执行比较的可能性。
o Normalization requirements, as specified in Section 2.2 of [RFC4013], are also designed to assist in comparisons.
o [RFC4013]第2.2节中规定的规范化要求也旨在帮助进行比较。
o Prohibited output. Certain characters are not permitted in correctly formed strings that follow Section 2.3 of [RFC4013]. Ensuring that NAIs conform to their ABNF is not sufficient; it is also necessary to ensure that they do not contain prohibited output.
o 禁止输出。[RFC4013]第2.3节之后格式正确的字符串中不允许使用某些字符。确保NAI符合其ABNF是不够的；还必须确保它们不包含禁止输出。
o Bidirectional characters are handled as specified in Section 2.4 of [RFC4013].
o 双向字符按照[RFC4013]第2.4节的规定进行处理。
o Unassigned code points are specified in Section 2.5 of [RFC4013]. The use of unassigned code points is prohibited.
o [RFC4013]第2.5节规定了未分配代码点。禁止使用未分配的代码点。
The mapping, normalization, and bidirectional character processing MUST be performed by end systems that take international text as input. In a network access setting, such systems are typically the client and the Authentication, Authorization, and Accounting (AAA) server. NAIs are sent over the wire in their canonical form, and tasks such as normalization do not typically need to be performed by nodes that just pass NAIs around or receive them from the network. End systems MUST also perform checking for prohibited output and unassigned code points. Other systems MAY perform such checks, when they know that a particular data item is an NAI.
映射、规范化和双向字符处理必须由接收国际文本作为输入的终端系统执行。在网络访问设置中，此类系统通常是客户端和身份验证、授权和计费（AAA）服务器。NAI以其规范形式通过网络发送，而诸如规范化之类的任务通常不需要由仅传递NAI或从网络接收NAI的节点来执行。终端系统还必须执行禁止输出和未分配代码点的检查。当其他系统知道特定数据项是NAI时，可以执行此类检查。
The realm name is an "IDN-unaware domain name slot" as defined in [RFC3490]. That is, it can contain only ASCII characters. An implementation MAY support Internationalized Domain Names (IDNs) using the ToASCII operation; see [RFC3490] for more information.
领域名称是[RFC3490]中定义的“IDN未知域名槽”。也就是说，它只能包含ASCII字符。一个实现可以支持使用ToASCII操作的国际化域名（idn）；有关更多信息，请参阅[RFC3490]。
The responsibility for the conversion of internationalized domain names to ASCII is left for the end systems, such as network access clients and AAA servers. Similarly, we expect domain name comparisons, matching, resolution, and AAA routing to be performed on the ASCII versions of the internationalized domain names. This provides a canonical representation, ensures that intermediate systems such as AAA proxies do not need to perform translations, and can be expected to work through systems that are unaware of international character sets.
将国际化域名转换为ASCII的责任留给终端系统，如网络访问客户端和AAA服务器。类似地，我们期望在国际化域名的ASCII版本上执行域名比较、匹配、解析和AAA路由。这提供了一种规范表示，确保诸如AAA代理之类的中间系统不需要执行翻译，并且可以预期在不知道国际字符集的系统中工作。
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 BNF described in [RFC0821], it has been extended for internationalization support as well as for purposes of Section 2.7, and is not necessarily compatible with the usernames used in e-mail. Note also that the internationalization requirements for NAIs and e-mail addresses are different, since the former need to be typed in only by the user himself and his own operator, not by others.
如本文件所述，网络访问标识符的形式如下user@realm. 请注意，虽然NAI的用户部分基于[RFC0821]中所述的BNF，但为了国际化支持以及第2.7节的目的，对其进行了扩展，并且不一定与电子邮件中使用的用户名兼容。还要注意的是，NAI和电子邮件地址的国际化要求是不同的，因为前者只需要用户自己和自己的操作员输入，而不需要其他人输入。
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035]. This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035], Fully Qualified Domain Names (FQDNs) such as 3com.com are commonly used and accepted by current software.
领域部分的BNF允许领域以数字开头，这是[RFC1035]中描述的BNF所不允许的。这一变化是为了反映当前的做法；尽管[RFC1035]中所述的BNF不允许使用完全限定域名（FQDN），如3com.com，但目前的软件普遍使用和接受。
NAIs are used, among other purposes, for routing AAA transactions to the user's home realm. Usually, the home realm appears in the 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 another mediating realm.
除其他用途外，NAI用于将AAA事务路由到用户的主域。通常，主领域出现在NAI的领域部分，但在某些情况下，可以使用不同的领域。例如，当只能通过另一个中介领域访问主领域时，这可能很有用。
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.
除非另有配置，否则必须默认使用主域。
Where these conditions are fulfilled, an NAI such as
如果满足这些条件，则NAI，如
user@homerealm.example.net
user@homerealm.example.net
MAY be represented as in
可表示为
homerealm.example.net!user@otherrealm.example.net
homerealm.example.net！user@otherrealm.example.net
In this case, the part before the (non-escaped) '!' MUST be a realm name as defined in the ABNF in Section 2.1. This realm name is an "IDN-unaware domain name slot", just like the realm name after the "@" character; see Section 2.4 for details. When receiving such an NAI, the other realm MUST convert the format back to "user@homerealm.example.net" when passing the NAI forward, as well as applying appropriate AAA routing for the transaction.
在本例中，位于（非转义）“”之前的零件必须是第2.1节ABNF中定义的领域名称。此域名是一个“IDN未知域名槽”，就像“@”字符后面的域名一样；详见第2.4节。当接收到这样的NAI时，另一个领域必须将格式转换回“user@homerealm.example.net“转发NAI时，以及为事务应用适当的AAA路由时。
The conversion process may apply also recursively. That is, after the conversion, the result may still have one or more '!' characters in the username. For instance, the NAI
转换过程也可以递归地应用。也就是说，在转换之后，结果可能仍然有一个或多个'！'用户名中的字符。例如，NAI
other2.example.net!home.example.net!user@other1.example.net
other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to
将首先在other1.example.net中转换为
home.example.net!user@other2.example.net
home.example.net！user@other2.example.net
and then at other2.example.net finally to
然后在other2.example.net上
user@homerealm.example.net
user@homerealm.example.net
Note that the syntax described in this section is optional and is not a part of the ABNF. The '!' character may appear in the username portion of an NAI for other purposes as well, and in those cases, the rules outlined here do not apply; the interpretation of the username is up to an agreement between the identified user and the realm given after the '@' character.
请注意，本节中描述的语法是可选的，不是ABNF的一部分。“！”字符可能出于其他目的出现在NAI的用户名部分，在这些情况下，此处概述的规则不适用；用户名的解释取决于标识的用户和在“@”字符后给出的领域之间的协议。
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
alice@xn--tmonesimerkki-bfbb.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
alice@xn--tmonesimerkki-bfbb.example.net
The last example uses an IDN converted into an ASCII representation.
最后一个示例使用转换为ASCII表示形式的IDN。
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
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, described in [RFC2865] and [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 [RFC3588].
由于NAI揭示了用户的家庭从属关系，因此它可能有助于攻击者进一步探测用户名空间。通常，这个问题在通过互联网以明文形式传输用户名的协议中最受关注，如[RFC2865]和[RFC2866]中所述的RADIUS协议。为了防止窥探用户名，协议可以使用传输它们的协议提供的保密服务，例如受IPsec[RFC3579]保护的RADIUS或受TLS[RFC3588]保护的Diameter。
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.3, 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 mechanism have
该规范通过省略用户名部分，增加了在NAI中隐藏用户名部分的可能性。如第2.3节所述，只有当NAI与能够以安全方式传输用户名的单独身份验证方法一起使用时，这才可能实现。在某些情况下，特定于应用程序的隐私机制
also been used with NAIs. For instance, some Extensible Authentication Protocol (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 privacy of the username is protected, even through intermediate nodes such as NASes.
也用于NAIs。例如，一些可扩展身份验证协议（EAP）方法在NAI[RFC3748]的用户名部分应用特定于方法的假名。虽然这两种方法都不能保护领域部分，但它们相对于传输保护的优势在于，用户名的隐私受到保护，即使是通过NASE等中间节点。
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. Using an NAI realm without ownership of the corresponding FQDN creates the possibility of conflict and therefore is to be discouraged.
NAI领域名称必须是唯一的，在获得使用特定完全限定域名（FQDN）的权利的同时，还可以获得为漫游目的使用给定NAI领域的权利。希望使用NAI领域名称的用户应首先获得使用相应FQDN的权限。使用没有相应FQDN所有权的NAI领域可能会产生冲突，因此不鼓励使用。
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 [RFC3588] 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[RFC3588]支持使用DNS来定位身份验证服务器，但现有RADIUS实现通常使用代理配置文件来定位域内的身份验证服务器并执行身份验证路由。[RFC2194]中描述的实现没有使用DNS来定位域中的身份验证服务器。类似地，现有的实现没有发现对动态路由协议或全局路由信息传播的需求。还要注意的是，没有要求NAI代表有效的电子邮件地址。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[RFC2194]Aboba，B.，Lu，J.，Alsop，J.，Ding，J.，和W.Wang，“漫游实施回顾”，RFC 2194，1997年9月。
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2341]Valencia，A.，Littlewood，M.，和T.Kolar，“思科第二层转发（协议）“L2F”，RFC 23411998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和G.Zorn，“点对点隧道协议”，RFC 2637，1999年7月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection Problem", Work in Progress, October 2005.
[netsel问题]Arkko，J.和B.Aboba，“网络发现和选择问题”，正在进行的工作，2005年10月。
This document contains the following updates with respect to the original NAI definition in RFC 2486 [RFC2486]:
本文件包含以下关于RFC 2486[RFC2486]中原始NAI定义的更新：
o International character set support has been added for both usernames and realms. Note that this implies character codes 128 - 255 may be used in the username portion, which may be unacceptable to nodes that only support RFC 2486. Many devices already allow this behaviour, however.
o 已为用户名和域添加了国际字符集支持。注意，这意味着用户名部分可能使用字符代码128-255，这对于仅支持RFC 2486的节点来说可能是不可接受的。然而，许多设备已经允许这种行为。
o Username privacy support has been added. Note that NAIs without a username (for privacy) may not be acceptable to RFC 2486-compliant nodes. Many devices already allow this behaviour, however.
o 已添加用户名隐私支持。请注意，不带用户名的NAI（出于隐私）可能不被符合RFC 2486的节点接受。然而，许多设备已经允许这种行为。
o A recommendation to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. Note that long NAIs may not be acceptable to RFC 2486-compliant nodes.
o 增加了支持至少253个八位字节的NAI长度的建议，并讨论了本规范中NAI长度与各种AAA协议之间的兼容性考虑。请注意，符合RFC 2486的节点可能不接受长NAI。
o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [netsel-problem]. Rather, it is intended as a clarification of RFC 2486.
o 中介网络语法及其含义已被充分描述，而不仅仅作为示例给出。请注意，此语法并不是针对[netsel problem]中定义的网络发现和选择需求的完整解决方案。相反，它旨在澄清RFC 2486。
However, as discussed in Section 2.7, this specification requires that this syntax be applied only when there is explicit knowledge that the peer system supports such syntax.
但是，如第2.7节所述，本规范要求仅当明确知道对等系统支持这种语法时，才应用这种语法。
o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification.
o 领域BNF条目定义已更改，以避免原始规范中出现错误（无限递归）。
o Several clarifications and improvements have been incorporated into the ABNF specification for NAIs.
o ABNF NAIs规范中包含了一些澄清和改进。
Thanks to Glen Zorn for many useful discussions of this problem space, and to Farid Adrangi for suggesting the representation of mediating networks in NAIs. Jonathan Rosenberg reported the BNF error. Dale Worley suggested clarifications of the x and special BNF entries. Arne Norefors reported the length differences between RFC 2486 and RFC 2865. Paul Hoffman helped with the international character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam Hartman, and Richard Perlman provided many useful comments on this
感谢格伦·佐恩（Glen Zorn）对这个问题空间进行了许多有益的讨论，感谢法里德·阿德兰吉（Farid Adrangi）建议在NAIs中代表中介网络。Jonathan Rosenberg报告了BNF错误。Dale Worley建议对x和特殊BNF条目进行澄清。Arne Norefors报告了RFC 2486和RFC 2865之间的长度差异。保罗·霍夫曼帮助处理国际角色设置问题。Kalle Tammela、Stefaan De Cnodder、Nagi Jonnala、Bert Wijnen、Blair Bullock、Yoshihiro Ohba、Ignacio Goyret、John Loughney、Henrik Levkowetz、Ted Hardie、Bill Fenner、Sam Hartman和Richard Perlman对此提供了许多有用的评论
document. The ABNF validator at http://www.apps.ietf.org/abnf.html was used to verify the syntactic correctness of the ABNF in Section 2.1.
文件ABNF验证器位于http://www.apps.ietf.org/abnf.html 用于验证第2.1节中ABNF的语法正确性。
Authors' Addresses
作者地址
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
Bernard Aboba微软一路微软美国华盛顿州雷德蒙98052
EMail: bernarda@microsoft.com
EMail: bernarda@microsoft.com
Mark A. Beadles ENDFORCE 565 Metro Place South Suite 300 Dublin OH 43017 USA
Mark A.Beadles ENDFORCE 565 Metro Place South套房300美国俄亥俄州都柏林43017
EMail: mbeadles@endforce.com
EMail: mbeadles@endforce.com
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。