idnits 2.17.1 draft-ietf-emu-rfc5448bis-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 : ---------------------------------------------------------------------------- -- 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 (June 25, 2018) is 2131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5448' is mentioned on line 1062, 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: December 27, 2018 P. Eronen 7 Nokia 8 June 25, 2018 10 Improved Extensible Authentication Protocol Method for 3rd Generation 11 Authentication and Key Agreement (EAP-AKA') 12 draft-ietf-emu-rfc5448bis-00 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 December 27, 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' . . . . . . . . . . . . . . . . . . . . . . . . 14 73 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 14 75 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 15 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 18 79 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 7.1. Security Properties of Binding Network Names . . . . . . 21 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 83 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 23 84 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 23 85 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 23 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 90 11.2. Informative References . . . . . . . . . . . . . . . . . 25 91 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 26 92 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 27 93 Appendix C. Changes from Previous Version of This Draft . . . . 27 94 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 27 95 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 28 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Introduction 100 This specification defines a new Extensible Authentication Protocol 101 (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA 102 method originally defined in [RFC4187]. What is new in EAP-AKA' is 103 that it has a new key derivation function, specified in 104 [TS-3GPP.33.402]. This function binds the keys derived within the 105 method to the name of the access network. This limits the effects of 106 compromised access network nodes and keys. This specification 107 defines the EAP encapsulation for AKA when the new key derivation 108 mechanism is in use. 110 3GPP has defined a number of applications for the revised AKA 111 mechanism, some based on native encapsulation of AKA over 3GPP radio 112 access networks and others based on the use of EAP. 114 For making the new key derivation mechanisms usable in EAP-AKA, 115 additional protocol mechanisms are necessary. Given that RFC 4187 116 calls for the use of CK (the encryption key) and IK (the integrity 117 key) from AKA, existing implementations continue to use these. Any 118 change of the key derivation must be unambiguous to both sides in the 119 protocol. That is, it must not be possible to accidentally connect 120 old equipment to new equipment and get the key derivation wrong or 121 attempt to use wrong keys without getting a proper error message. 122 The change must also be secure against bidding down attacks that 123 attempt to force the participants to use the least secure mechanism. 125 This specification therefore introduces a variant of the EAP-AKA 126 method, called EAP-AKA'. This method can employ the derived keys CK' 127 and IK' from the 3GPP specification and updates the used hash 128 function to SHA-256 [FIPS.180-2.2002]. But it is otherwise 129 equivalent to RFC 4187. Given that a different EAP method type value 130 is used for EAP-AKA and EAP-AKA', a mutually supported method may be 131 negotiated using the standard mechanisms in EAP [RFC3748]. 133 Note: Appendix D explains why it is important to be explicit about 134 the change of semantics for the keys, and why other approaches 135 would lead to severe interoperability problems. 137 This version of the EAP-AKA' specification is an update to RFC 5448. 138 The update consists of three things: 140 o Update the reference on how the Network Name field is constructed 141 in the protocol. The update helps ensure that EAP-AKA' becomes 142 compatible with 5G deployments as well. RFC 5448 referred to the 143 2008 version of that reference ([TS-3GPP.24.302]) and this update 144 points to the 5G version of that reference. 146 o Specify how EAP and EAP-AKA' use identifiers in 5G, as additional 147 identifiers are introduced, and for interoperability, it is 148 important that implementations use the right ones. 150 o Specify session identifiers and other exported parameters, as 151 those were not specified in [RFC5448] despite requirements set 152 forward in [RFC5247] to do so. Also, while [RFC5247] specified 153 session identifiers for EAP-AKA, it only did so for the full 154 authentication case, not for the case of fast re-authentication. 156 Arguably, the updates are small. For the first update, the 3GPP 157 specification number for the updated calculation has not changed, 158 only the version. But this reference is crucial in correct 159 calculation of the keys resulting from running the EAP-AKA' method, 160 so an update of the RFC with the newest version pointer may be 161 warranted. As always, feedback is welcome on that point as well as 162 on any other topic within this document. 164 Note: It is an open issue whether this update should refer to only 165 the 5G version of the definition, or be explicit that any further 166 update of that specification is something that EAP-AKA' 167 implementations should take into account. Note that one should 168 keep in mind that specification being automatically updated is 169 different from implementations taking notice of new things. 171 The second update is needed to ensure that implementations use the 172 correct identifiers in the context of 5G, as it introduces additional 173 privacy-protected identifiers, and it is no longer clear which 174 identifiers are used in EAP-AKA'. 176 The third update is necessary in order to fix a problem in previous 177 RFCs. 179 It is an explicit non-goal of this draft to include any other 180 technical modifications, addition of new features or other changes. 181 The EAP-AKA' base protocol is stable and needs to stay that way. If 182 there are any extensions or variants, those need to be proposed as 183 standalone extensions or even as different authentication methods. 185 The rest of this specification is structured as follows. Section 3 186 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to 187 prevent bidding down attacks from EAP-AKA'. Section 7 explains the 188 security differences between EAP-AKA and EAP-AKA'. Section 8 189 describes the IANA considerations and Appendix A and Appendix B 190 explains what updates to RFC 5448 AKA' and RFC 4187 EAP-AKA have been 191 made in this specification. Appendix D explains some of the design 192 rationale for creating EAP-AKA' Finally, Appendix E provides test 193 vectors. 195 Editor's Note: The publication of this RFC depends on its 196 normative references [TS-3GPP.24.302] and [TS-3GPP.33.501] from 197 3GPP reaching their final Release 15 status at 3GPP. This is 198 expected to happen shortly. The RFC Editor should check with the 199 3GPP liaisons that this has happened. RFC Editor: Please delete 200 this note upon publication of this specification as an RFC. 202 2. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 3. EAP-AKA' 210 EAP-AKA' is a new EAP method that follows the EAP-AKA specification 211 [RFC4187] in all respects except the following: 213 o It uses the Type code 50, not 23 (which is used by EAP-AKA). 215 o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, 216 to ensure that both the peer and server know the name of the 217 access network. 219 o It supports key derivation function negotiation via the AT_KDF 220 attribute (Section 3.2) to allow for future extensions. 222 o It calculates keys as defined in Section 3.3, not as defined in 223 EAP-AKA. 225 o It employs SHA-256 [FIPS.180-2.2002], not SHA-1 [FIPS.180-1.1995] 226 (Section 3.4). 228 Figure 1 shows an example of the authentication process. Each 229 message AKA'-Challenge and so on represents the corresponding message 230 from EAP-AKA, but with EAP-AKA' Type code. The definition of these 231 messages, along with the definition of attributes AT_RAND, AT_AUTN, 232 AT_MAC, and AT_RES can be found in [RFC4187]. 234 Peer Server 235 | EAP-Request/Identity | 236 |<-------------------------------------------------------| 237 | | 238 | EAP-Response/Identity | 239 | (Includes user's Network Access Identifier, NAI) | 240 |------------------------------------------------------->| 241 | +--------------------------------------------------+ 242 | | Server determines the network name and ensures | 243 | | that the given access network is authorized to | 244 | | use the claimed name. The server then runs the | 245 | | AKA' algorithms generating RAND and AUTN, and | 246 | | derives session keys from CK' and IK'. RAND and | 247 | | AUTN are sent as AT_RAND and AT_AUTN attributes, | 248 | | whereas the network name is transported in the | 249 | | AT_KDF_INPUT attribute. AT_KDF signals the used | 250 | | key derivation function. The session keys are | 251 | | used in creating the AT_MAC attribute. | 252 | +--------------------------------------------------+ 253 | EAP-Request/AKA'-Challenge | 254 | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| 255 |<-------------------------------------------------------| 256 +------------------------------------------------------+ | 257 | The peer determines what the network name should be, | | 258 | based on, e.g., what access technology it is using. | | 259 | The peer also retrieves the network name sent by | | 260 | the network from the AT_KDF_INPUT attribute. The | | 261 | two names are compared for discrepancies, and if | | 262 | necessary, the authentication is aborted. Otherwise,| | 263 | the network name from AT_KDF_INPUT attribute is | | 264 | used in running the AKA' algorithms, verifying AUTN | | 265 | from AT_AUTN and MAC from AT_MAC attributes. The | | 266 | peer then generates RES. The peer also derives | | 267 | session keys from CK'/IK'. The AT_RES and AT_MAC | | 268 | attributes are constructed. | | 269 +------------------------------------------------------+ | 270 | EAP-Response/AKA'-Challenge | 271 | (AT_RES, AT_MAC) | 272 |------------------------------------------------------->| 273 | +-------------------------------------------------+ 274 | | Server checks the RES and MAC values received | 275 | | in AT_RES and AT_MAC, respectively. Success | 276 | | requires both to be found correct. | 277 | +-------------------------------------------------+ 278 | EAP-Success | 279 |<-------------------------------------------------------| 281 Figure 1: EAP-AKA' Authentication Process 283 EAP-AKA' can operate on the same credentials as EAP-AKA and employ 284 the same identities. However, EAP-AKA' employs different leading 285 characters than EAP-AKA for the conventions given in Section 4.1.1 of 286 [RFC4187] for International Mobile Subscriber Identifier (IMSI) based 287 usernames. EAP-AKA' MUST use the leading character "6" (ASCII 36 288 hexadecimal) instead of "0" for IMSI-based permanent usernames. All 289 other usage and processing of the leading characters, usernames, and 290 identities is as defined by EAP-AKA [RFC4187]. For instance, the 291 pseudonym and fast re-authentication usernames need to be constructed 292 so that the server can recognize them. As an example, a pseudonym 293 could begin with a leading "7" character (ASCII 37 hexadecimal) and a 294 fast re-authentication username could begin with "8" (ASCII 38 295 hexadecimal). Note that a server that implements only EAP-AKA may 296 not recognize these leading characters. According to Section 4.1.4 297 of [RFC4187], such a server will re-request the identity via the EAP- 298 Request/AKA-Identity message, making obvious to the peer that EAP-AKA 299 and associated identity are expected. 301 3.1. AT_KDF_INPUT 303 The format of the AT_KDF_INPUT attribute is shown below. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | AT_KDF_INPUT | Length | Actual Network Name Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 . Network Name . 312 . . 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 The fields are as follows: 318 AT_KDF_INPUT 320 This is set to 23. 322 Length 324 The length of the attribute, calculated as defined in [RFC4187], 325 Section 8.1. 327 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 433 This is set to 24. 435 Length 437 The length of the attribute, MUST be set to 1. 439 Key Derivation Function 441 An enumerated value representing the key derivation function that 442 the server (or peer) wishes to use. Value 1 represents the 443 default key derivation function for EAP-AKA', i.e., employing CK' 444 and IK' as defined in Section 3.3. 446 Servers MUST send one or more AT_KDF attributes in the EAP-Request/ 447 AKA'-Challenge message. These attributes represent the desired 448 functions ordered by preference, the most preferred function being 449 the first attribute. 451 Upon receiving a set of these attributes, if the peer supports and is 452 willing to use the key derivation function indicated by the first 453 attribute, the function is taken into use without any further 454 negotiation. However, if the peer does not support this function or 455 is unwilling to use it, it does not process the received EAP-Request/ 456 AKA'-Challenge in any way except by responding with the EAP-Response/ 457 AKA'-Challenge message that contains only one attribute, AT_KDF with 458 the value set to the selected alternative. If there is no suitable 459 alternative, the peer behaves as if AUTN had been incorrect and 460 authentication fails (see Figure 3 of [RFC4187]). The peer fails the 461 authentication also if there are any duplicate values within the list 462 of AT_KDF attributes (except where the duplication is due to a 463 request to change the key derivation function; see below for further 464 information). 466 Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the 467 peer, the server checks that the suggested AT_KDF value was one of 468 the alternatives in its offer. The first AT_KDF value in the message 469 from the server is not a valid alternative. If the peer has replied 470 with the first AT_KDF value, the server behaves as if AT_MAC of the 471 response had been incorrect and fails the authentication. For an 472 overview of the failed authentication process in the server side, see 473 Section 3 and Figure 2 of [RFC4187]. Otherwise, the server re-sends 474 the EAP-Response/AKA'-Challenge message, but adds the selected 475 alternative to the beginning of the list of AT_KDF attributes and 476 retains the entire list following it. Note that this means that the 477 selected alternative appears twice in the set of AT_KDF values. 478 Responding to the peer's request to change the key derivation 479 function is the only legal situation where such duplication may 480 occur. 482 When the peer receives the new EAP-Request/AKA'-Challenge message, it 483 MUST check that the requested change, and only the requested change, 484 occurred in the list of AT_KDF attributes. If so, it continues with 485 processing the received EAP-Request/AKA'-Challenge as specified in 486 [RFC4187] and Section 3.1 of this document. If not, it behaves as if 487 AT_MAC had been incorrect and fails the authentication. If the peer 488 receives multiple EAP-Request/AKA'-Challenge messages with differing 489 AT_KDF attributes without having requested negotiation, the peer MUST 490 behave as if AT_MAC had been incorrect and fail the authentication. 492 Note that the peer may also request sequence number resynchronization 493 [RFC4187]. This happens after AT_KDF negotiation has already 494 completed. An AKA'-Synchronization-Failure message is sent as a 495 response to the newly received EAP-Request/AKA'-Challenge (the last 496 message of the AT_KDF negotiation). The AKA'-Synchronization-Failure 497 message MUST contain the AUTS parameter as specified in [RFC4187] and 498 a copy the AT_KDF attributes as they appeared in the last message of 499 the AT_KDF negotiation. If the AT_KDF attributes are found to differ 500 from their earlier values, the peer and server MUST behave as if 501 AT_MAC had been incorrect and fail the authentication. 503 3.3. Key Generation 505 Both the peer and server MUST derive the keys as follows. 507 AT_KDF set to 1 509 In this case, MK is derived and used as follows: 511 MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) 512 K_encr = MK[0..127] 513 K_aut = MK[128..383] 514 K_re = MK[384..639] 515 MSK = MK[640..1151] 516 EMSK = MK[1152..1663] 518 Here [n..m] denotes the substring from bit n to m. PRF' is a new 519 pseudo-random function specified in Section 3.4. The first 1664 520 bits from its output are used for K_encr (encryption key, 128 521 bits), K_aut (authentication key, 256 bits), K_re (re- 522 authentication key, 256 bits), MSK (Master Session Key, 512 bits), 523 and EMSK (Extended Master Session Key, 512 bits). These keys are 524 used by the subsequent EAP-AKA' process. K_encr is used by the 525 AT_ENCR_DATA attribute, and K_aut by the AT_MAC attribute. K_re 526 is used later in this section. MSK and EMSK are outputs from a 527 successful EAP method run [RFC3748]. 529 IK' and CK' are derived as specified in [TS-3GPP.33.402]. The 530 functions that derive IK' and CK' take the following parameters: 531 CK and IK produced by the AKA algorithm, and value of the Network 532 Name field comes from the AT_KDF_INPUT attribute (without length 533 or padding) . 535 The value "EAP-AKA'" is an eight-characters-long ASCII string. It 536 is used as is, without any trailing NUL characters. 538 Identity is the peer identity as specified in Section 7 of 539 [RFC4187]. 541 When the server creates an AKA challenge and corresponding AUTN, 542 CK, CK', IK, and IK' values, it MUST set the Authentication 543 Management Field (AMF) separation bit to 1 in the AKA algorithm 544 [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF 545 separation bit is set to 1. If the bit is not set to 1, the peer 546 behaves as if the AUTN had been incorrect and fails the 547 authentication. 549 On fast re-authentication, the following keys are calculated: 551 MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) 552 MSK = MK[0..511] 553 EMSK = MK[512..1023] 555 MSK and EMSK are the resulting 512-bit keys, taking the first 1024 556 bits from the result of PRF'. Note that K_encr and K_aut are not 557 re-derived on fast re-authentication. K_re is the re- 558 authentication key from the preceding full authentication and 559 stays unchanged over any fast re-authentication(s) that may happen 560 based on it. The value "EAP-AKA' re-auth" is a sixteen- 561 characters-long ASCII string, again represented without any 562 trailing NUL characters. Identity is the fast re-authentication 563 identity, counter is the value from the AT_COUNTER attribute, 564 NONCE_S is the nonce value from the AT_NONCE_S attribute, all as 565 specified in Section 7 of [RFC4187]. To prevent the use of 566 compromised keys in other places, it is forbidden to change the 567 network name when going from the full to the fast re- 568 authentication process. The peer SHOULD NOT attempt fast re- 569 authentication when it knows that the network name in the current 570 access network is different from the one in the initial, full 571 authentication. Upon seeing a re-authentication request with a 572 changed network name, the server SHOULD behave as if the re- 573 authentication identifier had been unrecognized, and fall back to 574 full authentication. The server observes the change in the name 575 by comparing where the fast re-authentication and full 576 authentication EAP transactions were received at the 577 Authentication, Authorization, and Accounting (AAA) protocol 578 level. 580 AT_KDF has any other value 582 Future variations of key derivation functions may be defined, and 583 they will be represented by new values of AT_KDF. If the peer 584 does not recognize the value, it cannot calculate the keys and 585 behaves as explained in Section 3.2. 587 AT_KDF is missing 589 The peer behaves as if the AUTN had been incorrect and MUST fail 590 the authentication. 592 If the peer supports a given key derivation function but is unwilling 593 to perform it for policy reasons, it refuses to calculate the keys 594 and behaves as explained in Section 3.2. 596 3.4. Hash Functions 598 EAP-AKA' uses SHA-256 [FIPS.180-2.2002], not SHA-1 [FIPS.180-1.1995] 599 as in EAP-AKA. This requires a change to the pseudo-random function 600 (PRF) as well as the AT_MAC and AT_CHECKCODE attributes. 602 3.4.1. PRF' 604 The PRF' construction is the same one IKEv2 uses (see Section 2.13 of 605 [RFC4306]). The function takes two arguments. K is a 256-bit value 606 and S is an octet string of arbitrary length. PRF' is defined as 607 follows: 609 PRF'(K,S) = T1 | T2 | T3 | T4 | ... 611 where: 612 T1 = HMAC-SHA-256 (K, S | 0x01) 613 T2 = HMAC-SHA-256 (K, T1 | S | 0x02) 614 T3 = HMAC-SHA-256 (K, T2 | S | 0x03) 615 T4 = HMAC-SHA-256 (K, T3 | S | 0x04) 616 ... 618 PRF' produces as many bits of output as is needed. HMAC-SHA-256 is 619 the application of HMAC [RFC2104] to SHA-256. 621 3.4.2. AT_MAC 623 When used within EAP-AKA', the AT_MAC attribute is changed as 624 follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value. 625 The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256 626 value by truncating the output to the first 16 bytes. Hence, the 627 length of the MAC is 16 bytes. 629 Otherwise, the use of AT_MAC in EAP-AKA' follows Section 10.15 of 630 [RFC4187]. 632 3.4.3. AT_CHECKCODE 634 When used within EAP-AKA', the AT_CHECKCODE attribute is changed as 635 follows. First, a 32-byte value is needed to accommodate a 256-bit 636 hash output: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | AT_CHECKCODE | Length | Reserved | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 | Checkcode (0 or 32 bytes) | 645 | | 646 | | 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Second, the checkcode is a hash value, calculated with SHA-256 650 [FIPS.180-2.2002], over the data specified in Section 10.13 of 651 [RFC4187]. 653 4. Bidding Down Prevention for EAP-AKA 655 As discussed in [RFC3748], negotiation of methods within EAP is 656 insecure. That is, a man-in-the-middle attacker may force the 657 endpoints to use a method that is not the strongest that they both 658 support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be 659 negotiated via EAP. 661 In order to prevent such attacks, this RFC specifies a new mechanism 662 for EAP-AKA that allows the endpoints to securely discover the 663 capabilities of each other. This mechanism comes in the form of the 664 AT_BIDDING attribute. This allows both endpoints to communicate 665 their desire and support for EAP-AKA' when exchanging EAP-AKA 666 messages. This attribute is not included in EAP-AKA' messages as 667 defined in this RFC. It is only included in EAP-AKA messages. This 668 is based on the assumption that EAP-AKA' is always preferable (see 669 Section 7). If during the EAP-AKA authentication process it is 670 discovered that both endpoints would have been able to use EAP-AKA', 671 the authentication process SHOULD be aborted, as a bidding down 672 attack may have happened. 674 The format of the AT_BIDDING attribute is shown below. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | AT_BIDDING | Length |D| Reserved | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 The fields are as follows: 684 AT_BIDDING 686 This is set to 136. 688 Length 690 The length of the attribute, MUST be set to 1. 692 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 858 EAP-AKA' has no ciphersuite negotiation mechanisms. It does have 859 a negotiation mechanism for selecting the key derivation 860 functions. This mechanism is secure against bidding down attacks. 861 The negotiation mechanism allows changing the offered key 862 derivation function, but the change is visible in the final EAP- 863 Request/AKA'-Challenge message that the server sends to the peer. 864 This message is authenticated via the AT_MAC attribute, and 865 carries both the chosen alternative and the initially offered 866 list. The peer refuses to accept a change it did not initiate. 867 As a result, both parties are aware that a change is being made 868 and what the original offer was. 870 Mutual authentication 872 Under the SHA-256 assumption, the properties of EAP-AKA' are at 873 least as good as those of EAP-AKA in this respect. Refer to 874 [RFC4187], Section 12 for further details. 876 Integrity protection 878 Under the SHA-256 assumption, the properties of EAP-AKA' are at 879 least as good (most likely better) as those of EAP-AKA in this 880 respect. Refer to [RFC4187], Section 12 for further details. The 881 only difference is that a stronger hash algorithm, SHA-256, is 882 used instead of SHA-1. 884 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 954 The properties of EAP-AKA' are exactly the same as those of EAP- 955 AKA in this respect. Refer to [RFC4187], Section 12 for further 956 details. 958 Channel binding 960 EAP-AKA', like EAP-AKA, does not provide channel bindings as 961 they're defined in [RFC3748] and [RFC5247]. New skippable 962 attributes can be used to add channel binding support in the 963 future, if required. 965 However, including the Network Name field in the AKA' algorithms 966 (which are also used for other purposes than EAP-AKA') provides a 967 form of cryptographic separation between different network names, 968 which resembles channel bindings. However, the network name does 969 not typically identify the EAP (pass-through) authenticator. See 970 the following section for more discussion. 972 7.1. Security Properties of Binding Network Names 974 The ability of EAP-AKA' to bind the network name into the used keys 975 provides some additional protection against key leakage to 976 inappropriate parties. The keys used in the protocol are specific to 977 a particular network name. If key leakage occurs due to an accident, 978 access node compromise, or another attack, the leaked keys are only 979 useful when providing access with that name. For instance, a 980 malicious access point cannot claim to be network Y if it has stolen 981 keys from network X. Obviously, if an access point is compromised, 982 the malicious node can still represent the compromised node. As a 983 result, neither EAP-AKA' nor any other extension can prevent such 984 attacks; however, the binding to a particular name limits the 985 attacker's choices, allows better tracking of attacks, makes it 986 possible to identify compromised networks, and applies good 987 cryptographic hygiene. 989 The server receives the EAP transaction from a given access network, 990 and verifies that the claim from the access network corresponds to 991 the name that this access network should be using. It becomes 992 impossible for an access network to claim over AAA that it is another 993 access network. In addition, if the peer checks that the information 994 it has received locally over the network-access link layer matches 995 with the information the server has given it via EAP-AKA', it becomes 996 impossible for the access network to tell one story to the AAA 997 network and another one to the peer. These checks prevent some 998 "lying NAS" (Network Access Server) attacks. For instance, a roaming 999 partner, R, might claim that it is the home network H in an effort to 1000 lure peers to connect to itself. Such an attack would be beneficial 1001 for the roaming partner if it can attract more users, and damaging 1002 for the users if their access costs in R are higher than those in 1003 other alternative networks, such as H. 1005 Any attacker who gets hold of the keys CK and IK, produced by the AKA 1006 algorithm, can compute the keys CK' and IK' and, hence, the Master 1007 Key (MK) according to the rules in Section 3.3. The attacker could 1008 then act as a lying NAS. In 3GPP systems in general, the keys CK and 1009 IK have been distributed to, for instance, nodes in a visited access 1010 network where they may be vulnerable. In order to reduce this risk, 1011 the AKA algorithm MUST be computed with the AMF separation bit set to 1012 1, and the peer MUST check that this is indeed the case whenever it 1013 runs EAP-AKA'. Furthermore, [TS-3GPP.33.402] requires that no CK or 1014 IK keys computed in this way ever leave the home subscriber system. 1016 The additional security benefits obtained from the binding depend 1017 obviously on the way names are assigned to different access networks. 1018 This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003]. 1019 Ideally, the names allow separating each different access technology, 1020 each different access network, and each different NAS within a 1021 domain. If this is not possible, the full benefits may not be 1022 achieved. For instance, if the names identify just an access 1023 technology, use of compromised keys in a different technology can be 1024 prevented, but it is not possible to prevent their use by other 1025 domains or devices using the same technology. 1027 8. IANA Considerations 1029 8.1. Type Value 1031 EAP-AKA' has the EAP Type value 50 in the Extensible Authentication 1032 Protocol (EAP) Registry under Method Types. Per Section 6.2 of 1033 [RFC3748], this allocation can be made with Designated Expert and 1034 Specification Required. 1036 8.2. Attribute Type Values 1038 EAP-AKA' shares its attribute space and subtypes with EAP-SIM 1039 [RFC4186] and EAP-AKA [RFC4187]. No new registries are needed. 1041 However, a new Attribute Type value (23) in the non-skippable range 1042 has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and 1043 EAP-SIM Parameters registry under Attribute Types. 1045 Also, a new Attribute Type value (24) in the non-skippable range has 1046 been assigned for AT_KDF (Section 3.2). 1048 Finally, a new Attribute Type value (136) in the skippable range has 1049 been assigned for AT_BIDDING (Section 4). 1051 8.3. Key Derivation Function Namespace 1053 IANA has also created a new namespace for EAP-AKA' AT_KDF Key 1054 Derivation Function Values. This namespace exists under the EAP-AKA 1055 and EAP-SIM Parameters registry. The initial contents of this 1056 namespace are given below; new values can be created through the 1057 Specification Required policy [RFC5226]. 1059 Value Description Reference 1060 --------- ---------------------- --------------- 1061 0 Reserved [RFC 5448] 1062 1 EAP-AKA' with CK'/IK' [RFC 5448] 1063 2-65535 Unassigned 1065 9. Contributors 1067 The test vectors in Appendix C were provided by Yogendra Pal and 1068 Jouni Malinen, based on two independent implementations of this 1069 specification. 1071 Jouni Malinen provided suggested text for Section 6. 1073 10. Acknowledgments 1075 The authors would like to thank Guenther Horn, Joe Salowey, Mats 1076 Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad 1077 Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni 1078 Malinen, Brian Weis, Russ Housley, Alfred Hoenes, Vesa Torvinen, 1079 Anand Palanigounder, and Mohit Sethi for their in-depth reviews and 1080 interesting discussions in this problem space. 1082 11. References 1084 11.1. Normative References 1086 [TS-3GPP.23.501] 1087 3GPP, "3rd Generation Partnership Project; Technical 1088 Specification Group Services and System Aspects; 3G 1089 Security; Security architecture and procedures for 5G 1090 System; (Release 15)", 3GPP Technical Specification 1091 23.501, December 2017. 1093 [TS-3GPP.24.302] 1094 3GPP, "3rd Generation Partnership Project; Technical 1095 Specification Group Core Network and Terminals; Access to 1096 the 3GPP Evolved Packet Core (EPC) via non-3GPP access 1097 networks; Stage 3; (Release 15)", 3GPP Draft Technical 1098 Specification 24.302, September 2017. 1100 [TS-3GPP.33.102] 1101 3GPP, "3rd Generation Partnership Project; Technical 1102 Specification Group Services and System Aspects; 3G 1103 Security; Security architecture (Release 8)", 1104 3GPP Technical Specification 33.102, December 2008. 1106 [TS-3GPP.33.402] 1107 3GPP, "3GPP System Architecture Evolution (SAE); Security 1108 aspects of non-3GPP accesses; Release 8", 3GPP Technical 1109 Specification 33.402, December 2008. 1111 [TS-3GPP.33.501] 1112 3GPP, "3rd Generation Partnership Project; Technical 1113 Specification Group Services and System Aspects; 3G 1114 Security; Security architecture and procedures for 5G 1115 System; Release 15", 3GPP Technical Specification 33.501, 1116 August 2017. 1118 [FIPS.180-2.2002] 1119 National Institute of Standards and Technology, "Secure 1120 Hash Standard", FIPS PUB 180-2, August 2002, 1121 . 1124 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1125 Hashing for Message Authentication", RFC 2104, 1126 DOI 10.17487/RFC2104, February 1997, . 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, 1131 DOI 10.17487/RFC2119, March 1997, . 1134 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1135 Levkowetz, Ed., "Extensible Authentication Protocol 1136 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1137 . 1139 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1140 Protocol Method for 3rd Generation Authentication and Key 1141 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1142 January 2006, . 1144 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1145 IANA Considerations Section in RFCs", RFC 5226, 1146 DOI 10.17487/RFC5226, May 2008, . 1149 11.2. Informative References 1151 [TS-3GPP.23.003] 1152 3GPP, "3rd Generation Partnership Project; Technical 1153 Specification Group Core Network and Terminals; Numbering, 1154 addressing and identification (Release 8)", 3GPP Technical 1155 Specification 23.003, December 2008. 1157 [TS-3GPP.35.208] 1158 3GPP, "3rd Generation Partnership Project; Technical 1159 Specification Group Services and System Aspects; 3G 1160 Security; Specification of the MILENAGE Algorithm Set: An 1161 example algorithm set for the 3GPP authentication and key 1162 generation functions f1, f1*, f2, f3, f4, f5 and f5*; 1163 Document 4: Design Conformance Test Data (Release 8)", 1164 3GPP Technical Specification 35.208, December 2008. 1166 [FIPS.180-1.1995] 1167 National Institute of Standards and Technology, "Secure 1168 Hash Standard", FIPS PUB 180-1, April 1995, 1169 . 1171 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 1172 Authentication Protocol Method for Global System for 1173 Mobile Communications (GSM) Subscriber Identity Modules 1174 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 1175 . 1177 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1178 Selection Hints for the Extensible Authentication Protocol 1179 (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, 1180 . 1182 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1183 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 1184 . 1186 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, 1187 "Network Discovery and Selection Problem", RFC 5113, 1188 DOI 10.17487/RFC5113, January 2008, . 1191 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1192 Authentication Protocol (EAP) Key Management Framework", 1193 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1194 . 1196 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1197 Extensible Authentication Protocol Method for 3rd 1198 Generation Authentication and Key Agreement (EAP-AKA')", 1199 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1200 . 1202 Appendix A. Changes from RFC 5448 1204 The changes consist first of all, referring to a newer version of 1205 [TS-3GPP.24.302]. The new version includes an updated definition of 1206 the Network Name field, to include 5G. 1208 Secondly, identifier usage for 5G has been specified in Section 5. 1210 Thirdly, exported parameters for EAP-AKA' have been defined in 1211 Section 6, as required by [RFC5247], including the definition of 1212 those parameters for both full authentication and fast re- 1213 authentication. 1215 Appendix B. Changes from RFC 4187 to RFC 5448 1217 The changes to RFC 4187 relate only to the bidding down prevention 1218 support defined in Section 4. In particular, this document does not 1219 change how the Master Key (MK) is calculated in RFC 4187 (it uses CK 1220 and IK, not CK' and IK'); neither is any processing of the AMF bit 1221 added to RFC 4187. 1223 Appendix C. Changes from Previous Version of This Draft 1225 RFC Editor: Please delete this section at the time of publication. 1227 The -00 version of the working group draft is merely a republication 1228 of the individaul draft. A version with technical changes is 1229 forthcoming. 1231 Appendix D. Importance of Explicit Negotiation 1233 Choosing between the traditional and revised AKA key derivation 1234 functions is easy when their use is unambiguously tied to a 1235 particular radio access network, e.g., Long Term Evolution (LTE) as 1236 defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined 1237 by 3GPP2. There is no possibility for interoperability problems if 1238 this radio access network is always used in conjunction with new 1239 protocols that cannot be mixed with the old ones; clients will always 1240 know whether they are connecting to the old or new system. 1242 However, using the new key derivation functions over EAP introduces 1243 several degrees of separation, making the choice of the correct key 1244 derivation functions much harder. Many different types of networks 1245 employ EAP. Most of these networks have no means to carry any 1246 information about what is expected from the authentication process. 1247 EAP itself is severely limited in carrying any additional 1248 information, as noted in [RFC4284] and [RFC5113]. Even if these 1249 networks or EAP were extended to carry additional information, it 1250 would not affect millions of deployed access networks and clients 1251 attaching to them. 1253 Simply changing the key derivation functions that EAP-AKA [RFC4187] 1254 uses would cause interoperability problems with all of the existing 1255 implementations. Perhaps it would be possible to employ strict 1256 separation into domain names that should be used by the new clients 1257 and networks. Only these new devices would then employ the new key 1258 derivation mechanism. While this can be made to work for specific 1259 cases, it would be an extremely brittle mechanism, ripe to result in 1260 problems whenever client configuration, routing of authentication 1261 requests, or server configuration does not match expectations. It 1262 also does not help to assume that the EAP client and server are 1263 running a particular release of 3GPP network specifications. Network 1264 vendors often provide features from future releases early or do not 1265 provide all features of the current release. And obviously, there 1266 are many EAP and even some EAP-AKA implementations that are not 1267 bundled with the 3GPP network offerings. In general, these 1268 approaches are expected to lead to hard-to-diagnose problems and 1269 increased support calls. 1271 Appendix E. Test Vectors 1273 Test vectors are provided below for four different cases. The test 1274 vectors may be useful for testing implementations. In the first two 1275 cases, we employ the Milenage algorithm and the algorithm 1276 configuration parameters (the subscriber key K and operator algorithm 1277 variant configuration value OP) from test set 19 in [TS-3GPP.35.208]. 1279 The last two cases use artificial values as the output of AKA, and is 1280 useful only for testing the computation of values within EAP-AKA', 1281 not AKA itself. 1283 Case 1 1285 The parameters for the AKA run are as follows: 1287 Identity: "0555444333222111" 1289 Network name: "WLAN" 1291 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1293 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1295 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1297 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1299 RES: 28d7 b0f2 a2ec 3de5 1301 Then the derived keys are generated as follows: 1303 CK': 0093 962d 0dd8 4aa5 684b 045c 9edf fa04 1305 IK': ccfc 230c a74f cc96 c0a5 d611 64f5 a76c 1307 K_encr: 766f a0a6 c317 174b 812d 52fb cd11 a179 1309 K_aut: 0842 ea72 2ff6 835b fa20 3249 9fc3 ec23 1310 c2f0 e388 b4f0 7543 ffc6 77f1 696d 71ea 1312 K_re: cf83 aa8b c7e0 aced 892a cc98 e76a 9b20 1313 95b5 58c7 795c 7094 715c b339 3aa7 d17a 1315 MSK: 67c4 2d9a a56c 1b79 e295 e345 9fc3 d187 1316 d42b e0bf 818d 3070 e362 c5e9 67a4 d544 1317 e8ec fe19 358a b303 9aff 03b7 c930 588c 1318 055b abee 58a0 2650 b067 ec4e 9347 c75a 1320 EMSK: f861 703c d775 590e 16c7 679e a387 4ada 1321 8663 11de 2907 64d7 60cf 76df 647e a01c 1322 313f 6992 4bdd 7650 ca9b ac14 1ea0 75c4 1323 ef9e 8029 c0e2 90cd bad5 638b 63bc 23fb 1325 Case 2 1327 The parameters for the AKA run are as follows: 1329 Identity: "0555444333222111" 1331 Network name: "HRPD" 1333 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1335 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1337 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1339 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1341 RES: 28d7 b0f2 a2ec 3de5 1343 Then the derived keys are generated as follows: 1345 CK': 3820 f027 7fa5 f777 32b1 fb1d 90c1 a0da 1347 IK': db94 a0ab 557e f6c9 ab48 619c a05b 9a9f 1349 K_encr: 05ad 73ac 915f ce89 ac77 e152 0d82 187b 1351 K_aut: 5b4a caef 62c6 ebb8 882b 2f3d 534c 4b35 1352 2773 37a0 0184 f20f f25d 224c 04be 2afd 1354 K_re: 3f90 bf5c 6e5e f325 ff04 eb5e f653 9fa8 1355 cca8 3981 94fb d00b e425 b3f4 0dba 10ac 1357 MSK: 87b3 2157 0117 cd6c 95ab 6c43 6fb5 073f 1358 f15c f855 05d2 bc5b b735 5fc2 1ea8 a757 1359 57e8 f86a 2b13 8002 e057 5291 3bb4 3b82 1360 f868 a961 17e9 1a2d 95f5 2667 7d57 2900 1362 EMSK: c891 d5f2 0f14 8a10 0755 3e2d ea55 5c9c 1363 b672 e967 5f4a 66b4 bafa 0273 79f9 3aee 1364 539a 5979 d0a0 042b 9d2a e28b ed3b 17a3 1365 1dc8 ab75 072b 80bd 0c1d a612 466e 402c 1367 Case 3 1369 The parameters for the AKA run are as follows: 1371 Identity: "0555444333222111" 1373 Network name: "WLAN" 1375 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1377 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1379 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1381 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1383 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1385 Then the derived keys are generated as follows: 1387 CK': cd4c 8e5c 68f5 7dd1 d7d7 dfd0 c538 e577 1389 IK': 3ece 6b70 5dbb f7df c459 a112 80c6 5524 1391 K_encr: 897d 302f a284 7416 488c 28e2 0dcb 7be4 1393 K_aut: c407 00e7 7224 83ae 3dc7 139e b0b8 8bb5 1394 58cb 3081 eccd 057f 9207 d128 6ee7 dd53 1396 K_re: 0a59 1a22 dd8b 5b1c f29e 3d50 8c91 dbbd 1397 b4ae e230 5189 2c42 b6a2 de66 ea50 4473 1399 MSK: 9f7d ca9e 37bb 2202 9ed9 86e7 cd09 d4a7 1400 0d1a c76d 9553 5c5c ac40 a750 4699 bb89 1401 61a2 9ef6 f3e9 0f18 3de5 861a d1be dc81 1402 ce99 1639 1b40 1aa0 06c9 8785 a575 6df7 1404 EMSK: 724d e00b db9e 5681 87be 3fe7 4611 4557 1405 d501 8779 537e e37f 4d3c 6c73 8cb9 7b9d 1406 c651 bc19 bfad c344 ffe2 b52c a78b d831 1407 6b51 dacc 5f2b 1440 cb95 1552 1cc7 ba23 1409 Case 4 1411 The parameters for the AKA run are as follows: 1413 Identity: "0555444333222111" 1415 Network name: "HRPD" 1417 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1419 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1421 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1423 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1425 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1427 Then the derived keys are generated as follows: 1429 CK': 8310 a71c e6f7 5488 9613 da8f 64d5 fb46 1431 IK': 5adf 1436 0ae8 3819 2db2 3f6f cb7f 8c76 1433 K_encr: 745e 7439 ba23 8f50 fcac 4d15 d47c d1d9 1435 K_aut: 3e1d 2aa4 e677 025c fd86 2a4b e183 61a1 1436 3a64 5765 5714 63df 833a 9759 e809 9879 1438 K_re: 99da 835e 2ae8 2462 576f e651 6fad 1f80 1439 2f0f a119 1655 dd0a 273d a96d 04e0 fcd3 1441 MSK: c6d3 a6e0 ceea 951e b20d 74f3 2c30 61d0 1442 680a 04b0 b086 ee87 00ac e3e0 b95f a026 1443 83c2 87be ee44 4322 94ff 98af 26d2 cc78 1444 3bac e75c 4b0a f7fd feb5 511b a8e4 cbd0 1446 EMSK: 7fb5 6813 838a dafa 99d1 40c2 f198 f6da 1447 cebf b6af ee44 4961 1054 02b5 08c7 f363 1448 352c b291 9644 b504 63e6 a693 5415 0147 1449 ae09 cbc5 4b8a 651d 8787 a689 3ed8 536d 1451 Authors' Addresses 1452 Jari Arkko 1453 Ericsson 1454 Jorvas 02420 1455 Finland 1457 Email: jari.arkko@piuha.net 1459 Vesa Lehtovirta 1460 Ericsson 1461 Jorvas 02420 1462 Finland 1464 Email: vesa.lehtovirta@ericsson.com 1466 Vesa Torvinen 1467 Ericsson 1468 Jorvas 02420 1469 Finland 1471 Email: vesa.torvinen@ericsson.com 1473 Pasi Eronen 1474 Nokia Research Center 1475 P.O. Box 407 1476 FIN-00045 Nokia Group 1477 Finland 1479 Email: pasi.eronen@nokia.com