idnits 2.17.1 draft-ietf-radext-populating-eapidentity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2930 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Best Current Practice March 21, 2016 5 Expires: September 22, 2016 7 Considerations regarding the correct use of EAP-Response/Identity 8 draft-ietf-radext-populating-eapidentity-00 10 Abstract 12 There are some subtle considerations for an EAP peer regarding the 13 content of the EAP-Response/Identity packet when authenticating with 14 EAP to an EAP server. This document describes two such 15 considerations and suggests workarounds to the associated problems. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 22, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Taxonomy of identities in EAP . . . . . . . . . . . . . . 2 54 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2. EAP-Response/Identity: Effects on EAP type negotiation . . . 5 56 3. Character (re-)encoding may be required . . . . . . . . . . . 6 57 4. Recommendations for EAP peer implementations . . . . . . . . 6 58 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 8.2. Informative References . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 1.1. Problem Statement 69 An Extensible Authentication Protocol (EAP, [RFC3748]) conversation 70 between an EAP peer and an EAP server starts with an (optional) 71 request for identity information by the EAP server (EAP-Request/ 72 Identity) followed by the peer's response with identity information 73 (EAP-Response/Identity). Only after this identity exchange are EAP 74 types negotiated. 76 EAP-Response/Identity is sent before EAP type negotiation takes 77 place, but it is not independent of the later-negotiated EAP type. 78 Two entanglements between EAP-Response/Identity and EAP methods' 79 notions of a user identifier are described in this document. 81 1. The choice of identity to send in EAP-Response/Identity may have 82 detrimental effects on the subsequent EAP type negotiation. 84 2. Using identity information from the preferred EAP type without 85 thoughtful conversion of character encoding may have detrimental 86 effects on the outcome of the authentication. 88 The following two chapters describe each of these issues in detail. 89 The last chapter contains recommendations for implementers of EAP 90 peers to avoid these issues. 92 1.2. Taxonomy of identities in EAP 94 The notion of identity occurs numerous times in the EAP protocol 95 stack (EAP-Response/Identity, Outer identity, method-specific 96 identity, tunneled identity). This document uses the following 97 terminology when discussing EAP identities. 99 o Method-specific Identity: Each EAP method has a means to identify 100 the user or machine that tries to authenticate. There are no 101 restrictions on the format or encoding of this method-specific 102 identity. If an EAP methods distinguishes between this actual 103 identity and a outer identity (see next bullet), then the Method- 104 specific Identity is also often called the Inner Identity. 106 o Method-specific Outer Identity: Some EAP methods allow privacy- 107 preserving enhancements where a string is sent as "identity" which 108 is actually not necessarily related to the user or machine that 109 tries to authenticate. There is often a relationship between the 110 Method-specific Outer Identity and the Inner Identity (e.g. they 111 often share the same NAI realm suffix); but this is not a 112 requirement. There are no restrictions on the format or encoding 113 of this method-specific identity. Method-specific outer 114 identities are either 116 * explicitly configured (e.g. string input UI: "Outer Identity") 118 * implicitly configured by copying the actual Method-specific 119 (Inner) Identity 121 * implicitly configured by copying the NAI realm of the Method- 122 specific (Inner) Identity and prefixing it non-configurably 123 with a fixed privacy-preserving local username part like 124 "anonymous" or the empty string (see [RFC7542]) 126 * configured in a mixed way, e.g. using a explicit string input 127 UI for the local part of the outer identity and combining it 128 implicitly with a copy of the NAI realm part of the Method- 129 specific (Inner) Identity 131 o EAP-Response/Identity: a string representing the user or machine 132 that tries to authenticate, used outside the EAP method-specific 133 context for the entire EAP session. There can be only one EAP- 134 Response/Identity per EAP session, even if that session is 135 configured with more than one EAP method to authenticate with. As 136 per [RFC3748] there is no encoding requirement on EAP-Response/ 137 Identity. In AAA protocol routing contexts, the content of EAP- 138 Response/Identity is often used for request routing purposes. 139 EAP-Response/Identity is chosen from the set: 141 * all method-specific outer identities from all configured EAP 142 types supporting the notion of an outer identity union 144 * all method-specific identities from all configured EAP types 145 without the notion of an outer identity 147 One of the two problems addressed in this document stems from this 148 fact: the set of identities may contain more than one element. 149 The resulting EAP-Response/Identity always routes all configured 150 EAP types to only one destination, even if different EAP types 151 would need routing to different destinations. 153 o User-Name: when using EAP in AAA protocol contexts (e.g. RADIUS 154 [RFC2865], Diameter [RFC6733]), this additional identity is 155 created outside the EAP peer (typically in a pass-through 156 authenticator) by copying EAP-Response/Identity content to the AAA 157 protocol's User-Name attribute. There is no format requirement on 158 User-Name, but there is an encoding requirement: the string MUST 159 be UTF-8 encoded. One of the two problems addressed in this 160 document stems from this fact: EAP-Response/Identity does not have 161 an encoding requirement, nor does it carry meta-information about 162 the encoding used - and yet, it needs to be coerced into a UTF-8 163 encoding. 165 o Further identities: Some EAP methods establish an EAP session 166 inside EAP (e.g. PEAP first establishes a TLS tunnel using a 167 method-specific outer identity, and then starts an EAP exchange 168 inside the tunnel). This being a new, independent EAP session, it 169 contains its own EAP-Response/Identity, can invoke EAP method 170 negotiation with different (inner) EAP types (this happens e.g. 171 with EAP-FAST and its configurable choice of EAP-GTC or EAP- 172 MSCHAPv2 inside the inner EAP session), and those inner EAP 173 methods then have their own (inner) method-specific identities. 174 Where the inner EAP method itself supports the notion of method- 175 specific outer identities, another identity could be configured. 176 For the purposes of this document, none of those details are 177 considered and the process by which the (outer) EAP method selects 178 its method-specific identity is left entirely to that EAP type. 179 This document does not consider the (inner) EAP-Response/Identity 180 in scope; the recommendations in this document to not apply to 181 such (inner) occurences of EAP-Response/Identity. 183 1.3. Requirements Language 185 In this document, several words are used to signify the requirements 186 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 187 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 188 and "OPTIONAL" in this document are to be interpreted as described in 189 RFC 2119. [RFC2119] 191 2. EAP-Response/Identity: Effects on EAP type negotiation 193 Assuming the EAP peer's EAP type selection is not the trivial case 194 (i.e. it has more than one configured EAP type for a given network or 195 application, and needs to make a decision which one to use), an issue 196 arises when the configured EAP types are not all configured with the 197 same method-specific outer identity (or method-specific identity for 198 EAP types not supporting the notion of an outer identity). 200 Issue: if the identities in the set of configured EAP types differ 201 (e.g. have a different [RFC7542] "realm" portion), and the 202 authenticator does not send identity selection hints as per 203 [RFC7542], then EAP type negotiation may be limited to those EAP 204 types which are terminated in the same EAP server. The reason for 205 that is because the information in the EAP-Response/Identity is used 206 for request routing decisions and thus determines the EAP server - a 207 given user identifier may be routed to a server which exclusively 208 serves the matching EAP type. Negotiating another EAP type from the 209 set of configured EAP types during the running EAP conversation is 210 then not possible. 212 Example: 214 Assume an EAP peer is configured to support two EAP types: 216 o EAP-AKA' [RFC5448] with user identifier imsi@mnc123.mcc123.3gpp- 217 network.org 219 o EAP-TTLS [RFC5281] with user identifier john@realm.example 221 The user connects to hotspot of a roaming consortium which could 222 authenticate him with EAP-TTLS and his john@realm.example identity. 223 The hotspot operator has no business relationship at all with the 224 3GPP consortium; incoming authentication requests for realms ending 225 in 3gppnetwork.org will be immediately rejected. Identity selection 226 hints are not sent. 228 Consequence: If the EAP peer consistently chooses the 229 imsi@mnc123.mcc123.3gpp-network.org user identifier as choice for its 230 initial EAP-Response/Identity, the user will be consistently and 231 perpetually rejected, even though in possession of a valid credential 232 for the hotspot. 234 An EAP peer should always try all options to authenticate. As the 235 example above shows, it may not be sufficient to rely on EAP method 236 negotiation alone to iterate through all configured EAP types and 237 come to a conclusive outcome of the authentication attempt. Multiple 238 new EAP authentications, each using an EAP-Response/Identity from a 239 different element of the set of method-specific outer identities, may 240 be required to fully iterate through the list of usable identities. 242 3. Character (re-)encoding may be required 244 The method-specific identities as configured in the EAP method 245 configuration are not always suited as identities to choose as EAP- 246 Response/Identity: EAP methods define the encoding of their method- 247 specific outer identities at their leisure; in particular, the chosen 248 encoding may or may not be UTF-8. 250 It is not the intention of EAP, as a mere method-agnostic container 251 which simply carries EAP types, to restrict an EAP method's choice of 252 encoding of method-specific identities. However, there are 253 restrictions in what should be contained in the EAP-Response/ 254 Identity: EAP is very often carried over a AAA protocol (e.g over 255 RADIUS as per [RFC3579]). The typical use for the contents of EAP- 256 Response/Identity inside AAA protocols like RADIUS [RFC2865] and 257 Diameter [RFC6733] is to copy the content of EAP-Response/Identity 258 into a "User-Name" attribute; the encoding of the User-Name attribute 259 is required to be UTF-8. EAP-Response/Identity does not carry 260 encoding information itself, so a conversion between a non-UTF-8 261 encoding and UTF-8 is not possible for the AAA entity doing the EAP- 262 Response/Identity to User-Name copying. 264 Consequence: If an EAP method's method-specific identity is not 265 encoded in UTF-8, and the EAP peer verbatimly uses that method- 266 specific identity for its EAP-Response/Identity field, then the AAA 267 entity is forced to violate its own specification because it has to, 268 but can not use UTF-8 for its own User-Name attribute. If the EAP 269 method supports a method-specific outer identity in a non UTF-8 270 character set, and the EAP peer verbatimly uses that outer identity 271 for its EAP-Response/Identity field, then the same violation occurs. 273 This jeopardizes the subsequent EAP authentication as a whole; 274 request routing may fail, lead to a wrong destination or introduce 275 routing loops due to differing interpretations of the User-Name in 276 EAP pass-through authenticators and AAA proxies. 278 4. Recommendations for EAP peer implementations 280 Where method-specific identities or method-specific outer identities 281 in configured EAP types in an EAP peer differ, the EAP peer can not 282 rely on the EAP type negotiation mechanism alone to provide useful 283 results. If an EAP authentication gets rejected, the EAP peer SHOULD 284 re-try the authentication using a different EAP-Response/Identity 285 than before. The EAP peer SHOULD try all possible EAP-Response/ 286 Identity contents from the entire set of configured EAP types before 287 declaring final authentication failure. 289 EAP peers need to maintain state on the encoding of the method- 290 specific identities and outer identities which are used in their 291 locally configured EAP types. When constructing an EAP-Response/ 292 Identity from the set of identities, they MUST (re-)encode the 293 corresponding identity as UTF-8 and use the resulting value for the 294 EAP-Response/Identity. 296 5. Privacy Considerations 298 Because the EAP-Response/Identity content is not encrypted, the 299 backtracking to a new EAP-Response/Identity will systematically 300 reveal all configured identities to intermediate passive listeners on 301 the path between the EAP peer and the EAP server (until one 302 authentication round succeeds). 304 This additional leakage of identity information is not very 305 significant though because where privacy is considered important, the 306 additional option for identity privacy which is present in most 307 modern EAP methods can be used. 309 If the EAP peer implementation is certain that all EAP types will be 310 terminated at the same EAP server (e.g. with a corresponding 311 configuration option) then the iteration over all identities can be 312 avoided, because the EAP type negotiation is then sufficient. 314 If a choice of which identity information to disclose needs to be 315 made by the EAP peer, when iterating through the list of identities 316 the EAP peer SHOULD 318 in first priority honour a manually configured order of preference 319 of EAP types, if any 321 in second priority try EAP types in order of less leakage first; 322 that is, EAP types with a method-specific outer identity that 323 differs from the method-specific identity should be tried before 324 other EAP types which would reveal actual user identities. 326 6. Security Considerations 328 The security of an EAP conversation is determined by the EAP method 329 which is used to authenticate. This document does not change the 330 actual authentication with an EAP method, and all the security 331 properties of the chosen EAP method remain. The format requirements 332 (character encoding) and operational considerations (re-try EAP with 333 a different EAP-Response/Identity) do not lead to new or different 334 security properties. 336 7. IANA Considerations 338 There are no IANA actions in this document. 340 8. References 342 8.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 8.2. Informative References 349 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 350 "Remote Authentication Dial In User Service (RADIUS)", RFC 351 2865, June 2000. 353 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 354 Dial In User Service) Support For Extensible 355 Authentication Protocol (EAP)", RFC 3579, September 2003. 357 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 358 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 359 3748, June 2004. 361 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 362 Protocol Tunneled Transport Layer Security Authenticated 363 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 365 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 366 Extensible Authentication Protocol Method for 3rd 367 Generation Authentication and Key Agreement (EAP-AKA')", 368 RFC 5448, May 2009. 370 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 371 "Diameter Base Protocol", RFC 6733, October 2012. 373 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 374 10.17487/RFC7542, May 2015, 375 . 377 Author's Address 379 Stefan Winter 380 Fondation RESTENA 381 6, rue Richard Coudenhove-Kalergi 382 Luxembourg 1359 383 LUXEMBOURG 385 Phone: +352 424409 1 386 Fax: +352 422473 387 EMail: stefan.winter@restena.lu 388 URI: http://www.restena.lu.