draft-ietf-radext-rfc2486bis-05.txt   naibis.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: August 22, 2005 SmartPipes Expires: January 19, 2006 SmartPipes
J. Arkko J. Arkko
Ericsson Ericsson
P. Eronen P. Eronen
Nokia Nokia
February 21, 2005 July 18, 2005
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-rfc2486bis-05 draft-ietf-radext-rfc2486bis-06
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 22, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
skipping to change at page 2, line 26 skipping to change at page 2, line 25
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 . . . . . . . . . . . 8 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 9
2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 9 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 9
2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 9
2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17
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 3, line 27 skipping to change at page 3, line 27
o National ISPs wishing to combine their operations with those of o National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent. dialup service in a group of countries or on a continent.
o Wireless LAN hotspots providing service to one or more ISPs. o Wireless LAN hotspots providing service to one or more ISPs.
o Businesses desiring to offer their employees a comprehensive o Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services may package of dialup services on a global basis. Those services may
include Internet access as well as secure access to corporate include Internet access as well as secure access to corporate
In order to enhance the interoperability of roaming services, it is In order to enhance the interoperability of roaming services, it is
necessary to have a standardized method for identifying users. This necessary to have a standardized method for identifying users. This
document defines syntax for the Network Access Identifier (NAI). document defines syntax for the Network Access Identifier (NAI).
Examples of implementations that use the NAI, and descriptions of its Examples of implementations that use the NAI, and descriptions of its
semantics, can be found in [RFC2194]. semantics, can be found in [RFC2194].
This document is a revised version of RFC 2486 [RFC2486] which This document is a revised version of RFC 2486 [RFC2486] which
originally defined NAIs. Differences and enhancements compared to originally defined NAIs. Differences and enhancements compared to
RFC 2486 are listed in Appendix A. RFC 2486 are listed in Appendix A.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 both the ABNF in this username portion in an NAI MUST fulfill both the ABNF in this
o Normalization requirements, as specified in Section 2.2 of o Normalization requirements, as specified in Section 2.2 of
[I-D.ietf-sasl-saslprep], also designed to assist comparisons. [I-D.ietf-sasl-saslprep], also designed to assist comparisons.
o Prohibited output. Certain characters are not permitted in o Prohibited output. Certain characters are not permitted in
o Bidirectional characters are handled as specified in Section 2.4 o Bidirectional characters are handled as specified in Section 2.4
of [I-D.ietf-sasl-saslprep]. of [I-D.ietf-sasl-saslprep].
The mapping, normalization, and bidirectional character processing The mapping, normalization, and bidirectional character processing
MUST be performed by end systems that take international text as MUST be performed by end systems that take international text as
input. In a network access setting, such systems are typically the input. In a network access setting, such systems are typically the
client and the AAA server. NAIs are sent over the wire in their client and the AAA server. NAIs are sent over the wire in their
canonical form, and tasks such as normalization do not typically need canonical form, and tasks such as normalization do not typically need
to be performed by nodes that just pass NAIs around or receive them to be performed by nodes that just pass NAIs around or receive them
from the network. End systems MUST also perform checking for from the network. End systems MUST also perform checking for
prohibited output and unassigned code points. Other systems MAY prohibited output and unassigned code points. Other systems MAY
perform such checks, when they know that a particular data item is a perform such checks, when they know that a particular data item is a
NAI. NAI.
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
is based on the BNF described in [RFC0821], 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, internationalization support as well as for purposes of Section 2.7,
and is not necessarily compatible with the usernames used in e-mail. and is not necessarily compatible with the usernames used in e-mail.
Note also that the internationalization requirements for NAIs and Note also that the internationalization requirements for NAIs and
e-mail addresses are different, since the former need to be typed in 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. only by the user himself and his own operator, not by others.
skipping to change at page 9, line 43 skipping to change at page 10, line 4
first condition is affected by roaming, as the availability of the first condition is affected by roaming, as the availability of the
other realm may depend on the user's location or the desired other realm may depend on the user's location or the desired
application. application.
The use of the home realm MUST be the default unless otherwise The use of the home realm MUST be the default unless otherwise
configured. configured.
Where these conditions are fulfilled, an NAI such as Where these conditions are fulfilled, an NAI such as
user@homerealm.example.net user@homerealm.example.net
The responsibility for the conversion of international domain names
MAY be represented as in MAY be represented as in
homerealm.example.net!user@otherrealm.example.net homerealm.example.net!user@otherrealm.example.net
In this case, the part before the (non-escaped) '!' MUST be a realm In this case, the part before the (non-escaped) '!' MUST be a realm
NAI, the other realm MUST convert the format back to NAI, the other realm MUST convert the format back to
"user@homerealm.example.net" when passing the NAI forward, as well as "user@homerealm.example.net" when passing the NAI forward, as well as
applying appropriate AAA routing for the transaction. applying appropriate AAA routing for the transaction.
The conversion process may apply also recursively. That is, after The conversion process may apply also recursively. That is, after
the conversion the result may still have one or more '!' characters the conversion the result may still have one or more '!' characters
in the username. For instance, the NAI in the username. For instance, the NAI
other2.example.net!home.example.net!user@other1.example.net other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to would first be converted in other1.example.net to
home.example.net!user@other2.example.net home.example.net!user@other2.example.net
and then at other2.example.net finally to and then at other2.example.net finally to
user@homerealm.example.net user@homerealm.example.net
2.8 Examples 2.8 Examples
Examples of valid Network Access Identifiers include: Examples of valid Network Access Identifiers include:
bob bob
joe@example.com joe@example.com
fred@foo-9.example.com fred@foo-9.example.com
jack@3rd.depts.example.com jack@3rd.depts.example.com
fred.smith@example.com fred.smith@example.com
fred_smith@example.com fred_smith@example.com
skipping to change at page 12, line 18 skipping to change at page 12, line 47
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] 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. 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)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[I-D.ietf-sasl-saslprep] [I-D.ietf-sasl-saslprep]
Zeilenga, K., "SASLprep: Stringprep profile for user names Zeilenga, K., "SASLprep: Stringprep profile for user names
and passwords", draft-ietf-sasl-saslprep-10 (work in and passwords", draft-ietf-sasl-saslprep-10 (work in
progress), July 2004. progress), July 2004.
5.2 Informative References 5.2 Informative References
[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. Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. RFC 2486, January 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. 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. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[I-D.ietf-eap-netsel-problem] [I-D.ietf-eap-netsel-problem]
Arkko, J. and B. Aboba, "Network Discovery and Selection Arkko, J. and B. Aboba, "Network Discovery and Selection
within the EAP Framework", within the EAP Framework",
draft-ietf-eap-netsel-problem-02 (work in progress), draft-ietf-eap-netsel-problem-02 (work in progress),
October 2004. October 2004.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: bernarda@microsoft.com Email: bernarda@microsoft.com
Mark A. Beadles Mark A. Beadles
SmartPipes SmartPipes
565 Metro Place South Suite 300 565 Metro Place South Suite 300
Dublin OH 43017 Dublin OH 43017
USA USA
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
Appendix A. Changes from RFC 2486 Appendix A. Changes from RFC 2486
This draft contains the following updates with respect to the This draft contains the following updates with respect to the
original NAI definition in RFC 2486 [RFC2486]: original NAI definition in RFC 2486 [RFC2486]:
o International character set support has been added for both o International character set support has been added for both
usernames and realms. Note that this implies character codes 128 usernames and realms. Note that this implies character codes 128
- 255 may be used in the username portion, which may be - 255 may be used in the username portion, which may be
unacceptable to nodes that only support RFC 2486. Many devices unacceptable to nodes that only support RFC 2486. Many devices
 End of changes. 

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