draft-ietf-radext-nai-04.txt   draft-ietf-radext-nai-05.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-04.txt> <draft-ietf-radext-nai-05.txt>
17 October 2013 6 November 2013
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-04 draft-ietf-radext-nai-05
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 others users. This document defines the syntax for the identify each others 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 client prior to accessing network resources. This document is a
revised version of RFC 4282 [RFC4282], which addresses issues with revised version of RFC 4282 [RFC4282], 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 April 16, 2014. This Internet-Draft will expire on May 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 23 skipping to change at page 3, line 23
1.4. Motivation .......................................... 7 1.4. Motivation .......................................... 7
2. NAI Definition ........................................... 8 2. NAI Definition ........................................... 8
2.1. UTF-8 Syntax and Normalization ...................... 8 2.1. UTF-8 Syntax and Normalization ...................... 8
2.2. Formal Syntax ....................................... 9 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 10 2.3. NAI Length Considerations ........................... 10
2.4. Support for Username Privacy ........................ 11 2.4. Support for Username Privacy ........................ 11
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 12 2.6. The Normalization Process ........................... 12
2.6.1. Issues with the Normalization Process .......... 13 2.6.1. Issues with the Normalization Process .......... 13
2.7. Use in Other Protocols .............................. 14 2.7. Use in Other Protocols .............................. 14
3. ........................................................... 14 3. ........................................................... 15
3.1. Compatibility with Email Usernames .................. 16 3.1. Compatibility with Email Usernames .................. 16
3.2. Compatibility with DNS .............................. 16 3.2. Compatibility with DNS .............................. 16
3.3. Realm Construction .................................. 17 3.3. Realm Construction .................................. 17
3.3.1. Historical Practices ........................... 17 3.3.1. Historical Practices ........................... 18
3.4. Examples ............................................ 18 3.4. Examples ............................................ 18
4. Security Considerations .................................. 19 4. Security Considerations .................................. 19
5. IANA Considerations ...................................... 19 5. IANA Considerations ...................................... 20
6. References ............................................... 20 6. References ............................................... 20
6.1. Normative References ................................ 20 6.1. Normative References ................................ 20
6.2. Informative References .............................. 20 6.2. Informative References .............................. 21
Appendix A - Changes from RFC4282 ............................ 23 Appendix A - Changes from RFC4282 ............................ 23
1. Introduction 1. Introduction
Considerable interest exists for a set of features that fit within 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 authentiction, or "roaming
capability" for network access, including dialup Internet users, capability" for network access, including dialup Internet users,
Virtual Private Network (VPN) usage, wireless LAN authentication, and Virtual Private Network (VPN) usage, wireless LAN authentication, and
other applications. Interested parties have included the following: other applications. Interested parties have included the following:
* Regional Internet Service Providers (ISPs) operating within a * Regional Internet Service Providers (ISPs) operating within a
skipping to change at page 9, line 21 skipping to change at page 9, line 21
%xF4 %x80-8F 2( UTF8-tail ) %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF UTF8-tail = %x80-BF
These are normatively defined in [RFC3629], but are repeated in this These are normatively defined in [RFC3629], but are repeated in this
document for reasons of convenience. document for reasons of convenience.
See [RFC5198] and section 2.6 of this specification for a discussion See [RFC5198] and section 2.6 of this specification for a discussion
of normalization. Strings which are not in Normal Form Composed (NFC) of normalization. Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such. are not valid NAIs and SHOULD NOT be treated as such.
Implementations which expect to receive a NAI, but get non-normalised Implementations which expect to receive a NAI, but which instead
(but otherwise valid) UTF-8 strings instead SHOULD attempt to create receive non-normalised (but otherwise valid) UTF-8 strings instead
a local version of the NAI, which is normalized from the input SHOULD attempt to create a local version of the NAI, which is
identifier. This local version can then be used for local normalized from the input identifier. This local version can then be
processing. used for local processing.
Systems MAY accept user identifiers in forms other than the NAI. Systems MAY accept user identifiers in forms other than the NAI.
This specification does not forbid that practice. It only codifies This specification does not forbid that practice. It only codifies
the format and interpretation of the NAI. We cannot expect to change the format and interpretation of the NAI. We cannot expect to change
existing protocols or practices. We can, however, suggest that using existing protocols or practices. We can, however, suggest that using
a consistent form for a user identifier is of a benefit to the a consistent form for a user identifier is of a benefit to the
community. community.
Where protocols carry identifiers which are expected to be Where protocols carry identifiers which are expected to be
transported over an AAA protocol, it is RECOMMENDED that the transported over an AAA protocol, it is RECOMMENDED that the
skipping to change at page 12, line 34 skipping to change at page 12, line 34
For this specification, that caveat means the following. Realms not For this specification, that caveat means the following. Realms not
matching the above ABNF are not valid NAIs. However, some realms matching the above ABNF are not valid NAIs. However, some realms
which do match the ABNF are still invalid NAIs. That is, matching which do match the ABNF are still invalid NAIs. That is, matching
the ABNF is a necessary, but not sufficient, requirement for an NAI. the ABNF is a necessary, but not sufficient, requirement for an NAI.
In general, the above requirement means following the requirements In general, the above requirement means following the requirements
specified in [RFC5891]. specified in [RFC5891].
2.6. The Normalization Process 2.6. The Normalization Process
Conversion to Unicode as well as normalization is expected to be Conversion to Unicode as well as normalization SHOULD be performed by
performed by end systems that take "local" text as input. Other AAA end systems that take "local" text as input. These systems are best
systems such as proxies do not have access to locale and character suited to determine the users intent, and can best convert from
set information that is available to end systems. Therefore, they "local" text to a normalized form.
are typically incapable of converting local input to Unicode.
Other AAA systems such as proxies do not have access to locale and
character set information that is available to end systems.
Therefore, they can not always convert local input to Unicode.
That is, all processing of NAIs from "local" character sets and That is, all processing of NAIs from "local" character sets and
locales to UTF-8 SHOULD BE performed by edge systems, prior to the locales to UTF-8 SHOULD be performed by edge systems, prior to the
NAIs entering the AAA system. Inside of an AAA system, NAIs are sent NAIs entering the AAA system. Inside of an AAA system, NAIs are sent
over the wire in their canonical form, and this canonical form is over the wire in their canonical form, and this canonical form is
used for all NAI and/or realm comparisons. used for all NAI and/or realm comparisons.
Copying of localized text into fields that can subsequently be placed Copying of localized text into fields that can subsequently be placed
into the RADIUS User-Name attribute is problematic. This practice into the RADIUS User-Name attribute is problematic. This practice
can result in a AAA proxy encountering non-UTF8 characters within can result in a AAA proxy encountering non-UTF8 characters within
what it expects to be an NAI. An example of this requirement is what it expects to be an NAI. An example of this requirement is
[RFC3579] Section 2.1, which states: [RFC3579] Section 2.1, which states:
skipping to change at page 13, line 46 skipping to change at page 13, line 48
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.
This opaque blob unfortunately contains localized text, which means This opaque blob unfortunately can contain localized text, which
that the AAA systems have to process that text. means that the AAA systems have to process that text.
These limitations have the following theoretical and practical These limitations have the following theoretical and practical
implications. implications.
* "local" systems used today generally do not normalize the NAI * "local" systems used today generally do not normalize the NAI
* Therefore AAA systems SHOUD attempt to normalize the NAI * Therefore AAA systems SHOUD attempt to normalize the NAI
The suggestion in the above sentence contradicts the suggestion in
the previous section. This is the reality of imperfect protocols.
Where the user identifier can be normalized, or determined to be in Where the user identifier can be normalized, or determined to be in
normal form, the normal form MUST be used as the NAI. In all other normal form, the normal form MUST be used as the NAI. In all other
circumstances, the user identifier MUST NOT be treated as an NAI. circumstances, the user identifier MUST NOT be treated as an NAI.
That data is still, however, a user identifier. AAA systems MUST NOT That data is still, however, a user identifier. AAA systems MUST NOT
fail authentication simply because the user identifier is not an NAI. fail authentication simply because the user identifier is not an NAI.
That is, when the realm portion of the NAI is not recognized by an
AAA server, it SHOULD try to normalize the NAI into NFC form. That
normalized form can then be used to see if the realm matches a known
realm. If no match is found, the original form of the NAI SHOULD be
used in all subsequent processing.
The AAA server may also convert realms to punycode, and perform all
realm comparisons on the resulting punycode strings. This conversion
follows the recommendations above, but may have different operational
effects and failure modes.
2.7. Use in Other Protocols 2.7. Use in Other Protocols
As noted earlier, the NAI MAY be used in other, non-AAA protocols. As noted earlier, the NAI MAY be used in other, non-AAA protocols.
It is RECOMMENDED that the definition given here be used unchanged. It is RECOMMENDED that the definition given here be used unchanged.
Using other definitions for user identifiers may hinder Using other definitions for user identifiers may hinder
interoperability, along with the users ability to authenticate interoperability, along with the users ability to authenticate
successfully. It is RECOMMENDED that protocols requiring the use of successfully. It is RECOMMENDED that protocols requiring the use of
a user identifier reference this specification, and suggest that the a user identifier reference this specification, and suggest that the
use of an NAI is RECOMMENDED. use of an NAI is RECOMMENDED.
 End of changes. 14 change blocks. 
21 lines changed or deleted 39 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/