draft-ietf-radext-nai-14.txt   draft-ietf-radext-nai-15.txt 
RADEXT 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-14.txt> <draft-ietf-radext-nai-15.txt>
4 December 2014 17 December 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-14 draft-ietf-radext-nai-15
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 other's users. This document defines the syntax for identify each other's users. This document defines the syntax for
the Network Access Identifier (NAI), the user identifier submitted by the Network Access Identifier (NAI), the user identifier submitted by
the client prior to accessing resources. This document is a revised the client prior to accessing resources. This document is a revised
version of RFC 4282, which addresses issues with international version of RFC 4282, which addresses issues with international
character sets, as well as a number of other corrections to the character sets, as well as a number of other corrections to the
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 June 04, 2015. This Internet-Draft will expire on June 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
2.6. The Normalization Process ........................... 14 2.6. The Normalization Process ........................... 14
2.6.1. Issues with the Normalization Process .......... 15 2.6.1. Issues with the Normalization Process .......... 15
2.7. Use in Other Protocols .............................. 16 2.7. Use in Other Protocols .............................. 16
2.8. Using the NAI format for other identifiers .......... 17 2.8. Using the NAI format for other identifiers .......... 17
3. Routing inside of AAA Systems ............................ 18 3. Routing inside of AAA Systems ............................ 18
3.1. Compatibility with Email Usernames .................. 19 3.1. Compatibility with Email Usernames .................. 19
3.2. Compatibility with DNS .............................. 19 3.2. Compatibility with DNS .............................. 19
3.3. Realm Construction .................................. 20 3.3. Realm Construction .................................. 20
3.3.1. Historical Practices ........................... 21 3.3.1. Historical Practices ........................... 21
3.4. Examples ............................................ 22 3.4. Examples ............................................ 22
4. Security Considerations .................................. 22 4. Security Considerations .................................. 23
4.1. Correlation of Identities over Time and Protocols ... 23 4.1. Correlation of Identities over Time and Protocols ... 23
4.2. Multiple Identifiers ................................ 23 4.2. Multiple Identifiers ................................ 23
5. Administration of Names .................................. 24 5. Administration of Names .................................. 24
6. IANA Considerations ...................................... 25 6. IANA Considerations ...................................... 25
7. References ............................................... 25 7. References ............................................... 25
7.1. Normative References ................................ 25 7.1. Normative References ................................ 25
7.2. Informative References .............................. 25 7.2. Informative References .............................. 26
Appendix A - Changes from RFC4282 ............................ 28 Appendix A - Changes from RFC4282 ............................ 29
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 authentication, or "roaming the general category of inter-domain authentication, 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. other applications.
By "inter-domain authentication", this document refers to situations By "inter-domain authentication", this document refers to situations
where a user has authentication credentials at one "home" domain, but where a user has authentication credentials at one "home" domain, but
skipping to change at page 21, line 9 skipping to change at page 21, line 9
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.
3.3.1. Historical Practices 3.3.1. Historical Practices
Some AAA systems have historically used NAI modifications with Some AAA systems have historically used NAI modifications with
multiple "prefix" and "suffix" decorations to perform explicit multiple "prefix" and "suffix" decorations to perform explicit
routing through multiple proxies inside of a AAA network. This routing through multiple proxies inside of a AAA network.
practice is NOT RECOMMENDED for the following reasons:
In RADIUS based environment, the use of decorated NAI is NOT
RECOMMENDED for the following reasons:
* Using explicit routing paths is fragile, and is unresponsive to * Using explicit routing paths is fragile, and is unresponsive to
changes in the network due to servers going up or down, or to changes in the network due to servers going up or down, or to
changing business relationships. changing business relationships.
* There is no RADIUS routing protocol, meaning that routing paths * There is no RADIUS routing protocol, meaning that routing paths
have to be communicated "out of band" to all intermediate AAA have to be communicated "out of band" to all intermediate AAA
nodes, and also to all edge systems (e.g. supplicants) expecting nodes, and also to all edge systems (e.g. supplicants) expecting
to obtain network access. to obtain network access.
skipping to change at page 21, line 47 skipping to change at page 21, line 49
* Leveraging the DNS name system for realm names establishes * Leveraging the DNS name system for realm names establishes
a globally unique name space for realms. a globally unique name space for realms.
In summary, network practices and capabilities have changed In summary, network practices and capabilities have changed
significantly since NAIs were first overloaded to define AAA routes significantly since NAIs were first overloaded to define AAA routes
through a network. While manually managed explicit path routing was through a network. While manually managed explicit path routing was
once useful, the time has come for better methods to be used. once useful, the time has come for better methods to be used.
Notwithstanding the above recommendations, the above practice is Notwithstanding the above recommendations, the above practice is
widely used for Diameter routing [RFC5729]. The routes described widely used for Diameter routing [RFC5729]. The routes described
there are managed automatically, from both credential provisioning there are managed automatically, for both credential provisioning and
and routing updates. Those routes also exist within a particular routing updates. Those routes also exist within a particular
framework (typically 3G), where membership is controlled and system framework (typically 3G), where membership is controlled and system
behavior is standardized. There are no known issues with using behavior is standardized. There are no known issues with using
explicit routing in such an environment. explicit routing in such an environment.
However, if decorated identifiers are used, such as:
homerealm.example.org!user@otherrealm.example.net
Then the part before the (non-escaped) '!' MUST be a "utf8-realm" as
defined in the ABNF in Section 2.2. When receiving such an
identifier, the "otherrealm.example.net" system MUST convert the
identifier to "user@homerealm.example.org" before forwarding the
request. The forwarding system MUST then apply normal AAA routing
for the transaction, based on the updated identifier.
3.4. Examples 3.4. Examples
Examples of valid Network Access Identifiers include the following: Examples of valid Network Access Identifiers include the following:
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 27, line 4 skipping to change at page 27, line 16
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]
Kent, S. and S. Keo, "Security Architecture for the Internet Kent, S. and S. Keo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[RFC5281] [RFC5281]
Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol
Tunneled Transport Layer Security Authenticated Protocol Version 0 Tunneled Transport Layer Security Authenticated Protocol Version 0
(EAP-TTLSv0)", RFC 5281, August 2008/ (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5322]
Resnick, P. (Ed), "Internet Message Format", RFC 5322, October
2008.
[RFC5335] [RFC5335]
Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, Y. Abel, Ed., "Internationalized Email Headers", RFC 5335,
September 2008. September 2008.
[RFC5729] [RFC5729]
Korhohen, J. (Ed) et. al., "Clarifications on the Routing of Korhohen, J. (Ed) et. al., "Clarifications on the Routing of
Diameter Requests Based on the Username and the Realm", RFC 5729, Diameter Requests Based on the Username and the Realm", RFC 5729,
December 2009 December 2009
[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.
[RFC6532]
Yang, A., et al, "Internationalized Email Headers", RFC 6532,
February 2012.
[RFC6733] [RFC6733]
V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October
2012. 2012.
[RFC6912] [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", RFC 6912, April 2013. in Labels in the DNS", RFC 6912, April 2013.
[EDUROAM] [EDUROAM]
http://eduroam.org, "eduroam (EDUcational ROAMing)" http://eduroam.org, "eduroam (EDUcational ROAMing)"
 End of changes. 10 change blocks. 
12 lines changed or deleted 33 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/