draft-ietf-radext-nai-13.txt   draft-ietf-radext-nai-14.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-13.txt> <draft-ietf-radext-nai-14.txt>
4 December 2014 4 December 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-13 draft-ietf-radext-nai-14
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 identifier submitted by the Network Access Identifier (NAI), the user identifier submitted by
the client prior to accessing resources. This document is a revised the client prior to accessing resources. This document is a revised
version of RFC 4282, which addresses issues with international version of RFC 4282, which addresses issues with international
character sets, as well as a number of other corrections to the character sets, as well as a number of other corrections to the
skipping to change at page 3, line 27 skipping to change at page 3, line 27
2.4. Support for Username Privacy ........................ 12 2.4. Support for Username Privacy ........................ 12
2.5. International Character Sets ........................ 13 2.5. International Character Sets ........................ 13
2.6. The Normalization Process ........................... 14 2.6. The Normalization Process ........................... 14
2.6.1. Issues with the Normalization Process .......... 15 2.6.1. Issues with the Normalization Process .......... 15
2.7. Use in Other Protocols .............................. 16 2.7. Use in Other Protocols .............................. 16
2.8. Using the NAI format for other identifiers .......... 17 2.8. Using the NAI format for other identifiers .......... 17
3. Routing inside of AAA Systems ............................ 18 3. Routing inside of AAA Systems ............................ 18
3.1. Compatibility with Email Usernames .................. 19 3.1. Compatibility with Email Usernames .................. 19
3.2. Compatibility with DNS .............................. 19 3.2. Compatibility with DNS .............................. 19
3.3. Realm Construction .................................. 20 3.3. Realm Construction .................................. 20
3.3.1. Historical Practices ........................... 20 3.3.1. Historical Practices ........................... 21
3.4. Examples ............................................ 21 3.4. Examples ............................................ 22
4. Security Considerations .................................. 22 4. Security Considerations .................................. 22
4.1. Correlation of Identities over Time and Protocols ... 23 4.1. Correlation of Identities over Time and Protocols ... 23
4.2. Multiple Identifiers ................................ 23 4.2. Multiple Identifiers ................................ 23
5. Administration of Names .................................. 24 5. Administration of Names .................................. 24
6. IANA Considerations ...................................... 24 6. IANA Considerations ...................................... 25
7. References ............................................... 25 7. References ............................................... 25
7.1. Normative References ................................ 25 7.1. Normative References ................................ 25
7.2. Informative References .............................. 25 7.2. Informative References .............................. 25
Appendix A - Changes from RFC4282 ............................ 28 Appendix A - Changes from RFC4282 ............................ 28
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 authentication, or "roaming the general category of inter-domain authentication, 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. other applications.
By "inter-domain authentication", we mean situations where a user has By "inter-domain authentication", this document refers to situations
authentication credentials at one "home" domain, but is able to where a user has authentication credentials at one "home" domain, but
present them at a second "visited" domain to access certain services is able to present them at a second "visited" domain to access
at the visited domain. The two domains generally have a pre-existing certain services at the visited domain. The two domains generally
relationship, so that the credentials can be passed from the visited have a pre-existing relationship, so that the credentials can be
domain to the home domain for verification. The home domain passed from the visited domain to the home domain for verification.
typically responds with a permit / deny response, which may also The home domain typically responds with a permit / deny response,
include authorization parameters which the visited domain is expected which may also include authorization parameters which the visited
to enforce on the user. domain is expected to enforce on the user.
That is, the "roaming" scenario involves a user visiting, or That is, the "roaming" scenario involves a user visiting, or
"roaming" to a non-home domain, and requesting the use of services at "roaming" to a non-home domain, and requesting the use of services at
that visted domain. that visted domain.
Interested parties have included the following: 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
with those of other regional providers to offer dialup service with those of other regional providers to offer dialup service
skipping to change at page 5, line 29 skipping to change at page 5, line 29
or identifier formats, which increases cost to both the user and the or identifier formats, which increases cost to both the user and the
administrator. administrator.
There are privacy implications to using one identifier across There are privacy implications to using one identifier across
multiple protocols. See Section 2.7 and Section 4 for further multiple protocols. See Section 2.7 and Section 4 for further
discussion of this topic. discussion of this topic.
The goal of this document is to define the format of an identifier 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 which can be used in many protocols. A protocol may transport an
encoded version of the NAI (e.g. '.' as %2E). However, the encoded version of the NAI (e.g. '.' as %2E). However, the
definition of the NAI is protocol independent. We hope to encourage definition of the NAI is protocol independent. The goal of this
the wide-spread adoption of the NAI format. This adoption will document is to encourage the wide-spread adoption of the NAI format.
decrease work required to leverage identification and authentication This adoption will decrease work required to leverage identification
in other protocols. It will also decrease the complexity of non-AAA and authentication in other protocols. It will also decrease the
systems for end users and administrators. complexity of non-AAA systems for end users and administrators.
We note that this document only suggests that the NAI format be used, This document only suggests that the NAI format be used, but does not
but does not require such use. Many protocols already define their require such use. Many protocols already define their own identifier
own identifier formats. Some of these are incompatible with the NAI, formats. Some of these are incompatible with the NAI, while others
while others allow the NAI in addition to non-NAI identifiers. The allow the NAI in addition to non-NAI identifiers. The definition of
definition of the NAI in this document has no requirements on the NAI in this document has no requirements on protocol
protocol specifications, implementations, or deployments. specifications, implementations, or deployments.
However, this document suggests that using one standard identifier However, this document suggests that using one standard identifier
format is preferable to using multiple incompatible identifier format is preferable to using multiple incompatible identifier
formats. Where identifiers need to be used in new protocols and/or formats. Where identifiers need to be used in new protocols and/or
specifications, it is RECOMMENDED that the format of the NAI be used. specifications, it is RECOMMENDED that the format of the NAI be used.
That is, the interpretation of the identifier is context-specific, That is, the interpretation of the identifier is context-specific,
while the format of the identifier remains the same. These issues while the format of the identifier remains the same. These issues
are discussed in more detail in Section 2.8, below. are discussed in more detail in Section 2.8, below.
The recommendation for a standard identifier format is not a The recommendation for a standard identifier format is not a
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Roaming capability can be loosely defined as the ability to use Roaming capability can be loosely defined as the ability to use
any one of multiple Internet Service Providers (ISPs), while any one of multiple Internet Service Providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one. maintaining a formal, customer-vendor relationship with only one.
Examples of cases where roaming capability might be required Examples of cases where roaming capability might be required
include ISP "confederations" and ISP-provided corporate network include ISP "confederations" and ISP-provided corporate network
access support. access support.
Normalization or Canonicalization Normalization or Canonicalization
These terms are defined in [RFC6365] Section 4. We incorporate These terms are defined in [RFC6365] Section 4. Those definitions
the definitions here by reference. are incorporated here by reference.
Locale Locale
This term is defined in [RFC6365] Section 8. We incorporate the This term is defined in [RFC6365] Section 8. Those definitions
definition here by reference. are incorporated here by reference.
Tunneling Service Tunneling Service
A tunneling service is any network service enabled by tunneling A tunneling service is any network service enabled by tunneling
protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One
example of a tunneling service is secure access to corporate example of a tunneling service is secure access to corporate
intranets via a Virtual Private Network (VPN). intranets via a Virtual Private Network (VPN).
1.2. Requirements Language 1.2. Requirements Language
skipping to change at page 8, line 19 skipping to change at page 8, line 19
Providers are involved in roaming consortia. Providers are involved in roaming consortia.
In order to be able to offer roaming capability, one of the In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in Network Access Identifier (NAI) submitted by the user to the NAS in
the initial network authentication. It is also expected that NASes the initial network authentication. It is also expected that NASes
will use the NAI as part of the process of opening a new tunnel, in will use the NAI as part of the process of opening a new tunnel, in
order to determine the tunnel endpoint. order to determine the tunnel endpoint.
We also hope that other protocols can take advantage of the NAI This document suggests that other protocols can take advantage of the
format. Many protocols include authentication capabilities, NAI format. Many protocols include authentication capabilities,
including defining their own identifier formats. These identifiers including defining their own identifier formats. These identifiers
can then end up being transported in AAA protocols, so that the can then end up being transported in AAA protocols, so that the
originating protocols can leverage AAA for user authentication. originating protocols can leverage AAA for user authentication.
There is therefore a need for a definition of a user identifier which There is therefore a need for a definition of a user identifier which
can be used in multiple protocols. can be used in multiple protocols.
While we define the NAI here, we recognize that existing protocols While the NAI is defined herein, it should be noted that existing
and deployments do not always use it. AAA systems MUST therefore be protocols and deployments do not always use it. AAA systems MUST
able to handle user identifiers which are not in the NAI format. The therefore be able to handle user identifiers which are not in the NAI
process by which that is done is outside of the scope of this format. The process by which that is done is outside of the scope of
document. this document.
Non-AAA systems can accept user identifiers in forms other than the Non-AAA systems can accept user identifiers in forms other than the
NAI. This specification does not forbid that practice. It only NAI. This specification does not forbid that practice. It only
codifies the format and interpretation of the NAI. We cannot expect codifies the format and interpretation of the NAI. This document
to change existing protocols or practices. We can, however, suggest cannot change existing protocols or practices. It can, however,
that using a consistent form for a user identifier is of a benefit to suggest that using a consistent form for a user identifier is of a
the community. benefit to the community.
We note that this document does not make any protocol-specific This document does not make any protocol-specific definitions for an
definitions for an identifier format, and it does not make changes to identifier format, and it does not make changes to any existing
any existing protocol. Instead, it defines a protocol-independent protocol. Instead, it defines a protocol-independent form for the
form for the NAI. It is hoped that the NAI is a user identifier NAI. It is hoped that the NAI is a user identifier which can be used
which can be used in multiple protocols. in multiple protocols.
Using a common identifier format implifies protocols requiring Using a common identifier format implifies protocols requiring
authentication, as they no longer need to specify protocol-specific authentication, as they no longer need to specify protocol-specific
format for user identifiers. It increases security, as it multiple format for user identifiers. It increases security, as it multiple
identifier formats allow attackers to make contradictory claims identifier formats allow attackers to make contradictory claims
without being detected (see Section 4.2 for further discussion of without being detected (see Section 4.2 for further discussion of
this topic). It simplifies deployments, as a user can have one this topic). It simplifies deployments, as a user can have one
identifier in multiple contexts, which allows them to be uniquely identifier in multiple contexts, which allows them to be uniquely
identified, so long as that identifier is itself protected against identified, so long as that identifier is itself protected against
access. unauthorized access.
In short, having a standard is better than having no standard at all. In short, having a standard is better than having no standard at all.
1.4. Motivation 1.4. Motivation
The changes from [RFC4282] are listed in detail in Appendix A. The changes from [RFC4282] are listed in detail in Appendix A.
However, some additional discussion is appropriate to motivate those However, some additional discussion is appropriate to motivate those
changes. changes.
The motivation to revise [RFC4282] began with internationalization The motivation to revise [RFC4282] began with internationalization
skipping to change at page 11, line 5 skipping to change at page 11, line 5
used for local processing. This local version of the identifier MUST used for local processing. This local version of the identifier MUST
NOT be used outside of the local context. NOT be used outside of the local context.
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
identifiers be in NAI format. Where the identifiers are not in the identifiers be in NAI format. Where the identifiers are not in the
NAI format, it is up to the AAA systems to discover this, and to NAI format, it is up to the AAA systems to discover this, and to
process them. This document does not suggest how that is done. process them. This document does not suggest how that is done.
However, existing practice indicates that it is possible. However, existing practice indicates that it is possible.
We expect that with wider use of internationalized domain names, As internationalized domain names become more widely used, existing
existing practices will be inadequate. We therefore define the NAI, practices are likely to become inadequate. This document therefore
which is a user identifier format that can correctly deal with defines the NAI, which is a user identifier format that can correctly
internationalized identifiers. deal with internationalized identifiers.
2.2. Formal Syntax 2.2. Formal Syntax
The grammar for the NAI is given below, described in Augmented The grammar for the NAI is given below, described in Augmented
Backus-Naur Form (ABNF) as documented in [RFC5234]. Backus-Naur Form (ABNF) as documented in [RFC5234].
nai = utf8-username nai = utf8-username
nai =/ "@" utf8-realm nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm nai =/ utf8-username "@" utf8-realm
skipping to change at page 12, line 51 skipping to change at page 12, line 51
In some situations, NAIs are used together with a separate In some situations, NAIs are used together with a separate
authentication method that can transfer the username part in a more authentication method that can transfer the username part in a more
secure manner to increase privacy. In this case, NAIs MAY be secure manner to increase privacy. In this case, NAIs MAY be
provided in an abbreviated form by omitting the username part. provided in an abbreviated form by omitting the username part.
Omitting the username part is RECOMMENDED over using a fixed username Omitting the username part is RECOMMENDED over using a fixed username
part, such as "anonymous", since including a fixed username part is part, such as "anonymous", since including a fixed username part is
ambiguous as to whether or not the NAI refers to a single user. ambiguous as to whether or not the NAI refers to a single user.
However, current practice is to use the username "anonymous" instead However, current practice is to use the username "anonymous" instead
of omitting the username part. This behavior is also permitted. of omitting the username part. This behavior is also permitted.
The most common use-case of such behavior is with TLS-based EAP The most common use-case of omitting or obfuscating the username part
methods such as TTLS [RFC5281]. Those methods allow for an "outer" is with TLS-based EAP methods such as TTLS [RFC5281]. Those methods
identifier, which is typically an anonymous "@realm". This outer allow for an "outer" identifier, which is typically an anonymous
identifier allows the authentication request to be routed from a "@realm". This outer identifier allows the authentication request to
visited domain to a home domain. At the same time, user privacy is be routed from a visited domain to a home domain. At the same time,
preserved. The protocol provides for an "inner" authentication the username part is kept confidential from the visited network. The
exchange, in which a full identifier is used to authenticate a user. protocol provides for an "inner" authentication exchange, in which a
full identifier is used to authenticate a user.
That scenario offers the best of both worlds. An anonymous NAI can That scenario offers the best of both worlds. An anonymous NAI can
be used to route authentication to the home domain, and the home be used to route authentication to the home domain, and the home
domain has sufficient information to identify and authenticate users. domain has sufficient information to identify and authenticate users.
However, some protocols do not support authenticate methods which However, some protocols do not support authenticate methods which
allow for "inner" and "outer" exchanges. Those protocols are limited allow for "inner" and "outer" exchanges. Those protocols are limited
to using an identifier which is publicly visible. It is therefore to using an identifier which is publicly visible. It is therefore
RECOMMENDED that such protocols use ephemeral identifiers. We RECOMMENDED that such protocols use ephemeral identifiers. We
recognize that this practice is not currently used, and will likely recognize that this practice is not currently used, and will likely
skipping to change at page 13, line 41 skipping to change at page 13, line 42
For roaming purposes, it is typically necessary to locate the For roaming purposes, it is typically necessary to locate the
appropriate backend authentication server for the given NAI before appropriate backend authentication server for the given NAI before
the authentication conversation can proceed. As a result, the authentication conversation can proceed. As a result,
authentication routing is impossible unless the realm portion is authentication routing is impossible unless the realm portion is
available, and in a well-known format. available, and in a well-known format.
2.5. International Character Sets 2.5. International Character Sets
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 username portion of
NAI is based on [RFC5890]. the NAI is based on the "Internationalized Email Headers" [RFC6532]
extensions to the "local-part" portion of email addresses [RFC5322].
In order to ensure a canonical representation, characters of the In order to ensure a canonical representation, characters of the
realm portion in an NAI MUST match the ABNF in this specification as realm portion in an NAI MUST match the ABNF in this specification as
well as the requirements specified in [RFC5891]. In practice, these well as the requirements specified in [RFC5891]. In practice, these
requirements consist of the following item: requirements consist of the following item:
* 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
skipping to change at page 15, line 17 skipping to change at page 15, line 19
the NAS MUST copy the contents of the Type-Data field of the the NAS MUST copy the contents of the Type-Data field of the
EAP-Response/Identity received from the peer into the User-Name EAP-Response/Identity received from the peer into the User-Name
attribute attribute
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, AAA systems are now expected 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 AAA systems such as proxies representation, ensures that intermediate AAA systems such as proxies
are not required to perform translations, and can be expected to work are not required to perform translations, and can be expected to work
through AAA systems that are unaware of international character sets. through AAA systems that are unaware of international character sets.
In an ideal world, the following requirements would be widely In an ideal world, the following requirements would be widely
implemented: implemented:
* Edge systems using "localized" text SHOULD normalize the NAI * Edge 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.
There are issues with this approach, however. There are issues with this approach, however.
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 The requirements in the preceding section are not implemented today.
implemented today. For example, most EAP implementations use a user For example, most EAP implementations use a user identifier which is
identifier which is passed to them from some other local system. passed to them from some other local system. This identifier is
This identifier is treated as an opaque blob, and is placed as-is treated as an opaque blob, and is placed as-is into the EAP Identity
into the EAP Identity field. Any subsequent system which receives field. Any subsequent system which receives that identifier is
that identifier is assumed to be able to understand and process it. assumed to be able to understand and process it.
This opaque blob unfortunately can contain localized text, which This opaque blob unfortunately can contain localized text, which
means 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.
* edge systems used today generally do not normalize the NAI * edge 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 suggestion in the above sentence contradicts the suggestion in
the previous section. This is the reality of imperfect protocols. 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.
skipping to change at page 16, line 35 skipping to change at page 16, line 38
2.7. Use in Other Protocols 2.7. Use in Other Protocols
As noted earlier, the NAI format can be used in other, non-AAA As noted earlier, the NAI format can be used in other, non-AAA
protocols. It is RECOMMENDED that the definition given here be used protocols. It is RECOMMENDED that the definition given here be used
unchanged. Using other definitions for user identifiers may hinder unchanged. 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 use the NAI format. a user identifier use the NAI format.
We cannot require other protocols to use the NAI format for user This document cannot require other protocols to use the NAI format
identifiers. Their needs are unknown, and at this time unknowable. for user identifiers. Their needs are unknown, and at this time
This document suggests that interoperability and inter-domain unknowable. This document suggests that interoperability and inter-
authentication is useful, and should be encouraged. domain authentication is useful, and should be encouraged.
Where a protocol is 8-bit clean, it can likely transport the NAI as- Where a protocol is 8-bit clean, it can likely transport the NAI as-
is, without further modification. is, without further modification.
Where a protocol is not 8-bit clean, it cannot transport the NAI as- Where a protocol is not 8-bit clean, it cannot transport the NAI as-
is. Instead, we presume that a protocol-specific transport layer is. Instead, this document presumes that a protocol-specific
takes care of encoding the NAI on input to the protocol, and decoding transport layer takes care of encoding the NAI on input to the
it when the NAI exits the protocol. The encoded or escaped version protocol, and decoding it when the NAI exits the protocol. The
of the NAI is not a valid NAI, and MUST NOT be presented to the AAA encoded or escaped version of the NAI is not a valid NAI, and MUST
system. NOT be presented to the AAA system.
For example, HTTP carries user identifiers, but escapes the '.' For example, HTTP carries user identifiers, but escapes the '.'
character as "%2E" (among others). When we desire HTTP to transport character as "%2E" (among others). When HTTP is used to transport
the NAI "fred@example.com", the data as transported will be in the the NAI "fred@example.com", the data as transported will be in the
form "fred@example%2Ecom". That data exists only within HTTP, and form "fred@example%2Ecom". That data exists only within HTTP, and
has no relevance to any AAA system. has no relevance to any AAA system.
Any comparison, validation, or use of the NAI MUST be done on its un- Any comparison, validation, or use of the NAI MUST be done on its un-
escaped (i.e. utf8-clean) form. escaped (i.e. utf8-clean) form.
2.8. Using the NAI format for other identifiers 2.8. Using the NAI format for other identifiers
As discussed in Section 1, above, is RECOMMENDED that the NAI format As discussed in Section 1, above, is RECOMMENDED that the NAI format
be used as the standard format for user identifiers. This section be used as the standard format for user identifiers. This section
discusses that use in more detail. discusses that use in more detail.
It is often useful to create new identifiers for use in specific It is often useful to create new identifiers for use in specific
contexts. These identifiers may have a number of different contexts. These identifiers may have a number of different
properties, most of which are unimportant to this document. For our properties, most of which are unimportant to this document. The goal
purposes, we are interested in identifiers which need to be in a of this document is to create identifiers which are to be in a well-
well-known format, and to have namespaces. The NAI format fits these known format, and to have namespaces. The NAI format fits these
requirements. requirements.
One example of such use is the "private user identity", which is an One example of such use is the "private user identity", which is an
identifier defined by the 3rd-Generation Partnership Project (3GPP). identifier defined by the 3rd-Generation Partnership Project (3GPP).
That identifier is used to uniquely identify the user to the network. That identifier is used to uniquely identify the user to the network.
The identifier is used for authorization, authentication, accounting, The identifier is used for authorization, authentication, accounting,
administation, etc. The "private user identity" is globally unique, administation, etc. The "private user identity" is globally unique,
and is defined by the home network operator. The format of the and is defined by the home network operator. The format of the
identifier is explicitly the NAI, as stated by Section 13.3 of identifier is explicitly the NAI, as stated by Section 13.3 of
[3GPP]: [3GPP]:
skipping to change at page 18, line 4 skipping to change at page 18, line 7
This format as defiend by 3GPP ensures that the identifier is This format as defiend by 3GPP ensures that the identifier is
globally unique, as it is based off of the "3gppnetwork.org" domain. globally unique, as it is based off of the "3gppnetwork.org" domain.
It ensures that the "realm" portion is specific to a particular home It ensures that the "realm" portion is specific to a particular home
network (or organization), via the "ims.mnc015.mcc234" prefix to the network (or organization), via the "ims.mnc015.mcc234" prefix to the
realm. Finally, it ensures that the "username" portion follows a realm. Finally, it ensures that the "username" portion follows a
well-known format. well-known format.
This document suggests that the NAI format be used for all new This document suggests that the NAI format be used for all new
specifications and/or protocols where a user identifier is required. specifications and/or protocols where a user identifier is required.
Where the username portions need to be created with subfields, a
It is RECOMMENDED that methods similar to that described above for well-known and documented method as has been done with 3GPP is
3GPP be used to derive the identifier. preferred to ad-hoc methods.
3. Routing inside of AAA Systems 3. 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. 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 can be wrong. Therefore, almost all "case insensitive" comparisons can be wrong.
Where the "utf8-realm" is entirely ASCII, current AAA systems Where the "utf8-realm" is entirely ASCII, current AAA systems
sometimes perform case-insensitive matching on realms. This method sometimes perform case-insensitive matching on realms. This method
MAY be continued, as it has been shown to work in practice. MAY be continued, as it has been shown to work in practice.
We also note that many existing non-AAA systems have user identifiers Many existing non-AAA systems have user identifiers which are similar
which are similar in format to the NAI, but which are not compliant in format to the NAI, but which are not compliant with this
with this specification. For example, they may use non-NFC form, or specification. For example, they may use non-NFC form, or they may
they may have multiple "@" characters in the user identifier. have multiple "@" characters in the user identifier. Intermediate
Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior nodes SHOULD normalize non-NFC identifiers to NFC, prior to looking
to looking up the "utf8-realm" in the logical routing table. up the "utf8-realm" in the logical routing table. Intermediate nodes
Intermediate nodes MUST NOT modify the identifiers that they forward. MUST NOT modify the identifiers that they forward. The data as
The data as entered by the user is inviolate. entered by the user is inviolate.
The "utf8-realm" provisioned in the logical AAA routing table SHOULD The "utf8-realm" provisioned in the logical AAA routing table SHOULD
be provisioned to the proxy prior to it receiving any AAA traffic. be provisioned to the proxy prior to it receiving any AAA traffic.
The "utf8-realm" SHOULD be supplied by the "next hop" or "home" The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for system that also supplies the routing information necessary for
packets to reach the next hop. packets 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
skipping to change at page 19, line 17 skipping to change at page 19, line 20
"fred@sales") is that many non-AAA systems treat a single label as "fred@sales") is that many non-AAA systems treat a single label as
being a local identifier within their realm. That is, a user logging 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 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 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 would mean changing the interpretation and meaning of
a single label, which cannot be done. a single label, which cannot be done.
3.1. Compatibility with Email Usernames 3.1. 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
NAI is based on the BNF described in [RFC5198], it has been modified is based on the "Internet Message Format" [RFC5322] "local-part"
for the purposes of Section 2.2. It does not permit quoted text portion of an email address as extended by "Internationalized Email
along with "folding" or "non-folding" whitespace that is commonly Headers" [RFC6532], it has been modified for the purposes of Section
used in email addresses. As such, the NAI is not necessarily 2.2. It does not permit quoted text along with "folding" or "non-
equivalent to usernames used in e-mail. folding" whitespace that is commonly used in email addresses. As
such, the NAI is not necessarily equivalent to usernames used in e-
mail.
However, it is a common practice to use email addresses as user However, it is a common practice to use email addresses as user
identifiers in AAA systems. The ABNF in Section 2.2 is defined to be identifiers in AAA systems. The ABNF in Section 2.2 is defined to be
close to the "utf8-addr-spec" portion of [RFC5335], while still being close to the "addr-spec" portion of [RFC5322] as extended by
compatible with [RFC4282], [RFC5890], and [RFC5891]. [RFC6532], while still being compatible with [RFC4282].
In contrast to [RFC4282] Section 2.5, we state that the In contrast to [RFC4282] Section 2.5, this document 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.
3.2. Compatibility with DNS 3.2. 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 (IDNs) [RFC5890]. As defined above, Internationalized Domain Names (IDNs) [RFC5890]. As defined above,
skipping to change at page 21, line 36 skipping to change at page 21, line 45
meets all requirements at all intermediate proxies. meets all requirements at all intermediate proxies.
* Leveraging the DNS name system for realm names establishes * Leveraging the DNS name system for realm names establishes
a globally unique name space for realms. a globally unique name space for realms.
In summary, network practices and capabilities have changed In summary, network practices and capabilities have changed
significantly since NAIs were first overloaded to define AAA routes significantly since NAIs were first overloaded to define AAA routes
through a network. While manually managed explicit path routing was through a network. While manually managed explicit path routing was
once useful, the time has come for better methods to be used. once useful, the time has come for better methods to be used.
Notwithstanding the above recommendations, we note that the above Notwithstanding the above recommendations, the above practice is
practice is widely used for Diameter routing [RFC5729]. The routes widely used for Diameter routing [RFC5729]. The routes described
described there are managed automatically, from both credential there are managed automatically, from both credential provisioning
provisioning and routing updates. Those routes also exist within a and routing updates. Those routes also exist within a particular
particular framework (typically 3G), where membership is controlled framework (typically 3G), where membership is controlled and system
and system behavior is standardized. There are no known issues with behavior is standardized. There are no known issues with using
using explicit routing in such an environment. explicit routing in such an environment.
3.4. Examples 3.4. Examples
Examples of valid Network Access Identifiers include the following: Examples of valid Network Access Identifiers include the following:
bob bob
joe@example.com joe@example.com
fred@foo-9.example.com fred@foo-9.example.com
jack@3rd.depts.example.com jack@3rd.depts.example.com
fred.smith@example.com fred.smith@example.com
skipping to change at page 23, line 23 skipping to change at page 23, line 31
in other protocols has implications for privacy. Any attacker who is in other protocols has implications for privacy. Any attacker who is
capable of observing traffic containing the NAI can track the user, capable of observing traffic containing the NAI can track the user,
and correlate his activity across time and across multiple protocols. and correlate his activity across time and across multiple protocols.
The authentication credentials therefore SHOULD be transported over The authentication credentials therefore SHOULD be transported over
channels which permit private communications, or multiple identifiers channels which permit private communications, or multiple identifiers
SHOULD be used, so that user tracking is impossible. SHOULD be used, so that user tracking is impossible.
It is RECOMMENDED that user privacy be enhanced by configuring It is RECOMMENDED that user privacy be enhanced by configuring
multiple identifiers for one user. These identifiers can be changed multiple identifiers for one user. These identifiers can be changed
over time, in order to make user tracking more difficult for a over time, in order to make user tracking more difficult for a
malicous observer. However, we recognise that provisioning and malicous observer. However, provisioning and management of the
management of the identifiers may be difficult in to do in practice, identifiers may be difficult in to do in practice, which is likely
which is likely why multiple identifiers are rarely used today. why multiple identifiers are rarely used today.
4.2. Multiple Identifiers 4.2. Multiple Identifiers
Section 1.3 states that multiple identifier formats allow attackers Section 1.3 states that multiple identifier formats allow attackers
to make contradictory claims without being detected. This statement to make contradictory claims without being detected. This statement
deserves further discussion. deserves further discussion.
Section 2.4 discussed "inner" and "outer" identifiers in the context Section 2.4 discussed "inner" and "outer" identifiers in the context
of TTLS [RFC5281]. A close reading of that specification shows there of TTLS [RFC5281]. A close reading of that specification shows there
is no requirement that the inner and outer identifiers be in any way is no requirement that the inner and outer identifiers be in any way
skipping to change at page 24, line 9 skipping to change at page 24, line 16
It is therefore RECOMMENDED that systems which permit anonymous It is therefore RECOMMENDED that systems which permit anonymous
"outer" identifiers require that the "inner" domain be the same as, "outer" identifiers require that the "inner" domain be the same as,
or a sub-domain of the "outer" domain. An authentication request or a sub-domain of the "outer" domain. An authentication request
using disparate realms is a security violation, and the request using disparate realms is a security violation, and the request
SHOULD be rejected. SHOULD be rejected.
The situation gets worse when multiple protocols are involved. The The situation gets worse when multiple protocols are involved. The
TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the
TLS tunnel. MS-CHAP defines its own identifier which is encapsulated TLS tunnel. MS-CHAP defines its own identifier which is encapsulated
inside of the MS-CHAP exchange. That identifier is not required to inside of the MS-CHAP exchange. That identifier is not required to
be UTF-8, and in practice, can be one of many unknown character sets. be any particular format, is not required to be in UTF-8, and in
There is no way in practice to determine which character set was used practice, can be one of many unknown character sets. There is no way
for that identifier. in practice to determine which character set was used for that
identifier.
The result is that the "outer" EAP Identity carried by TTLS is likely The result is that the "outer" EAP Identity carried by TTLS is likely
to not even share the same character set as the "inner" identifier to not even share the same character set as the "inner" identifier
used by MS-CHAP. The two identifiers are entirely independent, and used by MS-CHAP. The two identifiers are entirely independent, and
fundamentally incomparable. fundamentally incomparable.
Such protocol design is NOT RECOMMENDED. Such protocol design is NOT RECOMMENDED.
5. Administration of Names 5. Administration of Names
skipping to change at page 28, line 45 skipping to change at page 28, line 45
realm comparisons has been removed. No AAA system has implemented realm comparisons has been removed. No AAA system has implemented
these suggestions, so this change should have no operational these suggestions, so this change should have no operational
impact. impact.
* 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. The Punycode
that the ToAscii function is suggested to be used only when a transformation is suggested to be used only when a realm name is
realm name is used for DNS lookups, and even then the function is used for DNS lookups, and even then the function is only used by a
only used by a resolving API on the local system, and even then we resolving API on the local system, and even then it is recommended
recommend that only the home network perform this conversion. that only the home network perform this conversion.
* The "Realm Construction" section has been updated to note * The "Realm Construction" section has been updated to note
that editing of the NAI is NOT RECOMMENDED. that editing of the NAI is NOT RECOMMENDED.
* The "Examples" section has been updated to remove the instance * The "Examples" section has been updated to remove the instance
of the IDN being converted to ASCII. This behavior is now of the IDN being converted to ASCII. This behavior is now
forbidden. forbidden.
Authors' Addresses Authors' Addresses
 End of changes. 33 change blocks. 
118 lines changed or deleted 124 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/