--- 1/draft-ietf-radext-nai-14.txt 2014-12-17 07:14:52.166476135 -0800 +++ 2/draft-ietf-radext-nai-15.txt 2014-12-17 07:14:52.218477384 -0800 @@ -1,20 +1,20 @@ RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -4 December 2014 + +17 December 2014 The Network Access Identifier - draft-ietf-radext-nai-14 + draft-ietf-radext-nai-15 Abstract In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the @@ -34,21 +34,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -87,29 +87,29 @@ 2.6. The Normalization Process ........................... 14 2.6.1. Issues with the Normalization Process .......... 15 2.7. Use in Other Protocols .............................. 16 2.8. Using the NAI format for other identifiers .......... 17 3. Routing inside of AAA Systems ............................ 18 3.1. Compatibility with Email Usernames .................. 19 3.2. Compatibility with DNS .............................. 19 3.3. Realm Construction .................................. 20 3.3.1. Historical Practices ........................... 21 3.4. Examples ............................................ 22 -4. Security Considerations .................................. 22 +4. Security Considerations .................................. 23 4.1. Correlation of Identities over Time and Protocols ... 23 4.2. Multiple Identifiers ................................ 23 5. Administration of Names .................................. 24 6. IANA Considerations ...................................... 25 7. References ............................................... 25 7.1. Normative References ................................ 25 - 7.2. Informative References .............................. 25 -Appendix A - Changes from RFC4282 ............................ 28 + 7.2. Informative References .............................. 26 +Appendix A - Changes from RFC4282 ............................ 29 1. Introduction Considerable interest exists for a set of features that fit within the general category of inter-domain authentication, or "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. By "inter-domain authentication", this document refers to situations where a user has authentication credentials at one "home" domain, but @@ -892,22 +892,24 @@ other realm may depend on the user's location or the desired application. The use of the home realm MUST be the default unless otherwise configured. 3.3.1. Historical Practices Some AAA systems have historically used NAI modifications with multiple "prefix" and "suffix" decorations to perform explicit - routing through multiple proxies inside of a AAA network. This - practice is NOT RECOMMENDED for the following reasons: + routing through multiple proxies inside of a AAA network. + + 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 changes in the network due to servers going up or down, or to changing business relationships. * There is no RADIUS routing protocol, meaning that routing paths have to be communicated "out of band" to all intermediate AAA nodes, and also to all edge systems (e.g. supplicants) expecting to obtain network access. @@ -930,26 +932,37 @@ * Leveraging the DNS name system for realm names establishes a globally unique name space for realms. In summary, network practices and capabilities have changed significantly since NAIs were first overloaded to define AAA routes through a network. While manually managed explicit path routing was once useful, the time has come for better methods to be used. Notwithstanding the above recommendations, the above practice is widely used for Diameter routing [RFC5729]. The routes described - there are managed automatically, from both credential provisioning - and routing updates. Those routes also exist within a particular + there are managed automatically, for both credential provisioning and + routing updates. Those routes also exist within a particular framework (typically 3G), where membership is controlled and system behavior is standardized. There are no known issues with using 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 Examples of valid Network Access Identifiers include the following: bob joe@example.com fred@foo-9.example.com jack@3rd.depts.example.com fred.smith@example.com fred_smith@example.com @@ -1176,35 +1189,43 @@ Aboba, B. et al., "The Network Access Identifier", RFC 4282, December 2005. [RFC4301] Kent, S. and S. Keo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5281] Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 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] Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, September 2008. [RFC5729] Korhohen, J. (Ed) et. al., "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009 [RFC6055] Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011. +[RFC6532] + Yang, A., et al, "Internationalized Email Headers", RFC 6532, + February 2012. + [RFC6733] V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October 2012. [RFC6912] Sullivan, A., et al, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, April 2013. [EDUROAM] http://eduroam.org, "eduroam (EDUcational ROAMing)"