draft-ietf-radext-populating-eapidentity-00.txt   draft-ietf-radext-populating-eapidentity-01.txt 
RADIUS Extensions Working Group S. Winter RADIUS Extensions Working Group S. Winter
Internet-Draft RESTENA Internet-Draft RESTENA
Intended status: Best Current Practice March 21, 2016 Updates: 3748 (if approved) July 08, 2016
Expires: September 22, 2016 Intended status: Best Current Practice
Expires: January 9, 2017
Considerations regarding the correct use of EAP-Response/Identity Considerations regarding the correct use of EAP-Response/Identity
draft-ietf-radext-populating-eapidentity-00 draft-ietf-radext-populating-eapidentity-01
Abstract Abstract
There are some subtle considerations for an EAP peer regarding the There are some subtle considerations for an EAP peer regarding the
content of the EAP-Response/Identity packet when authenticating with content of the EAP-Response/Identity packet when authenticating with
EAP to an EAP server. This document describes two such EAP to an EAP server. This document describes two such
considerations and suggests workarounds to the associated problems. considerations and suggests workarounds to the associated problems.
One of these workarounds is a new requirement for EAP peers that the
use of UTF-8 is required for the content of EAP-Response/Identity
(which updates RFC3748).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2
1.2. Taxonomy of identities in EAP . . . . . . . . . . . . . . 2 1.2. Taxonomy of identities in EAP . . . . . . . . . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. EAP-Response/Identity: Effects on EAP type negotiation . . . 5 2. EAP-Response/Identity: Effects on EAP type negotiation . . . 5
3. Character (re-)encoding may be required . . . . . . . . . . . 6 3. Character (re-)encoding may be required . . . . . . . . . . . 6
4. Recommendations for EAP peer implementations . . . . . . . . 6 4. Recommendations for EAP peer implementations . . . . . . . . 7
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
1.1. Problem Statement 1.1. Problem Statement
An Extensible Authentication Protocol (EAP, [RFC3748]) conversation An Extensible Authentication Protocol (EAP, [RFC3748]) conversation
between an EAP peer and an EAP server starts with an (optional) between an EAP peer and an EAP server starts with an (optional)
request for identity information by the EAP server (EAP-Request/ request for identity information by the EAP server (EAP-Request/
Identity) followed by the peer's response with identity information Identity) followed by the peer's response with identity information
(EAP-Response/Identity). Only after this identity exchange are EAP (EAP-Response/Identity). Only after this identity exchange are EAP
types negotiated. types negotiated.
EAP-Response/Identity is sent before EAP type negotiation takes EAP-Response/Identity is sent before EAP type negotiation takes
place, but it is not independent of the later-negotiated EAP type. place, but it is not independent of the later-negotiated EAP type.
Two entanglements between EAP-Response/Identity and EAP methods' Two entanglements between EAP-Response/Identity and EAP methods'
notions of a user identifier are described in this document. notions of a user identifier are described in this document.
1. The choice of identity to send in EAP-Response/Identity may have 1. The choice of identifier to send in EAP-Response/Identity may
detrimental effects on the subsequent EAP type negotiation. have detrimental effects on the subsequent EAP type negotiation.
2. Using identity information from the preferred EAP type without 2. Using identifiers from the preferred EAP type without thoughtful
thoughtful conversion of character encoding may have detrimental conversion of character encoding may have detrimental effects on
effects on the outcome of the authentication. the outcome of the authentication.
The following two chapters describe each of these issues in detail. The following two chapters describe each of these issues in detail.
The last chapter contains recommendations for implementers of EAP The last chapter contains recommendations for implementers of EAP
peers to avoid these issues. peers to avoid these issues.
1.2. Taxonomy of identities in EAP 1.2. Taxonomy of identities in EAP
The notion of identity occurs numerous times in the EAP protocol The notion of identity occurs numerous times in the EAP protocol
stack (EAP-Response/Identity, Outer identity, method-specific stack (EAP-Response/Identity, Outer identity, method-specific
identity, tunneled identity). This document uses the following identity, tunneled identity). This document uses the following
terminology when discussing EAP identities. terminology when discussing EAP identities.
o Method-specific Identity: Each EAP method has a means to identify o User Identifier: Each EAP method has a means to identify the user
the user or machine that tries to authenticate. There are no or machine that tries to authenticate. There are no restrictions
restrictions on the format or encoding of this method-specific on the format or encoding of this identifier. The user identifier
identity. If an EAP methods distinguishes between this actual is often also referred to as "method-specific identity". If an
identity and a outer identity (see next bullet), then the Method- EAP method distinguishes between the user identifier and a realm
specific Identity is also often called the Inner Identity. identifier (see next bullet), then the user identifier is also
often referred to as the "inner/true/real identity".
o Method-specific Outer Identity: Some EAP methods allow privacy- o Realm Identifier: Some EAP methods allow privacy-preserving
preserving enhancements where a string is sent as "identity" which enhancements where a string is sent which is actually not
is actually not necessarily related to the user or machine that necessarily related to the user or machine that tries to
tries to authenticate. There is often a relationship between the authenticate. This identifier is often also referred to as "outer
Method-specific Outer Identity and the Inner Identity (e.g. they identity" or "roaming identity" or "anonymous outer identity".
often share the same NAI realm suffix); but this is not a There is often a relationship between the realm identifier and the
requirement. There are no restrictions on the format or encoding user identifier (e.g. they often share the same NAI realm suffix);
of this method-specific identity. Method-specific outer but this is not a requirement. There are no restrictions on the
identities are either format or encoding of the realm identifier. Realm identifiers are
either
* explicitly configured (e.g. string input UI: "Outer Identity") * explicitly configured (e.g. string input UI in EAP peer: "Outer
Identity")
* implicitly configured by copying the actual Method-specific * implicitly configured by copying the actual user identifier
(Inner) Identity
* implicitly configured by copying the NAI realm of the Method- * implicitly configured by copying the NAI realm of the user
specific (Inner) Identity and prefixing it non-configurably identifier and prefixing it non-configurably with a fixed
with a fixed privacy-preserving local username part like privacy-preserving local username part like "anonymous" or the
"anonymous" or the empty string (see [RFC7542]) empty string (see [RFC7542])
* configured in a mixed way, e.g. using a explicit string input * configured in a mixed way, e.g. using a explicit string input
UI for the local part of the outer identity and combining it UI for the local part of the realm identifier and combining it
implicitly with a copy of the NAI realm part of the Method- implicitly with a copy of the NAI realm part of the user
specific (Inner) Identity identifier
o EAP-Response/Identity: a string representing the user or machine o EAP-Response/Identity: a string representing the user or machine
that tries to authenticate, used outside the EAP method-specific that tries to authenticate, used outside the EAP method-specific
context for the entire EAP session. There can be only one EAP- context for the entire EAP conversation. There can be only one
Response/Identity per EAP session, even if that session is EAP-Response/Identity per EAP conversation, even if that
configured with more than one EAP method to authenticate with. As conversation could negotiate more than one EAP method to
per [RFC3748] there is no encoding requirement on EAP-Response/ authenticate with. As per [RFC3748] there is no encoding
Identity. In AAA protocol routing contexts, the content of EAP- requirement on EAP-Response/Identity (which this document changes:
Response/Identity is often used for request routing purposes.
EAP-Response/Identity is chosen from the set:
* all method-specific outer identities from all configured EAP the encoding MUST be UTF-8). In AAA protocol routing contexts,
types supporting the notion of an outer identity union the content of EAP-Response/Identity is often used for request
routing purposes. EAP-Response/Identity is chosen from the set:
* all method-specific identities from all configured EAP types * all realm identifiers from all configured EAP types supporting
without the notion of an outer identity the notion of a realm identifier
One of the two problems addressed in this document stems from this * all user identifiers from all configured EAP types without the
fact: the set of identities may contain more than one element. notion of a realm identifier
The resulting EAP-Response/Identity always routes all configured
EAP types to only one destination, even if different EAP types Several EAP types in a local configuration may share the same user
would need routing to different destinations. and/or realm identifiers. The set of identifiers for EAP-Response
/Identity may thus contain fewer elements than there are
configured EAP types in a local configuration. One of the two
problems addressed in this document stems from this fact: the set
of identifiers may contain more than one element. The resulting
EAP-Response/Identity always routes all configured EAP types to
only one destination, even if different EAP types would need
routing to different destinations.
o User-Name: when using EAP in AAA protocol contexts (e.g. RADIUS o User-Name: when using EAP in AAA protocol contexts (e.g. RADIUS
[RFC2865], Diameter [RFC6733]), this additional identity is [RFC2865], Diameter [RFC6733]), this additional identifier is
created outside the EAP peer (typically in a pass-through created outside the EAP peer (typically in a pass-through
authenticator) by copying EAP-Response/Identity content to the AAA authenticator) by copying EAP-Response/Identity content to the AAA
protocol's User-Name attribute. There is no format requirement on protocol's User-Name attribute. There is no format requirement on
User-Name, but there is an encoding requirement: the string MUST User-Name, but there is an encoding requirement: the string MUST
be UTF-8 encoded. One of the two problems addressed in this be UTF-8 encoded. One of the two problems addressed in this
document stems from this fact: EAP-Response/Identity does not have document stems from this fact: EAP-Response/Identity does not have
an encoding requirement, nor does it carry meta-information about an encoding requirement, nor does it carry meta-information about
the encoding used - and yet, it needs to be coerced into a UTF-8 the encoding used - and yet, it needs to be coerced into a UTF-8
encoding. encoding.
o Further identities: Some EAP methods establish an EAP session o Further identifiers: Some EAP methods establish an EAP session
inside EAP (e.g. PEAP first establishes a TLS tunnel using a inside EAP (e.g. PEAP first establishes a TLS tunnel using a realm
method-specific outer identity, and then starts an EAP exchange identifier, and then starts an EAP exchange inside the tunnel).
inside the tunnel). This being a new, independent EAP session, it This being a new, independent EAP session, it contains its own
contains its own EAP-Response/Identity, can invoke EAP method EAP-Response/Identity, can invoke EAP method negotiation with
negotiation with different (inner) EAP types (this happens e.g. different (inner) EAP types (this happens e.g. with EAP-FAST and
with EAP-FAST and its configurable choice of EAP-GTC or EAP- its configurable choice of EAP-GTC or EAP-MSCHAPv2 inside the
MSCHAPv2 inside the inner EAP session), and those inner EAP inner EAP session), and those inner EAP methods then have their
methods then have their own (inner) method-specific identities. own user identifiers. Where the inner EAP method itself supports
Where the inner EAP method itself supports the notion of method- the notion of realm identifiers, another identifier could be
specific outer identities, another identity could be configured. configured. For the purposes of this document, none of those
For the purposes of this document, none of those details are details are considered and the process by which the (outer) EAP
considered and the process by which the (outer) EAP method selects method selects its user identifier is left entirely to that EAP
its method-specific identity is left entirely to that EAP type. type. This document does not consider the (inner) EAP-Response/
This document does not consider the (inner) EAP-Response/Identity Identity in scope; the recommendations in this document to not
in scope; the recommendations in this document to not apply to apply to such (inner) occurences of EAP-Response/Identity.
such (inner) occurences of EAP-Response/Identity.
1.3. Requirements Language 1.3. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. [RFC2119] RFC 2119. [RFC2119]
2. EAP-Response/Identity: Effects on EAP type negotiation 2. EAP-Response/Identity: Effects on EAP type negotiation
Assuming the EAP peer's EAP type selection is not the trivial case Assuming the EAP peer's EAP type selection is not the trivial case
(i.e. it has more than one configured EAP type for a given network or (i.e. it has more than one configured EAP type for a given network or
application, and needs to make a decision which one to use), an issue application, and needs to make a decision which one to use), an issue
arises when the configured EAP types are not all configured with the arises when the configured EAP types are not all configured with the
same method-specific outer identity (or method-specific identity for same realm identifier (or user identifier for EAP types not
EAP types not supporting the notion of an outer identity). supporting the notion of a realm identifier).
Issue: if the identities in the set of configured EAP types differ Issue: if the identifiers in the set of configured EAP types differ
(e.g. have a different [RFC7542] "realm" portion), and the (e.g. have a different [RFC7542] "realm" portion), and the
authenticator does not send identity selection hints as per authenticator does not send identity selection hints as per
[RFC7542], then EAP type negotiation may be limited to those EAP [RFC7542], then EAP type negotiation may be limited to those EAP
types which are terminated in the same EAP server. The reason for types which are terminated in the same EAP server. The reason for
that is because the information in the EAP-Response/Identity is used that is because the information in the EAP-Response/Identity is used
for request routing decisions and thus determines the EAP server - a for request routing decisions and thus determines the EAP server - a
given user identifier may be routed to a server which exclusively given realm identifier may be routed to a server which exclusively
serves the matching EAP type. Negotiating another EAP type from the serves the corresponding EAP types. Negotiating another EAP type
set of configured EAP types during the running EAP conversation is from the set of configured EAP types during the running EAP
then not possible. conversation is then not possible.
Example: Example:
Assume an EAP peer is configured to support two EAP types: Assume an EAP peer is configured to support two EAP types:
o EAP-AKA' [RFC5448] with user identifier imsi@mnc123.mcc123.3gpp- o EAP-AKA' [RFC5448] with user identifier imsi@mnc123.mcc123.3gpp-
network.org network.org; the configuration is set up to authenticate only to
o EAP-TTLS [RFC5281] with user identifier john@realm.example * cellular networks
The user connects to hotspot of a roaming consortium which could * Wi-Fi Passpoint networks which advertise support for the MNC
authenticate him with EAP-TTLS and his john@realm.example identity. 123 and MCC 123
The hotspot operator has no business relationship at all with the
3GPP consortium; incoming authentication requests for realms ending The EAP server for this EAP type is in a host under control of the
in 3gppnetwork.org will be immediately rejected. Identity selection 3GPP consortium
hints are not sent.
o EAP-TTLS [RFC5281] with user identifier "john@realm.example" and
realm identifier "@realm.example"; the configuration is set up to
authenticate only to
* Wi-Fi networks with the SSID "eduroam"
* Wi-Fi Passpoint networks which advertise support for the
roaming consortium 00-1B-C5-04-60 (the eduroam consortium)
* wired ethernet
The EAP server for this EAP type is in a host under control of the
eduroam consortium
The user approaches a Passpoint Wi-Fi hotspot with SSID "arbitrary"
which emits a beacon advertising support for the MNC 123/MCC 123 AND
for the consortium identifier 00-1B-C5-04-60. The local
configuration thus yields two different EAP type candidates for
authentication to the network. Unbeknownst to the user's device, the
credit with the 3G provider is fully depleted and the user will be
unable to authenticate with his EAP-AKA' credentials. Using his
identifier of the roaming consortium eduroam (see also [RFC7593]), he
could authenticate with EAP-TTLS and his john@realm.example user
identifier. Identity selection hints are not sent.
Consequence: If the EAP peer consistently chooses the Consequence: If the EAP peer consistently chooses the
imsi@mnc123.mcc123.3gpp-network.org user identifier as choice for its imsi@mnc123.mcc123.3gpp-network.org user identifier as choice for its
initial EAP-Response/Identity, the user will be consistently and initial EAP-Response/Identity, requests will always be routed to the
3GPP consortium EAP server, and the user will be consistently and
perpetually rejected, even though in possession of a valid credential perpetually rejected, even though in possession of a valid credential
for the hotspot. for the hotspot.
An EAP peer should always try all options to authenticate. As the An EAP peer should always try all options to authenticate. As the
example above shows, it may not be sufficient to rely on EAP method example above shows, it may not be sufficient to rely on EAP method
negotiation alone to iterate through all configured EAP types and negotiation alone to iterate through all configured EAP types and
come to a conclusive outcome of the authentication attempt. Multiple come to a conclusive outcome of the authentication attempt. Multiple
new EAP authentications, each using an EAP-Response/Identity from a new EAP authentications, each using an EAP-Response/Identity from a
different element of the set of method-specific outer identities, may different element of the set of realm identifiers, may be required to
be required to fully iterate through the list of usable identities. fully iterate through the list of usable identities.
3. Character (re-)encoding may be required 3. Character (re-)encoding may be required
The method-specific identities as configured in the EAP method The user identifiers as configured in the EAP method configuration
configuration are not always suited as identities to choose as EAP- are not always suited as realm identifiers to choose as EAP-Response/
Response/Identity: EAP methods define the encoding of their method- Identity: EAP methods define the encoding of their method-specific
specific outer identities at their leisure; in particular, the chosen outer identities at their leisure; in particular, the chosen encoding
encoding may or may not be UTF-8. may or may not be UTF-8.
It is not the intention of EAP, as a mere method-agnostic container It is not the intention of EAP, as a mere method-agnostic container
which simply carries EAP types, to restrict an EAP method's choice of which simply carries EAP types, to restrict an EAP method's choice of
encoding of method-specific identities. However, there are encoding of user identifiers. However, there are restrictions in
restrictions in what should be contained in the EAP-Response/ what should be contained in the EAP-Response/Identity: EAP is very
Identity: EAP is very often carried over a AAA protocol (e.g over often carried over a AAA protocol (e.g over RADIUS as per [RFC3579]).
RADIUS as per [RFC3579]). The typical use for the contents of EAP- The typical use for the contents of EAP-Response/Identity inside AAA
Response/Identity inside AAA protocols like RADIUS [RFC2865] and protocols like RADIUS [RFC2865] and Diameter [RFC6733] is to copy the
Diameter [RFC6733] is to copy the content of EAP-Response/Identity content of EAP-Response/Identity into a "User-Name" attribute; the
into a "User-Name" attribute; the encoding of the User-Name attribute encoding of the User-Name attribute is required to be UTF-8. EAP-
is required to be UTF-8. EAP-Response/Identity does not carry Response/Identity does not carry encoding information itself, so a
encoding information itself, so a conversion between a non-UTF-8 conversion between a non-UTF-8 encoding and UTF-8 is not possible for
encoding and UTF-8 is not possible for the AAA entity doing the EAP- the AAA entity doing the EAP-Response/Identity to User-Name copying.
Response/Identity to User-Name copying.
Consequence: If an EAP method's method-specific identity is not Consequence: If an EAP method's user identifier is not encoded in
encoded in UTF-8, and the EAP peer verbatimly uses that method- UTF-8, and if the EAP peer verbatimly uses that user identifier for
specific identity for its EAP-Response/Identity field, then the AAA its EAP-Response/Identity field, then the AAA entity is forced to
entity is forced to violate its own specification because it has to, violate its own specification because it has to, but can not use
but can not use UTF-8 for its own User-Name attribute. If the EAP UTF-8 for its own User-Name attribute. If the EAP method supports a
method supports a method-specific outer identity in a non UTF-8 separate realm identifier in a non UTF-8 character set, and the EAP
character set, and the EAP peer verbatimly uses that outer identity peer verbatimly uses that realm identifier for its EAP-Response/
for its EAP-Response/Identity field, then the same violation occurs. Identity field, then the same violation occurs.
This jeopardizes the subsequent EAP authentication as a whole; This jeopardizes the subsequent EAP authentication as a whole;
request routing may fail, lead to a wrong destination or introduce request routing may fail, lead to a wrong destination or introduce
routing loops due to differing interpretations of the User-Name in routing loops due to differing interpretations of the User-Name in
EAP pass-through authenticators and AAA proxies. EAP pass-through authenticators and AAA proxies.
4. Recommendations for EAP peer implementations 4. Recommendations for EAP peer implementations
Where method-specific identities or method-specific outer identities Where realm identifiers or user identifiers between multiple
in configured EAP types in an EAP peer differ, the EAP peer can not configured EAP types in an EAP peer differ, the EAP peer can not rely
rely on the EAP type negotiation mechanism alone to provide useful on the EAP type negotiation mechanism alone to provide useful
results. If an EAP authentication gets rejected, the EAP peer SHOULD results. If an EAP authentication gets rejected, the EAP peer SHOULD
re-try the authentication using a different EAP-Response/Identity re-try the authentication using a different EAP-Response/Identity
than before. The EAP peer SHOULD try all possible EAP-Response/ than before. The EAP peer SHOULD try all possible EAP-Response/
Identity contents from the entire set of configured EAP types before Identity contents from the entire set of configured EAP types before
declaring final authentication failure. declaring final authentication failure.
EAP peers need to maintain state on the encoding of the method- EAP peers need to maintain state on the encoding of the configured
specific identities and outer identities which are used in their user identifiers and realm identifiers which are used in their local
locally configured EAP types. When constructing an EAP-Response/ EAP type configuration. When constructing an EAP-Response/Identity
Identity from the set of identities, they MUST (re-)encode the from the set of available identifiers, they MUST (re-)encode the
corresponding identity as UTF-8 and use the resulting value for the corresponding identifier as UTF-8 and use the resulting value for the
EAP-Response/Identity. EAP-Response/Identity.
Where an EAP method supports privacy-preserving realm identifiers,
those SHOULD be configured for user privacy reasons. For deployments
of such EAP types, these realm identifiers MUST be in the the format
Network Access Identifier (NAI), see [RFC7542] if the realm
identifiers are expected to become used beyond the scope of a single,
closed enterprise. Even in such closed environments, the NAI format
is RECOMMENDED. The RECOMMENDED format for the local part of the
realm identifier is the empty string; where this is not possible the
suggested alternative is the string "anonymous".
5. Privacy Considerations 5. Privacy Considerations
Because the EAP-Response/Identity content is not encrypted, the Because the EAP-Response/Identity content is not encrypted, the
backtracking to a new EAP-Response/Identity will systematically backtracking to a new EAP-Response/Identity will systematically
reveal all configured identities to intermediate passive listeners on reveal all configured identifiers to intermediate passive listeners
the path between the EAP peer and the EAP server (until one on the path between the EAP peer and the EAP server (until one
authentication round succeeds). authentication round succeeds).
This additional leakage of identity information is not very This additional leakage of identity information is not very
significant though because where privacy is considered important, the significant though, because where privacy is considered important,
additional option for identity privacy which is present in most the additional option for separate privacy-preserving realm
modern EAP methods can be used. identifiers which is present in most modern EAP methods can and
should be used.
If the EAP peer implementation is certain that all EAP types will be If the EAP peer implementation is certain that all EAP types will be
terminated at the same EAP server (e.g. with a corresponding terminated at the same EAP server (e.g. with a corresponding
configuration option) then the iteration over all identities can be configuration option) then the iteration over all identities can be
avoided, because the EAP type negotiation is then sufficient. avoided, because EAP type negotiation is then sufficient.
If a choice of which identity information to disclose needs to be If a choice of which identity information to disclose needs to be
made by the EAP peer, when iterating through the list of identities made by the EAP peer, when iterating through the list of identifiers
the EAP peer SHOULD the EAP peer SHOULD
in first priority honour a manually configured order of preference o in first priority honour a manually configured order of preference
of EAP types, if any of EAP types, if any
in second priority try EAP types in order of less leakage first; o in second priority try EAP types in order of less leakage first;
that is, EAP types with a method-specific outer identity that that is, EAP types with a privacy-preserving realm identifier that
differs from the method-specific identity should be tried before differs from the user identifier should be tried before other EAP
other EAP types which would reveal actual user identities. types which would reveal the corresponding actual user
identifiers.
6. Security Considerations 6. Security Considerations
The security of an EAP conversation is determined by the EAP method The security of an EAP conversation is determined by the EAP method
which is used to authenticate. This document does not change the which is used to authenticate. This document does not change the
actual authentication with an EAP method, and all the security actual authentication with an EAP method, and all the security
properties of the chosen EAP method remain. The format requirements properties of the chosen EAP method remain. The format requirements
(character encoding) and operational considerations (re-try EAP with (character encoding) and operational considerations (re-try EAP with
a different EAP-Response/Identity) do not lead to new or different a different EAP-Response/Identity) do not lead to new or different
security properties. security properties.
skipping to change at page 9, line 5 skipping to change at page 9, line 46
Generation Authentication and Key Agreement (EAP-AKA')", Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, May 2009. RFC 5448, May 2009.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI
10.17487/RFC7542, May 2015, 10.17487/RFC7542, May 2015,
<http://www.rfc-editor.org/info/rfc7542>. <http://www.rfc-editor.org/info/rfc7542>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593, DOI 10.17487/
RFC7593, September 2015,
<http://www.rfc-editor.org/info/rfc7593>.
Author's Address Author's Address
Stefan Winter Stefan Winter
Fondation RESTENA Fondation RESTENA
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG LUXEMBOURG
Phone: +352 424409 1 Phone: +352 424409 1
Fax: +352 422473 Fax: +352 422473
 End of changes. 41 change blocks. 
139 lines changed or deleted 190 lines changed or added

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