RADIUS Extensions Working Group                                S. Winter
Internet-Draft                                                   RESTENA
Updates: 3748 (if approved)                                July 08, 2016
Intended status: Best Current Practice                    March 21, 2016
Expires: September 22, 2016 January 9, 2017

   Considerations regarding the correct use of EAP-Response/Identity
              draft-ietf-radext-populating-eapidentity-00
              draft-ietf-radext-populating-eapidentity-01

Abstract

   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 22, 2016. January 9, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Taxonomy of identities in EAP . . . . . . . . . . . . . .   2   3
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4   5
   2.  EAP-Response/Identity: Effects on EAP type negotiation  . . .   5
   3.  Character (re-)encoding may be required . . . . . . . . . . .   6
   4.  Recommendations for EAP peer implementations  . . . . . . . .   6   7
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8   9

1.  Introduction

1.1.  Problem Statement

   An Extensible Authentication Protocol (EAP, [RFC3748]) conversation
   between an EAP peer and an EAP server starts with an (optional)
   request for identity information by the EAP server (EAP-Request/
   Identity) followed by the peer's response with identity information
   (EAP-Response/Identity).  Only after this identity exchange are EAP
   types negotiated.

   EAP-Response/Identity is sent before EAP type negotiation takes
   place, but it is not independent of the later-negotiated EAP type.
   Two entanglements between EAP-Response/Identity and EAP methods'
   notions of a user identifier are described in this document.

   1.  The choice of identity identifier to send in EAP-Response/Identity may
       have detrimental effects on the subsequent EAP type negotiation.

   2.  Using identity information identifiers from the preferred EAP type without thoughtful
       conversion of character encoding may have detrimental effects on
       the outcome of the authentication.

   The following two chapters describe each of these issues in detail.
   The last chapter contains recommendations for implementers of EAP
   peers to avoid these issues.

1.2.  Taxonomy of identities in EAP

   The notion of identity occurs numerous times in the EAP protocol
   stack (EAP-Response/Identity, Outer identity, method-specific
   identity, tunneled identity).  This document uses the following
   terminology when discussing EAP identities.

   o  Method-specific Identity:  User Identifier: Each EAP method has a means to identify the user
      or machine that tries to authenticate.  There are no restrictions
      on the format or encoding of this method-specific
      identity. identifier.  The user identifier
      is often also referred to as "method-specific identity".  If an
      EAP methods method distinguishes between this actual
      identity the user identifier and a outer identity realm
      identifier (see next bullet), then the Method-
      specific Identity user identifier is also
      often called referred to as the Inner Identity. "inner/true/real identity".

   o  Method-specific Outer Identity:  Realm Identifier: Some EAP methods allow privacy-
      preserving privacy-preserving
      enhancements where a string is sent as "identity" which is actually not
      necessarily related to the user or machine that tries to
      authenticate.  This identifier is often also referred to as "outer
      identity" or "roaming identity" or "anonymous outer identity".
      There is often a relationship between the
      Method-specific Outer Identity realm identifier and the Inner Identity
      user identifier (e.g. they often share the same NAI realm suffix);
      but this is not a requirement.  There are no restrictions on the
      format or encoding of this method-specific identity.  Method-specific outer
      identities the realm identifier.  Realm identifiers are
      either

      *  explicitly configured (e.g. string input UI: UI in EAP peer: "Outer
         Identity")

      *  implicitly configured by copying the actual Method-specific
         (Inner) Identity user identifier

      *  implicitly configured by copying the NAI realm of the Method-
         specific (Inner) Identity user
         identifier and prefixing it non-configurably with a fixed
         privacy-preserving local username part like "anonymous" or the
         empty string (see [RFC7542])

      *  configured in a mixed way, e.g. using a explicit string input
         UI for the local part of the outer identity realm identifier and combining it
         implicitly with a copy of the NAI realm part of the Method-
         specific (Inner) Identity user
         identifier

   o  EAP-Response/Identity: a string representing the user or machine
      that tries to authenticate, used outside the EAP method-specific
      context for the entire EAP session. conversation.  There can be only one EAP-
      Response/Identity
      EAP-Response/Identity per EAP session, conversation, even if that session is
      configured with
      conversation could negotiate more than one EAP method to
      authenticate with.  As per [RFC3748] there is no encoding
      requirement on EAP-Response/
      Identity. EAP-Response/Identity (which this document changes:

      the encoding MUST be UTF-8).  In AAA protocol routing contexts,
      the content of EAP-
      Response/Identity EAP-Response/Identity is often used for request
      routing purposes.  EAP-Response/Identity is chosen from the set:

      *  all method-specific outer identities realm identifiers from all configured EAP types supporting
         the notion of an outer identity union a realm identifier

      *  all method-specific identities user identifiers from all configured EAP types without the
         notion of an outer identity a realm identifier

      Several EAP types in a local configuration may share the same user
      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 identities 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
      [RFC2865], Diameter [RFC6733]), this additional identity identifier is
      created outside the EAP peer (typically in a pass-through
      authenticator) by copying EAP-Response/Identity content to the AAA
      protocol's User-Name attribute.  There is no format requirement on
      User-Name, but there is an encoding requirement: the string MUST
      be UTF-8 encoded.  One of the two problems addressed in this
      document stems from this fact: EAP-Response/Identity does not have
      an encoding requirement, nor does it carry meta-information about
      the encoding used - and yet, it needs to be coerced into a UTF-8
      encoding.

   o  Further identities: identifiers: Some EAP methods establish an EAP session
      inside EAP (e.g. PEAP first establishes a TLS tunnel using a
      method-specific outer identity, realm
      identifier, and then starts an EAP exchange inside the tunnel).
      This being a new, independent EAP session, it contains its own
      EAP-Response/Identity, can invoke EAP method negotiation with
      different (inner) EAP types (this happens e.g. with EAP-FAST and
      its configurable choice of EAP-GTC or EAP-
      MSCHAPv2 EAP-MSCHAPv2 inside the
      inner EAP session), and those inner EAP methods then have their
      own (inner) method-specific identities. user identifiers.  Where the inner EAP method itself supports
      the notion of method-
      specific outer identities, realm identifiers, another identity identifier could be
      configured.  For the purposes of this document, none of those
      details are considered and the process by which the (outer) EAP
      method selects its method-specific identity user identifier is left entirely to that EAP
      type.  This document does not consider the (inner) EAP-Response/Identity EAP-Response/
      Identity in scope; the recommendations in this document to not
      apply to such (inner) occurences of EAP-Response/Identity.

1.3.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.  [RFC2119]

2.  EAP-Response/Identity: Effects on EAP type negotiation

   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
   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
   same method-specific outer identity realm identifier (or method-specific identity user identifier for EAP types not
   supporting the notion of an outer identity). a realm identifier).

   Issue: if the identities identifiers in the set of configured EAP types differ
   (e.g. have a different [RFC7542] "realm" portion), and the
   authenticator does not send identity selection hints as per
   [RFC7542], then EAP type negotiation may be limited to those EAP
   types which are terminated in the same EAP server.  The reason for
   that is because the information in the EAP-Response/Identity is used
   for request routing decisions and thus determines the EAP server - a
   given user realm identifier may be routed to a server which exclusively
   serves the matching corresponding EAP type. types.  Negotiating another EAP type
   from the set of configured EAP types during the running EAP
   conversation is then not possible.

   Example:

   Assume an EAP peer is configured to support two EAP types:

   o  EAP-AKA' [RFC5448] with user identifier imsi@mnc123.mcc123.3gpp-
      network.org
      network.org; the configuration is set up to authenticate only to

      *  cellular networks

      *  Wi-Fi Passpoint networks which advertise support for the MNC
         123 and MCC 123

      The EAP server for this EAP type is in a host under control of the
      3GPP consortium

   o  EAP-TTLS [RFC5281] with user identifier john@realm.example "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 connects to approaches a Passpoint Wi-Fi hotspot of 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 which eduroam (see also [RFC7593]), he
   could authenticate him with EAP-TTLS and his john@realm.example identity.
   The hotspot operator has no business relationship at all with the
   3GPP consortium; incoming authentication requests for realms ending
   in 3gppnetwork.org will be immediately rejected. user
   identifier.  Identity selection hints are not sent.

   Consequence: If the EAP peer consistently chooses the
   imsi@mnc123.mcc123.3gpp-network.org user identifier as choice for its
   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
   for the hotspot.

   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
   negotiation alone to iterate through all configured EAP types and
   come to a conclusive outcome of the authentication attempt.  Multiple
   new EAP authentications, each using an EAP-Response/Identity from a
   different element of the set of method-specific outer identities, realm identifiers, may be required to
   fully iterate through the list of usable identities.

3.  Character (re-)encoding may be required

   The method-specific identities user identifiers as configured in the EAP method configuration
   are not always suited as identities realm identifiers to choose as EAP-
   Response/Identity: EAP-Response/
   Identity: EAP methods define the encoding of their method-
   specific method-specific
   outer identities at their leisure; in particular, the chosen encoding
   may or may not be UTF-8.

   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
   encoding of method-specific identities. user identifiers.  However, there are restrictions in
   what should be contained in the EAP-Response/
   Identity: EAP-Response/Identity: EAP is very
   often carried over a AAA protocol (e.g over RADIUS as per [RFC3579]).
   The typical use for the contents of EAP-
   Response/Identity EAP-Response/Identity inside AAA
   protocols like RADIUS [RFC2865] and Diameter [RFC6733] is to copy the
   content of EAP-Response/Identity into a "User-Name" attribute; the
   encoding of the User-Name attribute is required to be UTF-8.  EAP-Response/Identity  EAP-
   Response/Identity does not carry encoding information itself, so a
   conversion between a non-UTF-8 encoding and UTF-8 is not possible for
   the AAA entity doing the EAP-
   Response/Identity EAP-Response/Identity to User-Name copying.

   Consequence: If an EAP method's method-specific identity user identifier is not encoded in
   UTF-8, and if the EAP peer verbatimly uses that method-
   specific identity user identifier for
   its EAP-Response/Identity field, then the AAA entity is forced to
   violate its own specification because it has to, but can not use
   UTF-8 for its own User-Name attribute.  If the EAP method supports a method-specific outer identity
   separate realm identifier in a non UTF-8 character set, and the EAP
   peer verbatimly uses that outer identity realm identifier for its EAP-Response/Identity EAP-Response/
   Identity field, then the same violation occurs.

   This jeopardizes the subsequent EAP authentication as a whole;
   request routing may fail, lead to a wrong destination or introduce
   routing loops due to differing interpretations of the User-Name in
   EAP pass-through authenticators and AAA proxies.

4.  Recommendations for EAP peer implementations

   Where method-specific identities realm identifiers or method-specific outer identities
   in user identifiers between multiple
   configured EAP types in an EAP peer differ, the EAP peer can not rely
   on the EAP type negotiation mechanism alone to provide useful
   results.  If an EAP authentication gets rejected, the EAP peer SHOULD
   re-try the authentication using a different EAP-Response/Identity
   than before.  The EAP peer SHOULD try all possible EAP-Response/
   Identity contents from the entire set of configured EAP types before
   declaring final authentication failure.

   EAP peers need to maintain state on the encoding of the method-
   specific identities configured
   user identifiers and outer identities realm identifiers which are used in their
   locally configured local
   EAP types. type configuration.  When constructing an EAP-Response/
   Identity EAP-Response/Identity
   from the set of identities, available identifiers, they MUST (re-)encode the
   corresponding identity identifier as UTF-8 and use the resulting value for the
   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

   Because the EAP-Response/Identity content is not encrypted, the
   backtracking to a new EAP-Response/Identity will systematically
   reveal all configured identities identifiers to intermediate passive listeners
   on the path between the EAP peer and the EAP server (until one
   authentication round succeeds).

   This additional leakage of identity information is not very
   significant though though, because where privacy is considered important,
   the additional option for identity privacy separate privacy-preserving realm
   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
   terminated at the same EAP server (e.g. with a corresponding
   configuration option) then the iteration over all identities can be
   avoided, because the EAP type negotiation is then sufficient.

   If a choice of which identity information to disclose needs to be
   made by the EAP peer, when iterating through the list of identities identifiers
   the EAP peer SHOULD

   o  in first priority honour a manually configured order of preference
      of EAP types, if any

   o  in second priority try EAP types in order of less leakage first;
      that is, EAP types with a method-specific outer identity privacy-preserving realm identifier that
      differs from the method-specific identity user identifier should be tried before other EAP
      types which would reveal the corresponding actual user identities.
      identifiers.

6.  Security Considerations

   The security of an EAP conversation is determined by the EAP method
   which is used to authenticate.  This document does not change the
   actual authentication with an EAP method, and all the security
   properties of the chosen EAP method remain.  The format requirements
   (character encoding) and operational considerations (re-try EAP with
   a different EAP-Response/Identity) do not lead to new or different
   security properties.

7.  IANA Considerations

   There are no IANA actions in this document.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.

   [RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
              Extensible Authentication Protocol Method for 3rd
              Generation Authentication and Key Agreement (EAP-AKA')",
              RFC 5448, May 2009.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542, DOI
              10.17487/RFC7542, May 2015,
              <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

   Stefan Winter
   Fondation RESTENA
   6, rue Richard Coudenhove-Kalergi
   Luxembourg  1359
   LUXEMBOURG

   Phone: +352 424409 1
   Fax:   +352 422473
   EMail: stefan.winter@restena.lu
   URI:   http://www.restena.lu.