--- 1/draft-ietf-radext-nai-05.txt 2014-06-17 15:14:26.597502893 -0700 +++ 2/draft-ietf-radext-nai-06.txt 2014-06-17 15:14:26.641503961 -0700 @@ -1,29 +1,29 @@ -Network Working Group DeKok, Alan +RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -6 November 2013 + +17 June 2014 The Network Access Identifier - draft-ietf-radext-nai-05 + draft-ietf-radext-nai-06 Abstract In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to - identify each others users. This document defines the syntax for the - Network Access Identifier (NAI), the user identity submitted by the - client prior to accessing network resources. This document is a - revised version of RFC 4282 [RFC4282], which addresses issues with + identify each other's users. This document defines the syntax for + the Network Access Identifier (NAI), the user identity submitted by + the client prior to accessing network 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 previous document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -34,25 +34,25 @@ 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 May 6, 2014. + This Internet-Draft will expire on January 17, 2015. 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. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -65,47 +65,47 @@ modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents -3. ........................................................... 3 Appendix A - Changes from RFC4282 ............................ 3 1. Introduction ............................................. 4 1.1. Terminology ......................................... 5 1.2. Requirements Language ............................... 6 1.3. Purpose ............................................. 7 1.4. Motivation .......................................... 7 2. NAI Definition ........................................... 8 2.1. UTF-8 Syntax and Normalization ...................... 8 2.2. Formal Syntax ....................................... 9 2.3. NAI Length Considerations ........................... 10 2.4. Support for Username Privacy ........................ 11 2.5. International Character Sets ........................ 11 2.6. The Normalization Process ........................... 12 2.6.1. Issues with the Normalization Process .......... 13 2.7. Use in Other Protocols .............................. 14 -3. ........................................................... 15 +3. Routing inside of AAA Systems ............................ 15 3.1. Compatibility with Email Usernames .................. 16 3.2. Compatibility with DNS .............................. 16 3.3. Realm Construction .................................. 17 3.3.1. Historical Practices ........................... 18 3.4. Examples ............................................ 18 4. Security Considerations .................................. 19 -5. IANA Considerations ...................................... 20 -6. References ............................................... 20 - 6.1. Normative References ................................ 20 - 6.2. Informative References .............................. 21 +5. Administration of Names .................................. 20 +6. IANA Considerations ...................................... 20 +7. References ............................................... 20 + 7.1. Normative References ................................ 20 + 7.2. Informative References .............................. 21 Appendix A - Changes from RFC4282 ............................ 23 1. Introduction Considerable interest exists for a set of features that fit within the general category of inter-domain authentiction, or "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included the following: * Regional Internet Service Providers (ISPs) operating within a @@ -221,22 +221,23 @@ Tunneling Service A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One example of a tunneling service is secure access to corporate intranets via a Virtual Private Network (VPN). 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. 1.3. Purpose As described in [RFC2194], there are a number of providers offering network access services, and the number of Internet Service Providers involved in roaming consortia is increasing rapidly. In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the @@ -415,21 +416,21 @@ Remote Authentication Dial-In User Service (RADIUS) protocol. Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the ability to handle at least 63 octets is recommended." As a result, it may not be possible to transfer NAIs beyond 63 octets through all devices. In addition, since only a single User-Name attribute may be included in a RADIUS message and the maximum attribute length is 253 octets; RADIUS is unable to support NAI lengths beyond 253 octets. * 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 very long. However, an NAI transported over Diameter may eventually be translated to RADIUS, in which case the above limitations will apply. * NAIs may be transported in other protocols. Each protocol can have its own limitations on maximum NAI length. The above criteria should permit the widest use, and widest possible inter-operability of the NAI. @@ -478,21 +479,21 @@ insufficient information, which meant that the form was not canonical. Specifying the realm requirement as above means that the requirements depend on specifications that are referenced here, rather than copied here. This allows the realm definition to be updated when the referenced documents change, without requiring a revision of this specification. 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 from being valid in a DNS U-label. These restrictions cannot be expressed algorithmically. For this specification, that caveat means the following. Realms not matching the above ABNF are not valid NAIs. However, some realms which do match the ABNF are still invalid NAIs. That is, matching the ABNF is a necessary, but not sufficient, requirement for an NAI. In general, the above requirement means following the requirements @@ -619,21 +620,21 @@ For example, HTTP carries user identifiers, but escapes the '.' character as "%2E" (among others). When we desire HTTP to transport the NAI "fred@example.com", the data as transported will be in the form "fred@example%2Ecom". That data exists only within HTTP, and has no relevance to any AAA system. Any comparison, validation, or use of the NAI MUST be done on its un- 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 requests within a AAA proxy network. The semantics of this operation 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 "next hop" AAA servers. Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to perform this lookup. As noted earlier, intermediate nodes may not have access to the same locale information @@ -841,62 +842,67 @@ 4. Security Considerations Since an NAI reveals the home affiliation of a user, it may assist an attacker in further probing the username space. Typically, this problem is of most concern in protocols that transmit the username in clear-text across the Internet, such as in RADIUS, described in [RFC2865] and [RFC2866]. In order to prevent snooping of the username, protocols may use confidentiality services provided by 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 in the NAI, by omitting it. As discussed in Section 2.4, this is possible only when NAIs are used together with a separate authentication method that can transfer the username in a secure manner. In some cases, application-specific privacy mechanism have also been used with NAIs. For instance, some EAP methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. While neither of these approaches can protect the realm part, their advantage over transport protection is that privacy of the username 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, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace. NAI realm names are required to be unique, and the rights to use a given NAI realm for roaming purposes are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Those wishing to use an NAI realm name should first acquire - the rights to use the corresponding FQDN. Using an NAI realm without - ownership of the corresponding FQDN creates the possibility of - conflict and is therefore discouraged. + the rights to use the corresponding FQDN. Administrators MUST NOT + publicly use an NAI realm without first owning the corresponding + 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 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 configuration files in order to locate authentication servers within a domain and perform authentication routing. The implementations described in [RFC2194] did not use DNS for location of the authentication server within a domain. Similarly, existing implementations have not found a need for dynamic routing protocols or propagation of global routing information. Note also that there 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5198] @@ -908,21 +914,21 @@ Specifications: ABNF", RFC 5234, January 2008. [RFC5890] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 5890, August 2010 [RFC6365] Hoffman, P., and Klensin, J., "Terminology Used in Internationalization in the IETF", RFC 6365, September 2011 -6.2. Informative References +7.2. Informative References [RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. [RFC2637] @@ -939,24 +945,20 @@ Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (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] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4282] Aboba, B. et al., "The Network Access Identifier", RFC 4282, December 2005. [RFC4301] @@ -971,24 +973,27 @@ http://eduroam.org, "eduroam (EDUcational ROAMing)" [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891 [RFC6055] Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized 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 - in Labels in the DNS", draft-iab-dns-zone-codepoint-pples, work in - progress. + in Labels in the DNS", RFC 6912, April 2013. Acknowledgments The initial text for this document was [RFC4282], which was then heavily edited. The original authors of [RFC4282] were Bernard Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. The ABNF validator at http://www.apps.ietf.org/abnf.html was used to verify the syntactic correctness of the ABNF in Section 2.