draft-ietf-radext-nai-01.txt   draft-ietf-radext-nai-02.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-01.txt> <draft-ietf-radext-nai-02.txt>
8 January 2013 28 January 2013
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-01 draft-ietf-radext-nai-02
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 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
Appendix A - Changes from RFC4282 ............................ 3 Appendix A - Changes from RFC4282 ............................ 3
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 6
1.3. Purpose ............................................. 6 1.3. Purpose ............................................. 7
1.4. Motivation .......................................... 6 1.4. Motivation .......................................... 7
2. NAI Definition ........................................... 7 2. NAI Definition ........................................... 8
2.1. UTF-8 Syntax and Normalization ...................... 7 2.1. UTF-8 Syntax and Normalization ...................... 8
2.2. Formal Syntax ....................................... 7 2.2. Formal Syntax ....................................... 8
2.3. NAI Length Considerations ........................... 8 2.3. NAI Length Considerations ........................... 9
2.4. Support for Username Privacy ........................ 9 2.4. Support for Username Privacy ........................ 10
2.5. International Character Sets ........................ 9 2.5. International Character Sets ........................ 10
2.6. The Normalization Process ........................... 10 2.6. The Normalization Process ........................... 11
2.7. Use in Other Protocols .............................. 11 2.7. Use in Other Protocols .............................. 12
2.8. Routing inside of AAA Systems ....................... 11 2.8. Routing inside of AAA Systems ....................... 12
2.9. Compatibility with Email Usernames .................. 12 2.9. Compatibility with Email Usernames .................. 13
2.10. Compatibility with DNS ............................. 12 2.10. Compatibility with DNS ............................. 14
2.11. Realm Construction ................................. 13 2.11. Realm Construction ................................. 15
2.11.1. Historical Practices .......................... 14 2.11.1. Historical Practices .......................... 15
2.12. Examples ........................................... 15 2.12. Examples ........................................... 16
3. Security Considerations .................................. 15 3. Security Considerations .................................. 17
4. IANA Considerations ...................................... 16 4. IANA Considerations ...................................... 17
5. References ............................................... 16 5. References ............................................... 18
5.1. Normative References ................................ 16 5.1. Normative References ................................ 18
5.2. Informative References .............................. 17 5.2. Informative References .............................. 18
Appendix A - Changes from RFC4282 ............................ 19 Appendix A - Changes from RFC4282 ............................ 21
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
particular state or province, looking to combine their efforts particular state or province, looking to combine their efforts
skipping to change at page 4, line 41 skipping to change at page 4, line 41
* Other protocols which are interested in leveraging the users * Other protocols which are interested in leveraging the users
credentials in order to take advantage of an existing credentials in order to take advantage of an existing
authentication framework. authentication framework.
In order to enhance the interoperability of these services, it is In order to enhance the interoperability of these services, it is
necessary to have a standardized method for identifying users. This necessary to have a standardized method for identifying users. This
document defines syntax for the Network Access Identifier (NAI). document defines syntax for the Network Access Identifier (NAI).
Examples of implementations that use the NAI, and descriptions of its Examples of implementations that use the NAI, and descriptions of its
semantics, can be found in [RFC2194]. 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 This document is a revised version of [RFC4282], which originally
defined internationalized NAIs. Differences and enhancements defined internationalized NAIs. Differences and enhancements
compared to that document are listed in Appendix A. compared to that document are listed in Appendix A.
1.1. Terminology 1.1. Terminology
This document frequently uses the following terms: 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 Text which is either in non-UTF-8, or in non-normalized form. The
character set, encoding, and locale are (in general) unknown to character set, encoding, and locale are (in general) unknown to
Authentication, Authorization, and Accounting (AAA) network 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 Network Access Identifier
The Network Access Identifier (NAI) is the user identity submitted The Network Access Identifier (NAI) is the user identity submitted
by the client during network access authentication. The purpose by the client during network access authentication. The purpose
of the NAI is to identify the user as well as to assist in the 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 routing of the authentication request. Please note that the NAI
may not necessarily be the same as the user's email address or the may not necessarily be the same as the user's email address or the
user identity submitted in an application layer authentication. user identity submitted in an application layer authentication.
skipping to change at page 6, line 40 skipping to change at page 7, line 40
changes. changes.
The motivation to revise [RFC4282] began with internationalization The motivation to revise [RFC4282] began with internationalization
concerns raised in the context of [EDUROAM]. Section 2.1 of concerns raised in the context of [EDUROAM]. Section 2.1 of
[RFC4282] defines ABNF for realms which limits the realm grammar to [RFC4282] defines ABNF for realms which limits the realm grammar to
English letters, digits, and the hyphen "-" character. The intent English letters, digits, and the hyphen "-" character. The intent
appears to have been to encode, compare, and transport realms with appears to have been to encode, compare, and transport realms with
the ToASCII operation defined in [RFC5890]. There are a number of the ToASCII operation defined in [RFC5890]. There are a number of
problems with this approach: 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, with the Extensible Authentication Protocol (EAP) and RADIUS,
which are both 8-bit clean, and which both recommend the use of which are both 8-bit clean, and which both recommend the use of
UTF-8 for identities. 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 and which are nearly impossible for intermediate nodes to perform
correctly without information about that language. 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. 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. 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. 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 client, proxy, or server has implemented any of the requirements
in [RFC4282] Section 2.4, among other sections. in [RFC4282] Section 2.4, among other sections.
With international roaming growing in popularity, it is important for With international roaming growing in popularity, it is important for
these issues to be corrected in order to provide robust and inter- these issues to be corrected in order to provide robust and inter-
operable network services. operable network services.
2. NAI Definition 2. NAI Definition
2.1. UTF-8 Syntax and Normalization 2.1. UTF-8 Syntax and Normalization
skipping to change at page 10, line 5 skipping to change at page 11, line 5
This specification allows both international usernames and realms. This specification allows both international usernames and realms.
International usernames are based on the use of Unicode characters, International usernames are based on the use of Unicode characters,
encoded as UTF-8. Internationalization of the realm portion of the encoded as UTF-8. Internationalization of the realm portion of the
NAI is based on "Internationalized Email Headers" [RFC5335]. NAI is based on "Internationalized Email Headers" [RFC5335].
In order to ensure a canonical representation, characters of the In order to ensure a canonical representation, characters of the
username portion in an NAI MUST match the ABNF in this specification username portion in an NAI MUST match the ABNF in this specification
as well as the requirements specified in [RFC5891]. In practice, as well as the requirements specified in [RFC5891]. In practice,
these requirements consist of the following item: 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. Fully Qualified Domain Name (FQDN) within the DNS.
This list is significantly shorter and simpler than the list in This list is significantly shorter and simpler than the list in
Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended
on intermediate nodes performing canonicalizations based on on intermediate nodes performing canonicalizations based on
insufficient information, which meant that the form was not insufficient information, which meant that the form was not
canonical. This document instead suggests (Section 2.10) that the canonical. This document instead suggests (Section 2.10) that the
realm owner provide a canonical form of the realm, and that all realm owner provide a canonical form of the realm, and that all
intermediate nodes use that form without modification. intermediate nodes use that form without modification.
skipping to change at page 11, line 34 skipping to change at page 12, line 34
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.
We cannot require other protocols to use the NAI for user We cannot require other protocols to use the NAI for user
identifiers. Their needs are unknown, and unknowable. We simply identifiers. Their needs are unknown, and unknowable. We simply
suggest that interoperability and inter-domain authentication is suggest that interoperability and inter-domain authentication is
useful, and should be encouraged. 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 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 definition or handling of the NAI. That is, if a protocol escapes
the '.' character as "%2E", then the protocol may have an identifier the '.' character as "%2E", then the protocol may have an identifier
transported as "fred@example%2Ecom", whereas the NAI for that user is transported as "fred@example%2Ecom", whereas the NAI for that user is
"fred@example.com". Any comparison, validation, or use of the NAI "fred@example.com". Any comparison, validation, or use of the NAI
MUST be done on its un-escaped (i.e. utf8-clean) form. MUST be done on its un-escaped (i.e. utf8-clean) form.
2.8. Routing inside of AAA Systems 2.8. Routing inside of AAA Systems
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. Comparisons between the without modification to perform this lookup. Comparisons between the
NAI as given in a AAA packet, and as provisioned in a logical AAA 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 routing table SHOULD be done as a byte-for-byte equality test. As
"utf8-realm" provisioned in the logical AAA routing table SHOULD be noted earlier, intermediate nodes may not have access to the same
provisioned prior to the proxy receiving any AAA traffic, and SHOULD locale information as the system which injected the NAI into the AAA
be supplied by the "next hop" system that also supplies the other routing systems. Therefore, almost all "case insensitive"
information about the next hop. 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 This "next hop" information may be any of, or all of, the following
information: IP address; port; RADIUS shared secret; TLS certificate; information: IP address; port; RADIUS shared secret; TLS certificate;
DNS host name; or instruction to use dyanmic DNS discovery (i.e. look 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 It is RECOMMENDED to use the entirety of the "utf8-realm" for the
routing decisions. However, systems MAY use a portion of the routing decisions. However, systems MAY use a portion of the
"utf8-realm" portion, so long as that portion is a valid "utf8-realm" portion, so long as that portion is a valid
"utf8-realm", and that portion is handled as above. For example, "utf8-realm", and that portion is handled as above. For example,
routing "fred@example.com" to a "com" destination is forbidden, routing "fred@example.com" to a "com" destination is forbidden,
because "com" is not a valid "utf8-realm". However, routing because "com" is not a valid "utf8-realm". However, routing
"fred@sales.example.com" to the "example.com" destination is "fred@sales.example.com" to the "example.com" destination is
permissible. 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 2.9. Compatibility with Email Usernames
As proposed in this document, the Network Access Identifier is of the As proposed in this document, the Network Access Identifier is of the
form "user@realm". Please note that while the user portion 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 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 for the purposes of Section 2.2. It does not permit quoted text
along with "folding" or "non-folding" whitespace that is commonly along with "folding" or "non-folding" whitespace that is commonly
used in email addresses. As such, the NAI is not necessarily used in email addresses. As such, the NAI is not necessarily
equivalent to usernames used in e-mail. equivalent to usernames used in e-mail.
skipping to change at page 12, line 49 skipping to change at page 14, line 21
In contrast to [RFC4282] Section 2.5, we state that the In contrast to [RFC4282] Section 2.5, we state that the
internationalization requirements for NAIs and email addresses are internationalization requirements for NAIs and email addresses are
substantially similar. The NAI and email identifiers may be the substantially similar. The NAI and email identifiers may be the
same, and both need to be entered by the user and/or the operator same, and both need to be entered by the user and/or the operator
supplying network access to that user. There is therefore good supplying network access to that user. There is therefore good
reason for the internationalization requirements to be similar. reason for the internationalization requirements to be similar.
2.10. Compatibility with DNS 2.10. Compatibility with DNS
The "utf8-realm" portion of the NAI is intended to be compatible with The "utf8-realm" portion of the NAI is intended to be compatible with
Internationalized Domain Names [RFC5890]. As defined above, the Internationalized Domain Names (IDNs) [RFC5890]. As defined above,
"utf8-realm" portion as transported within the RADIUS User-Name the "utf8-realm" portion as transported within an 8-bit clean
attribute is composed of U-labels, not A-labels. There is therefore protocol such as RADIUS and EAP can contain any valid UTF8 character.
no reason for a NAS to apply the ToAscii function to the "utf8-realm" There is therefore no reason for a NAS to apply the ToAscii function
portion of an NAI, prior to placing the NAI into a RADIUS User-Name to the "utf8-realm" portion of an NAI, prior to placing the NAI into
attribute. 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 When the realm portion of the NAI is used as the basis for name
resolution, it may be necessary to convert internationalized realm resolution, it may be necessary to convert internationalized realm
names to ASCII using the ToASCII operation defined in [RFC5890]. As names to ASCII using the ToASCII operation defined in [RFC5890]. As
noted in [RFC6055] Section 2, resolver Application Programming noted in [RFC6055] Section 2, resolver Application Programming
Interfaces (APIs) are not necessarily DNS-specific, so that the Interfaces (APIs) are not necessarily DNS-specific, so that the
ToASCII operation needs to be applied carefully: ToASCII operation needs to be applied carefully:
Applications which convert an IDN to A-label form before calling (for Applications which convert an IDN to A-label form before calling (for
example) getaddrinfo() will result in name resolution failures if the example) getaddrinfo() will result in name resolution failures if the
skipping to change at page 19, line 23 skipping to change at page 21, line 23
* The formal syntax in Section 2.1 has been updated to allow * The formal syntax in Section 2.1 has been updated to allow
UTF-8 in the "realm" portion of the NAI. UTF-8 in the "realm" portion of the NAI.
* The formal syntax in [RFC4282] Section 2.1 applied to the * The formal syntax in [RFC4282] Section 2.1 applied to the
NAI after it was "internationalized" via the ToAscii function. NAI after it was "internationalized" via the ToAscii function.
The contents of the NAI before it was "internationalized" were The contents of the NAI before it was "internationalized" were
left indeterminate. This document updates the formal syntax to left indeterminate. This document updates the formal syntax to
define an internationalized form of the NAI, and forbids the use define an internationalized form of the NAI, and forbids the use
of the ToAscii function for NAI "internationalization". 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 combination
of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr-
spec" defined in [RFC5335] Section 4.4. spec" defined in [RFC5335] Section 4.4.
* All use of the ToAscii function has been moved to normal * All use of the ToAscii function has been moved to normal
requirements on DNS implementations when realms are used as the requirements on DNS implementations when realms are used as the
basis for DNS lookups. This involves no changes to the existing basis for DNS lookups. This involves no changes to the existing
DNS infrastructure. DNS infrastructure.
* The discussions on internationalized character sets in Section 2.4 * The discussions on internationalized character sets in Section 2.4
have been updated. The suggestion to use the ToAscii function for have been updated. The suggestion to use the ToAscii function for
realm comparisons has been removed. No AAA system implemented the realm comparisons has been removed. No AAA system has implemented
suggestion, so this change should have no operational impact. 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, document. The concept of a "local AAA routing table" is also new,
although it accurately describes the functionality of wide-spread although it accurately describes the functionality of wide-spread
implementations. implementations.
* The "Compatibility with EMail Usernames" and "Compatibility * The "Compatibility with EMail Usernames" and "Compatibility
with DNS" sections have been revised and updated. We now note with DNS" sections have been revised and updated. We now note
that the ToAscii function is suggested to be used only when a 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 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 only used by a resolving API on the local system, and even then we
recommend that only the home network perform this conversion. recommend that only the home network perform this conversion.
 End of changes. 22 change blocks. 
53 lines changed or deleted 87 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/