--- 1/draft-ietf-radext-rfc2486bis-02.txt 2006-02-05 01:15:45.000000000 +0100 +++ 2/draft-ietf-radext-rfc2486bis-03.txt 2006-02-05 01:15:46.000000000 +0100 @@ -1,22 +1,23 @@ + Network Working Group B. Aboba Internet-Draft Microsoft -Expires: May 5, 2005 M. Beadles - SmartPipes +Obsoletes: 2486 (if approved) M. Beadles +Expires: May 2, 2005 SmartPipes J. Arkko Ericsson P. Eronen Nokia - November 4, 2004 + November 2004 The Network Access Identifier - draft-ietf-radext-rfc2486bis-02 + draft-ietf-radext-rfc2486bis-03 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. @@ -29,34 +30,34 @@ 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 May 5, 2005. + This Internet-Draft will expire on May 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 + 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -71,49 +72,50 @@ 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 5.2 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 - A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 12 - B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 13 + B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 1. Introduction Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, - including dialup Internet users, VPN usage, wireless LAN - authentication, and other applications. Interested parties have - included: + including dialup Internet users, Virtual Private Network (VPN) usage, + wireless LAN authentication, and other applications. Interested + parties have included: 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 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 Wireless LAN hotspots providing service to one or more ISPs. 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 Virtual Private Network (VPN), enabled by - tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel - mode. + intranets via a VPN, enabled by tunneling protocols such as + Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 + Forwarding (L2F) protocol [RFC2341], Layer 2 Tunneling Protocol + (L2TP) [RFC2661], and IPsec tunnel mode [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]. 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. @@ -174,24 +176,24 @@ 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. 2. NAI Definition 2.1 Formal Syntax - The grammar for the NAI is given below, described in ABNF as - documented in [RFC2234]. The grammar for the username is based on - [RFC0821], and the grammar for the realm is an updated version of - [RFC1035]. + The grammar for the NAI is given below, described in Augmented + Backus-Naur Form (ABNF) as documented in [RFC2234]. The grammar for + the username is based on [RFC0821], and the grammar for the realm is + an updated version of [RFC1035]. nai = username nai =/ "@" realm nai =/ username "@" realm username = dot-string dot-string = string dot-string =/ dot-string "." string string = char string =/ string char @@ -242,28 +244,29 @@ alpha = %x41-5A ; 'A'-'Z' alpha =/ %x61-7A ; 'a'-'z' digit = %x30-39 ; '0'-'9' 2.2 NAI Length Considerations 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: - o NAIs are often transported in the User-Name attribute of RADIUS. + o NAIs are often transported in the User-Name attribute of 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. + 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 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. 2.3 Support for Username Privacy @@ -412,35 +415,36 @@ [RFC2865] and [RFC2866]. 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] or Diameter protected by TLS [RFC3588]. 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 - also been used with NAIs. For instance, some EAP methods apply a - method-specific pseudonyms in the username part of the NAI. 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. + 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. 4. IANA Considerations 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 + 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] 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 @@ -475,36 +479,54 @@ 5.2 Informative References [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. + [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer + Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. + and G. Zorn, "Point-to-Point Tunneling Protocol", RFC + 2637, July 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. + and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC + 2661, August 1999. + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. + Levkowetz, "Extensible Authentication Protocol (EAP)", RFC + 3748, June 2004. + [I-D.ietf-eap-netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and Selection within the EAP Framework", draft-ietf-eap-netsel-problem-02 (work in progress), October 2004. Authors' Addresses Bernard Aboba Microsoft @@ -569,30 +590,31 @@ o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification. o Several clarifications and improvements have been incorporated to the ABNF specification for NAIs. Appendix B. Acknowledgements Thanks to Glen Zorn for many useful discussions of this problem - space, and for Farid Adrangi and others for suggesting mediating - network representation in NAIs. Jonathan Rosenberg reported the BNF + 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, - 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. + John Loughney, 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. Intellectual Property Statement 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