--- 1/draft-ietf-radext-rfc2486bis-05.txt 2006-02-05 01:15:49.000000000 +0100 +++ 2/draft-ietf-radext-rfc2486bis-06.txt 2006-02-05 01:15:50.000000000 +0100 @@ -1,50 +1,48 @@ Network Working Group B. Aboba Internet-Draft Microsoft Obsoletes: 2486 (if approved) M. Beadles -Expires: August 22, 2005 SmartPipes +Expires: January 19, 2006 SmartPipes J. Arkko Ericsson P. Eronen Nokia - February 21, 2005 + July 18, 2005 The Network Access Identifier - draft-ietf-radext-rfc2486bis-05 + draft-ietf-radext-rfc2486bis-06 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. + 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. + 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 August 22, 2005. + This Internet-Draft will expire on January 19, 2006. Copyright Notice Copyright (C) The Internet Society (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 @@ -62,33 +60,33 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . 7 2.4 International Character Sets . . . . . . . . . . . . . . . 7 - 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 8 + 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 9 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 9 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 - 5.2 Informative References . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . 17 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, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included: o Regional Internet Service Providers (ISPs) operating within a @@ -98,24 +96,24 @@ 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 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]. + 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. @@ -302,61 +300,69 @@ 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) [RFC3490]. 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]. These requirements consist of the - following: + specification as well as the requirements specified in [I-D.ietf- + sasl-saslprep]. These requirements consist of the following: - o Mapping requirements, as specified in Section 2.1 of - [I-D.ietf-sasl-saslprep]. Mapping consists of mapping certain - characters to others (such as SPACE) in order to increase the - likelihood of correctly performed comparisons. + o Mapping requirements, as specified in Section 2.1 of [I-D.ietf- + sasl-saslprep]. Mapping consists of mapping certain characters to + others (such as SPACE) in order to increase the likelihood of + correctly performed comparisons. o Normalization requirements, as specified in Section 2.2 of [I-D.ietf-sasl-saslprep], also designed to assist comparisons. o Prohibited output. Certain characters are not permitted in - correctly formed strings that follow Section 2.3 of - [I-D.ietf-sasl-saslprep]. Ensuring that NAIs conform to their - ABNF is not sufficient, it is also necessary to ensure that they - do not contain prohibited output. + correctly formed strings that follow Section 2.3 of [I-D.ietf- + sasl-saslprep]. Ensuring that NAIs conform to their ABNF is not + sufficient, it is also necessary to ensure that they do not + contain prohibited output. o Bidirectional characters are handled as specified in Section 2.4 of [I-D.ietf-sasl-saslprep]. - o Unassigned code points are specified in Section 2.5 of - [I-D.ietf-sasl-saslprep]. The use of unassigned code points is - prohibited. + o Unassigned code points are specified in Section 2.5 of [I-D.ietf- + sasl-saslprep]. The use of unassigned code points is prohibited. 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]. 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. + 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. + 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 [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. @@ -387,45 +393,53 @@ 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. When receiving such an + 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. 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. + 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 @@ -506,109 +520,110 @@ [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. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. - [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, + [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. 5.2 Informative References - [RFC0821] 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. - [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., and W. Wang, + "Review of Roaming Implementations", RFC 2194, + September 1997. - [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer + [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. + [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. + [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. + [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. + [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. + [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 One Microsoft Way Redmond, WA 98052 USA - EMail: bernarda@microsoft.com + Email: bernarda@microsoft.com Mark A. Beadles SmartPipes 565 Metro Place South Suite 300 Dublin OH 43017 USA - EMail: mbeadles@smartpipes.com + Email: mbeadles@smartpipes.com + Jari Arkko Ericsson Jorvas 02420 Finland - EMail: jari.arkko@ericsson.com + Email: jari.arkko@ericsson.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland - EMail: pasi.eronen@nokia.com + 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 [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