| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright © The Internet Society (2005).
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.
1.
Introduction
1.1
Terminology
1.2
Requirements language
1.3
Purpose
2.
NAI Definition
2.1
Formal Syntax
2.2
NAI Length Considerations
2.3
Support for Username Privacy
2.4
International Character Sets
2.5
Compatibility with E-Mail Usernames
2.6
Compatibility with DNS
2.7
Realm Construction
2.8
Examples
3.
Security Considerations
4.
IANA Considerations
5.
References
5.1
Normative References
5.2
Informative References
§
Authors' Addresses
A.
Changes from RFC 2486
B.
Acknowledgements
§
Intellectual Property and Copyright Statements
| TOC |
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:
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] (Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, “Review of Roaming Implementations,” September 1997.).
This document is a revised version of RFC 2486 (Aboba, B. and M. Beadles, “The Network Access Identifier,” January 1999.)[RFC2486] which originally defined NAIs. Differences and enhancements compared to RFC 2486 are listed in Appendix A (Changes from 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.
- 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.
- 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.
- 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).
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
As described in [RFC2194] (Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, “Review of Roaming Implementations,” September 1997.), there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly.
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.
| TOC |
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC2234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.). The grammar for the username is based on [RFC0821] (Postel, J., “Simple Mail Transfer Protocol,” August 1982.), and the grammar for the realm is an updated version of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.).
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
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
; [I-D.ietf-sasl-saslprep]).
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)
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:
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 (IANA Considerations)) for that realm.
In some situations NAIs are 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.
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 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. The realm part internationalization is based on International Domain Name (IDN) [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.).
In order to ensure a canonical representation, characters of the username portion in an NAI MUST fulfill both the ABNF in this specification as well as the requirements specified in [I-D.ietf-sasl-saslprep] (Zeilenga, K., “SASLprep: Stringprep profile for user names and passwords,” July 2004.). These requirements consist of the following:
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 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 a NAI.
The realm name is an "IDN-unaware domain name slot" as defined in [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.). That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) for more information.
The responsibility for the conversion of international 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 international 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.
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] (Postel, J., “Simple Mail Transfer Protocol,” August 1982.), it has been extended for internationalization support as well as for purposes of Section 2.7 (Realm Construction), 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.
The BNF of the realm portion allows the realm to begin with a digit, which is not permitted by the BNF described in [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). This change was made to reflect current practice; although not permitted by the BNF described in [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.), FQDNs such as 3com.com are commonly used, and accepted by current software.
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 only reachable via another mediating realm.
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 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
user@homerealm.example.net
MAY be represented as in
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 (Formal Syntax). This realm name is an "IDN-unaware domain name slot", just like the realm name after the "@" character; see Section 2.4 (International Character Sets) 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.
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
other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to
home.example.net!user@other2.example.net
and then at other2.example.net finally to
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 a 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.
Examples of valid Network Access Identifiers include:
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
alice@xn--tmonesimerkki-bfbb.example.net
\(user\)@example.net
The last example uses an IDN converted into an ASCII representation.
Examples of invalid Network Access Identifiers include:
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
| TOC |
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 which transmit the user name in clear-text across the Internet, such as in RADIUS, described in [RFC2865] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) and [RFC2866] (Rigney, C., “RADIUS Accounting,” June 2000.). In order to prevent snooping of the user name, protocols may use confidentiality services provided by protocols transporting them, such RADIUS protected by IPsec [RFC3579] (Aboba, B. and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP),” September 2003.) or Diameter protected by TLS [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).
This specification adds the possibility of hiding the username part in the NAI, by omitting it. As discussed in Section 2.3 (Support for Username Privacy), 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 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] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.). 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.
| TOC |
In order to to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace.
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.
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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) 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] (Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, “Review of Roaming Implementations,” September 1997.) 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 that the NAI represent a valid email address.
| TOC |
| TOC |
| [RFC1035] | Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987. |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (HTML, XML). |
| [RFC2234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997. |
| [RFC3490] | Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003. |
| [I-D.ietf-sasl-saslprep] | Zeilenga, K., “SASLprep: Stringprep profile for user names and passwords,” draft-ietf-sasl-saslprep-10 (work in progress), July 2004. |
| TOC |
| TOC |
| Bernard Aboba | |
| Microsoft | |
| One Microsoft Way | |
| Redmond, WA 98052 | |
| USA | |
| Email: | bernarda@microsoft.com |
| Mark A. Beadles | |
| SmartPipes | |
| 565 Metro Place South Suite 300 | |
| Dublin OH 43017 | |
| USA | |
| Email: | mbeadles@smartpipes.com |
| Jari Arkko | |
| Ericsson | |
| Jorvas 02420 | |
| Finland | |
| Email: | jari.arkko@ericsson.com |
| Pasi Eronen | |
| Nokia Research Center | |
| P.O. Box 407 | |
| FIN-00045 Nokia Group | |
| Finland | |
| Email: | pasi.eronen@nokia.com |
| TOC |
This draft contains the following updates with respect to the original NAI definition in RFC 2486 (Aboba, B. and M. Beadles, “The Network Access Identifier,” January 1999.)[RFC2486]:
| TOC |
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 draft. 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 (Formal Syntax).
| TOC |
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.
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.
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.
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.
Copyright © The Internet Society (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.
Funding for the RFC Editor function is currently provided by the Internet Society.