--- 1/draft-ietf-radext-nai-01.txt 2013-01-28 17:16:28.460040999 +0100 +++ 2/draft-ietf-radext-nai-02.txt 2013-01-28 17:16:28.492041642 +0100 @@ -1,20 +1,20 @@ Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -8 January 2013 + +28 January 2013 The Network Access Identifier - draft-ietf-radext-nai-01 + draft-ietf-radext-nai-02 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 international character sets, as well as a number of other @@ -67,44 +67,44 @@ 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 Appendix A - Changes from RFC4282 ............................ 3 1. Introduction ............................................. 4 - 1.1. Terminology ......................................... 4 - 1.2. Requirements Language ............................... 5 - 1.3. Purpose ............................................. 6 - 1.4. Motivation .......................................... 6 -2. NAI Definition ........................................... 7 - 2.1. UTF-8 Syntax and Normalization ...................... 7 - 2.2. Formal Syntax ....................................... 7 - 2.3. NAI Length Considerations ........................... 8 - 2.4. Support for Username Privacy ........................ 9 - 2.5. International Character Sets ........................ 9 - 2.6. The Normalization Process ........................... 10 - 2.7. Use in Other Protocols .............................. 11 - 2.8. Routing inside of AAA Systems ....................... 11 - 2.9. Compatibility with Email Usernames .................. 12 - 2.10. Compatibility with DNS ............................. 12 - 2.11. Realm Construction ................................. 13 - 2.11.1. Historical Practices .......................... 14 - 2.12. Examples ........................................... 15 -3. Security Considerations .................................. 15 -4. IANA Considerations ...................................... 16 -5. References ............................................... 16 - 5.1. Normative References ................................ 16 - 5.2. Informative References .............................. 17 -Appendix A - Changes from RFC4282 ............................ 19 + 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 ....................................... 8 + 2.3. NAI Length Considerations ........................... 9 + 2.4. Support for Username Privacy ........................ 10 + 2.5. International Character Sets ........................ 10 + 2.6. The Normalization Process ........................... 11 + 2.7. Use in Other Protocols .............................. 12 + 2.8. Routing inside of AAA Systems ....................... 12 + 2.9. Compatibility with Email Usernames .................. 13 + 2.10. Compatibility with DNS ............................. 14 + 2.11. Realm Construction ................................. 15 + 2.11.1. Historical Practices .......................... 15 + 2.12. Examples ........................................... 16 +3. Security Considerations .................................. 17 +4. IANA Considerations ...................................... 17 +5. References ............................................... 18 + 5.1. Normative References ................................ 18 + 5.2. Informative References .............................. 18 +Appendix A - Changes from RFC4282 ............................ 21 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 particular state or province, looking to combine their efforts @@ -128,34 +128,45 @@ * Other protocols which are interested in leveraging the users credentials in order to take advantage of an existing authentication framework. In order to enhance the interoperability of these services, it is necessary to have a standardized method for identifying users. This document defines syntax for the Network Access Identifier (NAI). Examples of implementations that use the NAI, and descriptions of its semantics, can be found in [RFC2194]. + The goal of this document is to define the format of an identifier + which can be used in many protocols. A protocol may transport an + encoded version of the NAI (e.g. '.' as %2E). However, the + definition of the NAI is protocol independent. We hope to encourage + the wide-spread adoption of the NAI as an identifier. This adoption + will decrease work required to leverage identification and + authentication in other protocols. It will also decrease the + complexity of systems for end users and administrators. + This document is a revised version of [RFC4282], which originally defined internationalized NAIs. Differences and enhancements compared to that document are listed in Appendix A. 1.1. Terminology This document frequently uses the following terms: - "local" or "localized" text + "Local" or "localized" text 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. + 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. @@ -218,41 +229,41 @@ changes. 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: - o The [RFC4282] ABNF is not aligned with internationalization of DNS. + * The [RFC4282] ABNF is not aligned with internationalization of DNS. - o The requirement in Section 2.1 that realms are ASCII conflicts + * 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 identities. - o Section 2.4 required mappings that are language-specific, + * 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. - o Section 2.4 requires normalization of user names, which + * Section 2.4 requires normalization of user names, which may conflict with local system or administrative requirements. - o The recommendations in Section 2.4 for treatment of + * The recommendations in Section 2.4 for treatment of bidirectional characters have proven to be unworkable. - o The prohibition against use of unassigned code points in + * The prohibition against use of unassigned code points in Section 2.4 effectively prohibits support for new scripts. - o No Authentication, Authorization, and Accounting (AAA) + * 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 2.1. UTF-8 Syntax and Normalization @@ -375,21 +386,21 @@ This specification allows both international usernames and realms. International usernames are based on the use of Unicode characters, encoded as UTF-8. Internationalization of the realm portion of the NAI is based on "Internationalized Email Headers" [RFC5335]. In order to ensure a canonical representation, characters of the username portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. In practice, these requirements consist of the following item: - o Realms MUST be of the form that can be registered as a + * Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended on intermediate nodes performing canonicalizations based on insufficient information, which meant that the form was not canonical. This document instead suggests (Section 2.10) that the realm owner provide a canonical form of the realm, and that all intermediate nodes use that form without modification. @@ -453,58 +464,78 @@ interoperability, along with the users ability to authenticate successfully. It is RECOMMENDED that protocols requiring the use of a user identifier reference this specification, and suggest that the use of an NAI is RECOMMENDED. We cannot require other protocols to use the NAI for user identifiers. Their needs are unknown, and unknowable. We simply suggest that interoperability and inter-domain authentication is useful, and should be encouraged. + Where a protocol is 8-bit clean, it can likely transport the NAI as- + is, without further modification. + Where a protocol is not 8-bit clean, it MUST NOT affect the definition or handling of the NAI. That is, if a protocol escapes the '.' character as "%2E", then the protocol may have an identifier transported as "fred@example%2Ecom", whereas the NAI for that user is "fred@example.com". Any comparison, validation, or use of the NAI MUST be done on its un-escaped (i.e. utf8-clean) form. 2.8. 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. Comparisons between the NAI as given in a AAA packet, and as provisioned in a logical AAA - routing table SHOULD be done as a byte-for-byte equality test. The - "utf8-realm" provisioned in the logical AAA routing table SHOULD be - provisioned prior to the proxy receiving any AAA traffic, and SHOULD - be supplied by the "next hop" system that also supplies the other - information about the next hop. + routing table SHOULD be done as a byte-for-byte equality test. As + noted earlier, intermediate nodes may not have access to the same + locale information as the system which injected the NAI into the AAA + routing systems. Therefore, almost all "case insensitive" + comparisons will be wrong. Where the "utf8-realm" is entirely ASCII, + current systems sometimes perform case-insensitive matching on + realms. This practice MAY be continued, as it has been shown to work + in practice. + + The "utf8-realm" provisioned in the logical AAA routing table SHOULD + be provisioned to the proxy prior to it receiving any AAA traffic. + The "utf8-realm" SHOULD be supplied by the "next hop" system that + also supplies the other information, necessary to reach the next hop. This "next hop" information may be any of, or all of, the following information: IP address; port; RADIUS shared secret; TLS certificate; DNS host name; or instruction to use dyanmic DNS discovery (i.e. look - up a record in the "utf8-realm" domain). + up a record in the "utf8-realm" domain). This list is not + exhaustive, and my be extended by future specifications. It is RECOMMENDED to use the entirety of the "utf8-realm" for the routing decisions. However, systems MAY use a portion of the "utf8-realm" portion, so long as that portion is a valid "utf8-realm", and that portion is handled as above. For example, routing "fred@example.com" to a "com" destination is forbidden, because "com" is not a valid "utf8-realm". However, routing "fred@sales.example.com" to the "example.com" destination is permissible. + Another reason to forbid the use of a single label (e.g. + "fred@sales") is that many systems treat a single label as being a + local identifier within their realm. That is, a user logging in as + "fred@sales" to a domain "example.com", would be treated as if the + NAI was instead "fred@sales.example.com". Permitting the use of a + single label would mean changing the interpretation and meaning of a + single label, which cannot be done. + 2.9. Compatibility with Email Usernames As proposed in this document, the Network Access Identifier is of the form "user@realm". Please note that while the user portion of the NAI is based on the BNF described in [RFC5198], it has been modified for the purposes of Section 2.2. It does not permit quoted text along with "folding" or "non-folding" whitespace that is commonly used in email addresses. As such, the NAI is not necessarily equivalent to usernames used in e-mail. @@ -516,26 +547,28 @@ In contrast to [RFC4282] Section 2.5, we state that the internationalization requirements for NAIs and email addresses are substantially similar. The NAI and email identifiers may be the same, and both need to be entered by the user and/or the operator supplying network access to that user. There is therefore good reason for the internationalization requirements to be similar. 2.10. Compatibility with DNS The "utf8-realm" portion of the NAI is intended to be compatible with - Internationalized Domain Names [RFC5890]. As defined above, the - "utf8-realm" portion as transported within the RADIUS User-Name - attribute is composed of U-labels, not A-labels. There is therefore - no reason for a NAS to apply the ToAscii function to the "utf8-realm" - portion of an NAI, prior to placing the NAI into a RADIUS User-Name - attribute. + Internationalized Domain Names (IDNs) [RFC5890]. As defined above, + the "utf8-realm" portion as transported within an 8-bit clean + protocol such as RADIUS and EAP can contain any valid UTF8 character. + There is therefore no reason for a NAS to apply the ToAscii function + to the "utf8-realm" portion of an NAI, prior to placing the NAI into + a RADIUS User-Name attribute. Unlike DNS, the NAI does not make a + distinction between A-labels and U-labels. Is instead an IDNA-valid + label, as per Section 2.3.2.1 of [RFC5890]. When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to ASCII using the ToASCII operation defined in [RFC5890]. As noted in [RFC6055] Section 2, resolver Application Programming Interfaces (APIs) are not necessarily DNS-specific, so that the ToASCII operation needs to be applied carefully: Applications which convert an IDN to A-label form before calling (for example) getaddrinfo() will result in name resolution failures if the @@ -818,36 +851,37 @@ * The formal syntax in Section 2.1 has been updated to allow UTF-8 in the "realm" portion of the NAI. * The formal syntax in [RFC4282] Section 2.1 applied to the NAI after it was "internationalized" via the ToAscii function. The contents of the NAI before it was "internationalized" were left indeterminate. This document updates the formal syntax to define an internationalized form of the NAI, and forbids the use of the ToAscii function for NAI "internationalization". - o The grammar for the user and realm portion is based on a + * The grammar for the user and realm portion is based on a combination of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- spec" defined in [RFC5335] Section 4.4. * All use of the ToAscii function has been moved to normal requirements on DNS implementations when realms are used as the basis for DNS lookups. This involves no changes to the existing DNS infrastructure. * The discussions on internationalized character sets in Section 2.4 have been updated. The suggestion to use the ToAscii function for - realm comparisons has been removed. No AAA system implemented the - suggestion, so this change should have no operational impact. + realm comparisons has been removed. No AAA system has implemented + these suggestions, so this change should have no operational + impact. - o The section "Routing inside of AAA Systems" section is new in this + * The section "Routing inside of AAA Systems" section is new in this document. The concept of a "local AAA routing table" is also new, although it accurately describes the functionality of wide-spread implementations. * The "Compatibility with EMail Usernames" and "Compatibility with DNS" sections have been revised and updated. We now note that the ToAscii function is suggested to be used only when a realm name is used for DNS lookups, and even then the function is only used by a resolving API on the local system, and even then we recommend that only the home network perform this conversion.