--- 1/draft-ietf-radext-rfc2486bis-03.txt 2006-02-05 01:15:47.000000000 +0100 +++ 2/draft-ietf-radext-rfc2486bis-04.txt 2006-02-05 01:15:47.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group B. Aboba Internet-Draft Microsoft Obsoletes: 2486 (if approved) M. Beadles -Expires: May 2, 2005 SmartPipes +Expires: August 22, 2005 SmartPipes J. Arkko Ericsson P. Eronen Nokia - November 2004 + February 21, 2005 The Network Access Identifier - draft-ietf-radext-rfc2486bis-03 + draft-ietf-radext-rfc2486bis-04 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,25 +30,25 @@ 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 2, 2005. + This Internet-Draft will expire on August 22, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + 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 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 @@ -62,33 +62,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 . . . . . . . . . . . 7 + 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 8 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8 - 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8 - 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9 + 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 - 5.2 Informative References . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 - A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 13 - B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 15 + 5.2 Informative References . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 + A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 + B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . 16 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 @@ -201,48 +201,57 @@ 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 + c =/ %x2A ; '*' allowed + c =/ %x2B ; '+' allowed ; ',' not allowed - c =/ %x2d ; '-' allowed + c =/ %x2D ; '-' allowed ; '.' not allowed - c =/ %x2f ; '/' allowed + c =/ %x2F ; '/' allowed c =/ %x30-39 ; '0'-'9' allowed ; ';', ':', '<' not allowed - c =/ %x3d ; '=' allowed + c =/ %x3D ; '=' allowed ; '>' not allowed - c =/ %x3f ; '?' allowed + c =/ %x3F ; '?' allowed ; '@' not allowed c =/ %x41-5a ; 'A'-'Z' allowed ; '[', '\', ']' not allowed - c =/ %x5e ; '^' allowed - c =/ %x5f ; '_' 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 + 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 allowed (not in RFC 2486) - ; c must also satisfy rules in Section 2.4 + 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 characters (this - ; was not allowed in RFC 2486) + ; 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' 2.2 NAI Length Considerations @@ -268,44 +277,68 @@ 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 authoritative domain (in the sense of Section 4) for that realm. - Where privacy is a concern, NAIs MAY be provided in an abbreviated - form by omitting the username portion. 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 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. 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 the requirements specified in - [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. + 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: + + 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. + + 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 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. 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 @@ -597,24 +629,24 @@ Appendix B. Acknowledgements 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, 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, 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. 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 @@ -638,18 +670,18 @@ 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 Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.