Internet DRAFT - draft-winter-radext-populating-eapidentity

draft-winter-radext-populating-eapidentity







RADIUS Extensions Working Group                                S. Winter
Internet-Draft                                                   RESTENA
Intended status: Best Current Practice                  October 27, 2014
Expires: April 30, 2015


   Considerations regarding the correct use of EAP-Response/Identity
             draft-winter-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.

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 April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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.




Winter                   Expires April 30, 2015                 [Page 1]

Internet-Draft      Populating EAP-Response/Identity        October 2014


Table of Contents

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

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 to send in EAP-Response/Identity may have
       detrimental effects on the subsequent EAP type negotiation.

   2.  Using identity information 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.  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",




Winter                   Expires April 30, 2015                 [Page 2]

Internet-Draft      Populating EAP-Response/Identity        October 2014


   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 user identifier.

   Issue: if the user identifiers in the set of configured EAP types
   differ (e.g. have a different [RFC4282] "realm" portion), and the
   authenticator does not send identity selection hints as per
   [RFC4284], 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 identifier may be routed to a server which exclusively
   serves the matching EAP type.  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

   o  EAP-TTLS [RFC5281] with user identifier john@realm.example

   The user connects to hotspot of a roaming consortium which 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.  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, 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



Winter                   Expires April 30, 2015                 [Page 3]

Internet-Draft      Populating EAP-Response/Identity        October 2014


   come to a conclusive outcome of the authentication attempt.  Multiple
   new EAP authentications, each using a different user identifier from
   the set of configured user identities, may be required to fully
   iterate through the list of usable identities.

3.  Character (re-)encoding may be required

   The user identifier as configured in the EAP method configuration is
   not always suited as user identifier to choose as EAP-Response/
   Identity.  This is trivially true when using tunneled EAP types and
   configuring anonymous outer identity for the tunneling EAP type.
   There is at least one additional, non-trivial, case to consider
   however:

   EAP methods define the encoding of their user identifiers; in
   particular, the encoding of the user identifiers as defined the EAP
   method may or may not be UTF-8; some EAP methods are even known not
   to put any encoding restrictions on their user identifiers at all.

   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 a user identifier.  However, there are restrictions in
   what should be contained in the 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 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 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 to User-Name copying.

   Consequence: If an EAP method's user identifier is not encoded in
   UTF-8, and the EAP peer verbatimly uses that method's notion of a
   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 configuration sets an outer identity in a non UTF-8 character
   set, and the EAP peer verbatimly uses that outer identity for its
   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.






Winter                   Expires April 30, 2015                 [Page 4]

Internet-Draft      Populating EAP-Response/Identity        October 2014


4.  Recommendations for EAP peer implementations

   Where user identifiers between 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 user identifiers from the entire set of configured EAP types
   before declaring final authentication failure.

   EAP peers need to maintain state on the encoding of the user
   identifiers which are used in their locally configured EAP types.
   When constructing an EAP-Response/Identity from that user identifier,
   they MUST (re-)encode that user identifier as UTF-8 and use the
   resulting value for the EAP-Response/Identity.  If the EAP type is
   configured for the use of anonymous outer identities, the desired
   outer identity MUST also be (re-)encoded in UTF-8 encoding before
   being put into the EAP-Response/Identity.

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 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 because where privacy is considered important, the
   additional option for identity privacy which is present in most
   modern EAP methods can 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
   the EAP peer SHOULD

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

      in second priority try EAP types in order of less leakage first;
      that is, EAP types with a configured outer identity should be
      tried before other EAP types which would reveal actual user
      identities.



Winter                   Expires April 30, 2015                 [Page 5]

Internet-Draft      Populating EAP-Response/Identity        October 2014


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.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4284]  Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
              Selection Hints for the Extensible Authentication Protocol
              (EAP)", RFC 4284, January 2006.

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






Winter                   Expires April 30, 2015                 [Page 6]

Internet-Draft      Populating EAP-Response/Identity        October 2014


   [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.

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.































Winter                   Expires April 30, 2015                 [Page 7]