--- 1/draft-ietf-radext-rfc2486bis-01.txt 2006-02-05 01:15:44.000000000 +0100 +++ 2/draft-ietf-radext-rfc2486bis-02.txt 2006-02-05 01:15:44.000000000 +0100 @@ -1,23 +1,22 @@ - Network Working Group B. Aboba Internet-Draft Microsoft -Expires: April 19, 2005 M. Beadles +Expires: May 5, 2005 M. Beadles SmartPipes J. Arkko Ericsson P. Eronen Nokia - October 19, 2004 + November 4, 2004 The Network Access Identifier - draft-ietf-radext-rfc2486bis-01 + draft-ietf-radext-rfc2486bis-02 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. @@ -30,21 +29,21 @@ 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 April 19, 2005. + This Internet-Draft will expire on May 5, 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 @@ -54,57 +53,61 @@ 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 - 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 Requirements language . . . . . . . . . . . . . . . . 4 - 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 Requirements language . . . . . . . . . . . . . . . . . . 4 + 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . 5 - 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 . . . . . . . . . 7 - 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . 7 - 2.7 Realm Construction . . . . . . . . . . . . . . . . . . 8 - 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6 + 2.3 Support for Username Privacy . . . . . . . . . . . . . . . 7 + 2.4 International Character Sets . . . . . . . . . . . . . . . 7 + 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 . . . . . . . . . . . . . . . . . . . . . 11 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1 Normative References . . . . . . . . . . . . . . . . . . 12 - 5.2 Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 - A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 - B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . 16 + 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 + 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: + 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. 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). @@ -102,54 +105,58 @@ 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. 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 [7]. + semantics, can be found in [RFC2194]. - This document is a revised version of RFC 2486 which originally - defined NAIs. Differences and enhancements compared to RFC 2486 are - listed in Appendix A. + 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. 1.1 Terminology 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). 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", @@ -147,43 +154,44 @@ 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). 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as - described in [2]. + described in [RFC2119]. 1.3 Purpose - As described in [7], there are a number of providers offering network - access services, and the number of Internet Service Providers + 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. 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. 2. NAI Definition 2.1 Formal Syntax The grammar for the NAI is given below, described in ABNF as - documented in [3]. The grammar for the username is based on [6], and - the grammar for the realm is an updated version of [1]. + 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 @@ -233,30 +241,32 @@ let-dig = alpha / digit 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. - Unfortunately, RFC 2865 [9] 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. + 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 NAIs can also be transported in the User-Name attribute of - Diameter [12], which supports content lengths up to 2^24 - 9 + 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 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 @@ -272,51 +282,51 @@ 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. 2.4 International Character Sets 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) [4]. + based on International Domain Name (IDN) [RFC3490]. In order to ensure a canonical representation, characters of the username portion in an NAI MUST fulfill the requirements specified in - [5]. In addition, the use of certain special characters (see grammar - rule c) are prohibited as well in order to retain compatibility with - the previous version of this RFC. + [I-D.ietf-sasl-saslprep]. In addition, the use of certain special + characters (see grammar rule c) are prohibited as well in order to + retain compatibility with the previous version of this RFC. The realm name is an "IDN-unaware domain name slot" as defined in - [4]. That is, it can contain only ASCII characters. An + [RFC3490]. That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) - using the ToASCII operation; see [4] for more information. + using the ToASCII operation; see [RFC3490] for more information. 2.5 Compatibility with E-Mail Usernames 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 [6], it has been extended for + 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. 2.6 Compatibility with DNS The BNF of the realm portion allows the realm to begin with a digit, - which is not permitted by the BNF described in [1]. This change was - made to reflect current practice; although not permitted by the BNF - described in [1], FQDNs such as 3com.com are commonly used, and - accepted by current software. + 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], FQDNs such as 3com.com are + commonly used, and accepted by current software. 2.7 Realm Construction 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 @@ -361,49 +372,54 @@ user@homerealm.example.net 2.8 Examples 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@foo - fred@foo_9.com - fred@bigco.com@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 @example.net 3. Security Considerations 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 - [9] and [10]. In order to prevent snooping of the user name, - protocols may use confidentiality services provided by protocols - transporting them, such RADIUS protected by IPsec [11] or Diameter - protected by TLS [12]. + [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 @@ -418,77 +434,82 @@ 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 - [12] 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 [7] - 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. + [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 that the NAI represent a valid email address. 5. References 5.1 Normative References - [1] Mockapetris, P., "Domain names - implementation and + [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. - [4] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing - Domain Names in Applications (IDNA)", RFC 3490, March 2003. + [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. - [5] Zeilenga, K., "SASLprep: Stringprep profile for user names and - passwords", draft-ietf-sasl-saslprep-04 (work in progress), - October 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. 5.2 Informative References - [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - August 1982. + [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. - [7] 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. and W. Wang, + "Review of Roaming Implementations", RFC 2194, September + 1997. - [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC - 2486, January 1999. + [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", + RFC 2486, January 1999. - [9] 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. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2865, June 2000. - [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. - [11] 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. and P. Calhoun, "RADIUS (Remote Authentication + Dial In User Service) Support For Extensible + Authentication Protocol (EAP)", RFC 3579, September 2003. - [12] 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. and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. - [13] Arkko, J. and B. Aboba, "Network Discovery and Selection within - the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in - progress), January 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 One Microsoft Way Redmond, WA 98052 USA EMail: bernarda@microsoft.com @@ -512,44 +533,50 @@ Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Appendix A. Changes from RFC 2486 This draft contains the following updates with respect to the - original NAI definition in RFC 2486: + original NAI definition in RFC 2486 [RFC2486]: + 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 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 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 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 [13]. Rather, it is intended as a - clarification of RFC 2486. + selection needs as defined in [I-D.ietf-eap-netsel-problem]. + Rather, it is intended as a clarification of 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. + 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 error. Dale Worley suggested clarifications of the x and special BNF entries. Arne Norefors reported the length differences between RFC