--- 1/draft-ietf-radext-nai-07.txt 2014-09-24 07:14:41.219086084 -0700 +++ 2/draft-ietf-radext-nai-08.txt 2014-09-24 07:14:41.271087354 -0700 @@ -1,20 +1,20 @@ RADEXT Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track - -23 September 2014 + +24 September 2014 The Network Access Identifier - draft-ietf-radext-nai-07 + draft-ietf-radext-nai-08 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 @@ -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 23, 2015. + This Internet-Draft will expire on June 24, 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 @@ -536,37 +536,34 @@ As a result, AAA proxies expect the contents of the EAP- Response/Identity sent by an EAP supplicant to consist of UTF-8 characters, not localized text. Using localized text in AAA username or identity fields means that realm routing becomes difficult or impossible. In contrast to [RFC4282] Section 2.4, we expect AAA systems to perform NAI comparisons, matching, and AAA routing based on the NAI as it is received. This specification provides a canonical representation, ensures that intermediate systems such as AAA proxies - do not need to perform translations, and can be expected to work + are not required to perform translations, and can be expected to work through systems that are unaware of international character sets. - In short, + In an ideal world, the following requirements would be widely + implemented: * End systems using "localized" text SHOULD normalize the NAI prior to it being used as an identifier in an authentication protocol. * AAA systems SHOULD NOT normalize the NAI, as they may not have sufficient information to perform the normalization. - For example, much of the common realm routing can be done on the - "utf8-realm" portion of NAI, through simple checks for equality. - This routing can be done even if the AAA proxy is unaware of - internalized domain names. All that is required is for the AAA proxy - to be able to enter, store, and compare 8-bit data. + There are issues with this approach, however. 2.6.1. Issues with the Normalization Process We recognize that the requirements in the preceding section are not implemented today. For example, most EAP implementations use a user identifier which is passed to them from some other local system. This identifier is treated as an opaque blob, and is placed as-is into the EAP Identity field. Any subsequent system which receives that identifier is assumed to be able to understand and process it. @@ -682,21 +678,21 @@ 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 as the system which injected the NAI into the AAA routing systems. - Therefore, almost all "case insensitive" comparisons will be wrong. + Therefore, almost all "case insensitive" comparisons can 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. We also note that many existing systems have user identifiers which are similar in format to the NAI, but which are not compliant with this specification. For example, they may use non-NFC form, or they may have multiple "@" characters in the user identifier. Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking up the "utf8-realm" in the logical routing table.