--- 1/draft-ietf-radext-nai-09.txt 2014-10-30 08:15:00.947281585 -0700 +++ 2/draft-ietf-radext-nai-10.txt 2014-10-30 08:15:00.995282731 -0700 @@ -1,31 +1,31 @@ RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - + 29 October 2014 The Network Access Identifier - draft-ietf-radext-nai-09 + draft-ietf-radext-nai-10 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 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. + 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 + 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 other groups may also distribute working documents as Internet- Drafts. @@ -71,47 +71,47 @@ than English. Table of Contents 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 .......................................... 8 -2. NAI Definition ........................................... 8 +2. NAI Definition ........................................... 9 2.1. UTF-8 Syntax and Normalization ...................... 9 - 2.2. Formal Syntax ....................................... 9 + 2.2. Formal Syntax ....................................... 10 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 2.8. Using the NAI format for other identifiers .......... 15 3. Routing inside of AAA Systems ............................ 16 3.1. Compatibility with Email Usernames .................. 17 3.2. Compatibility with DNS .............................. 17 3.3. Realm Construction .................................. 18 - 3.3.1. Historical Practices ........................... 18 + 3.3.1. Historical Practices ........................... 19 3.4. Examples ............................................ 19 4. Security Considerations .................................. 20 5. Administration of Names .................................. 21 6. IANA Considerations ...................................... 21 7. References ............................................... 21 7.1. Normative References ................................ 21 7.2. Informative References .............................. 22 -Appendix A - Changes from RFC4282 ............................ 24 +Appendix A - Changes from RFC4282 ............................ 25 1. Introduction 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 authentication, 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 particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area. * National ISPs wishing to combine their operations with those of @@ -184,45 +184,45 @@ Text which is either in non-UTF-8, or in non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. The client which "knows" the locale may have a different concept of this text than other AAA entities, which do not know the same locale. Network Access Identifier The Network Access Identifier (NAI) is the user identity submitted - by the client during network access authentication. The purpose - of the NAI is to identify the user as well as to assist in the - routing of the authentication request. Please note that the NAI - may not necessarily be the same as the user's email address or the - user identity submitted in an application layer authentication. + by a client during authentication. The purpose of the NAI is to + identify the user as well as to assist in the routing of the + authentication request. Please note that the NAI may not + necessarily be the same as the user's email address or the user + identity submitted in an application layer authentication. Network Access Server The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point. Roaming Capability Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. - Normalization Canonicalization + Normalization or Canonicalization These terms are defined in [RFC6365] Section 4. We incorporate the definitions here by reference. Locale This term is defined in [RFC6365] Section 8. We incorporate the definition here by reference. Tunneling Service @@ -298,37 +298,40 @@ The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms which limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with the ToASCII operation defined in [RFC5890]. There are a number of problems with this approach: * The [RFC4282] ABNF is not aligned with internationalization of DNS. - * The requirement in Section 2.1 that realms are ASCII conflicts - with the Extensible Authentication Protocol (EAP) and RADIUS, - which are both 8-bit clean, and which both recommend the use of - UTF-8 for identitifiers. + * The requirement in [RFC4282] Section 2.1 that realms are ASCII + conflicts with the Extensible Authentication Protocol (EAP) and + RADIUS, which are both 8-bit clean, and which both recommend the + use of UTF-8 for identitifiers. - * Section 2.4 required mappings that are language-specific, - and which are nearly impossible for intermediate nodes to perform - correctly without information about that language. + * [RFC4282] Section 2.4 required mappings that are + language-specific, and which are nearly impossible for + intermediate nodes to perform correctly without information about + that language. - * Section 2.4 requires normalization of user names, which - may conflict with local system or administrative requirements. + * [RFC4282] Section 2.4 requires normalization of user names, + which may conflict with local system or administrative + requirements. - * The recommendations in Section 2.4 for treatment of + * The recommendations in RFC4282] Section 2.4 for treatment of bidirectional characters have proven to be unworkable. * The prohibition against use of unassigned code points in - Section 2.4 effectively prohibits support for new scripts. + RFC4282] Section 2.4 effectively prohibits support for new + scripts. * No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in [RFC4282] Section 2.4, among other sections. With international roaming growing in popularity, it is important for these issues to be corrected in order to provide robust and inter- operable network services. 2. NAI Definition