draft-ietf-radext-nai-07.txt   draft-ietf-radext-nai-08.txt 
RADEXT Working Group DeKok, Alan RADEXT Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-07.txt> <draft-ietf-radext-nai-08.txt>
23 September 2014 24 September 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-07 draft-ietf-radext-nai-08
Abstract Abstract
In order to provide inter-domain authentication services, it is In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to necessary to have a standardized method that domains can use to
identify each other's users. This document defines the syntax for identify each other's users. This document defines the syntax for
the Network Access Identifier (NAI), the user identity submitted by the Network Access Identifier (NAI), the user identity submitted by
the client prior to accessing network resources. This document is a the client prior to accessing network resources. This document is a
revised version of RFC 4282, which addresses issues with revised version of RFC 4282, which addresses issues with
international character sets, as well as a number of other international character sets, as well as a number of other
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 21 skipping to change at page 13, line 21
As a result, AAA proxies expect the contents of the EAP- As a result, AAA proxies expect the contents of the EAP-
Response/Identity sent by an EAP supplicant to consist of UTF-8 Response/Identity sent by an EAP supplicant to consist of UTF-8
characters, not localized text. Using localized text in AAA username characters, not localized text. Using localized text in AAA username
or identity fields means that realm routing becomes difficult or or identity fields means that realm routing becomes difficult or
impossible. impossible.
In contrast to [RFC4282] Section 2.4, we expect AAA systems to In contrast to [RFC4282] Section 2.4, we expect AAA systems to
perform NAI comparisons, matching, and AAA routing based on the NAI perform NAI comparisons, matching, and AAA routing based on the NAI
as it is received. This specification provides a canonical as it is received. This specification provides a canonical
representation, ensures that intermediate systems such as AAA proxies 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. 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 * End systems using "localized" text SHOULD normalize the NAI
prior to it being used as an identifier in an authentication prior to it being used as an identifier in an authentication
protocol. protocol.
* AAA systems SHOULD NOT normalize the NAI, as they may not have * AAA systems SHOULD NOT normalize the NAI, as they may not have
sufficient information to perform the normalization. sufficient information to perform the normalization.
For example, much of the common realm routing can be done on the There are issues with this approach, however.
"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.
2.6.1. Issues with the Normalization Process 2.6.1. Issues with the Normalization Process
We recognize that the requirements in the preceding section are not We recognize that the requirements in the preceding section are not
implemented today. For example, most EAP implementations use a user implemented today. For example, most EAP implementations use a user
identifier which is passed to them from some other local system. identifier which is passed to them from some other local system.
This identifier is treated as an opaque blob, and is placed as-is This identifier is treated as an opaque blob, and is placed as-is
into the EAP Identity field. Any subsequent system which receives into the EAP Identity field. Any subsequent system which receives
that identifier is assumed to be able to understand and process it. that identifier is assumed to be able to understand and process it.
skipping to change at page 16, line 23 skipping to change at page 16, line 19
Many AAA systems use the "utf8-realm" portion of the NAI to route Many AAA systems use the "utf8-realm" portion of the NAI to route
requests within a AAA proxy network. The semantics of this operation requests within a AAA proxy network. The semantics of this operation
involves a logical AAA routing table, where the "utf8-realm" portion 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 acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
without modification to perform this lookup. As noted earlier, without modification to perform this lookup. As noted earlier,
intermediate nodes may not have access to the same locale information intermediate nodes may not have access to the same locale information
as the system which injected the NAI into the AAA routing systems. 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 Where the "utf8-realm" is entirely ASCII, current systems sometimes
perform case-insensitive matching on realms. This practice MAY be perform case-insensitive matching on realms. This practice MAY be
continued, as it has been shown to work in practice. continued, as it has been shown to work in practice.
We also note that many existing systems have user identifiers which We also note that many existing systems have user identifiers which
are similar in format to the NAI, but which are not compliant with 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 this specification. For example, they may use non-NFC form, or they
may have multiple "@" characters in the user identifier. may have multiple "@" characters in the user identifier.
Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior
to looking up the "utf8-realm" in the logical routing table. to looking up the "utf8-realm" in the logical routing table.
 End of changes. 7 change blocks. 
12 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/