RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Best Current Practice February 14, 2014 Expires: August 18, 2014 Considerations regarding the correct use of EAP-Response/Identity draft-winter-radext-populating-eapidentity-00 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 August 18, 2014. 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 August 18, 2014 [Page 1]
Internet-Draft Populating EAP-Response/Identity February 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 . . . . . . . . 4 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 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 the username to be used in the EAP method 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 August 18, 2014 [Page 2]
Internet-Draft Populating EAP-Response/Identity February 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, 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 username. Issue: if the usernames in the set of configured EAP types differ (e.g. have a different [RFC4282] "realm" portion), 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 username 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 username imsi@mnc123.mcc123.3gpp- network.org o EAP-TTLS [RFC5281] with username 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. Consequence: If the EAP peer consistently choses the imsi@mnc123.mcc123.3gpp-network.org username 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 come to a conclusive outcome of the authentication attempt. Multiple new EAP authentications, each using a different username from the set of configured usernames, may be required to fully iterate through the list of usable identities. Winter Expires August 18, 2014 [Page 3]
Internet-Draft Populating EAP-Response/Identity February 2014 3. Character (re-)encoding may be required The username as configured in the EAP method configuration is not always suited as username 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 usernames; in particular, the encoding of the usernames 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 usernames. 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 username. 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 username is not encoded in UTF-8, and the EAP peer verbatimly uses that method's notion of a username 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. This jeopardizes the subsequent EAP authentication as a whole; request routing may fail or lead to a wrong destinationi, or the AAA payload may be discarded by the recipient due to the malformedness of the User-Name attribute. 4. Recommendations for EAP peer implementations Where usernames 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 usernames from the entire set of configured EAP types before declaring final authentication failure. EAP peers need to maintain state on the encoding of the usernames which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that username information, Winter Expires August 18, 2014 [Page 4]
Internet-Draft Populating EAP-Response/Identity February 2014 they SHOULD (re-)encode that username 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 should 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. 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. Winter Expires August 18, 2014 [Page 5]
Internet-Draft Populating EAP-Response/Identity February 2014 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. [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. 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 August 18, 2014 [Page 6]