idnits 2.17.1 draft-arkko-eap-rfc5448bis-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5448, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC4187, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5448' is mentioned on line 1061, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft V. Lehtovirta 4 Obsoletes: 5448 (if approved) V. Torvinen 5 Intended status: Informational Ericsson 6 Expires: September 6, 2018 P. Eronen 7 Nokia 8 March 5, 2018 10 Improved Extensible Authentication Protocol Method for 3rd Generation 11 Authentication and Key Agreement (EAP-AKA') 12 draft-arkko-eap-rfc5448bis-01 14 Abstract 16 This specification defines a new EAP method, EAP-AKA', a small 17 revision of the EAP-AKA method. The change is a new key derivation 18 function that binds the keys derived within the method to the name of 19 the access network. The new key derivation mechanism has been 20 defined in the 3rd Generation Partnership Project (3GPP). This 21 specification allows its use in EAP in an interoperable manner. In 22 addition, EAP-AKA' employs SHA-256 instead of SHA-1. 24 This specification also updates RFC 4187 EAP-AKA to prevent bidding 25 down attacks from EAP-AKA'. 27 This version of the EAP-AKA' specification updates a reference to 28 constructing one field in the protocol, so that EAP-AKA' becomes 29 compatible with 5G deployments as well. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 6, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 67 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 11 71 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 13 72 3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 13 73 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 14 75 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 14 76 5. Identifier Usage in 5G . . . . . . . . . . . . . . . . . . . 16 77 5.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 17 78 5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 17 79 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7.1. Security Properties of Binding Network Names . . . . . . 21 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 83 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 22 85 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 23 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 11.2. Informative References . . . . . . . . . . . . . . . . . 25 91 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 26 92 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 26 93 Appendix C. Importance of Explicit Negotiation . . . . . . . . . 26 94 Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 97 1. Introduction 99 This specification defines a new Extensible Authentication Protocol 100 (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA 101 method originally defined in [RFC4187]. What is new in EAP-AKA' is 102 that it has a new key derivation function, specified in 103 [TS-3GPP.33.402]. This function binds the keys derived within the 104 method to the name of the access network. This limits the effects of 105 compromised access network nodes and keys. This specification 106 defines the EAP encapsulation for AKA when the new key derivation 107 mechanism is in use. 109 3GPP has defined a number of applications for the revised AKA 110 mechanism, some based on native encapsulation of AKA over 3GPP radio 111 access networks and others based on the use of EAP. 113 For making the new key derivation mechanisms usable in EAP-AKA, 114 additional protocol mechanisms are necessary. Given that RFC 4187 115 calls for the use of CK (the encryption key) and IK (the integrity 116 key) from AKA, existing implementations continue to use these. Any 117 change of the key derivation must be unambiguous to both sides in the 118 protocol. That is, it must not be possible to accidentally connect 119 old equipment to new equipment and get the key derivation wrong or 120 attempt to use wrong keys without getting a proper error message. 121 The change must also be secure against bidding down attacks that 122 attempt to force the participants to use the least secure mechanism. 124 This specification therefore introduces a variant of the EAP-AKA 125 method, called EAP-AKA'. This method can employ the derived keys CK' 126 and IK' from the 3GPP specification and updates the used hash 127 function to SHA-256 [FIPS.180-2.2002]. But it is otherwise 128 equivalent to RFC 4187. Given that a different EAP method type value 129 is used for EAP-AKA and EAP-AKA', a mutually supported method may be 130 negotiated using the standard mechanisms in EAP [RFC3748]. 132 Note: Appendix C explains why it is important to be explicit about 133 the change of semantics for the keys, and why other approaches 134 would lead to severe interoperability problems. 136 This version of the EAP-AKA' specification is an update to RFC 5448. 137 The update consists of three things: 139 o Update the reference on how the Network Name field is constructed 140 in the protocol. The update helps ensure that EAP-AKA' becomes 141 compatible with 5G deployments as well. RFC 5448 referred to the 142 2008 version of that reference ([TS-3GPP.24.302]) and this update 143 points to the 5G version of that reference. 145 o Specify how EAP and EAP-AKA' use identifiers in 5G, as additional 146 identifiers are introduced, and for interoperability, it is 147 important that implementations use the right ones. 149 o Specify session identifiers and other exported parameters, as 150 those were not specified in [RFC5448] despite requirements set 151 forward in [RFC5247] to do so. Also, while [RFC5247] specified 152 session identifiers for EAP-AKA, it only did so for the full 153 authentication case, not for the case of fast re-authentication. 155 Arguably, the updates are small. For the first update, the 3GPP 156 specification number for the updated calculation has not changed, 157 only the version. But this reference is crucial in correct 158 calculation of the keys resulting from running the EAP-AKA' method, 159 so an update of the RFC with the newest version pointer may be 160 warranted. As always, feedback is welcome on that point as well as 161 on any other topic within this document. 163 Note: It is an open issue whether this update should refer to only 164 the 5G version of the definition, or be explicit that any further 165 update of that specification is something that EAP-AKA' 166 implementations should take into account. Note that one should 167 keep in mind that specification being automatically updated is 168 different from implementations taking notice of new things. 170 The second update is needed to ensure that implementations use the 171 correct identifiers in the context of 5G, as it introduces additional 172 privacy-protected identifiers, and it is no longer clear which 173 identifiers are used in EAP-AKA'. 175 The third update is necessary in order to fix a problem in previous 176 RFCs. 178 It is an explicit non-goal of this draft to include any other 179 technical modifications, addition of new features or other changes. 180 The EAP-AKA' base protocol is stable and needs to stay that way. If 181 there are any extensions or variants, those need to be proposed as 182 standalone extensions or even as different authentication methods. 184 The rest of this specification is structured as follows. Section 3 185 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to 186 prevent bidding down attacks from EAP-AKA'. Section 7 explains the 187 security differences between EAP-AKA and EAP-AKA'. Section 8 188 describes the IANA considerations and Appendix A and Appendix B 189 explains what updates to RFC 5448 AKA' and RFC 4187 EAP-AKA have been 190 made in this specification. Appendix C explains some of the design 191 rationale for creating EAP-AKA' Finally, Appendix D provides test 192 vectors. 194 Editor's Note: The publication of this RFC depends on its 195 normative references [TS-3GPP.24.302] and [TS-3GPP.33.501] from 196 3GPP reaching their final Release 15 status at 3GPP. This is 197 expected to happen shortly. The RFC Editor should check with the 198 3GPP liaisons that this has happened. RFC Editor: Please delete 199 this note upon publication of this specification as an RFC. 201 2. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 3. EAP-AKA' 209 EAP-AKA' is a new EAP method that follows the EAP-AKA specification 210 [RFC4187] in all respects except the following: 212 o It uses the Type code 50, not 23 (which is used by EAP-AKA). 214 o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, 215 to ensure that both the peer and server know the name of the 216 access network. 218 o It supports key derivation function negotiation via the AT_KDF 219 attribute (Section 3.2) to allow for future extensions. 221 o It calculates keys as defined in Section 3.3, not as defined in 222 EAP-AKA. 224 o It employs SHA-256 [FIPS.180-2.2002], not SHA-1 [FIPS.180-1.1995] 225 (Section 3.4). 227 Figure 1 shows an example of the authentication process. Each 228 message AKA'-Challenge and so on represents the corresponding message 229 from EAP-AKA, but with EAP-AKA' Type code. The definition of these 230 messages, along with the definition of attributes AT_RAND, AT_AUTN, 231 AT_MAC, and AT_RES can be found in [RFC4187]. 233 Peer Server 234 | EAP-Request/Identity | 235 |<-------------------------------------------------------| 236 | | 237 | EAP-Response/Identity | 238 | (Includes user's Network Access Identifier, NAI) | 239 |------------------------------------------------------->| 240 | +--------------------------------------------------+ 241 | | Server determines the network name and ensures | 242 | | that the given access network is authorized to | 243 | | use the claimed name. The server then runs the | 244 | | AKA' algorithms generating RAND and AUTN, and | 245 | | derives session keys from CK' and IK'. RAND and | 246 | | AUTN are sent as AT_RAND and AT_AUTN attributes, | 247 | | whereas the network name is transported in the | 248 | | AT_KDF_INPUT attribute. AT_KDF signals the used | 249 | | key derivation function. The session keys are | 250 | | used in creating the AT_MAC attribute. | 251 | +--------------------------------------------------+ 252 | EAP-Request/AKA'-Challenge | 253 | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| 254 |<-------------------------------------------------------| 255 +------------------------------------------------------+ | 256 | The peer determines what the network name should be, | | 257 | based on, e.g., what access technology it is using. | | 258 | The peer also retrieves the network name sent by | | 259 | the network from the AT_KDF_INPUT attribute. The | | 260 | two names are compared for discrepancies, and if | | 261 | necessary, the authentication is aborted. Otherwise,| | 262 | the network name from AT_KDF_INPUT attribute is | | 263 | used in running the AKA' algorithms, verifying AUTN | | 264 | from AT_AUTN and MAC from AT_MAC attributes. The | | 265 | peer then generates RES. The peer also derives | | 266 | session keys from CK'/IK'. The AT_RES and AT_MAC | | 267 | attributes are constructed. | | 268 +------------------------------------------------------+ | 269 | EAP-Response/AKA'-Challenge | 270 | (AT_RES, AT_MAC) | 271 |------------------------------------------------------->| 272 | +-------------------------------------------------+ 273 | | Server checks the RES and MAC values received | 274 | | in AT_RES and AT_MAC, respectively. Success | 275 | | requires both to be found correct. | 276 | +-------------------------------------------------+ 277 | EAP-Success | 278 |<-------------------------------------------------------| 280 Figure 1: EAP-AKA' Authentication Process 282 EAP-AKA' can operate on the same credentials as EAP-AKA and employ 283 the same identities. However, EAP-AKA' employs different leading 284 characters than EAP-AKA for the conventions given in Section 4.1.1 of 285 [RFC4187] for International Mobile Subscriber Identifier (IMSI) based 286 usernames. EAP-AKA' MUST use the leading character "6" (ASCII 36 287 hexadecimal) instead of "0" for IMSI-based permanent usernames. All 288 other usage and processing of the leading characters, usernames, and 289 identities is as defined by EAP-AKA [RFC4187]. For instance, the 290 pseudonym and fast re-authentication usernames need to be constructed 291 so that the server can recognize them. As an example, a pseudonym 292 could begin with a leading "7" character (ASCII 37 hexadecimal) and a 293 fast re-authentication username could begin with "8" (ASCII 38 294 hexadecimal). Note that a server that implements only EAP-AKA may 295 not recognize these leading characters. According to Section 4.1.4 296 of [RFC4187], such a server will re-request the identity via the EAP- 297 Request/AKA-Identity message, making obvious to the peer that EAP-AKA 298 and associated identity are expected. 300 3.1. AT_KDF_INPUT 302 The format of the AT_KDF_INPUT attribute is shown below. 304 0 1 2 3 305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | AT_KDF_INPUT | Length | Actual Network Name Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 . Network Name . 311 . . 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 The fields are as follows: 317 AT_KDF_INPUT 319 This is set to 23. 321 Length 323 The length of the attribute, calculated as defined in [RFC4187], 324 Section 8.1. 326 Actual Network Name Length 328 This is a 2 byte actual length field, needed due to the 329 requirement that the previous field is expressed in multiples of 4 330 bytes per the usual EAP-AKA rules. The Actual Network Name Length 331 field provides the length of the network name in bytes. 333 Network Name 335 This field contains the network name of the access network for 336 which the authentication is being performed. The name does not 337 include any terminating null characters. Because the length of 338 the entire attribute must be a multiple of 4 bytes, the sender 339 pads the name with 1, 2, or 3 bytes of all zero bits when 340 necessary. 342 Only the server sends the AT_KDF_INPUT attribute. Per 343 [TS-3GPP.33.402], the server always verifies the authorization of a 344 given access network to use a particular name before sending it to 345 the peer over EAP-AKA'. The value of the AT_KDF_INPUT attribute from 346 the server MUST be non-empty. If it is empty, the peer behaves as if 347 AUTN had been incorrect and authentication fails. See Section 3 and 348 Figure 3 of [RFC4187] for an overview of how authentication failures 349 are handled. 351 In addition, the peer MAY check the received value against its own 352 understanding of the network name. Upon detecting a discrepancy, the 353 peer either warns the user and continues, or fails the authentication 354 process. More specifically, the peer SHOULD have a configurable 355 policy that it can follow under these circumstances. If the policy 356 indicates that it can continue, the peer SHOULD log a warning message 357 or display it to the user. If the peer chooses to proceed, it MUST 358 use the network name as received in the AT_KDF_INPUT attribute. If 359 the policy indicates that the authentication should fail, the peer 360 behaves as if AUTN had been incorrect and authentication fails. 362 The Network Name field contains a UTF-8 string. This string MUST be 363 constructed as specified in [TS-3GPP.24.302] for "Access Network 364 Identity". The string is structured as fields separated by colons 365 (:). The algorithms and mechanisms to construct the identity string 366 depend on the used access technology. 368 On the network side, the network name construction is a configuration 369 issue in an access network and an authorization check in the 370 authentication server. On the peer, the network name is constructed 371 based on the local observations. For instance, the peer knows which 372 access technology it is using on the link, it can see information in 373 a link-layer beacon, and so on. The construction rules specify how 374 this information maps to an access network name. Typically, the 375 network name consists of the name of the access technology, or the 376 name of the access technology followed by some operator identifier 377 that was advertised in a link-layer beacon. In all cases, 378 [TS-3GPP.24.302] is the normative specification for the construction 379 in both the network and peer side. If the peer policy allows running 380 EAP-AKA' over an access technology for which that specification does 381 not provide network name construction rules, the peer SHOULD rely 382 only on the information from the AT_KDF_INPUT attribute and not 383 perform a comparison. 385 If a comparison of the locally determined network name and the one 386 received over EAP-AKA' is performed on the peer, it MUST be done as 387 follows. First, each name is broken down to the fields separated by 388 colons. If one of the names has more colons and fields than the 389 other one, the additional fields are ignored. The remaining 390 sequences of fields are compared, and they match only if they are 391 equal character by character. This algorithm allows a prefix match 392 where the peer would be able to match "", "FOO", and "FOO:BAR" 393 against the value "FOO:BAR" received from the server. This 394 capability is important in order to allow possible updates to the 395 specifications that dictate how the network names are constructed. 396 For instance, if a peer knows that it is running on access technology 397 "FOO", it can use the string "FOO" even if the server uses an 398 additional, more accurate description, e.g., "FOO:BAR", that contains 399 more information. 401 The allocation procedures in [TS-3GPP.24.302] ensure that conflicts 402 potentially arising from using the same name in different types of 403 networks are avoided. The specification also has detailed rules 404 about how a client can determine these based on information available 405 to the client, such as the type of protocol used to attach to the 406 network, beacons sent out by the network, and so on. Information 407 that the client cannot directly observe (such as the type or version 408 of the home network) is not used by this algorithm. 410 The AT_KDF_INPUT attribute MUST be sent and processed as explained 411 above when AT_KDF attribute has the value 1. Future definitions of 412 new AT_KDF values MUST define how this attribute is sent and 413 processed. 415 3.2. AT_KDF 417 AT_KDF is an attribute that the server uses to reference a specific 418 key derivation function. It offers a negotiation capability that can 419 be useful for future evolution of the key derivation functions. 421 The format of the AT_KDF attribute is shown below. 423 0 1 2 3 424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | AT_KDF | Length | Key Derivation Function | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 The fields are as follows: 431 AT_KDF 432 This is set to 24. 434 Length 436 The length of the attribute, MUST be set to 1. 438 Key Derivation Function 440 An enumerated value representing the key derivation function that 441 the server (or peer) wishes to use. Value 1 represents the 442 default key derivation function for EAP-AKA', i.e., employing CK' 443 and IK' as defined in Section 3.3. 445 Servers MUST send one or more AT_KDF attributes in the EAP-Request/ 446 AKA'-Challenge message. These attributes represent the desired 447 functions ordered by preference, the most preferred function being 448 the first attribute. 450 Upon receiving a set of these attributes, if the peer supports and is 451 willing to use the key derivation function indicated by the first 452 attribute, the function is taken into use without any further 453 negotiation. However, if the peer does not support this function or 454 is unwilling to use it, it does not process the received EAP-Request/ 455 AKA'-Challenge in any way except by responding with the EAP-Response/ 456 AKA'-Challenge message that contains only one attribute, AT_KDF with 457 the value set to the selected alternative. If there is no suitable 458 alternative, the peer behaves as if AUTN had been incorrect and 459 authentication fails (see Figure 3 of [RFC4187]). The peer fails the 460 authentication also if there are any duplicate values within the list 461 of AT_KDF attributes (except where the duplication is due to a 462 request to change the key derivation function; see below for further 463 information). 465 Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the 466 peer, the server checks that the suggested AT_KDF value was one of 467 the alternatives in its offer. The first AT_KDF value in the message 468 from the server is not a valid alternative. If the peer has replied 469 with the first AT_KDF value, the server behaves as if AT_MAC of the 470 response had been incorrect and fails the authentication. For an 471 overview of the failed authentication process in the server side, see 472 Section 3 and Figure 2 of [RFC4187]. Otherwise, the server re-sends 473 the EAP-Response/AKA'-Challenge message, but adds the selected 474 alternative to the beginning of the list of AT_KDF attributes and 475 retains the entire list following it. Note that this means that the 476 selected alternative appears twice in the set of AT_KDF values. 477 Responding to the peer's request to change the key derivation 478 function is the only legal situation where such duplication may 479 occur. 481 When the peer receives the new EAP-Request/AKA'-Challenge message, it 482 MUST check that the requested change, and only the requested change, 483 occurred in the list of AT_KDF attributes. If so, it continues with 484 processing the received EAP-Request/AKA'-Challenge as specified in 485 [RFC4187] and Section 3.1 of this document. If not, it behaves as if 486 AT_MAC had been incorrect and fails the authentication. If the peer 487 receives multiple EAP-Request/AKA'-Challenge messages with differing 488 AT_KDF attributes without having requested negotiation, the peer MUST 489 behave as if AT_MAC had been incorrect and fail the authentication. 491 Note that the peer may also request sequence number resynchronization 492 [RFC4187]. This happens after AT_KDF negotiation has already 493 completed. An AKA'-Synchronization-Failure message is sent as a 494 response to the newly received EAP-Request/AKA'-Challenge (the last 495 message of the AT_KDF negotiation). The AKA'-Synchronization-Failure 496 message MUST contain the AUTS parameter as specified in [RFC4187] and 497 a copy the AT_KDF attributes as they appeared in the last message of 498 the AT_KDF negotiation. If the AT_KDF attributes are found to differ 499 from their earlier values, the peer and server MUST behave as if 500 AT_MAC had been incorrect and fail the authentication. 502 3.3. Key Generation 504 Both the peer and server MUST derive the keys as follows. 506 AT_KDF set to 1 508 In this case, MK is derived and used as follows: 510 MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) 511 K_encr = MK[0..127] 512 K_aut = MK[128..383] 513 K_re = MK[384..639] 514 MSK = MK[640..1151] 515 EMSK = MK[1152..1663] 517 Here [n..m] denotes the substring from bit n to m. PRF' is a new 518 pseudo-random function specified in Section 3.4. The first 1664 519 bits from its output are used for K_encr (encryption key, 128 520 bits), K_aut (authentication key, 256 bits), K_re (re- 521 authentication key, 256 bits), MSK (Master Session Key, 512 bits), 522 and EMSK (Extended Master Session Key, 512 bits). These keys are 523 used by the subsequent EAP-AKA' process. K_encr is used by the 524 AT_ENCR_DATA attribute, and K_aut by the AT_MAC attribute. K_re 525 is used later in this section. MSK and EMSK are outputs from a 526 successful EAP method run [RFC3748]. 528 IK' and CK' are derived as specified in [TS-3GPP.33.402]. The 529 functions that derive IK' and CK' take the following parameters: 530 CK and IK produced by the AKA algorithm, and value of the Network 531 Name field comes from the AT_KDF_INPUT attribute (without length 532 or padding) . 534 The value "EAP-AKA'" is an eight-characters-long ASCII string. It 535 is used as is, without any trailing NUL characters. 537 Identity is the peer identity as specified in Section 7 of 538 [RFC4187]. 540 When the server creates an AKA challenge and corresponding AUTN, 541 CK, CK', IK, and IK' values, it MUST set the Authentication 542 Management Field (AMF) separation bit to 1 in the AKA algorithm 543 [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF 544 separation bit is set to 1. If the bit is not set to 1, the peer 545 behaves as if the AUTN had been incorrect and fails the 546 authentication. 548 On fast re-authentication, the following keys are calculated: 550 MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) 551 MSK = MK[0..511] 552 EMSK = MK[512..1023] 554 MSK and EMSK are the resulting 512-bit keys, taking the first 1024 555 bits from the result of PRF'. Note that K_encr and K_aut are not 556 re-derived on fast re-authentication. K_re is the re- 557 authentication key from the preceding full authentication and 558 stays unchanged over any fast re-authentication(s) that may happen 559 based on it. The value "EAP-AKA' re-auth" is a sixteen- 560 characters-long ASCII string, again represented without any 561 trailing NUL characters. Identity is the fast re-authentication 562 identity, counter is the value from the AT_COUNTER attribute, 563 NONCE_S is the nonce value from the AT_NONCE_S attribute, all as 564 specified in Section 7 of [RFC4187]. To prevent the use of 565 compromised keys in other places, it is forbidden to change the 566 network name when going from the full to the fast re- 567 authentication process. The peer SHOULD NOT attempt fast re- 568 authentication when it knows that the network name in the current 569 access network is different from the one in the initial, full 570 authentication. Upon seeing a re-authentication request with a 571 changed network name, the server SHOULD behave as if the re- 572 authentication identifier had been unrecognized, and fall back to 573 full authentication. The server observes the change in the name 574 by comparing where the fast re-authentication and full 575 authentication EAP transactions were received at the 576 Authentication, Authorization, and Accounting (AAA) protocol 577 level. 579 AT_KDF has any other value 581 Future variations of key derivation functions may be defined, and 582 they will be represented by new values of AT_KDF. If the peer 583 does not recognize the value, it cannot calculate the keys and 584 behaves as explained in Section 3.2. 586 AT_KDF is missing 588 The peer behaves as if the AUTN had been incorrect and MUST fail 589 the authentication. 591 If the peer supports a given key derivation function but is unwilling 592 to perform it for policy reasons, it refuses to calculate the keys 593 and behaves as explained in Section 3.2. 595 3.4. Hash Functions 597 EAP-AKA' uses SHA-256 [FIPS.180-2.2002], not SHA-1 [FIPS.180-1.1995] 598 as in EAP-AKA. This requires a change to the pseudo-random function 599 (PRF) as well as the AT_MAC and AT_CHECKCODE attributes. 601 3.4.1. PRF' 603 The PRF' construction is the same one IKEv2 uses (see Section 2.13 of 604 [RFC4306]). The function takes two arguments. K is a 256-bit value 605 and S is an octet string of arbitrary length. PRF' is defined as 606 follows: 608 PRF'(K,S) = T1 | T2 | T3 | T4 | ... 610 where: 611 T1 = HMAC-SHA-256 (K, S | 0x01) 612 T2 = HMAC-SHA-256 (K, T1 | S | 0x02) 613 T3 = HMAC-SHA-256 (K, T2 | S | 0x03) 614 T4 = HMAC-SHA-256 (K, T3 | S | 0x04) 615 ... 617 PRF' produces as many bits of output as is needed. HMAC-SHA-256 is 618 the application of HMAC [RFC2104] to SHA-256. 620 3.4.2. AT_MAC 621 When used within EAP-AKA', the AT_MAC attribute is changed as 622 follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value. 623 The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256 624 value by truncating the output to the first 16 bytes. Hence, the 625 length of the MAC is 16 bytes. 627 Otherwise, the use of AT_MAC in EAP-AKA' follows Section 10.15 of 628 [RFC4187]. 630 3.4.3. AT_CHECKCODE 632 When used within EAP-AKA', the AT_CHECKCODE attribute is changed as 633 follows. First, a 32-byte value is needed to accommodate a 256-bit 634 hash output: 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | AT_CHECKCODE | Length | Reserved | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 | Checkcode (0 or 32 bytes) | 643 | | 644 | | 645 | | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Second, the checkcode is a hash value, calculated with SHA-256 649 [FIPS.180-2.2002], over the data specified in Section 10.13 of 650 [RFC4187]. 652 4. Bidding Down Prevention for EAP-AKA 654 As discussed in [RFC3748], negotiation of methods within EAP is 655 insecure. That is, a man-in-the-middle attacker may force the 656 endpoints to use a method that is not the strongest that they both 657 support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be 658 negotiated via EAP. 660 In order to prevent such attacks, this RFC specifies a new mechanism 661 for EAP-AKA that allows the endpoints to securely discover the 662 capabilities of each other. This mechanism comes in the form of the 663 AT_BIDDING attribute. This allows both endpoints to communicate 664 their desire and support for EAP-AKA' when exchanging EAP-AKA 665 messages. This attribute is not included in EAP-AKA' messages as 666 defined in this RFC. It is only included in EAP-AKA messages. This 667 is based on the assumption that EAP-AKA' is always preferable (see 668 Section 7). If during the EAP-AKA authentication process it is 669 discovered that both endpoints would have been able to use EAP-AKA', 670 the authentication process SHOULD be aborted, as a bidding down 671 attack may have happened. 673 The format of the AT_BIDDING attribute is shown below. 675 0 1 2 3 676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | AT_BIDDING | Length |D| Reserved | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 The fields are as follows: 683 AT_BIDDING 685 This is set to 136. 687 Length 689 The length of the attribute, MUST be set to 1. 691 D 693 This bit is set to 1 if the sender supports EAP-AKA', is willing 694 to use it, and prefers it over EAP-AKA. Otherwise, it should be 695 set to zero. 697 Reserved 699 This field MUST be set to zero when sent and ignored on receipt. 701 The server sends this attribute in the EAP-Request/AKA-Challenge 702 message. If the peer supports EAP-AKA', it compares the received 703 value to its own capabilities. If it turns out that both the server 704 and peer would have been able to use EAP-AKA' and preferred it over 705 EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the 706 authentication (see Figure 3 of [RFC4187]). A peer not supporting 707 EAP-AKA' will simply ignore this attribute. In all cases, the 708 attribute is protected by the integrity mechanisms of EAP-AKA, so it 709 cannot be removed by a man-in-the-middle attacker. 711 Note that we assume (Section 7) that EAP-AKA' is always stronger than 712 EAP-AKA. As a result, there is no need to prevent bidding "down" 713 attacks in the other direction, i.e., attackers forcing the endpoints 714 to use EAP-AKA'. 716 5. Identifier Usage in 5G 718 In EAP-AKA', the peer identity may be communicated to the server in 719 one of three ways: 721 o As a part of link layer establishment procedures, externally to 722 EAP. 724 o With the EAP-Response/Identity message in the beginning of the EAP 725 exchange, but before the selection of EAP-AKA'. 727 o Transmitted from the peer to the server using EAP-AKA messages 728 instead of EAP-Response/Identity. In this case, the server 729 includes an identity requesting attribute (AT_ANY_ID_REQ, 730 AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA- 731 Identity message; and the peer includes the AT_IDENTITY attribute, 732 which contains the peer's identity, in the EAP-Response/AKA- 733 Identity message. 735 The identity carried above may be a permanent identity or a pseudonym 736 identity or fast re-authentication identity as defined in this RFC. 738 In networks where EAP is the only part handling such pseudonym or 739 fast re-authentication identities, this usage is clear. However, 5G 740 supports the concept of pseudonym or privacy identifiers, and it is 741 important for interoperability that the right type of identifiers are 742 used in the right place. 744 5G defines the SUbscription Permanent Identifier (SUPI) and 745 SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501] 746 [TS-3GPP.33.501]. SUPI is globally unique and allocated to each 747 subscriber. However, it is only used internally in the 5G network, 748 and is privacy sensitive. The SUCI is a privacy preserving 749 identifier containing the concealed SUPI, using public key 750 cryptography to encrypt the SUPI. 752 Given the choice between these two types of identifiers, two areas 753 need further specification in EAP-AKA' to ensure that different 754 implementations understand each other and stay interoperable: 756 o Where identifiers are used within EAP-AKA' -- such as key 757 derivation -- specify what values exactly should be used, to avoid 758 ambiguity. 760 o Where identifiers are carried within EAP-AKA' packets -- such as 761 in the AT_IDENTITY attribute -- specify which identifiers should 762 be filled in. 764 In 5G, the normal mode of operation is that identifiers are only 765 transmitted outside EAP. However, in a system involving terminals 766 from many generations and several connectivity options via 5G and 767 other mechanisms, implementations and the EAP-AKA' specification need 768 to prepare for many different situations, including sometimes having 769 to communicate identities within EAP. 771 The following sections propose one way of clarifying which 772 identifiers are used and how. However, other answers are also 773 possible (e.g., always use the permanent identity). Further 774 discussion on this point is welcome! 776 5.1. Key Derivation 778 In EAP-AKA', the peer identity is used in the Section 3.3 key 779 derivation formula. The identity used in this formula MUST be 780 exactly the one sent in EAP-AKA' AT_IDENTITY attribute, if one was 781 sent, regardless of the kind of identity that it may have been. If 782 no AT_IDENTITY was sent, the identity MUST be the exactly the one 783 sent in the generic EAP Identity exchange, if one was made. Again, 784 the identity MUST be used exactly as sent. 786 Alternative specification: This could also require that the SUPI 787 identity be always used, regardless of what identity was sent. 789 If no identity was communicated inside EAP, then the identity is the 790 one communicated outside EAP in link layer messaging. 792 In this case, the used identity MUST be the identity most recently 793 communicated by the peer to the network, again regardless of what 794 type of identity it may have been. 796 5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 798 The EAP authentication option is only available in 5G when the new 5G 799 core network is also in use. However, in other networks an EAP-AKA' 800 peer may be connecting to other types of networks and existing 801 equipment. 803 When the EAP peer is connecting to a 5G access network and uses the 804 5G core network signalling mechanisms, it MUST assume that the EAP 805 server is in a 5G network. In that situation, the EAP peer SHOULD 806 employ only the privacy preserving SUCI identifier within EAP (either 807 in EAP Identity Response or EAP-AKA' AT_IDENTITY attribute). 809 Similarly, if the peer is explicitly communicating through mechanisms 810 developed for 5G to connect to 5G networks over WLAN, it MUST assume 811 that the EAP server is in a 5G network, and again employ the SUCI 812 within EAP. 814 Otherwise, the peer SHOULD employ IMSI or SUPI as it is configured to 815 use. 817 The use of fast re-authentication and pseudonym identifiers in 5G or 818 other networks is for further discussion. Discussion of this topic 819 is again welcome! 821 6. Exported Parameters 823 The EAP-AKA' Session-Id is the concatenation of the EAP Type Code 824 (50, one octet) with the contents of the RAND field from the AT_RAND 825 attribute, followed by the contents of the AUTN field in the AT_AUTN 826 attribute: 828 Session-Id = 50 || RAND || AUTN 830 When using fast re-authentication, the EAP-AKA' Session-Id is the 831 concatenation of the EAP Type Code (50) with the contents of the 832 NONCE_S field from the AT_NONCE_S attribute, followed by the contents 833 of the MAC field from the AT_MAC attribute from EAP-Request/AKA- 834 Reauthentication: 836 Session-Id = 50 || NONCE_S || MAC 838 The Peer-Id is the contents of the Identity field from the 839 AT_IDENTITY attribute, using only the Actual Identity Length octets 840 from the beginning. Note that the contents are used as they are 841 transmitted, regardless of whether the transmitted identity was a 842 permanent, pseudonym, or fast EAP re-authentication identity. The 843 Server-Id is the null string (zero length). 845 7. Security Considerations 847 A summary of the security properties of EAP-AKA' follows. These 848 properties are very similar to those in EAP-AKA. We assume that 849 SHA-256 is at least as secure as SHA-1. This is called the SHA-256 850 assumption in the remainder of this section. Under this assumption, 851 EAP-AKA' is at least as secure as EAP-AKA. 853 If the AT_KDF attribute has value 1, then the security properties of 854 EAP-AKA' are as follows: 856 Protected ciphersuite negotiation 857 EAP-AKA' has no ciphersuite negotiation mechanisms. It does have 858 a negotiation mechanism for selecting the key derivation 859 functions. This mechanism is secure against bidding down attacks. 860 The negotiation mechanism allows changing the offered key 861 derivation function, but the change is visible in the final EAP- 862 Request/AKA'-Challenge message that the server sends to the peer. 863 This message is authenticated via the AT_MAC attribute, and 864 carries both the chosen alternative and the initially offered 865 list. The peer refuses to accept a change it did not initiate. 866 As a result, both parties are aware that a change is being made 867 and what the original offer was. 869 Mutual authentication 871 Under the SHA-256 assumption, the properties of EAP-AKA' are at 872 least as good as those of EAP-AKA in this respect. Refer to 873 [RFC4187], Section 12 for further details. 875 Integrity protection 877 Under the SHA-256 assumption, the properties of EAP-AKA' are at 878 least as good (most likely better) as those of EAP-AKA in this 879 respect. Refer to [RFC4187], Section 12 for further details. The 880 only difference is that a stronger hash algorithm, SHA-256, is 881 used instead of SHA-1. 883 Replay protection 885 Under the SHA-256 assumption, the properties of EAP-AKA' are at 886 least as good as those of EAP-AKA in this respect. Refer to 887 [RFC4187], Section 12 for further details. 889 Confidentiality 891 The properties of EAP-AKA' are exactly the same as those of EAP- 892 AKA in this respect. Refer to [RFC4187], Section 12 for further 893 details. 895 Key derivation 897 EAP-AKA' supports key derivation with an effective key strength 898 against brute force attacks equal to the minimum of the length of 899 the derived keys and the length of the AKA base key, i.e., 128 900 bits or more. The key hierarchy is specified in Section 3.3. 902 The Transient EAP Keys used to protect EAP-AKA packets (K_encr, 903 K_aut, K_re), the MSK, and the EMSK are cryptographically 904 separate. If we make the assumption that SHA-256 behaves as a 905 pseudo-random function, an attacker is incapable of deriving any 906 non-trivial information about any of these keys based on the other 907 keys. An attacker also cannot calculate the pre-shared secret 908 from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any 909 practically feasible means. 911 EAP-AKA' adds an additional layer of key derivation functions 912 within itself to protect against the use of compromised keys. 913 This is discussed further in Section 7.1. 915 EAP-AKA' uses a pseudo-random function modeled after the one used 916 in IKEv2 [RFC4306] together with SHA-256. 918 Key strength 920 See above. 922 Dictionary attack resistance 924 Under the SHA-256 assumption, the properties of EAP-AKA' are at 925 least as good as those of EAP-AKA in this respect. Refer to 926 [RFC4187], Section 12 for further details. 928 Fast reconnect 930 Under the SHA-256 assumption, the properties of EAP-AKA' are at 931 least as good as those of EAP-AKA in this respect. Refer to 932 [RFC4187], Section 12 for further details. Note that 933 implementations MUST prevent performing a fast reconnect across 934 method types. 936 Cryptographic binding 938 Note that this term refers to a very specific form of binding, 939 something that is performed between two layers of authentication. 940 It is not the same as the binding to a particular network name. 941 The properties of EAP-AKA' are exactly the same as those of EAP- 942 AKA in this respect, i.e., as it is not a tunnel method, this 943 property is not applicable to it. Refer to [RFC4187], Section 12 944 for further details. 946 Session independence 948 The properties of EAP-AKA' are exactly the same as those of EAP- 949 AKA in this respect. Refer to [RFC4187], Section 12 for further 950 details. 952 Fragmentation 953 The properties of EAP-AKA' are exactly the same as those of EAP- 954 AKA in this respect. Refer to [RFC4187], Section 12 for further 955 details. 957 Channel binding 959 EAP-AKA', like EAP-AKA, does not provide channel bindings as 960 they're defined in [RFC3748] and [RFC5247]. New skippable 961 attributes can be used to add channel binding support in the 962 future, if required. 964 However, including the Network Name field in the AKA' algorithms 965 (which are also used for other purposes than EAP-AKA') provides a 966 form of cryptographic separation between different network names, 967 which resembles channel bindings. However, the network name does 968 not typically identify the EAP (pass-through) authenticator. See 969 the following section for more discussion. 971 7.1. Security Properties of Binding Network Names 973 The ability of EAP-AKA' to bind the network name into the used keys 974 provides some additional protection against key leakage to 975 inappropriate parties. The keys used in the protocol are specific to 976 a particular network name. If key leakage occurs due to an accident, 977 access node compromise, or another attack, the leaked keys are only 978 useful when providing access with that name. For instance, a 979 malicious access point cannot claim to be network Y if it has stolen 980 keys from network X. Obviously, if an access point is compromised, 981 the malicious node can still represent the compromised node. As a 982 result, neither EAP-AKA' nor any other extension can prevent such 983 attacks; however, the binding to a particular name limits the 984 attacker's choices, allows better tracking of attacks, makes it 985 possible to identify compromised networks, and applies good 986 cryptographic hygiene. 988 The server receives the EAP transaction from a given access network, 989 and verifies that the claim from the access network corresponds to 990 the name that this access network should be using. It becomes 991 impossible for an access network to claim over AAA that it is another 992 access network. In addition, if the peer checks that the information 993 it has received locally over the network-access link layer matches 994 with the information the server has given it via EAP-AKA', it becomes 995 impossible for the access network to tell one story to the AAA 996 network and another one to the peer. These checks prevent some 997 "lying NAS" (Network Access Server) attacks. For instance, a roaming 998 partner, R, might claim that it is the home network H in an effort to 999 lure peers to connect to itself. Such an attack would be beneficial 1000 for the roaming partner if it can attract more users, and damaging 1001 for the users if their access costs in R are higher than those in 1002 other alternative networks, such as H. 1004 Any attacker who gets hold of the keys CK and IK, produced by the AKA 1005 algorithm, can compute the keys CK' and IK' and, hence, the Master 1006 Key (MK) according to the rules in Section 3.3. The attacker could 1007 then act as a lying NAS. In 3GPP systems in general, the keys CK and 1008 IK have been distributed to, for instance, nodes in a visited access 1009 network where they may be vulnerable. In order to reduce this risk, 1010 the AKA algorithm MUST be computed with the AMF separation bit set to 1011 1, and the peer MUST check that this is indeed the case whenever it 1012 runs EAP-AKA'. Furthermore, [TS-3GPP.33.402] requires that no CK or 1013 IK keys computed in this way ever leave the home subscriber system. 1015 The additional security benefits obtained from the binding depend 1016 obviously on the way names are assigned to different access networks. 1017 This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003]. 1018 Ideally, the names allow separating each different access technology, 1019 each different access network, and each different NAS within a 1020 domain. If this is not possible, the full benefits may not be 1021 achieved. For instance, if the names identify just an access 1022 technology, use of compromised keys in a different technology can be 1023 prevented, but it is not possible to prevent their use by other 1024 domains or devices using the same technology. 1026 8. IANA Considerations 1028 8.1. Type Value 1030 EAP-AKA' has the EAP Type value 50 in the Extensible Authentication 1031 Protocol (EAP) Registry under Method Types. Per Section 6.2 of 1032 [RFC3748], this allocation can be made with Designated Expert and 1033 Specification Required. 1035 8.2. Attribute Type Values 1037 EAP-AKA' shares its attribute space and subtypes with EAP-SIM 1038 [RFC4186] and EAP-AKA [RFC4187]. No new registries are needed. 1040 However, a new Attribute Type value (23) in the non-skippable range 1041 has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and 1042 EAP-SIM Parameters registry under Attribute Types. 1044 Also, a new Attribute Type value (24) in the non-skippable range has 1045 been assigned for AT_KDF (Section 3.2). 1047 Finally, a new Attribute Type value (136) in the skippable range has 1048 been assigned for AT_BIDDING (Section 4). 1050 8.3. Key Derivation Function Namespace 1052 IANA has also created a new namespace for EAP-AKA' AT_KDF Key 1053 Derivation Function Values. This namespace exists under the EAP-AKA 1054 and EAP-SIM Parameters registry. The initial contents of this 1055 namespace are given below; new values can be created through the 1056 Specification Required policy [RFC5226]. 1058 Value Description Reference 1059 --------- ---------------------- --------------- 1060 0 Reserved [RFC 5448] 1061 1 EAP-AKA' with CK'/IK' [RFC 5448] 1062 2-65535 Unassigned 1064 9. Contributors 1066 The test vectors in Appendix C were provided by Yogendra Pal and 1067 Jouni Malinen, based on two independent implementations of this 1068 specification. 1070 Jouni Malinen provided suggested text for Section 6. 1072 10. Acknowledgments 1074 The authors would like to thank Guenther Horn, Joe Salowey, Mats 1075 Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad 1076 Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni 1077 Malinen, Brian Weis, Russ Housley, Alfred Hoenes, Vesa Torvinen, 1078 Anand Palanigounder, and Mohit Sethi for their in-depth reviews and 1079 interesting discussions in this problem space. 1081 11. References 1083 11.1. Normative References 1085 [TS-3GPP.23.501] 1086 3GPP, "3rd Generation Partnership Project; Technical 1087 Specification Group Services and System Aspects; 3G 1088 Security; Security architecture and procedures for 5G 1089 System; (Release 15)", 3GPP Technical Specification 1090 23.501, December 2017. 1092 [TS-3GPP.24.302] 1093 3GPP, "3rd Generation Partnership Project; Technical 1094 Specification Group Core Network and Terminals; Access to 1095 the 3GPP Evolved Packet Core (EPC) via non-3GPP access 1096 networks; Stage 3; (Release 15)", 3GPP Draft Technical 1097 Specification 24.302, September 2017. 1099 [TS-3GPP.33.102] 1100 3GPP, "3rd Generation Partnership Project; Technical 1101 Specification Group Services and System Aspects; 3G 1102 Security; Security architecture (Release 8)", 3GPP 1103 Technical Specification 33.102, December 2008. 1105 [TS-3GPP.33.402] 1106 3GPP, "3GPP System Architecture Evolution (SAE); Security 1107 aspects of non-3GPP accesses; Release 8", 3GPP Technical 1108 Specification 33.402, December 2008. 1110 [TS-3GPP.33.501] 1111 3GPP, "3rd Generation Partnership Project; Technical 1112 Specification Group Services and System Aspects; 3G 1113 Security; Security architecture and procedures for 5G 1114 System; Release 15", 3GPP Technical Specification 33.501, 1115 August 2017. 1117 [FIPS.180-2.2002] 1118 National Institute of Standards and Technology, "Secure 1119 Hash Standard", FIPS PUB 180-2, August 2002, . 1122 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1123 Hashing for Message Authentication", RFC 2104, DOI 1124 10.17487/RFC2104, February 1997, . 1127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1128 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1129 RFC2119, March 1997, . 1132 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1133 Levkowetz, Ed., "Extensible Authentication Protocol 1134 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . 1137 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1138 Protocol Method for 3rd Generation Authentication and Key 1139 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1140 January 2006, . 1142 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1143 IANA Considerations Section in RFCs", RFC 5226, DOI 1144 10.17487/RFC5226, May 2008, . 1147 11.2. Informative References 1149 [TS-3GPP.23.003] 1150 3GPP, "3rd Generation Partnership Project; Technical 1151 Specification Group Core Network and Terminals; Numbering, 1152 addressing and identification (Release 8)", 3GPP Technical 1153 Specification 23.003, December 2008. 1155 [TS-3GPP.35.208] 1156 3GPP, "3rd Generation Partnership Project; Technical 1157 Specification Group Services and System Aspects; 3G 1158 Security; Specification of the MILENAGE Algorithm Set: An 1159 example algorithm set for the 3GPP authentication and key 1160 generation functions f1, f1*, f2, f3, f4, f5 and f5*; 1161 Document 4: Design Conformance Test Data (Release 8)", 1162 3GPP Technical Specification 35.208, December 2008. 1164 [FIPS.180-1.1995] 1165 National Institute of Standards and Technology, "Secure 1166 Hash Standard", FIPS PUB 180-1, April 1995, 1167 . 1169 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 1170 Authentication Protocol Method for Global System for 1171 Mobile Communications (GSM) Subscriber Identity Modules 1172 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 1173 . 1175 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1176 Selection Hints for the Extensible Authentication Protocol 1177 (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, 1178 . 1180 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1181 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 1182 . 1184 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, 1185 "Network Discovery and Selection Problem", RFC 5113, DOI 1186 10.17487/RFC5113, January 2008, . 1189 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1190 Authentication Protocol (EAP) Key Management Framework", 1191 RFC 5247, DOI 10.17487/RFC5247, August 2008, . 1194 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1195 Extensible Authentication Protocol Method for 3rd 1196 Generation Authentication and Key Agreement (EAP-AKA')", 1197 RFC 5448, DOI 10.17487/RFC5448, May 2009, . 1200 Appendix A. Changes from RFC 5448 1202 The changes consist first of all, referring to a newer version of 1203 [TS-3GPP.24.302]. The new version includes an updated definition of 1204 the Network Name field, to include 5G. 1206 Secondly, identifier usage for 5G has been specified in Section 5. 1208 Thirdly, exported parameters for EAP-AKA' have been defined in 1209 Section 6, as required by [RFC5247], including the definition of 1210 those parameters for both full authentication and fast re- 1211 authentication. 1213 Appendix B. Changes from RFC 4187 to RFC 5448 1215 The changes to RFC 4187 relate only to the bidding down prevention 1216 support defined in Section 4. In particular, this document does not 1217 change how the Master Key (MK) is calculated in RFC 4187 (it uses CK 1218 and IK, not CK' and IK'); neither is any processing of the AMF bit 1219 added to RFC 4187. 1221 Appendix C. Importance of Explicit Negotiation 1223 Choosing between the traditional and revised AKA key derivation 1224 functions is easy when their use is unambiguously tied to a 1225 particular radio access network, e.g., Long Term Evolution (LTE) as 1226 defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined 1227 by 3GPP2. There is no possibility for interoperability problems if 1228 this radio access network is always used in conjunction with new 1229 protocols that cannot be mixed with the old ones; clients will always 1230 know whether they are connecting to the old or new system. 1232 However, using the new key derivation functions over EAP introduces 1233 several degrees of separation, making the choice of the correct key 1234 derivation functions much harder. Many different types of networks 1235 employ EAP. Most of these networks have no means to carry any 1236 information about what is expected from the authentication process. 1237 EAP itself is severely limited in carrying any additional 1238 information, as noted in [RFC4284] and [RFC5113]. Even if these 1239 networks or EAP were extended to carry additional information, it 1240 would not affect millions of deployed access networks and clients 1241 attaching to them. 1243 Simply changing the key derivation functions that EAP-AKA [RFC4187] 1244 uses would cause interoperability problems with all of the existing 1245 implementations. Perhaps it would be possible to employ strict 1246 separation into domain names that should be used by the new clients 1247 and networks. Only these new devices would then employ the new key 1248 derivation mechanism. While this can be made to work for specific 1249 cases, it would be an extremely brittle mechanism, ripe to result in 1250 problems whenever client configuration, routing of authentication 1251 requests, or server configuration does not match expectations. It 1252 also does not help to assume that the EAP client and server are 1253 running a particular release of 3GPP network specifications. Network 1254 vendors often provide features from future releases early or do not 1255 provide all features of the current release. And obviously, there 1256 are many EAP and even some EAP-AKA implementations that are not 1257 bundled with the 3GPP network offerings. In general, these 1258 approaches are expected to lead to hard-to-diagnose problems and 1259 increased support calls. 1261 Appendix D. Test Vectors 1263 Test vectors are provided below for four different cases. The test 1264 vectors may be useful for testing implementations. In the first two 1265 cases, we employ the Milenage algorithm and the algorithm 1266 configuration parameters (the subscriber key K and operator algorithm 1267 variant configuration value OP) from test set 19 in [TS-3GPP.35.208]. 1269 The last two cases use artificial values as the output of AKA, and is 1270 useful only for testing the computation of values within EAP-AKA', 1271 not AKA itself. 1273 Case 1 1275 The parameters for the AKA run are as follows: 1277 Identity: "0555444333222111" 1279 Network name: "WLAN" 1281 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1283 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1285 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1287 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1289 RES: 28d7 b0f2 a2ec 3de5 1291 Then the derived keys are generated as follows: 1293 CK': 0093 962d 0dd8 4aa5 684b 045c 9edf fa04 1295 IK': ccfc 230c a74f cc96 c0a5 d611 64f5 a76c 1297 K_encr: 766f a0a6 c317 174b 812d 52fb cd11 a179 1299 K_aut: 0842 ea72 2ff6 835b fa20 3249 9fc3 ec23 1300 c2f0 e388 b4f0 7543 ffc6 77f1 696d 71ea 1302 K_re: cf83 aa8b c7e0 aced 892a cc98 e76a 9b20 1303 95b5 58c7 795c 7094 715c b339 3aa7 d17a 1305 MSK: 67c4 2d9a a56c 1b79 e295 e345 9fc3 d187 1306 d42b e0bf 818d 3070 e362 c5e9 67a4 d544 1307 e8ec fe19 358a b303 9aff 03b7 c930 588c 1308 055b abee 58a0 2650 b067 ec4e 9347 c75a 1310 EMSK: f861 703c d775 590e 16c7 679e a387 4ada 1311 8663 11de 2907 64d7 60cf 76df 647e a01c 1312 313f 6992 4bdd 7650 ca9b ac14 1ea0 75c4 1313 ef9e 8029 c0e2 90cd bad5 638b 63bc 23fb 1315 Case 2 1317 The parameters for the AKA run are as follows: 1319 Identity: "0555444333222111" 1321 Network name: "HRPD" 1323 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1325 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1327 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1329 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1331 RES: 28d7 b0f2 a2ec 3de5 1333 Then the derived keys are generated as follows: 1335 CK': 3820 f027 7fa5 f777 32b1 fb1d 90c1 a0da 1337 IK': db94 a0ab 557e f6c9 ab48 619c a05b 9a9f 1338 K_encr: 05ad 73ac 915f ce89 ac77 e152 0d82 187b 1340 K_aut: 5b4a caef 62c6 ebb8 882b 2f3d 534c 4b35 1341 2773 37a0 0184 f20f f25d 224c 04be 2afd 1343 K_re: 3f90 bf5c 6e5e f325 ff04 eb5e f653 9fa8 1344 cca8 3981 94fb d00b e425 b3f4 0dba 10ac 1346 MSK: 87b3 2157 0117 cd6c 95ab 6c43 6fb5 073f 1347 f15c f855 05d2 bc5b b735 5fc2 1ea8 a757 1348 57e8 f86a 2b13 8002 e057 5291 3bb4 3b82 1349 f868 a961 17e9 1a2d 95f5 2667 7d57 2900 1351 EMSK: c891 d5f2 0f14 8a10 0755 3e2d ea55 5c9c 1352 b672 e967 5f4a 66b4 bafa 0273 79f9 3aee 1353 539a 5979 d0a0 042b 9d2a e28b ed3b 17a3 1354 1dc8 ab75 072b 80bd 0c1d a612 466e 402c 1356 Case 3 1358 The parameters for the AKA run are as follows: 1360 Identity: "0555444333222111" 1362 Network name: "WLAN" 1364 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1366 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1368 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1370 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1372 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1374 Then the derived keys are generated as follows: 1376 CK': cd4c 8e5c 68f5 7dd1 d7d7 dfd0 c538 e577 1378 IK': 3ece 6b70 5dbb f7df c459 a112 80c6 5524 1380 K_encr: 897d 302f a284 7416 488c 28e2 0dcb 7be4 1382 K_aut: c407 00e7 7224 83ae 3dc7 139e b0b8 8bb5 1383 58cb 3081 eccd 057f 9207 d128 6ee7 dd53 1385 K_re: 0a59 1a22 dd8b 5b1c f29e 3d50 8c91 dbbd 1386 b4ae e230 5189 2c42 b6a2 de66 ea50 4473 1388 MSK: 9f7d ca9e 37bb 2202 9ed9 86e7 cd09 d4a7 1389 0d1a c76d 9553 5c5c ac40 a750 4699 bb89 1390 61a2 9ef6 f3e9 0f18 3de5 861a d1be dc81 1391 ce99 1639 1b40 1aa0 06c9 8785 a575 6df7 1393 EMSK: 724d e00b db9e 5681 87be 3fe7 4611 4557 1394 d501 8779 537e e37f 4d3c 6c73 8cb9 7b9d 1395 c651 bc19 bfad c344 ffe2 b52c a78b d831 1396 6b51 dacc 5f2b 1440 cb95 1552 1cc7 ba23 1398 Case 4 1400 The parameters for the AKA run are as follows: 1402 Identity: "0555444333222111" 1404 Network name: "HRPD" 1406 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1408 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1410 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1412 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1414 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1416 Then the derived keys are generated as follows: 1418 CK': 8310 a71c e6f7 5488 9613 da8f 64d5 fb46 1420 IK': 5adf 1436 0ae8 3819 2db2 3f6f cb7f 8c76 1422 K_encr: 745e 7439 ba23 8f50 fcac 4d15 d47c d1d9 1424 K_aut: 3e1d 2aa4 e677 025c fd86 2a4b e183 61a1 1425 3a64 5765 5714 63df 833a 9759 e809 9879 1427 K_re: 99da 835e 2ae8 2462 576f e651 6fad 1f80 1428 2f0f a119 1655 dd0a 273d a96d 04e0 fcd3 1430 MSK: c6d3 a6e0 ceea 951e b20d 74f3 2c30 61d0 1431 680a 04b0 b086 ee87 00ac e3e0 b95f a026 1432 83c2 87be ee44 4322 94ff 98af 26d2 cc78 1433 3bac e75c 4b0a f7fd feb5 511b a8e4 cbd0 1435 EMSK: 7fb5 6813 838a dafa 99d1 40c2 f198 f6da 1436 cebf b6af ee44 4961 1054 02b5 08c7 f363 1437 352c b291 9644 b504 63e6 a693 5415 0147 1438 ae09 cbc5 4b8a 651d 8787 a689 3ed8 536d 1440 Authors' Addresses 1442 Jari Arkko 1443 Ericsson 1444 Jorvas 02420 1445 Finland 1447 Email: jari.arkko@piuha.net 1449 Vesa Lehtovirta 1450 Ericsson 1451 Jorvas 02420 1452 Finland 1454 Email: vesa.lehtovirta@ericsson.com 1456 Vesa Torvinen 1457 Ericsson 1458 Jorvas 02420 1459 Finland 1461 Email: vesa.torvinen@ericsson.com 1463 Pasi Eronen 1464 Nokia Research Center 1465 P.O. Box 407 1466 FIN-00045 Nokia Group 1467 Finland 1469 Email: pasi.eronen@nokia.com