idnits 2.17.1 draft-ietf-emu-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4187, updated by this document, for RFC5378 checks: 2001-05-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 5448' is mentioned on line 1078, but not defined -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 Updates: 4187 (if approved) Ericsson 6 Intended status: Informational P. Eronen 7 Expires: January 3, 2019 Nokia 8 July 2, 2018 10 Improved Extensible Authentication Protocol Method for 3rd Generation 11 Authentication and Key Agreement (EAP-AKA') 12 draft-ietf-emu-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 January 3, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 12 71 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 19 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 7.1. Security Properties of Binding Network Names . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . 24 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 90 11.2. Informative References . . . . . . . . . . . . . . . . . 26 91 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 27 92 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 27 93 Appendix C. Changes from Previous Version of This Draft . . . . 28 94 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 28 95 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 29 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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-4]. But it is otherwise equivalent to 129 RFC 4187. Given that a different EAP method type value is used for 130 EAP-AKA and EAP-AKA', a mutually supported method may be negotiated 131 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 obsoletes RFC 5448. The 138 changes consist 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 Release 8 version of [TS-3GPP.24.302] and this update points to 144 the first 5G version, Release 15. 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] 197 reaching a stable status for Release 15, as indicated by 3GPP. 198 This is expected to happen shortly. The RFC Editor should check 199 with the 3GPP liaisons that this has happened. RFC Editor: Please 200 delete 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", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 3. EAP-AKA' 212 EAP-AKA' is a new EAP method that follows the EAP-AKA specification 213 [RFC4187] in all respects except the following: 215 o It uses the Type code 50, not 23 (which is used by EAP-AKA). 217 o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, 218 to ensure that both the peer and server know the name of the 219 access network. 221 o It supports key derivation function negotiation via the AT_KDF 222 attribute (Section 3.2) to allow for future extensions. 224 o It calculates keys as defined in Section 3.3, not as defined in 225 EAP-AKA. 227 o It employs SHA-256, not SHA-1 [FIPS.180-4] (Section 3.4). 229 Figure 1 shows an example of the authentication process. Each 230 message AKA'-Challenge and so on represents the corresponding message 231 from EAP-AKA, but with EAP-AKA' Type code. The definition of these 232 messages, along with the definition of attributes AT_RAND, AT_AUTN, 233 AT_MAC, and AT_RES can be found in [RFC4187]. 235 Peer Server 236 | EAP-Request/Identity | 237 |<-------------------------------------------------------| 238 | | 239 | EAP-Response/Identity | 240 | (Includes user's Network Access Identifier, NAI) | 241 |------------------------------------------------------->| 242 | +--------------------------------------------------+ 243 | | Server determines the network name and ensures | 244 | | that the given access network is authorized to | 245 | | use the claimed name. The server then runs the | 246 | | AKA' algorithms generating RAND and AUTN, and | 247 | | derives session keys from CK' and IK'. RAND and | 248 | | AUTN are sent as AT_RAND and AT_AUTN attributes, | 249 | | whereas the network name is transported in the | 250 | | AT_KDF_INPUT attribute. AT_KDF signals the used | 251 | | key derivation function. The session keys are | 252 | | used in creating the AT_MAC attribute. | 253 | +--------------------------------------------------+ 254 | EAP-Request/AKA'-Challenge | 255 | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| 256 |<-------------------------------------------------------| 257 +------------------------------------------------------+ | 258 | The peer determines what the network name should be, | | 259 | based on, e.g., what access technology it is using. | | 260 | The peer also retrieves the network name sent by | | 261 | the network from the AT_KDF_INPUT attribute. The | | 262 | two names are compared for discrepancies, and if | | 263 | necessary, the authentication is aborted. Otherwise,| | 264 | the network name from AT_KDF_INPUT attribute is | | 265 | used in running the AKA' algorithms, verifying AUTN | | 266 | from AT_AUTN and MAC from AT_MAC attributes. The | | 267 | peer then generates RES. The peer also derives | | 268 | session keys from CK'/IK'. The AT_RES and AT_MAC | | 269 | attributes are constructed. | | 270 +------------------------------------------------------+ | 271 | EAP-Response/AKA'-Challenge | 272 | (AT_RES, AT_MAC) | 273 |------------------------------------------------------->| 274 | +-------------------------------------------------+ 275 | | Server checks the RES and MAC values received | 276 | | in AT_RES and AT_MAC, respectively. Success | 277 | | requires both to be found correct. | 278 | +-------------------------------------------------+ 279 | EAP-Success | 280 |<-------------------------------------------------------| 282 Figure 1: EAP-AKA' Authentication Process 284 EAP-AKA' can operate on the same credentials as EAP-AKA and employ 285 the same identities. However, EAP-AKA' employs different leading 286 characters than EAP-AKA for the conventions given in Section 4.1.1 of 287 [RFC4187] for International Mobile Subscriber Identifier (IMSI) based 288 usernames. EAP-AKA' MUST use the leading character "6" (ASCII 36 289 hexadecimal) instead of "0" for IMSI-based permanent usernames. All 290 other usage and processing of the leading characters, usernames, and 291 identities is as defined by EAP-AKA [RFC4187]. For instance, the 292 pseudonym and fast re-authentication usernames need to be constructed 293 so that the server can recognize them. As an example, a pseudonym 294 could begin with a leading "7" character (ASCII 37 hexadecimal) and a 295 fast re-authentication username could begin with "8" (ASCII 38 296 hexadecimal). Note that a server that implements only EAP-AKA may 297 not recognize these leading characters. According to Section 4.1.4 298 of [RFC4187], such a server will re-request the identity via the EAP- 299 Request/AKA-Identity message, making obvious to the peer that EAP-AKA 300 and associated identity are expected. 302 3.1. AT_KDF_INPUT 304 The format of the AT_KDF_INPUT attribute is shown below. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | AT_KDF_INPUT | Length | Actual Network Name Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 . Network Name . 313 . . 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 The fields are as follows: 319 AT_KDF_INPUT 321 This is set to 23. 323 Length 325 The length of the attribute, calculated as defined in [RFC4187], 326 Section 8.1. 328 Actual Network Name Length 329 This is a 2 byte actual length field, needed due to the 330 requirement that the previous field is expressed in multiples of 4 331 bytes per the usual EAP-AKA rules. The Actual Network Name Length 332 field provides the length of the network name in bytes. 334 Network Name 336 This field contains the network name of the access network for 337 which the authentication is being performed. The name does not 338 include any terminating null characters. Because the length of 339 the entire attribute must be a multiple of 4 bytes, the sender 340 pads the name with 1, 2, or 3 bytes of all zero bits when 341 necessary. 343 Only the server sends the AT_KDF_INPUT attribute. The value is sent 344 as specified in [TS-3GPP.24.302] for non-3GPP access networks, and as 345 specified in [TS-3GPP.33.501] for 5G access networks. Per 346 [TS-3GPP.33.402], the server always verifies the authorization of a 347 given access network to use a particular name before sending it to 348 the peer over EAP-AKA'. The value of the AT_KDF_INPUT attribute from 349 the server MUST be non-empty. If it is empty, the peer behaves as if 350 AUTN had been incorrect and authentication fails. See Section 3 and 351 Figure 3 of [RFC4187] for an overview of how authentication failures 352 are handled. 354 Note: Currently, [TS-3GPP.24.302] or [TS-3GPP.33.501] specify 355 separate values. The former specifies what is called "Access 356 Network ID" and the latter specifies what is called "Serving 357 Network Name". However, from an EAP-AKA' perspective both occupy 358 the same field, and need to be distinghuishable from each other. 359 Currently specified values are distinguishable, but it would be 360 useful that this be specified explicitly in the 3GPP 361 specifications. 363 In addition, the peer MAY check the received value against its own 364 understanding of the network name. Upon detecting a discrepancy, the 365 peer either warns the user and continues, or fails the authentication 366 process. More specifically, the peer SHOULD have a configurable 367 policy that it can follow under these circumstances. If the policy 368 indicates that it can continue, the peer SHOULD log a warning message 369 or display it to the user. If the peer chooses to proceed, it MUST 370 use the network name as received in the AT_KDF_INPUT attribute. If 371 the policy indicates that the authentication should fail, the peer 372 behaves as if AUTN had been incorrect and authentication fails. 374 The Network Name field contains a UTF-8 string. This string MUST be 375 constructed as specified in [TS-3GPP.24.302] for "Access Network 376 Identity". The string is structured as fields separated by colons 377 (:). The algorithms and mechanisms to construct the identity string 378 depend on the used access technology. 380 On the network side, the network name construction is a configuration 381 issue in an access network and an authorization check in the 382 authentication server. On the peer, the network name is constructed 383 based on the local observations. For instance, the peer knows which 384 access technology it is using on the link, it can see information in 385 a link-layer beacon, and so on. The construction rules specify how 386 this information maps to an access network name. Typically, the 387 network name consists of the name of the access technology, or the 388 name of the access technology followed by some operator identifier 389 that was advertised in a link-layer beacon. In all cases, 390 [TS-3GPP.24.302] is the normative specification for the construction 391 in both the network and peer side. If the peer policy allows running 392 EAP-AKA' over an access technology for which that specification does 393 not provide network name construction rules, the peer SHOULD rely 394 only on the information from the AT_KDF_INPUT attribute and not 395 perform a comparison. 397 If a comparison of the locally determined network name and the one 398 received over EAP-AKA' is performed on the peer, it MUST be done as 399 follows. First, each name is broken down to the fields separated by 400 colons. If one of the names has more colons and fields than the 401 other one, the additional fields are ignored. The remaining 402 sequences of fields are compared, and they match only if they are 403 equal character by character. This algorithm allows a prefix match 404 where the peer would be able to match "", "FOO", and "FOO:BAR" 405 against the value "FOO:BAR" received from the server. This 406 capability is important in order to allow possible updates to the 407 specifications that dictate how the network names are constructed. 408 For instance, if a peer knows that it is running on access technology 409 "FOO", it can use the string "FOO" even if the server uses an 410 additional, more accurate description, e.g., "FOO:BAR", that contains 411 more information. 413 The allocation procedures in [TS-3GPP.24.302] ensure that conflicts 414 potentially arising from using the same name in different types of 415 networks are avoided. The specification also has detailed rules 416 about how a client can determine these based on information available 417 to the client, such as the type of protocol used to attach to the 418 network, beacons sent out by the network, and so on. Information 419 that the client cannot directly observe (such as the type or version 420 of the home network) is not used by this algorithm. 422 The AT_KDF_INPUT attribute MUST be sent and processed as explained 423 above when AT_KDF attribute has the value 1. Future definitions of 424 new AT_KDF values MUST define how this attribute is sent and 425 processed. 427 3.2. AT_KDF 429 AT_KDF is an attribute that the server uses to reference a specific 430 key derivation function. It offers a negotiation capability that can 431 be useful for future evolution of the key derivation functions. 433 The format of the AT_KDF attribute is shown below. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | AT_KDF | Length | Key Derivation Function | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 The fields are as follows: 443 AT_KDF 445 This is set to 24. 447 Length 449 The length of the attribute, MUST be set to 1. 451 Key Derivation Function 453 An enumerated value representing the key derivation function that 454 the server (or peer) wishes to use. Value 1 represents the 455 default key derivation function for EAP-AKA', i.e., employing CK' 456 and IK' as defined in Section 3.3. 458 Servers MUST send one or more AT_KDF attributes in the EAP-Request/ 459 AKA'-Challenge message. These attributes represent the desired 460 functions ordered by preference, the most preferred function being 461 the first attribute. 463 Upon receiving a set of these attributes, if the peer supports and is 464 willing to use the key derivation function indicated by the first 465 attribute, the function is taken into use without any further 466 negotiation. However, if the peer does not support this function or 467 is unwilling to use it, it does not process the received EAP-Request/ 468 AKA'-Challenge in any way except by responding with the EAP-Response/ 469 AKA'-Challenge message that contains only one attribute, AT_KDF with 470 the value set to the selected alternative. If there is no suitable 471 alternative, the peer behaves as if AUTN had been incorrect and 472 authentication fails (see Figure 3 of [RFC4187]). The peer fails the 473 authentication also if there are any duplicate values within the list 474 of AT_KDF attributes (except where the duplication is due to a 475 request to change the key derivation function; see below for further 476 information). 478 Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the 479 peer, the server checks that the suggested AT_KDF value was one of 480 the alternatives in its offer. The first AT_KDF value in the message 481 from the server is not a valid alternative. If the peer has replied 482 with the first AT_KDF value, the server behaves as if AT_MAC of the 483 response had been incorrect and fails the authentication. For an 484 overview of the failed authentication process in the server side, see 485 Section 3 and Figure 2 of [RFC4187]. Otherwise, the server re-sends 486 the EAP-Response/AKA'-Challenge message, but adds the selected 487 alternative to the beginning of the list of AT_KDF attributes and 488 retains the entire list following it. Note that this means that the 489 selected alternative appears twice in the set of AT_KDF values. 490 Responding to the peer's request to change the key derivation 491 function is the only legal situation where such duplication may 492 occur. 494 When the peer receives the new EAP-Request/AKA'-Challenge message, it 495 MUST check that the requested change, and only the requested change, 496 occurred in the list of AT_KDF attributes. If so, it continues with 497 processing the received EAP-Request/AKA'-Challenge as specified in 498 [RFC4187] and Section 3.1 of this document. If not, it behaves as if 499 AT_MAC had been incorrect and fails the authentication. If the peer 500 receives multiple EAP-Request/AKA'-Challenge messages with differing 501 AT_KDF attributes without having requested negotiation, the peer MUST 502 behave as if AT_MAC had been incorrect and fail the authentication. 504 Note that the peer may also request sequence number resynchronization 505 [RFC4187]. This happens after AT_KDF negotiation has already 506 completed. An AKA'-Synchronization-Failure message is sent as a 507 response to the newly received EAP-Request/AKA'-Challenge (the last 508 message of the AT_KDF negotiation). The AKA'-Synchronization-Failure 509 message MUST contain the AUTS parameter as specified in [RFC4187] and 510 a copy the AT_KDF attributes as they appeared in the last message of 511 the AT_KDF negotiation. If the AT_KDF attributes are found to differ 512 from their earlier values, the peer and server MUST behave as if 513 AT_MAC had been incorrect and fail the authentication. 515 3.3. Key Generation 517 Both the peer and server MUST derive the keys as follows. 519 AT_KDF set to 1 521 In this case, MK is derived and used as follows: 523 MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) 524 K_encr = MK[0..127] 525 K_aut = MK[128..383] 526 K_re = MK[384..639] 527 MSK = MK[640..1151] 528 EMSK = MK[1152..1663] 530 Here [n..m] denotes the substring from bit n to m. PRF' is a new 531 pseudo-random function specified in Section 3.4. The first 1664 532 bits from its output are used for K_encr (encryption key, 128 533 bits), K_aut (authentication key, 256 bits), K_re (re- 534 authentication key, 256 bits), MSK (Master Session Key, 512 bits), 535 and EMSK (Extended Master Session Key, 512 bits). These keys are 536 used by the subsequent EAP-AKA' process. K_encr is used by the 537 AT_ENCR_DATA attribute, and K_aut by the AT_MAC attribute. K_re 538 is used later in this section. MSK and EMSK are outputs from a 539 successful EAP method run [RFC3748]. 541 IK' and CK' are derived as specified in [TS-3GPP.33.402]. The 542 functions that derive IK' and CK' take the following parameters: 543 CK and IK produced by the AKA algorithm, and value of the Network 544 Name field comes from the AT_KDF_INPUT attribute (without length 545 or padding) . 547 The value "EAP-AKA'" is an eight-characters-long ASCII string. It 548 is used as is, without any trailing NUL characters. 550 Identity is the peer identity as specified in Section 7 of 551 [RFC4187]. 553 When the server creates an AKA challenge and corresponding AUTN, 554 CK, CK', IK, and IK' values, it MUST set the Authentication 555 Management Field (AMF) separation bit to 1 in the AKA algorithm 556 [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF 557 separation bit is set to 1. If the bit is not set to 1, the peer 558 behaves as if the AUTN had been incorrect and fails the 559 authentication. 561 On fast re-authentication, the following keys are calculated: 563 MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) 564 MSK = MK[0..511] 565 EMSK = MK[512..1023] 567 MSK and EMSK are the resulting 512-bit keys, taking the first 1024 568 bits from the result of PRF'. Note that K_encr and K_aut are not 569 re-derived on fast re-authentication. K_re is the re- 570 authentication key from the preceding full authentication and 571 stays unchanged over any fast re-authentication(s) that may happen 572 based on it. The value "EAP-AKA' re-auth" is a sixteen- 573 characters-long ASCII string, again represented without any 574 trailing NUL characters. Identity is the fast re-authentication 575 identity, counter is the value from the AT_COUNTER attribute, 576 NONCE_S is the nonce value from the AT_NONCE_S attribute, all as 577 specified in Section 7 of [RFC4187]. To prevent the use of 578 compromised keys in other places, it is forbidden to change the 579 network name when going from the full to the fast re- 580 authentication process. The peer SHOULD NOT attempt fast re- 581 authentication when it knows that the network name in the current 582 access network is different from the one in the initial, full 583 authentication. Upon seeing a re-authentication request with a 584 changed network name, the server SHOULD behave as if the re- 585 authentication identifier had been unrecognized, and fall back to 586 full authentication. The server observes the change in the name 587 by comparing where the fast re-authentication and full 588 authentication EAP transactions were received at the 589 Authentication, Authorization, and Accounting (AAA) protocol 590 level. 592 AT_KDF has any other value 594 Future variations of key derivation functions may be defined, and 595 they will be represented by new values of AT_KDF. If the peer 596 does not recognize the value, it cannot calculate the keys and 597 behaves as explained in Section 3.2. 599 AT_KDF is missing 601 The peer behaves as if the AUTN had been incorrect and MUST fail 602 the authentication. 604 If the peer supports a given key derivation function but is unwilling 605 to perform it for policy reasons, it refuses to calculate the keys 606 and behaves as explained in Section 3.2. 608 3.4. Hash Functions 610 EAP-AKA' uses SHA-256, not SHA-1 (see [FIPS.180-4]) as in EAP-AKA. 611 This requires a change to the pseudo-random function (PRF) as well as 612 the AT_MAC and AT_CHECKCODE attributes. 614 3.4.1. PRF' 616 The PRF' construction is the same one IKEv2 uses (see Section 2.13 of 617 [RFC4306]). The function takes two arguments. K is a 256-bit value 618 and S is an octet string of arbitrary length. PRF' is defined as 619 follows: 621 PRF'(K,S) = T1 | T2 | T3 | T4 | ... 623 where: 624 T1 = HMAC-SHA-256 (K, S | 0x01) 625 T2 = HMAC-SHA-256 (K, T1 | S | 0x02) 626 T3 = HMAC-SHA-256 (K, T2 | S | 0x03) 627 T4 = HMAC-SHA-256 (K, T3 | S | 0x04) 628 ... 630 PRF' produces as many bits of output as is needed. HMAC-SHA-256 is 631 the application of HMAC [RFC2104] to SHA-256. 633 3.4.2. AT_MAC 635 When used within EAP-AKA', the AT_MAC attribute is changed as 636 follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value. 637 The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256 638 value by truncating the output to the first 16 bytes. Hence, the 639 length of the MAC is 16 bytes. 641 Otherwise, the use of AT_MAC in EAP-AKA' follows Section 10.15 of 642 [RFC4187]. 644 3.4.3. AT_CHECKCODE 646 When used within EAP-AKA', the AT_CHECKCODE attribute is changed as 647 follows. First, a 32-byte value is needed to accommodate a 256-bit 648 hash output: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | AT_CHECKCODE | Length | Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | | 656 | Checkcode (0 or 32 bytes) | 657 | | 658 | | 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Second, the checkcode is a hash value, calculated with SHA-256 663 [FIPS.180-4], over the data specified in Section 10.13 of [RFC4187]. 665 4. Bidding Down Prevention for EAP-AKA 667 As discussed in [RFC3748], negotiation of methods within EAP is 668 insecure. That is, a man-in-the-middle attacker may force the 669 endpoints to use a method that is not the strongest that they both 670 support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be 671 negotiated via EAP. 673 In order to prevent such attacks, this RFC specifies a new mechanism 674 for EAP-AKA that allows the endpoints to securely discover the 675 capabilities of each other. This mechanism comes in the form of the 676 AT_BIDDING attribute. This allows both endpoints to communicate 677 their desire and support for EAP-AKA' when exchanging EAP-AKA 678 messages. This attribute is not included in EAP-AKA' messages as 679 defined in this RFC. It is only included in EAP-AKA messages. This 680 is based on the assumption that EAP-AKA' is always preferable (see 681 Section 7). If during the EAP-AKA authentication process it is 682 discovered that both endpoints would have been able to use EAP-AKA', 683 the authentication process SHOULD be aborted, as a bidding down 684 attack may have happened. 686 The format of the AT_BIDDING attribute is shown below. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | AT_BIDDING | Length |D| Reserved | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 The fields are as follows: 696 AT_BIDDING 697 This is set to 136. 699 Length 701 The length of the attribute, MUST be set to 1. 703 D 705 This bit is set to 1 if the sender supports EAP-AKA', is willing 706 to use it, and prefers it over EAP-AKA. Otherwise, it should be 707 set to zero. 709 Reserved 711 This field MUST be set to zero when sent and ignored on receipt. 713 The server sends this attribute in the EAP-Request/AKA-Challenge 714 message. If the peer supports EAP-AKA', it compares the received 715 value to its own capabilities. If it turns out that both the server 716 and peer would have been able to use EAP-AKA' and preferred it over 717 EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the 718 authentication (see Figure 3 of [RFC4187]). A peer not supporting 719 EAP-AKA' will simply ignore this attribute. In all cases, the 720 attribute is protected by the integrity mechanisms of EAP-AKA, so it 721 cannot be removed by a man-in-the-middle attacker. 723 Note that we assume (Section 7) that EAP-AKA' is always stronger than 724 EAP-AKA. As a result, there is no need to prevent bidding "down" 725 attacks in the other direction, i.e., attackers forcing the endpoints 726 to use EAP-AKA'. 728 5. Identifier Usage in 5G 730 In EAP-AKA', the peer identity may be communicated to the server in 731 one of three ways: 733 o As a part of link layer establishment procedures, externally to 734 EAP. 736 o With the EAP-Response/Identity message in the beginning of the EAP 737 exchange, but before the selection of EAP-AKA'. 739 o Transmitted from the peer to the server using EAP-AKA messages 740 instead of EAP-Response/Identity. In this case, the server 741 includes an identity requesting attribute (AT_ANY_ID_REQ, 742 AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA- 743 Identity message; and the peer includes the AT_IDENTITY attribute, 744 which contains the peer's identity, in the EAP-Response/AKA- 745 Identity message. 747 The identity carried above may be a permanent identity or a pseudonym 748 identity or fast re-authentication identity as defined in this RFC. 750 In networks where EAP is the only part handling such pseudonym or 751 fast re-authentication identities, this usage is clear. However, 5G 752 supports the concept of pseudonym or privacy identifiers, and it is 753 important for interoperability that the right type of identifiers are 754 used in the right place. 756 5G defines the SUbscription Permanent Identifier (SUPI) and 757 SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501] 758 [TS-3GPP.33.501]. SUPI is globally unique and allocated to each 759 subscriber. However, it is only used internally in the 5G network, 760 and is privacy sensitive. The SUCI is a privacy preserving 761 identifier containing the concealed SUPI, using public key 762 cryptography to encrypt the SUPI. 764 Given the choice between these two types of identifiers, two areas 765 need further specification in EAP-AKA' to ensure that different 766 implementations understand each other and stay interoperable: 768 o Where identifiers are used within EAP-AKA' -- such as key 769 derivation -- specify what values exactly should be used, to avoid 770 ambiguity. 772 o Where identifiers are carried within EAP-AKA' packets -- such as 773 in the AT_IDENTITY attribute -- specify which identifiers should 774 be filled in. 776 In 5G, the normal mode of operation is that identifiers are only 777 transmitted outside EAP. However, in a system involving terminals 778 from many generations and several connectivity options via 5G and 779 other mechanisms, implementations and the EAP-AKA' specification need 780 to prepare for many different situations, including sometimes having 781 to communicate identities within EAP. 783 The following sections clarify which identifiers are used and how. 785 5.1. Key Derivation 787 In EAP-AKA', the peer identity is used in the Section 3.3 key 788 derivation formula. 790 If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF 791 parameter has the value 1, and this authentication is not a fast re- 792 authentication, then the peer identity used in the key derivation 793 MUST be the 5G SUPI for the peer. This rule applies to all full EAP- 794 AKA' authentication processes, even if the peer sent some other 795 identifier at a lower layer or as a response to an EAP Identity 796 Request or if no identity was sent. 798 In all other cases, the following applies: 800 The identity used in the key derivation formula MUST be exactly 801 the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, 802 regardless of the kind of identity that it may have been. If no 803 AT_IDENTITY was sent, the identity MUST be the exactly the one 804 sent in the generic EAP Identity exchange, if one was made. 805 Again, the identity MUST be used exactly as sent. 807 If no identity was communicated inside EAP, then the identity is 808 the one communicated outside EAP in link layer messaging. 810 In this case, the used identity MUST be the identity most recently 811 communicated by the peer to the network, again regardless of what 812 type of identity it may have been. 814 5.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 816 The EAP authentication option is only available in 5G when the new 5G 817 core network is also in use. However, in other networks an EAP-AKA' 818 peer may be connecting to other types of networks and existing 819 equipment. 821 When the EAP peer is connecting to a 5G access network and uses the 822 5G core network signalling mechanisms, it can assume that the EAP 823 server is in a 5G network. The EAP level identity exchanges are not 824 generally used in this case, but if there is, the EAP peer SHOULD 825 employ only the privacy preserving SUCI identifier within EAP (either 826 in EAP Identity Response or EAP-AKA' AT_IDENTITY attribute). 828 Similarly, if the peer is explicitly communicating through mechanisms 829 developed for 5G to connect to 5G networks over WLAN, it MUST assume 830 that the EAP server is in a 5G network, and again employ the SUCI 831 within EAP. 833 Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is 834 configured to use. 836 6. Exported Parameters 838 The EAP-AKA' Session-Id is the concatenation of the EAP Type Code 839 (50, one octet) with the contents of the RAND field from the AT_RAND 840 attribute, followed by the contents of the AUTN field in the AT_AUTN 841 attribute: 843 Session-Id = 50 || RAND || AUTN 845 When using fast re-authentication, the EAP-AKA' Session-Id is the 846 concatenation of the EAP Type Code (50) with the contents of the 847 NONCE_S field from the AT_NONCE_S attribute, followed by the contents 848 of the MAC field from the AT_MAC attribute from EAP-Request/AKA- 849 Reauthentication: 851 Session-Id = 50 || NONCE_S || MAC 853 The Peer-Id is the contents of the Identity field from the 854 AT_IDENTITY attribute, using only the Actual Identity Length octets 855 from the beginning. Note that the contents are used as they are 856 transmitted, regardless of whether the transmitted identity was a 857 permanent, pseudonym, or fast EAP re-authentication identity. The 858 Server-Id is the null string (zero length). 860 7. Security Considerations 862 A summary of the security properties of EAP-AKA' follows. These 863 properties are very similar to those in EAP-AKA. We assume that 864 SHA-256 is at least as secure as SHA-1. This is called the SHA-256 865 assumption in the remainder of this section. Under this assumption, 866 EAP-AKA' is at least as secure as EAP-AKA. 868 If the AT_KDF attribute has value 1, then the security properties of 869 EAP-AKA' are as follows: 871 Protected ciphersuite negotiation 873 EAP-AKA' has no ciphersuite negotiation mechanisms. It does have 874 a negotiation mechanism for selecting the key derivation 875 functions. This mechanism is secure against bidding down attacks. 876 The negotiation mechanism allows changing the offered key 877 derivation function, but the change is visible in the final EAP- 878 Request/AKA'-Challenge message that the server sends to the peer. 879 This message is authenticated via the AT_MAC attribute, and 880 carries both the chosen alternative and the initially offered 881 list. The peer refuses to accept a change it did not initiate. 882 As a result, both parties are aware that a change is being made 883 and what the original offer was. 885 Mutual authentication 887 Under the SHA-256 assumption, the properties of EAP-AKA' are at 888 least as good as those of EAP-AKA in this respect. Refer to 889 [RFC4187], Section 12 for further details. 891 Integrity protection 893 Under the SHA-256 assumption, the properties of EAP-AKA' are at 894 least as good (most likely better) as those of EAP-AKA in this 895 respect. Refer to [RFC4187], Section 12 for further details. The 896 only difference is that a stronger hash algorithm, SHA-256, is 897 used instead of SHA-1. 899 Replay protection 901 Under the SHA-256 assumption, the properties of EAP-AKA' are at 902 least as good as those of EAP-AKA in this respect. Refer to 903 [RFC4187], Section 12 for further details. 905 Confidentiality 907 The properties of EAP-AKA' are exactly the same as those of EAP- 908 AKA in this respect. Refer to [RFC4187], Section 12 for further 909 details. 911 Key derivation 913 EAP-AKA' supports key derivation with an effective key strength 914 against brute force attacks equal to the minimum of the length of 915 the derived keys and the length of the AKA base key, i.e., 128 916 bits or more. The key hierarchy is specified in Section 3.3. 918 The Transient EAP Keys used to protect EAP-AKA packets (K_encr, 919 K_aut, K_re), the MSK, and the EMSK are cryptographically 920 separate. If we make the assumption that SHA-256 behaves as a 921 pseudo-random function, an attacker is incapable of deriving any 922 non-trivial information about any of these keys based on the other 923 keys. An attacker also cannot calculate the pre-shared secret 924 from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any 925 practically feasible means. 927 EAP-AKA' adds an additional layer of key derivation functions 928 within itself to protect against the use of compromised keys. 929 This is discussed further in Section 7.1. 931 EAP-AKA' uses a pseudo-random function modeled after the one used 932 in IKEv2 [RFC4306] together with SHA-256. 934 Key strength 936 See above. 938 Dictionary attack resistance 940 Under the SHA-256 assumption, the properties of EAP-AKA' are at 941 least as good as those of EAP-AKA in this respect. Refer to 942 [RFC4187], Section 12 for further details. 944 Fast reconnect 946 Under the SHA-256 assumption, the properties of EAP-AKA' are at 947 least as good as those of EAP-AKA in this respect. Refer to 948 [RFC4187], Section 12 for further details. Note that 949 implementations MUST prevent performing a fast reconnect across 950 method types. 952 Cryptographic binding 954 Note that this term refers to a very specific form of binding, 955 something that is performed between two layers of authentication. 956 It is not the same as the binding to a particular network name. 957 The properties of EAP-AKA' are exactly the same as those of EAP- 958 AKA in this respect, i.e., as it is not a tunnel method, this 959 property is not applicable to it. Refer to [RFC4187], Section 12 960 for further details. 962 Session independence 964 The properties of EAP-AKA' are exactly the same as those of EAP- 965 AKA in this respect. Refer to [RFC4187], Section 12 for further 966 details. 968 Fragmentation 970 The properties of EAP-AKA' are exactly the same as those of EAP- 971 AKA in this respect. Refer to [RFC4187], Section 12 for further 972 details. 974 Channel binding 976 EAP-AKA', like EAP-AKA, does not provide channel bindings as 977 they're defined in [RFC3748] and [RFC5247]. New skippable 978 attributes can be used to add channel binding support in the 979 future, if required. 981 However, including the Network Name field in the AKA' algorithms 982 (which are also used for other purposes than EAP-AKA') provides a 983 form of cryptographic separation between different network names, 984 which resembles channel bindings. However, the network name does 985 not typically identify the EAP (pass-through) authenticator. See 986 the following section for more discussion. 988 7.1. Security Properties of Binding Network Names 990 The ability of EAP-AKA' to bind the network name into the used keys 991 provides some additional protection against key leakage to 992 inappropriate parties. The keys used in the protocol are specific to 993 a particular network name. If key leakage occurs due to an accident, 994 access node compromise, or another attack, the leaked keys are only 995 useful when providing access with that name. For instance, a 996 malicious access point cannot claim to be network Y if it has stolen 997 keys from network X. Obviously, if an access point is compromised, 998 the malicious node can still represent the compromised node. As a 999 result, neither EAP-AKA' nor any other extension can prevent such 1000 attacks; however, the binding to a particular name limits the 1001 attacker's choices, allows better tracking of attacks, makes it 1002 possible to identify compromised networks, and applies good 1003 cryptographic hygiene. 1005 The server receives the EAP transaction from a given access network, 1006 and verifies that the claim from the access network corresponds to 1007 the name that this access network should be using. It becomes 1008 impossible for an access network to claim over AAA that it is another 1009 access network. In addition, if the peer checks that the information 1010 it has received locally over the network-access link layer matches 1011 with the information the server has given it via EAP-AKA', it becomes 1012 impossible for the access network to tell one story to the AAA 1013 network and another one to the peer. These checks prevent some 1014 "lying NAS" (Network Access Server) attacks. For instance, a roaming 1015 partner, R, might claim that it is the home network H in an effort to 1016 lure peers to connect to itself. Such an attack would be beneficial 1017 for the roaming partner if it can attract more users, and damaging 1018 for the users if their access costs in R are higher than those in 1019 other alternative networks, such as H. 1021 Any attacker who gets hold of the keys CK and IK, produced by the AKA 1022 algorithm, can compute the keys CK' and IK' and, hence, the Master 1023 Key (MK) according to the rules in Section 3.3. The attacker could 1024 then act as a lying NAS. In 3GPP systems in general, the keys CK and 1025 IK have been distributed to, for instance, nodes in a visited access 1026 network where they may be vulnerable. In order to reduce this risk, 1027 the AKA algorithm MUST be computed with the AMF separation bit set to 1028 1, and the peer MUST check that this is indeed the case whenever it 1029 runs EAP-AKA'. Furthermore, [TS-3GPP.33.402] requires that no CK or 1030 IK keys computed in this way ever leave the home subscriber system. 1032 The additional security benefits obtained from the binding depend 1033 obviously on the way names are assigned to different access networks. 1034 This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003]. 1035 Ideally, the names allow separating each different access technology, 1036 each different access network, and each different NAS within a 1037 domain. If this is not possible, the full benefits may not be 1038 achieved. For instance, if the names identify just an access 1039 technology, use of compromised keys in a different technology can be 1040 prevented, but it is not possible to prevent their use by other 1041 domains or devices using the same technology. 1043 8. IANA Considerations 1045 8.1. Type Value 1047 EAP-AKA' has the EAP Type value 50 in the Extensible Authentication 1048 Protocol (EAP) Registry under Method Types. Per Section 6.2 of 1049 [RFC3748], this allocation can be made with Designated Expert and 1050 Specification Required. 1052 8.2. Attribute Type Values 1054 EAP-AKA' shares its attribute space and subtypes with EAP-SIM 1055 [RFC4186] and EAP-AKA [RFC4187]. No new registries are needed. 1057 However, a new Attribute Type value (23) in the non-skippable range 1058 has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and 1059 EAP-SIM Parameters registry under Attribute Types. 1061 Also, a new Attribute Type value (24) in the non-skippable range has 1062 been assigned for AT_KDF (Section 3.2). 1064 Finally, a new Attribute Type value (136) in the skippable range has 1065 been assigned for AT_BIDDING (Section 4). 1067 8.3. Key Derivation Function Namespace 1069 IANA has also created a new namespace for EAP-AKA' AT_KDF Key 1070 Derivation Function Values. This namespace exists under the EAP-AKA 1071 and EAP-SIM Parameters registry. The initial contents of this 1072 namespace are given below; new values can be created through the 1073 Specification Required policy [RFC8126]. 1075 Value Description Reference 1076 --------- ---------------------- --------------- 1077 0 Reserved [RFC 5448] 1078 1 EAP-AKA' with CK'/IK' [RFC 5448] 1079 2-65535 Unassigned 1081 9. Contributors 1083 The test vectors in Appendix C were provided by Yogendra Pal and 1084 Jouni Malinen, based on two independent implementations of this 1085 specification. 1087 Jouni Malinen provided suggested text for Section 6. 1089 10. Acknowledgments 1091 The authors would like to thank Guenther Horn, Joe Salowey, Mats 1092 Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad 1093 Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni 1094 Malinen, Brian Weis, Russ Housley, Alfred Hoenes, Vesa Torvinen, 1095 Anand Palanigounder, and Mohit Sethi for their in-depth reviews and 1096 interesting discussions in this problem space. 1098 11. References 1100 11.1. Normative References 1102 [TS-3GPP.23.501] 1103 3GPP, "3rd Generation Partnership Project; Technical 1104 Specification Group Services and System Aspects; 3G 1105 Security; Security architecture and procedures for 5G 1106 System; (Release 15)", 3GPP Technical Specification 1107 23.501, December 2017. 1109 [TS-3GPP.24.302] 1110 3GPP, "3rd Generation Partnership Project; Technical 1111 Specification Group Core Network and Terminals; Access to 1112 the 3GPP Evolved Packet Core (EPC) via non-3GPP access 1113 networks; Stage 3; (Release 15)", 3GPP Draft Technical 1114 Specification 24.302, June 2018. 1116 [TS-3GPP.33.102] 1117 3GPP, "3rd Generation Partnership Project; Technical 1118 Specification Group Services and System Aspects; 3G 1119 Security; Security architecture (Release 15)", 3GPP Draft 1120 Technical Specification 33.102, June 2018. 1122 [TS-3GPP.33.402] 1123 3GPP, "3GPP System Architecture Evolution (SAE); Security 1124 aspects of non-3GPP accesses (Release 15)", 3GPP Draft 1125 Technical Specification 33.402, June 2018. 1127 [TS-3GPP.33.501] 1128 3GPP, "3rd Generation Partnership Project; Technical 1129 Specification Group Services and System Aspects; 3G 1130 Security; Security architecture and procedures for 5G 1131 System (Release 15)", 3GPP Draft Technical Specification 1132 33.501, June 2018. 1134 [FIPS.180-4] 1135 National Institute of Standards and Technology, "Secure 1136 Hash Standard", FIPS PUB 180-4, August 2015, 1137 . 1140 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1141 Hashing for Message Authentication", RFC 2104, 1142 DOI 10.17487/RFC2104, February 1997, . 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, . 1150 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1151 Levkowetz, Ed., "Extensible Authentication Protocol 1152 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1153 . 1155 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1156 Protocol Method for 3rd Generation Authentication and Key 1157 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1158 January 2006, . 1160 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1161 Writing an IANA Considerations Section in RFCs", BCP 26, 1162 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1163 . 1165 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1166 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1167 May 2017, . 1169 11.2. Informative References 1171 [TS-3GPP.23.003] 1172 3GPP, "3rd Generation Partnership Project; Technical 1173 Specification Group Core Network and Terminals; Numbering, 1174 addressing and identification (Release 15)", 3GPP Draft 1175 Technical Specification 23.003, June 2018. 1177 [TS-3GPP.35.208] 1178 3GPP, "3rd Generation Partnership Project; Technical 1179 Specification Group Services and System Aspects; 3G 1180 Security; Specification of the MILENAGE Algorithm Set: An 1181 example algorithm set for the 3GPP authentication and key 1182 generation functions f1, f1*, f2, f3, f4, f5 and f5*; 1183 Document 4: Design Conformance Test Data (Release 14)", 1184 3GPP Technical Specification 35.208, March 2017. 1186 [FIPS.180-1] 1187 National Institute of Standards and Technology, "Secure 1188 Hash Standard", FIPS PUB 180-1, April 1995, 1189 . 1191 [FIPS.180-2] 1192 National Institute of Standards and Technology, "Secure 1193 Hash Standard", FIPS PUB 180-2, August 2002, 1194 . 1197 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 1198 Authentication Protocol Method for Global System for 1199 Mobile Communications (GSM) Subscriber Identity Modules 1200 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 1201 . 1203 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1204 Selection Hints for the Extensible Authentication Protocol 1205 (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, 1206 . 1208 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1209 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 1210 . 1212 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, 1213 "Network Discovery and Selection Problem", RFC 5113, 1214 DOI 10.17487/RFC5113, January 2008, . 1217 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1218 IANA Considerations Section in RFCs", RFC 5226, 1219 DOI 10.17487/RFC5226, May 2008, . 1222 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1223 Authentication Protocol (EAP) Key Management Framework", 1224 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1225 . 1227 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1228 Extensible Authentication Protocol Method for 3rd 1229 Generation Authentication and Key Agreement (EAP-AKA')", 1230 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1231 . 1233 Appendix A. Changes from RFC 5448 1235 The changes consist first of all, referring to a newer version of 1236 [TS-3GPP.24.302]. The new version includes an updated definition of 1237 the Network Name field, to include 5G. 1239 Secondly, identifier usage for 5G has been specified in Section 5. 1241 Thirdly, exported parameters for EAP-AKA' have been defined in 1242 Section 6, as required by [RFC5247], including the definition of 1243 those parameters for both full authentication and fast re- 1244 authentication. 1246 Finally, the references to [RFC2119], [RFC5226], [FIPS.180-1] and 1247 [FIPS.180-2] have been updated to their most recent versions and 1248 language in this document changed accordingly. Similarly, references 1249 to all 3GPP technical specifications have been updated to their 5G 1250 (Release 15) versions or otherwise most recent version when there has 1251 not been a 5G-related update. 1253 Appendix B. Changes from RFC 4187 to RFC 5448 1255 The changes to RFC 4187 relate only to the bidding down prevention 1256 support defined in Section 4. In particular, this document does not 1257 change how the Master Key (MK) is calculated in RFC 4187 (it uses CK 1258 and IK, not CK' and IK'); neither is any processing of the AMF bit 1259 added to RFC 4187. 1261 Appendix C. Changes from Previous Version of This Draft 1263 RFC Editor: Please delete this section at the time of publication. 1265 The -00 version of the working group draft is merely a republication 1266 of an earlier individual draft. 1268 The -01 version of the working group clarifies updates relationship 1269 to RFC 4187, clarifies language relating to obsoleting RFC 5448, 1270 clarifies when the 3GPP references are expected to be stable, updates 1271 several past references to their more recently published versions, 1272 specifies what identifiers should be used in key derivation formula 1273 for 5G, specifies how to construct the network name in manner that is 1274 compatible with both 5G and previous versions, and has some minor 1275 editorial changes. 1277 Appendix D. Importance of Explicit Negotiation 1279 Choosing between the traditional and revised AKA key derivation 1280 functions is easy when their use is unambiguously tied to a 1281 particular radio access network, e.g., Long Term Evolution (LTE) as 1282 defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined 1283 by 3GPP2. There is no possibility for interoperability problems if 1284 this radio access network is always used in conjunction with new 1285 protocols that cannot be mixed with the old ones; clients will always 1286 know whether they are connecting to the old or new system. 1288 However, using the new key derivation functions over EAP introduces 1289 several degrees of separation, making the choice of the correct key 1290 derivation functions much harder. Many different types of networks 1291 employ EAP. Most of these networks have no means to carry any 1292 information about what is expected from the authentication process. 1293 EAP itself is severely limited in carrying any additional 1294 information, as noted in [RFC4284] and [RFC5113]. Even if these 1295 networks or EAP were extended to carry additional information, it 1296 would not affect millions of deployed access networks and clients 1297 attaching to them. 1299 Simply changing the key derivation functions that EAP-AKA [RFC4187] 1300 uses would cause interoperability problems with all of the existing 1301 implementations. Perhaps it would be possible to employ strict 1302 separation into domain names that should be used by the new clients 1303 and networks. Only these new devices would then employ the new key 1304 derivation mechanism. While this can be made to work for specific 1305 cases, it would be an extremely brittle mechanism, ripe to result in 1306 problems whenever client configuration, routing of authentication 1307 requests, or server configuration does not match expectations. It 1308 also does not help to assume that the EAP client and server are 1309 running a particular release of 3GPP network specifications. Network 1310 vendors often provide features from future releases early or do not 1311 provide all features of the current release. And obviously, there 1312 are many EAP and even some EAP-AKA implementations that are not 1313 bundled with the 3GPP network offerings. In general, these 1314 approaches are expected to lead to hard-to-diagnose problems and 1315 increased support calls. 1317 Appendix E. Test Vectors 1319 Test vectors are provided below for four different cases. The test 1320 vectors may be useful for testing implementations. In the first two 1321 cases, we employ the Milenage algorithm and the algorithm 1322 configuration parameters (the subscriber key K and operator algorithm 1323 variant configuration value OP) from test set 19 in [TS-3GPP.35.208]. 1325 The last two cases use artificial values as the output of AKA, and is 1326 useful only for testing the computation of values within EAP-AKA', 1327 not AKA itself. 1329 Case 1 1331 The parameters for the AKA run are as follows: 1333 Identity: "0555444333222111" 1335 Network name: "WLAN" 1337 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1339 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1341 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1343 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1345 RES: 28d7 b0f2 a2ec 3de5 1347 Then the derived keys are generated as follows: 1349 CK': 0093 962d 0dd8 4aa5 684b 045c 9edf fa04 1351 IK': ccfc 230c a74f cc96 c0a5 d611 64f5 a76c 1353 K_encr: 766f a0a6 c317 174b 812d 52fb cd11 a179 1355 K_aut: 0842 ea72 2ff6 835b fa20 3249 9fc3 ec23 1356 c2f0 e388 b4f0 7543 ffc6 77f1 696d 71ea 1358 K_re: cf83 aa8b c7e0 aced 892a cc98 e76a 9b20 1359 95b5 58c7 795c 7094 715c b339 3aa7 d17a 1361 MSK: 67c4 2d9a a56c 1b79 e295 e345 9fc3 d187 1362 d42b e0bf 818d 3070 e362 c5e9 67a4 d544 1363 e8ec fe19 358a b303 9aff 03b7 c930 588c 1364 055b abee 58a0 2650 b067 ec4e 9347 c75a 1366 EMSK: f861 703c d775 590e 16c7 679e a387 4ada 1367 8663 11de 2907 64d7 60cf 76df 647e a01c 1368 313f 6992 4bdd 7650 ca9b ac14 1ea0 75c4 1369 ef9e 8029 c0e2 90cd bad5 638b 63bc 23fb 1371 Case 2 1373 The parameters for the AKA run are as follows: 1375 Identity: "0555444333222111" 1377 Network name: "HRPD" 1379 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 1381 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 1383 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 1385 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 1387 RES: 28d7 b0f2 a2ec 3de5 1389 Then the derived keys are generated as follows: 1391 CK': 3820 f027 7fa5 f777 32b1 fb1d 90c1 a0da 1393 IK': db94 a0ab 557e f6c9 ab48 619c a05b 9a9f 1395 K_encr: 05ad 73ac 915f ce89 ac77 e152 0d82 187b 1397 K_aut: 5b4a caef 62c6 ebb8 882b 2f3d 534c 4b35 1398 2773 37a0 0184 f20f f25d 224c 04be 2afd 1400 K_re: 3f90 bf5c 6e5e f325 ff04 eb5e f653 9fa8 1401 cca8 3981 94fb d00b e425 b3f4 0dba 10ac 1403 MSK: 87b3 2157 0117 cd6c 95ab 6c43 6fb5 073f 1404 f15c f855 05d2 bc5b b735 5fc2 1ea8 a757 1405 57e8 f86a 2b13 8002 e057 5291 3bb4 3b82 1406 f868 a961 17e9 1a2d 95f5 2667 7d57 2900 1408 EMSK: c891 d5f2 0f14 8a10 0755 3e2d ea55 5c9c 1409 b672 e967 5f4a 66b4 bafa 0273 79f9 3aee 1410 539a 5979 d0a0 042b 9d2a e28b ed3b 17a3 1411 1dc8 ab75 072b 80bd 0c1d a612 466e 402c 1413 Case 3 1415 The parameters for the AKA run are as follows: 1417 Identity: "0555444333222111" 1419 Network name: "WLAN" 1421 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1423 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1425 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1427 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1429 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1431 Then the derived keys are generated as follows: 1433 CK': cd4c 8e5c 68f5 7dd1 d7d7 dfd0 c538 e577 1435 IK': 3ece 6b70 5dbb f7df c459 a112 80c6 5524 1437 K_encr: 897d 302f a284 7416 488c 28e2 0dcb 7be4 1439 K_aut: c407 00e7 7224 83ae 3dc7 139e b0b8 8bb5 1440 58cb 3081 eccd 057f 9207 d128 6ee7 dd53 1442 K_re: 0a59 1a22 dd8b 5b1c f29e 3d50 8c91 dbbd 1443 b4ae e230 5189 2c42 b6a2 de66 ea50 4473 1445 MSK: 9f7d ca9e 37bb 2202 9ed9 86e7 cd09 d4a7 1446 0d1a c76d 9553 5c5c ac40 a750 4699 bb89 1447 61a2 9ef6 f3e9 0f18 3de5 861a d1be dc81 1448 ce99 1639 1b40 1aa0 06c9 8785 a575 6df7 1450 EMSK: 724d e00b db9e 5681 87be 3fe7 4611 4557 1451 d501 8779 537e e37f 4d3c 6c73 8cb9 7b9d 1452 c651 bc19 bfad c344 ffe2 b52c a78b d831 1453 6b51 dacc 5f2b 1440 cb95 1552 1cc7 ba23 1455 Case 4 1457 The parameters for the AKA run are as follows: 1459 Identity: "0555444333222111" 1461 Network name: "HRPD" 1463 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 1465 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 1467 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 1469 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 1471 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 1473 Then the derived keys are generated as follows: 1475 CK': 8310 a71c e6f7 5488 9613 da8f 64d5 fb46 1477 IK': 5adf 1436 0ae8 3819 2db2 3f6f cb7f 8c76 1479 K_encr: 745e 7439 ba23 8f50 fcac 4d15 d47c d1d9 1481 K_aut: 3e1d 2aa4 e677 025c fd86 2a4b e183 61a1 1482 3a64 5765 5714 63df 833a 9759 e809 9879 1484 K_re: 99da 835e 2ae8 2462 576f e651 6fad 1f80 1485 2f0f a119 1655 dd0a 273d a96d 04e0 fcd3 1487 MSK: c6d3 a6e0 ceea 951e b20d 74f3 2c30 61d0 1488 680a 04b0 b086 ee87 00ac e3e0 b95f a026 1489 83c2 87be ee44 4322 94ff 98af 26d2 cc78 1490 3bac e75c 4b0a f7fd feb5 511b a8e4 cbd0 1492 EMSK: 7fb5 6813 838a dafa 99d1 40c2 f198 f6da 1493 cebf b6af ee44 4961 1054 02b5 08c7 f363 1494 352c b291 9644 b504 63e6 a693 5415 0147 1495 ae09 cbc5 4b8a 651d 8787 a689 3ed8 536d 1497 Authors' Addresses 1498 Jari Arkko 1499 Ericsson 1500 Jorvas 02420 1501 Finland 1503 Email: jari.arkko@piuha.net 1505 Vesa Lehtovirta 1506 Ericsson 1507 Jorvas 02420 1508 Finland 1510 Email: vesa.lehtovirta@ericsson.com 1512 Vesa Torvinen 1513 Ericsson 1514 Jorvas 02420 1515 Finland 1517 Email: vesa.torvinen@ericsson.com 1519 Pasi Eronen 1520 Nokia Research Center 1521 P.O. Box 407 1522 FIN-00045 Nokia Group 1523 Finland 1525 Email: pasi.eronen@nokia.com