draft-ietf-radext-rfc2486bis-02.txt   draft-ietf-radext-rfc2486bis-03.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
Internet-Draft Microsoft Internet-Draft Microsoft
Expires: May 5, 2005 M. Beadles Obsoletes: 2486 (if approved) M. Beadles
SmartPipes Expires: May 2, 2005 SmartPipes
J. Arkko J. Arkko
Ericsson Ericsson
P. Eronen P. Eronen
Nokia Nokia
November 4, 2004 November 2004
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-rfc2486bis-02 draft-ietf-radext-rfc2486bis-03
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 40 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 5, 2005. This Internet-Draft will expire on May 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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
might be required include ISP "confederations" and ISP-provided might be required include ISP "confederations" and ISP-provided
corporate network access support. This document is a revised version corporate network access support. This document is a revised version
of RFC 2486 which originally defined NAIs. Enhancements include of RFC 2486 which originally defined NAIs. Enhancements include
international character set and privacy support, as well as a number international character set and privacy support, as well as a number
of corrections to the original RFC. of corrections to the original RFC.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7
2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8
2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8
2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 12 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 13
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 15
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, VPN usage, wireless LAN including dialup Internet users, Virtual Private Network (VPN) usage,
authentication, and other applications. Interested parties have wireless LAN authentication, and other applications. Interested
included: parties have included:
o Regional Internet Service Providers (ISPs) operating within a o Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service with those of other regional providers to offer dialup service
over a wider area. over a wider area.
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
intranets via a Virtual Private Network (VPN), enabled by intranets via a VPN, enabled by tunneling protocols such as
tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2
mode. 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 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 5, line 17 skipping to change at page 5, line 19
server. For use in roaming, this function is accomplished via the server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in Network Access Identifier (NAI) submitted by the user to the NAS in
the initial network authentication. It is also expected that NASes 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 will use the NAI as part of the process of opening a new tunnel, in
order to determine the tunnel endpoint. order to determine the tunnel endpoint.
2. NAI Definition 2. NAI Definition
2.1 Formal Syntax 2.1 Formal Syntax
The grammar for the NAI is given below, described in ABNF as The grammar for the NAI is given below, described in Augmented
documented in [RFC2234]. The grammar for the username is based on Backus-Naur Form (ABNF) as documented in [RFC2234]. The grammar for
[RFC0821], and the grammar for the realm is an updated version of the username is based on [RFC0821], and the grammar for the realm is
[RFC1035]. an updated version of [RFC1035].
nai = username nai = username
nai =/ "@" realm nai =/ "@" realm
nai =/ username "@" realm nai =/ username "@" realm
username = dot-string username = dot-string
dot-string = string dot-string = string
dot-string =/ dot-string "." string dot-string =/ dot-string "." string
string = char string = char
string =/ string char string =/ string char
skipping to change at page 6, line 37 skipping to change at page 6, line 40
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
Devices handling NAIs MUST support an NAI length of at least 72 Devices handling NAIs MUST support an NAI length of at least 72
octets. Support for an NAI length of 253 octets is RECOMMENDED. octets. Support for an NAI length of 253 octets is RECOMMENDED.
However, the following implementation issues should be considered: However, the following implementation issues should be considered:
o NAIs are often transported in the User-Name attribute of RADIUS. o NAIs are often transported in the User-Name attribute of Remote
Authentication Dial In User Service (RADIUS) protocol.
Unfortunately, RFC 2865 [RFC2865] Section 5.1 states that "the Unfortunately, RFC 2865 [RFC2865] Section 5.1 states that "the
ability to handle at least 63 octets is recommended." As a result, ability to handle at least 63 octets is recommended." As a
it may not be possible to transfer NAIs beyond 63 octets through result, it may not be possible to transfer NAIs beyond 63 octets
all devices. In addition, since only a single User-Name attribute through all devices. In addition, since only a single User-Name
may be included in a RADIUS message and the maximum attribute attribute may be included in a RADIUS message and the maximum
length is 253 octets, RADIUS is unable to support NAI lengths attribute length is 253 octets, RADIUS is unable to support NAI
beyond 253 octets. lengths beyond 253 octets.
o NAIs can also be transported in the User-Name attribute of o NAIs can also be transported in the User-Name attribute of
Diameter [RFC3588], 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 octets. As a result, NAIs processed only by Diameter nodes can be
very long. Unfortunately, an NAI transported over Diameter may very long. Unfortunately, an NAI transported over Diameter may
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
skipping to change at page 10, line 21 skipping to change at page 10, line 22
[RFC2865] and [RFC2866]. In order to prevent snooping of the user [RFC2865] and [RFC2866]. In order to prevent snooping of the user
name, protocols may use confidentiality services provided by name, protocols may use confidentiality services provided by
protocols transporting them, such RADIUS protected by IPsec [RFC3579] protocols transporting them, such RADIUS protected by IPsec [RFC3579]
or Diameter protected by TLS [RFC3588]. or Diameter protected by TLS [RFC3588].
This specification adds the possibility of hiding the username part This specification adds the possibility of hiding the username part
in the NAI, by omitting it. As discussed in Section 2.3, this is in the NAI, by omitting it. As discussed in Section 2.3, this is
possible only when NAIs are used together with a separate possible only when NAIs are used together with a separate
authentication method that can transfer the username in a secure authentication method that can transfer the username in a secure
manner. In some cases application-specific privacy mechanism have manner. In some cases application-specific privacy mechanism have
also been used with NAIs. For instance, some EAP methods apply a also been used with NAIs. For instance, some Extensible
method-specific pseudonyms in the username part of the NAI. While Authentication Protocol (EAP) methods apply method-specific
neither of these approaches can protect the realm part, their pseudonyms in the username part of the NAI [RFC3748]. While neither
advantage over transport protection is that privacy of the username of these approaches can protect the realm part, their advantage over
is protected even through intermediate nodes such as NASes. transport protection is that privacy of the username is protected
even through intermediate nodes such as NASes.
4. IANA Considerations 4. IANA Considerations
In order to to avoid creating any new administrative procedures, In order to to avoid creating any new administrative procedures,
administration of the NAI realm namespace piggybacks on the administration of the NAI realm namespace piggybacks on the
administration of the DNS namespace. administration of the DNS namespace.
NAI realm names are required to be unique and the rights to use a NAI realm names are required to be unique and the rights to use a
given NAI realm for roaming purposes are obtained coincident with given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular fully qualified domain name acquiring the rights to use a particular Fully Qualified Domain Name
(FQDN). Those wishing to use an NAI realm name should first acquire (FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without the rights to use the corresponding FQDN. Using an NAI realm without
ownership of the corresponding FQDN creates the possibility of ownership of the corresponding FQDN creates the possibility of
conflict and therefore is to be discouraged. conflict and therefore is to be discouraged.
Note that the use of an FQDN as the realm name does not require use 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 of the DNS for location of the authentication server. While Diameter
[RFC3588] supports the use of DNS for location of authentication [RFC3588] supports the use of DNS for location of authentication
servers, existing RADIUS implementations typically use proxy servers, existing RADIUS implementations typically use proxy
configuration files in order to locate authentication servers within configuration files in order to locate authentication servers within
skipping to change at page 11, line 36 skipping to change at page 11, line 39
5.2 Informative References 5.2 Informative References
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982. 821, August 1982.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
"Review of Roaming Implementations", RFC 2194, September "Review of Roaming Implementations", RFC 2194, September
1997. 1997.
[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", [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. 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.
[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, [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000. 2865, June 2000.
[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.
[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] [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
skipping to change at page 13, line 39 skipping to change at page 14, line 15
o The realm BNF entry definition has been changed to avoid an error o The realm BNF entry definition has been changed to avoid an error
(infinite recursion) in the original specification. (infinite recursion) in the original specification.
o Several clarifications and improvements have been incorporated to o Several clarifications and improvements have been incorporated to
the ABNF specification for NAIs. the ABNF specification for NAIs.
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 for Farid Adrangi and others for suggesting mediating space, and to Farid Adrangi for suggesting the representation of
network representation 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,
and Richard Perlman provided many useful comments on this draft. The John Loughney, and Richard Perlman provided many useful comments on
ABNF validator at http://www.apps.ietf.org/abnf.html was used to this draft. The ABNF validator at http://www.apps.ietf.org/abnf.html
verify the syntactic correctness of the ABNF in Section 2.1. was 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
 End of changes. 

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