draft-ietf-radext-nai-05.txt   draft-ietf-radext-nai-06.txt 
Network Working Group DeKok, Alan RADEXT Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-05.txt> <draft-ietf-radext-nai-06.txt>
6 November 2013 17 June 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-05 draft-ietf-radext-nai-06
Abstract Abstract
In order to provide inter-domain authentication services, it is In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to necessary to have a standardized method that domains can use to
identify each others users. This document defines the syntax for the identify each other's users. This document defines the syntax for
Network Access Identifier (NAI), the user identity submitted by the the Network Access Identifier (NAI), the user identity submitted by
client prior to accessing network resources. This document is a the client prior to accessing network resources. This document is a
revised version of RFC 4282 [RFC4282], which addresses issues with revised version of RFC 4282, which addresses issues with
international character sets, as well as a number of other international character sets, as well as a number of other
corrections to the previous document. corrections to the previous document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 6, 2014. This Internet-Draft will expire on January 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
3. ........................................................... 3
Appendix A - Changes from RFC4282 ............................ 3 Appendix A - Changes from RFC4282 ............................ 3
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
1.3. Purpose ............................................. 7 1.3. Purpose ............................................. 7
1.4. Motivation .......................................... 7 1.4. Motivation .......................................... 7
2. NAI Definition ........................................... 8 2. NAI Definition ........................................... 8
2.1. UTF-8 Syntax and Normalization ...................... 8 2.1. UTF-8 Syntax and Normalization ...................... 8
2.2. Formal Syntax ....................................... 9 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 10 2.3. NAI Length Considerations ........................... 10
2.4. Support for Username Privacy ........................ 11 2.4. Support for Username Privacy ........................ 11
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 12 2.6. The Normalization Process ........................... 12
2.6.1. Issues with the Normalization Process .......... 13 2.6.1. Issues with the Normalization Process .......... 13
2.7. Use in Other Protocols .............................. 14 2.7. Use in Other Protocols .............................. 14
3. ........................................................... 15 3. Routing inside of AAA Systems ............................ 15
3.1. Compatibility with Email Usernames .................. 16 3.1. Compatibility with Email Usernames .................. 16
3.2. Compatibility with DNS .............................. 16 3.2. Compatibility with DNS .............................. 16
3.3. Realm Construction .................................. 17 3.3. Realm Construction .................................. 17
3.3.1. Historical Practices ........................... 18 3.3.1. Historical Practices ........................... 18
3.4. Examples ............................................ 18 3.4. Examples ............................................ 18
4. Security Considerations .................................. 19 4. Security Considerations .................................. 19
5. IANA Considerations ...................................... 20 5. Administration of Names .................................. 20
6. References ............................................... 20 6. IANA Considerations ...................................... 20
6.1. Normative References ................................ 20 7. References ............................................... 20
6.2. Informative References .............................. 21 7.1. Normative References ................................ 20
7.2. Informative References .............................. 21
Appendix A - Changes from RFC4282 ............................ 23 Appendix A - Changes from RFC4282 ............................ 23
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 inter-domain authentiction, or "roaming the general category of inter-domain authentiction, or "roaming
capability" for network access, including dialup Internet users, capability" for network access, including dialup Internet users,
Virtual Private Network (VPN) usage, wireless LAN authentication, and Virtual Private Network (VPN) usage, wireless LAN authentication, and
other applications. Interested parties have included the following: other applications. Interested parties have included the following:
* Regional Internet Service Providers (ISPs) operating within a * Regional Internet Service Providers (ISPs) operating within a
skipping to change at page 6, line 36 skipping to change at page 6, line 36
Tunneling Service Tunneling Service
A tunneling service is any network service enabled by tunneling A tunneling service is any network service enabled by tunneling
protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One
example of a tunneling service is secure access to corporate example of a tunneling service is secure access to corporate
intranets via a Virtual Private Network (VPN). intranets via a Virtual Private Network (VPN).
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
1.3. Purpose 1.3. Purpose
As described in [RFC2194], there are a number of providers offering As described in [RFC2194], there are a number of providers offering
network access services, and the number of Internet Service Providers network access services, and the number of Internet Service Providers
involved in roaming consortia is increasing rapidly. involved in roaming consortia is increasing rapidly.
In order to be able to offer roaming capability, one of the In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the server. For use in roaming, this function is accomplished via the
skipping to change at page 11, line 4 skipping to change at page 11, line 4
Remote Authentication Dial-In User Service (RADIUS) protocol. 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 ability to handle at least 63 octets is recommended." As a
result, it may not be possible to transfer NAIs beyond 63 octets result, it may not be possible to transfer NAIs beyond 63 octets
through all devices. In addition, since only a single User-Name through all devices. In addition, since only a single User-Name
attribute may be included in a RADIUS message and the maximum attribute may be included in a RADIUS message and the maximum
attribute length is 253 octets; RADIUS is unable to support NAI attribute length is 253 octets; RADIUS is unable to support NAI
lengths beyond 253 octets. lengths beyond 253 octets.
* NAIs can also be transported in the User-Name attribute of * NAIs can also be transported in the User-Name attribute of
Diameter [RFC3588], which supports content lengths up to 2^24 - 9 Diameter [RFC6733], 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. However, an NAI transported over Diameter may very long. However, 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 will apply. limitations will apply.
* NAIs may be transported in other protocols. Each protocol * NAIs may be transported in other protocols. Each protocol
can have its own limitations on maximum NAI length. can have its own limitations on maximum NAI length.
The above criteria should permit the widest use, and widest possible The above criteria should permit the widest use, and widest possible
inter-operability of the NAI. inter-operability of the NAI.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
insufficient information, which meant that the form was not insufficient information, which meant that the form was not
canonical. canonical.
Specifying the realm requirement as above means that the requirements Specifying the realm requirement as above means that the requirements
depend on specifications that are referenced here, rather than copied depend on specifications that are referenced here, rather than copied
here. This allows the realm definition to be updated when the here. This allows the realm definition to be updated when the
referenced documents change, without requiring a revision of this referenced documents change, without requiring a revision of this
specification. specification.
One caveat on the above recommendation is the issues noted in One caveat on the above recommendation is the issues noted in
[CODEPOINTS]. That document notes that there are additional [RFC6912]. That document notes that there are additional
restrictions around DNS registration which forbid some code points restrictions around DNS registration which forbid some code points
from being valid in a DNS U-label. These restrictions cannot be from being valid in a DNS U-label. These restrictions cannot be
expressed algorithmically. expressed algorithmically.
For this specification, that caveat means the following. Realms not For this specification, that caveat means the following. Realms not
matching the above ABNF are not valid NAIs. However, some realms matching the above ABNF are not valid NAIs. However, some realms
which do match the ABNF are still invalid NAIs. That is, matching which do match the ABNF are still invalid NAIs. That is, matching
the ABNF is a necessary, but not sufficient, requirement for an NAI. the ABNF is a necessary, but not sufficient, requirement for an NAI.
In general, the above requirement means following the requirements In general, the above requirement means following the requirements
skipping to change at page 15, line 16 skipping to change at page 15, line 16
For example, HTTP carries user identifiers, but escapes the '.' For example, HTTP carries user identifiers, but escapes the '.'
character as "%2E" (among others). When we desire HTTP to transport character as "%2E" (among others). When we desire HTTP to transport
the NAI "fred@example.com", the data as transported will be in the the NAI "fred@example.com", the data as transported will be in the
form "fred@example%2Ecom". That data exists only within HTTP, and form "fred@example%2Ecom". That data exists only within HTTP, and
has no relevance to any AAA system. has no relevance to any AAA system.
Any comparison, validation, or use of the NAI MUST be done on its un- Any comparison, validation, or use of the NAI MUST be done on its un-
escaped (i.e. utf8-clean) form. escaped (i.e. utf8-clean) form.
3. 3. Routing inside of AAA Systems
Many AAA systems use the "utf8-realm" portion of the NAI to route Many AAA systems use the "utf8-realm" portion of the NAI to route
requests within a AAA proxy network. The semantics of this operation requests within a AAA proxy network. The semantics of this operation
involves a logical AAA routing table, where the "utf8-realm" portion involves a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
without modification to perform this lookup. As noted earlier, without modification to perform this lookup. As noted earlier,
intermediate nodes may not have access to the same locale information intermediate nodes may not have access to the same locale information
skipping to change at page 19, line 45 skipping to change at page 19, line 45
4. Security Considerations 4. Security Considerations
Since an NAI reveals the home affiliation of a user, it may assist an Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically, this attacker in further probing the username space. Typically, this
problem is of most concern in protocols that transmit the username in problem is of most concern in protocols that transmit the username in
clear-text across the Internet, such as in RADIUS, described in clear-text across the Internet, such as in RADIUS, described in
[RFC2865] and [RFC2866]. In order to prevent snooping of the [RFC2865] and [RFC2866]. In order to prevent snooping of the
username, protocols may use confidentiality services provided by username, protocols may use confidentiality services provided by
protocols transporting them, such as RADIUS protected by IPsec protocols transporting them, such as RADIUS protected by IPsec
[RFC3579] or Diameter protected by TLS [RFC3588]. [RFC3579] or Diameter protected by TLS [RFC6733].
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.4, this is in the NAI, by omitting it. As discussed in Section 2.4, 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 also been used with NAIs. For instance, some EAP methods apply
method-specific pseudonyms in the username part of the NAI [RFC3748]. method-specific pseudonyms in the username part of the NAI [RFC3748].
While neither of these approaches can protect the realm part, their While neither of these approaches can protect the realm part, their
advantage over transport protection is that privacy of the username advantage over transport protection is that privacy of the username
is protected, even through intermediate nodes such as NASes. is protected, even through intermediate nodes such as NASes.
5. IANA Considerations 5. Administration of Names
In order to avoid creating any new administrative procedures, In order 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. Administrators MUST NOT
ownership of the corresponding FQDN creates the possibility of publicly use an NAI realm without first owning the corresponding
conflict and is therefore discouraged. FQDN. Private use of unowned NAI realms within an administative
domain is allowed, though it is RECOMMENDED that example names be
used, such as "example.com".
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 [RFC6733] 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
a domain and perform authentication routing. The implementations a domain and perform authentication routing. The implementations
described in [RFC2194] did not use DNS for location of the described in [RFC2194] did not use DNS for location of the
authentication server within a domain. Similarly, existing authentication server within a domain. Similarly, existing
implementations have not found a need for dynamic routing protocols implementations have not found a need for dynamic routing protocols
or propagation of global routing information. Note also that there or propagation of global routing information. Note also that there
is no requirement that the NAI represent a valid email address. is no requirement that the NAI represent a valid email address.
6. References 6. IANA Considerations
6.1. Normative References This document has no actions for IANA.
7. References
7.1. Normative References
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997. Levels", RFC 2119, March, 1997.
[RFC3629] [RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63,
RFC 3629, November 2003. RFC 3629, November 2003.
[RFC5198] [RFC5198]
skipping to change at page 21, line 17 skipping to change at page 21, line 21
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[RFC5890] [RFC5890]
Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 5890, August 2010 Domain Names in Applications (IDNA)", RFC 5890, August 2010
[RFC6365] [RFC6365]
Hoffman, P., and Klensin, J., "Terminology Used in Hoffman, P., and Klensin, J., "Terminology Used in
Internationalization in the IETF", RFC 6365, September 2011 Internationalization in the IETF", RFC 6365, September 2011
6.2. Informative References 7.2. Informative References
[RFC2194] [RFC2194]
Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997. Roaming Implementations", RFC 2194, September 1997.
[RFC2341] [RFC2341]
Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) "L2F"", RFC 2341, May 1998. Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2637] [RFC2637]
skipping to change at page 21, line 48 skipping to change at page 22, line 5
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866] [RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3579] [RFC3579]
Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[RFC3588]
Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] [RFC3748]
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004. June 2004.
[RFC4282] [RFC4282]
Aboba, B. et al., "The Network Access Identifier", RFC 4282, Aboba, B. et al., "The Network Access Identifier", RFC 4282,
December 2005. December 2005.
[RFC4301] [RFC4301]
skipping to change at page 22, line 33 skipping to change at page 22, line 33
http://eduroam.org, "eduroam (EDUcational ROAMing)" http://eduroam.org, "eduroam (EDUcational ROAMing)"
[RFC5891] [RFC5891]
Klensin, J., "Internationalized Domain Names in Applications Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", RFC 5891 (IDNA): Protocol", RFC 5891
[RFC6055] [RFC6055]
Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized
Domain Names", RFC 6055, February 2011. Domain Names", RFC 6055, February 2011.
[CODEPOINTS] [RFC6733]
V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October
2012.
[RFC6912]
Sullivan, A., et al, "Principles for Unicode Code Point Inclusion Sullivan, A., et al, "Principles for Unicode Code Point Inclusion
in Labels in the DNS", draft-iab-dns-zone-codepoint-pples, work in in Labels in the DNS", RFC 6912, April 2013.
progress.
Acknowledgments Acknowledgments
The initial text for this document was [RFC4282], which was then The initial text for this document was [RFC4282], which was then
heavily edited. The original authors of [RFC4282] were Bernard heavily edited. The original authors of [RFC4282] were Bernard
Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
The ABNF validator at http://www.apps.ietf.org/abnf.html was used to The ABNF validator at http://www.apps.ietf.org/abnf.html was used to
verify the syntactic correctness of the ABNF in Section 2. verify the syntactic correctness of the ABNF in Section 2.
 End of changes. 23 change blocks. 
38 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/