draft-ietf-radext-rfc2486bis-03.txt   draft-ietf-radext-rfc2486bis-04.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 2486 (if approved) M. Beadles Obsoletes: 2486 (if approved) M. Beadles
Expires: May 2, 2005 SmartPipes Expires: August 22, 2005 SmartPipes
J. Arkko J. Arkko
Ericsson Ericsson
P. Eronen P. Eronen
Nokia Nokia
November 2004 February 21, 2005
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-rfc2486bis-03 draft-ietf-radext-rfc2486bis-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
In order to provide roaming services, it is necessary to have a In order to provide roaming services, it is necessary to have a
standardized method for identifying users. This document defines the standardized method for identifying users. This document defines the
syntax for the Network Access Identifier (NAI), the user identity syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during network authentication. "Roaming" may submitted by the client during network authentication. "Roaming" may
be loosely defined as the ability to use any one of multiple Internet 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 relationship with only one. Examples of where roaming capabilities
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Requirements language . . . . . . . . . . . . . . . . . . 4 1.2 Requirements language . . . . . . . . . . . . . . . . . . 4
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5
2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6 2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6
2.3 Support for Username Privacy . . . . . . . . . . . . . . . 7 2.3 Support for Username Privacy . . . . . . . . . . . . . . . 7
2.4 International Character Sets . . . . . . . . . . . . . . . 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.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8
2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9
2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
5.2 Informative References . . . . . . . . . . . . . . . . . . . 11 5.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 13 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
Considerable interest exists for a set of features that fit within Considerable interest exists for a set of features that fit within
the general category of "roaming capability" for network access, the general category of "roaming capability" for network access,
including dialup Internet users, Virtual Private Network (VPN) usage, including dialup Internet users, Virtual Private Network (VPN) usage,
wireless LAN authentication, and other applications. Interested wireless LAN authentication, and other applications. Interested
parties have included: parties have included:
o Regional Internet Service Providers (ISPs) operating within a o Regional Internet Service Providers (ISPs) operating within a
skipping to change at page 5, line 44 skipping to change at page 5, line 44
char =/ "\" x char =/ "\" x
c = %x21 ; '!' allowed c = %x21 ; '!' allowed
; '"' not allowed ; '"' not allowed
c =/ %x23 ; '#' allowed c =/ %x23 ; '#' allowed
c =/ %x24 ; '$' allowed c =/ %x24 ; '$' allowed
c =/ %x25 ; '%' allowed c =/ %x25 ; '%' allowed
c =/ %x26 ; '&' allowed c =/ %x26 ; '&' allowed
c =/ %x27 ; ''' allowed c =/ %x27 ; ''' allowed
; '(', ')' not allowed ; '(', ')' not allowed
c =/ %x2a ; '*' allowed c =/ %x2A ; '*' allowed
c =/ %x2b ; '+' allowed c =/ %x2B ; '+' allowed
; ',' not allowed ; ',' not allowed
c =/ %x2d ; '-' allowed c =/ %x2D ; '-' allowed
; '.' not allowed ; '.' not allowed
c =/ %x2f ; '/' allowed c =/ %x2F ; '/' allowed
c =/ %x30-39 ; '0'-'9' allowed c =/ %x30-39 ; '0'-'9' allowed
; ';', ':', '<' not allowed ; ';', ':', '<' not allowed
c =/ %x3d ; '=' allowed c =/ %x3D ; '=' allowed
; '>' not allowed ; '>' not allowed
c =/ %x3f ; '?' allowed c =/ %x3F ; '?' allowed
; '@' not allowed ; '@' not allowed
c =/ %x41-5a ; 'A'-'Z' allowed c =/ %x41-5a ; 'A'-'Z' allowed
; '[', '\', ']' not allowed ; '[', '\', ']' not allowed
c =/ %x5e ; '^' allowed c =/ %x5E ; '^' allowed
c =/ %x5f ; '_' allowed c =/ %x5F ; '_' allowed
c =/ %x60 ; '`' allowed c =/ %x60 ; '`' allowed
c =/ %x61-7a ; 'a'-'z' allowed c =/ %x61-7A ; 'a'-'z' allowed
c =/ %x7b ; '{' allowed c =/ %x7B ; '{' allowed
c =/ %x7c ; '|' allowed c =/ %x7C ; '|' allowed
c =/ %x7d ; '}' allowed c =/ %x7D ; '}' allowed
c =/ %x7e ; '~' allowed c =/ %x7E ; '~' allowed
; DEL not allowed ; DEL not allowed
c =/ %x80-ff ; UTF-8 allowed (not in RFC 2486) c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; c must also satisfy rules in Section 2.4 ; 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; x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8 characters (this ; as well as all UTF-8-octets as defined
; was not allowed in RFC 2486) ; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
realm = 1*( label "." ) label realm = 1*( label "." ) label
label = let-dig * (ldh-str) label = let-dig * (ldh-str)
ldh-str = *( alpha / digit / "-" ) let-dig ldh-str = *( alpha / digit / "-" ) let-dig
let-dig = alpha / digit let-dig = alpha / digit
alpha = %x41-5A ; 'A'-'Z' alpha = %x41-5A ; 'A'-'Z'
alpha =/ %x61-7A ; 'a'-'z' alpha =/ %x61-7A ; 'a'-'z'
digit = %x30-39 ; '0'-'9' digit = %x30-39 ; '0'-'9'
2.2 NAI Length Considerations 2.2 NAI Length Considerations
skipping to change at page 7, line 19 skipping to change at page 7, line 29
eventually be translated to RADIUS, in which case the above eventually be translated to RADIUS, in which case the above
limitations apply. limitations apply.
2.3 Support for Username Privacy 2.3 Support for Username Privacy
Interpretation of the "username" part of the NAI depends on the realm Interpretation of the "username" part of the NAI depends on the realm
in question. Therefore, the "username" part SHOULD be treated as in question. Therefore, the "username" part SHOULD be treated as
opaque data when processed by nodes that are not a part of the opaque data when processed by nodes that are not a part of the
authoritative domain (in the sense of Section 4) for that realm. authoritative domain (in the sense of Section 4) for that realm.
Where privacy is a concern, NAIs MAY be provided in an abbreviated In some situations NAIs are are used together with a separate
form by omitting the username portion. This is possible only when authentication method that can transfer the username part in a more
NAIs are used together with a separate authentication method that can secure manner to increase privacy. In this case, NAIs MAY be
transfer the username in a secure manner. 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 For roaming purposes it is typically necessary to locate the
appropriate backend authentication server for the given NAI before appropriate backend authentication server for the given NAI before
the authentication conversation can proceed. As a result, the realm the authentication conversation can proceed. As a result, the realm
portion is typically required in order for the authentication portion is typically required in order for the authentication
exchange to be routed to the appropriate server. exchange to be routed to the appropriate server.
2.4 International Character Sets 2.4 International Character Sets
This specification allows both international usernames and realms. This specification allows both international usernames and realms.
International usernames are based on the use of Unicode characters, International usernames are based on the use of Unicode characters,
encoded as UTF-8 and processed with a certain algorithm to ensure a encoded as UTF-8 and processed with a certain algorithm to ensure a
canonical representation. The realm part internationalization is canonical representation. The realm part internationalization is
based on International Domain Name (IDN) [RFC3490]. based on International Domain Name (IDN) [RFC3490].
In order to ensure a canonical representation, characters of the In order to ensure a canonical representation, characters of the
username portion in an NAI MUST fulfill the requirements specified in username portion in an NAI MUST fulfill both the ABNF in this
[I-D.ietf-sasl-saslprep]. In addition, the use of certain special specification as well as the requirements specified in
characters (see grammar rule c) are prohibited as well in order to [I-D.ietf-sasl-saslprep]. These requirements consist of the
retain compatibility with the previous version of this RFC. 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 The realm name is an "IDN-unaware domain name slot" as defined in
[RFC3490]. 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) implementation MAY support internationalized domain names (IDNs)
using the ToASCII operation; see [RFC3490] for more information. using the ToASCII operation; see [RFC3490] for more information.
2.5 Compatibility with E-Mail Usernames 2.5 Compatibility with E-Mail Usernames
As proposed in this document, the Network Access Identifier is of the 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 form user@realm. Please note that while the user portion of the NAI
skipping to change at page 14, line 22 skipping to change at page 15, line 16
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Glen Zorn for many useful discussions of this problem Thanks to Glen Zorn for many useful discussions of this problem
space, and to Farid Adrangi for suggesting the representation of space, and to Farid Adrangi for suggesting the representation of
mediating networks in NAIs. Jonathan Rosenberg reported the BNF mediating networks in NAIs. Jonathan Rosenberg reported the BNF
error. Dale Worley suggested clarifications of the x and special BNF error. Dale Worley suggested clarifications of the x and special BNF
entries. Arne Norefors reported the length differences between RFC entries. Arne Norefors reported the length differences between RFC
2486 and RFC 2865. Paul Hoffman helped with the international 2486 and RFC 2865. Paul Hoffman helped with the international
character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi
Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret, Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret,
John Loughney, and Richard Perlman provided many useful comments on John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam
this draft. The ABNF validator at http://www.apps.ietf.org/abnf.html Hartman, and Richard Perlman provided many useful comments on this
was used to verify the syntactic correctness of the ABNF in Section draft. The ABNF validator at http://www.apps.ietf.org/abnf.html was
2.1. used to verify the syntactic correctness of the ABNF in Section 2.1.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 15, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement 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 to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/