idnits 2.17.1 draft-ietf-emu-rfc5448bis-10.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. -- The draft header indicates that this document updates RFC4187, but the abstract doesn't seem to directly say this. It does mention RFC4187 though, so this could be OK. -- The draft header indicates that this document updates RFC5448, but the abstract doesn't seem to directly say this. It does mention RFC5448 though, so this could be OK. 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 (May 10, 2021) is 1081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-12) exists of draft-ietf-emu-aka-pfs-05 Summary: 1 error (**), 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 Updates: 5448,4187 (if approved) V. Torvinen 5 Intended status: Informational Ericsson 6 Expires: November 11, 2021 P. Eronen 7 Independent 8 May 10, 2021 10 Improved Extensible Authentication Protocol Method for 3GPP Mobile 11 Network Authentication and Key Agreement (EAP-AKA') 12 draft-ietf-emu-rfc5448bis-10 14 Abstract 16 The 3GPP Mobile Network Authentication and Key Agreement (AKA) is an 17 authentication mechanism for devices wishing to access mobile 18 networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible 19 within the Extensible Authentication Protocol (EAP) framework. RFC 20 5448 (EAP-AKA') was an improved version of EAP-AKA. 22 This document is the most recent specification of EAP-AKA', 23 including, for instance, details and references about related to 24 operating EAP-AKA' in 5G networks. 26 EAP-AKA' differs from EAP-AKA by providing a key derivation function 27 that binds the keys derived within the method to the name of the 28 access network. The key derivation function has been defined in the 29 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use 30 in EAP in an interoperable manner. EAP-AKA' also updates the 31 algorithm used in hash functions, as it employs SHA-256 / HMAC- 32 SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. 34 This version of EAP-AKA' specification specifies the protocol 35 behaviour for both 4G and 5G deployments, whereas the previous 36 version only did this for 4G. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 11, 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 74 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8 76 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13 78 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15 79 3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 15 80 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 15 81 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 15 82 3.5. Summary of Attributes for EAP-AKA' . . . . . . . . . . . 16 83 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 18 84 4.1. Summary of Attributes for EAP-AKA . . . . . . . . . . . . 20 85 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 20 86 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 20 87 5.2. Generating Pseudonyms and Fast Re-Authentication 88 Identities . . . . . . . . . . . . . . . . . . . . . . . 21 89 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 22 90 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 23 91 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY 92 Attribute . . . . . . . . . . . . . . . . . . . . . . 24 93 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 24 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 30 97 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32 98 7.4. Security Properties of Binding Network Names . . . . . . 33 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 100 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 34 101 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 34 102 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 34 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 105 9.2. Informative References . . . . . . . . . . . . . . . . . 37 106 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 40 107 Appendix B. Changes to RFC 4187 . . . . . . . . . . . . . . . . 41 108 Appendix C. Changes from Previous Version of This Draft . . . . 41 109 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 45 110 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 46 111 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50 112 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 115 1. Introduction 117 The 3GPP Mobile Network Authentication and Key Agreement (AKA) is an 118 authentication mechanism for devices wishing to access mobile 119 networks. [RFC4187] (EAP-AKA) made the use of this mechanism 120 possible within the Extensible Authentication Protocol (EAP) 121 framework [RFC3748]. 123 [RFC5448] (EAP-AKA') was an improved version of EAP-AKA. EAP-AKA' 124 was defined in RFC 5448 and updated EAP-AKA RFC 4187. 126 This document is the most recent specification of EAP-AKA', 127 including, for instance, details and references about related to 128 operating EAP-AKA' in 5G networks. RFC 5448 is not obsole, but the 129 most recent and fully backwards compatible specification is in this 130 document. 132 EAP-AKA' is commonly implemented in mobile phones and network 133 equipment. It can be used for authentication to gain network access 134 via Wireless LAN networks and, with 5G, also directly to mobile 135 networks. 137 EAP-AKA' differs from EAP-AKA by providing a different key derivation 138 function. This function binds the keys derived within the method to 139 the name of the access network. This limits the effects of 140 compromised access network nodes and keys. EAP-AKA' also updates the 141 algorithm used for hash functions. 143 The EAP-AKA' method employs the derived keys CK' and IK' from the 144 3GPP specification [TS-3GPP.33.402] and updates the used hash 145 function to SHA-256 [FIPS.180-4] and HMAC to HMAC-SHA-256. 146 Otherwise, EAP-AKA' is equivalent to EAP-AKA. Given that a different 147 EAP method type value is used for EAP-AKA and EAP-AKA', a mutually 148 supported method may be negotiated using the standard mechanisms in 149 EAP [RFC3748]. 151 Note that any change of the key derivation must be unambiguous to 152 both sides in the protocol. That is, it must not be possible to 153 accidentally connect old equipment to new equipment and get the 154 key derivation wrong or attempt to use wrong keys without getting 155 a proper error message. See Appendix D for further information. 157 Note also that choices in authentication protocols should be 158 secure against bidding down attacks that attempt to force the 159 participants to use the least secure function. See Section 4 for 160 further information. 162 The changes from RFC 5448 to this specification are as follows: 164 o Update the reference on how the Network Name field is constructed 165 in the protocol. This update ensures that EAP-AKA' is compatible 166 with 5G deployments. RFC 5448 referred to the Release 8 version 167 of [TS-3GPP.24.302] and this update points to the first 5G 168 version, Release 15. 170 o Specify how EAP and EAP-AKA' use identifiers in 5G. Additional 171 identifiers are introduced in 5G, and for interoperability, it is 172 necessary that the right identifiers are used as inputs in the key 173 derivation. In addition, for identity privacy it is important 174 that when privacy-friendly identifiers in 5G are used, no 175 trackable, permanent identifiers are passed in EAP-AKA' either. 177 o Specify session identifiers and other exported parameters, as 178 those were not specified in [RFC5448] despite requirements set 179 forward in [RFC5247] to do so. Also, while [RFC5247] specified 180 session identifiers for EAP-AKA, it only did so for the full 181 authentication case, not for the case of fast re-authentication. 183 o Update the requirements on generating pseudonym usernames and fast 184 re-authentication identities to ensure identity privacy. 186 o Describe what has been learned about any vulnerabilities in AKA or 187 EAP-AKA'. 189 o Describe the privacy and pervasive monitoring considerations 190 related to EAP-AKA'. 192 o Summaries of the attributes have been added. 194 Some of the updates are small. For instance, for the first update, 195 the reference update does not change the 3GPP specification number, 196 only the version. But this reference is crucial in correct 197 calculation of the keys resulting from running the EAP-AKA' method, 198 so an update of the RFC with the newest version pointer may be 199 warranted. 201 Note: Any further updates in 3GPP specifications that affect, for 202 instance, key derivation is something that EAP-AKA' 203 implementations need to take into account. Upon such updates 204 there will be a need to both update this specification and the 205 implementations. 207 It is an explicit non-goal of this draft to include any other 208 technical modifications, addition of new features or other changes. 209 The EAP-AKA' base protocol is stable and needs to stay that way. If 210 there are any extensions or variants, those need to be proposed as 211 standalone extensions or even as different authentication methods. 213 The rest of this specification is structured as follows. Section 3 214 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to 215 prevent bidding down attacks from EAP-AKA'. Section 5 specifies 216 requirements regarding the use of peer identities, including how 5G 217 identifiers are used in the EAP-AKA' context. Section 6 specifies 218 what parameters EAP-AKA' exports out of the method. Section 7 219 explains the security differences between EAP-AKA and EAP-AKA'. 220 Section 8 describes the IANA considerations and Appendix A and 221 Appendix B explains what updates to RFC 5448 EAP-AKA' and RFC 4187 222 EAP-AKA have been made in this specification. Appendix D explains 223 some of the design rationale for creating EAP-AKA'. Finally, 224 Appendix E provides test vectors. 226 2. Requirements Language 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in BCP 231 14 [RFC2119] [RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 3. EAP-AKA' 236 EAP-AKA' is an EAP method that follows the EAP-AKA specification 237 [RFC4187] in all respects except the following: 239 o It uses the Type code 0x32, not 0x17 (which is used by EAP-AKA). 241 o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, 242 to ensure that both the peer and server know the name of the 243 access network. 245 o It supports key derivation function negotiation via the AT_KDF 246 attribute (Section 3.2) to allow for future extensions. 248 o It calculates keys as defined in Section 3.3, not as defined in 249 EAP-AKA. 251 o It employs SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 252 [FIPS.180-4] (Section 3.4 [RFC2104]). 254 Figure 1 shows an example of the authentication process. Each 255 message AKA'-Challenge and so on represents the corresponding message 256 from EAP-AKA, but with EAP-AKA' Type code. The definition of these 257 messages, along with the definition of attributes AT_RAND, AT_AUTN, 258 AT_MAC, and AT_RES can be found in [RFC4187]. 260 Peer Server 261 | EAP-Request/Identity | 262 |<-------------------------------------------------------| 263 | | 264 | EAP-Response/Identity | 265 | (Includes user's Network Access Identifier, NAI) | 266 |------------------------------------------------------->| 267 | +--------------------------------------------------+ 268 | | Server determines the network name and ensures | 269 | | that the given access network is authorized to | 270 | | use the claimed name. The server then runs the | 271 | | AKA' algorithms generating RAND and AUTN, and | 272 | | derives session keys from CK' and IK'. RAND and | 273 | | AUTN are sent as AT_RAND and AT_AUTN attributes, | 274 | | whereas the network name is transported in the | 275 | | AT_KDF_INPUT attribute. AT_KDF signals the used | 276 | | key derivation function. The session keys are | 277 | | used in creating the AT_MAC attribute. | 278 | +--------------------------------------------------+ 279 | EAP-Request/AKA'-Challenge | 280 | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| 281 |<-------------------------------------------------------| 282 +------------------------------------------------------+ | 283 | The peer determines what the network name should be, | | 284 | based on, e.g., what access technology it is using. | | 285 | The peer also retrieves the network name sent by | | 286 | the network from the AT_KDF_INPUT attribute. The | | 287 | two names are compared for discrepancies, and if | | 288 | necessary, the authentication is aborted. Otherwise,| | 289 | the network name from AT_KDF_INPUT attribute is | | 290 | used in running the AKA' algorithms, verifying AUTN | | 291 | from AT_AUTN and MAC from AT_MAC attributes. The | | 292 | peer then generates RES. The peer also derives | | 293 | session keys from CK'/IK'. The AT_RES and AT_MAC | | 294 | attributes are constructed. | | 295 +------------------------------------------------------+ | 296 | EAP-Response/AKA'-Challenge | 297 | (AT_RES, AT_MAC) | 298 |------------------------------------------------------->| 299 | +--------------------------------------------------+ 300 | | Server checks the RES and MAC values received | 301 | | in AT_RES and AT_MAC, respectively. Success | 302 | | requires both to be found correct. | 303 | +--------------------------------------------------+ 304 | EAP-Success | 305 |<-------------------------------------------------------| 307 Figure 1: EAP-AKA' Authentication Process 309 EAP-AKA' can operate on the same credentials as EAP-AKA and employ 310 the same identities. However, EAP-AKA' employs different leading 311 characters than EAP-AKA for the conventions given in Section 4.1.1 of 312 [RFC4187] for International Mobile Subscriber Identifier (IMSI) based 313 usernames. For 4G networks, EAP-AKA' MUST use the leading character 314 "6" (ASCII 36 hexadecimal) instead of "0" for IMSI-based permanent 315 usernames. For 5G networks, leading character "6" is not used for 316 IMSI-based permanent user names. Identifier usage in 5G is specified 317 in Section 5.3. All other usage and processing of the leading 318 characters, usernames, and identities is as defined by EAP-AKA 319 [RFC4187]. For instance, the pseudonym and fast re-authentication 320 usernames need to be constructed so that the server can recognize 321 them. As an example, a pseudonym could begin with a leading "7" 322 character (ASCII 37 hexadecimal) and a fast re-authentication 323 username could begin with "8" (ASCII 38 hexadecimal). Note that a 324 server that implements only EAP-AKA may not recognize these leading 325 characters. According to Section 4.1.4 of [RFC4187], such a server 326 will re-request the identity via the EAP- Request/AKA-Identity 327 message, making obvious to the peer that EAP-AKA and associated 328 identity are expected. 330 3.1. AT_KDF_INPUT 332 The format of the AT_KDF_INPUT attribute is shown below. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | AT_KDF_INPUT | Length | Actual Network Name Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 . Network Name . 341 . . 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 The fields are as follows: 347 AT_KDF_INPUT 349 This is set to 23. 351 Length 353 The length of the attribute, calculated as defined in [RFC4187], 354 Section 8.1. 356 Actual Network Name Length 358 This is a 2 byte actual length field, needed due to the 359 requirement that the previous field is expressed in multiples of 4 360 bytes per the usual EAP-AKA rules. The Actual Network Name Length 361 field provides the length of the network name in bytes. 363 Network Name 365 This field contains the network name of the access network for 366 which the authentication is being performed. The name does not 367 include any terminating null characters. Because the length of 368 the entire attribute must be a multiple of 4 bytes, the sender 369 pads the name with 1, 2, or 3 bytes of all zero bits when 370 necessary. 372 Only the server sends the AT_KDF_INPUT attribute. The value is sent 373 as specified in [TS-3GPP.24.302] for both non-3GPP access networks 374 and for 5G access networks. Per [TS-3GPP.33.402], the server always 375 verifies the authorization of a given access network to use a 376 particular name before sending it to the peer over EAP-AKA'. The 377 value of the AT_KDF_INPUT attribute from the server MUST be non- 378 empty, with a greater than zero length in the Actual Network Name 379 Length field. If AT_KDF_INPUT attribute is empty, the peer behaves 380 as if AUTN had been incorrect and authentication fails. See 381 Section 3 and Figure 3 of [RFC4187] for an overview of how 382 authentication failures are handled. 384 In addition, the peer MAY check the received value against its own 385 understanding of the network name. Upon detecting a discrepancy, the 386 peer either warns the user and continues, or fails the authentication 387 process. More specifically, the peer SHOULD have a configurable 388 policy that it can follow under these circumstances. If the policy 389 indicates that it can continue, the peer SHOULD log a warning message 390 or display it to the user. If the peer chooses to proceed, it MUST 391 use the network name as received in the AT_KDF_INPUT attribute. If 392 the policy indicates that the authentication should fail, the peer 393 behaves as if AUTN had been incorrect and authentication fails. 395 The Network Name field contains a UTF-8 string. This string MUST be 396 constructed as specified in [TS-3GPP.24.302] for "Access Network 397 Identity". The string is structured as fields separated by colons 398 (:). The algorithms and mechanisms to construct the identity string 399 depend on the used access technology. 401 On the network side, the network name construction is a configuration 402 issue in an access network and an authorization check in the 403 authentication server. On the peer, the network name is constructed 404 based on the local observations. For instance, the peer knows which 405 access technology it is using on the link, it can see information in 406 a link-layer beacon, and so on. The construction rules specify how 407 this information maps to an access network name. Typically, the 408 network name consists of the name of the access technology, or the 409 name of the access technology followed by some operator identifier 410 that was advertised in a link-layer beacon. In all cases, 411 [TS-3GPP.24.302] is the normative specification for the construction 412 in both the network and peer side. If the peer policy allows running 413 EAP-AKA' over an access technology for which that specification does 414 not provide network name construction rules, the peer SHOULD rely 415 only on the information from the AT_KDF_INPUT attribute and not 416 perform a comparison. 418 If a comparison of the locally determined network name and the one 419 received over EAP-AKA' is performed on the peer, it MUST be done as 420 follows. First, each name is broken down to the fields separated by 421 colons. If one of the names has more colons and fields than the 422 other one, the additional fields are ignored. The remaining 423 sequences of fields are compared, and they match only if they are 424 equal character by character. This algorithm allows a prefix match 425 where the peer would be able to match "", "FOO", and "FOO:BAR" 426 against the value "FOO:BAR" received from the server. This 427 capability is important in order to allow possible updates to the 428 specifications that dictate how the network names are constructed. 429 For instance, if a peer knows that it is running on access technology 430 "FOO", it can use the string "FOO" even if the server uses an 431 additional, more accurate description, e.g., "FOO:BAR", that contains 432 more information. 434 The allocation procedures in [TS-3GPP.24.302] ensure that conflicts 435 potentially arising from using the same name in different types of 436 networks are avoided. The specification also has detailed rules 437 about how a client can determine these based on information available 438 to the client, such as the type of protocol used to attach to the 439 network, beacons sent out by the network, and so on. Information 440 that the client cannot directly observe (such as the type or version 441 of the home network) is not used by this algorithm. 443 The AT_KDF_INPUT attribute MUST be sent and processed as explained 444 above when AT_KDF attribute has the value 1. Future definitions of 445 new AT_KDF values MUST define how this attribute is sent and 446 processed. 448 3.2. AT_KDF 450 AT_KDF is an attribute that the server uses to reference a specific 451 key derivation function. It offers a negotiation capability that can 452 be useful for future evolution of the key derivation functions. 454 The format of the AT_KDF attribute is shown below. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | AT_KDF | Length | Key Derivation Function | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 The fields are as follows: 464 AT_KDF 466 This is set to 24. 468 Length 470 The length of the attribute, calculated as defined in [RFC4187], 471 Section 8.1. For AT_KDF, the Length field MUST be set to 1. 473 Key Derivation Function 475 An enumerated value representing the key derivation function that 476 the server (or peer) wishes to use. Value 1 represents the 477 default key derivation function for EAP-AKA', i.e., employing CK' 478 and IK' as defined in Section 3.3. 480 Servers MUST send one or more AT_KDF attributes in the EAP-Request/ 481 AKA'-Challenge message. These attributes represent the desired 482 functions ordered by preference, the most preferred function being 483 the first attribute. 485 Upon receiving a set of these attributes, if the peer supports and is 486 willing to use the key derivation function indicated by the first 487 attribute, the function is taken into use without any further 488 negotiation. However, if the peer does not support this function or 489 is unwilling to use it, it does not process the received EAP-Request/ 490 AKA'-Challenge in any way except by responding with the EAP-Response/ 491 AKA'-Challenge message that contains only one attribute, AT_KDF with 492 the value set to the selected alternative. If there is no suitable 493 alternative, the peer behaves as if AUTN had been incorrect and 494 authentication fails (see Figure 3 of [RFC4187]). The peer fails the 495 authentication also if there are any duplicate values within the list 496 of AT_KDF attributes (except where the duplication is due to a 497 request to change the key derivation function; see below for further 498 information). 500 Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF from the 501 peer, the server checks that the suggested AT_KDF value was one of 502 the alternatives in its offer. The first AT_KDF value in the message 503 from the server is not a valid alternative since the peer should have 504 accepted it without further negotiation. If the peer has replied 505 with the first AT_KDF value, the server behaves as if AT_MAC of the 506 response had been incorrect and fails the authentication. For an 507 overview of the failed authentication process in the server side, see 508 Section 3 and Figure 2 of [RFC4187]. Otherwise, the server re-sends 509 the EAP-Response/AKA'-Challenge message, but adds the selected 510 alternative to the beginning of the list of AT_KDF attributes and 511 retains the entire list following it. Note that this means that the 512 selected alternative appears twice in the set of AT_KDF values. 513 Responding to the peer's request to change the key derivation 514 function is the only legal situation where such duplication may 515 occur. 517 When the peer receives the new EAP-Request/AKA'-Challenge message, it 518 MUST check that the requested change, and only the requested change, 519 occurred in the list of AT_KDF attributes. If so, it continues with 520 processing the received EAP-Request/AKA'-Challenge as specified in 521 [RFC4187] and Section 3.1 of this document. If not, it behaves as if 522 AT_MAC had been incorrect and fails the authentication. If the peer 523 receives multiple EAP-Request/AKA'-Challenge messages with differing 524 AT_KDF attributes without having requested negotiation, the peer MUST 525 behave as if AT_MAC had been incorrect and fail the authentication. 527 Note that the peer may also request sequence number resynchronization 528 [RFC4187]. This happens after AT_KDF negotiation has already 529 completed. That is, the EAP-Request/AKA'-Challenge and, possibly, 530 the EAP-Response/AKA'-Challenge message are exchanged first to come 531 up with a mutually acceptable key derivation function, and only then 532 the possible AKA'-Synchronization-Failure message is sent. The AKA'- 533 Synchronization-Failure message is sent as a response to the newly 534 received EAP-Request/AKA'-Challenge which is the last message of the 535 AT_KDF negotiation. Note that if the first proposed KDF is 536 acceptable, then last message is at the same time the first EAP- 537 Request/AKA'-Challenge message. The AKA'-Synchronization-Failure 538 message MUST contain the AUTS parameter as specified in [RFC4187] and 539 a copy the AT_KDF attributes as they appeared in the last message of 540 the AT_KDF negotiation. If the AT_KDF attributes are found to differ 541 from their earlier values, the peer and server MUST behave as if 542 AT_MAC had been incorrect and fail the authentication. 544 3.3. Key Derivation 546 Both the peer and server MUST derive the keys as follows. 548 AT_KDF parameter has the value 1 550 In this case, MK is derived and used as follows: 552 MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) 553 K_encr = MK[0..127] 554 K_aut = MK[128..383] 555 K_re = MK[384..639] 556 MSK = MK[640..1151] 557 EMSK = MK[1152..1663] 559 Here [n..m] denotes the substring from bit n to m, including bits 560 n and m. PRF' is a new pseudo-random function specified in 561 Section 3.4. The first 1664 bits from its output are used for 562 K_encr (encryption key, 128 bits), K_aut (authentication key, 256 563 bits), K_re (re-authentication key, 256 bits), MSK (Master Session 564 Key, 512 bits), and EMSK (Extended Master Session Key, 512 bits). 565 These keys are used by the subsequent EAP-AKA' process. K_encr is 566 used by the AT_ENCR_DATA attribute, and K_aut by the AT_MAC 567 attribute. K_re is used later in this section. MSK and EMSK are 568 outputs from a successful EAP method run [RFC3748]. 570 IK' and CK' are derived as specified in [TS-3GPP.33.402]. The 571 functions that derive IK' and CK' take the following parameters: 572 CK and IK produced by the AKA algorithm, and value of the Network 573 Name field comes from the AT_KDF_INPUT attribute (without length 574 or padding). 576 The value "EAP-AKA'" is an eight-characters-long ASCII string. It 577 is used as is, without any trailing NUL characters. 579 Identity is the peer identity as specified in Section 7 of 580 [RFC4187], and Section 5.3.2 in this document for the 5G cases. 582 When the server creates an AKA challenge and corresponding AUTN, 583 CK, CK', IK, and IK' values, it MUST set the Authentication 584 Management Field (AMF) separation bit to 1 in the AKA algorithm 585 [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF 586 separation bit is set to 1. If the bit is not set to 1, the peer 587 behaves as if the AUTN had been incorrect and fails the 588 authentication. 590 On fast re-authentication, the following keys are calculated: 592 MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) 593 MSK = MK[0..511] 594 EMSK = MK[512..1023] 596 MSK and EMSK are the resulting 512-bit keys, taking the first 1024 597 bits from the result of PRF'. Note that K_encr and K_aut are not 598 re-derived on fast re-authentication. K_re is the re- 599 authentication key from the preceding full authentication and 600 stays unchanged over any fast re-authentication(s) that may happen 601 based on it. The value "EAP-AKA' re-auth" is a sixteen- 602 characters-long ASCII string, again represented without any 603 trailing NUL characters. Identity is the fast re-authentication 604 identity, counter is the value from the AT_COUNTER attribute, 605 NONCE_S is the nonce value from the AT_NONCE_S attribute, all as 606 specified in Section 7 of [RFC4187]. To prevent the use of 607 compromised keys in other places, it is forbidden to change the 608 network name when going from the full to the fast re- 609 authentication process. The peer SHOULD NOT attempt fast re- 610 authentication when it knows that the network name in the current 611 access network is different from the one in the initial, full 612 authentication. Upon seeing a re-authentication request with a 613 changed network name, the server SHOULD behave as if the re- 614 authentication identifier had been unrecognized, and fall back to 615 full authentication. The server observes the change in the name 616 by comparing where the fast re-authentication and full 617 authentication EAP transactions were received at the 618 Authentication, Authorization, and Accounting (AAA) protocol 619 level. 621 AT_KDF has any other value 623 Future variations of key derivation functions may be defined, and 624 they will be represented by new values of AT_KDF. If the peer 625 does not recognize the value, it cannot calculate the keys and 626 behaves as explained in Section 3.2. 628 AT_KDF is missing 630 The peer behaves as if the AUTN had been incorrect and MUST fail 631 the authentication. 633 If the peer supports a given key derivation function but is unwilling 634 to perform it for policy reasons, it refuses to calculate the keys 635 and behaves as explained in Section 3.2. 637 3.4. Hash Functions 639 EAP-AKA' uses SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 (see 640 [FIPS.180-4] [RFC2104]) as in EAP-AKA. This requires a change to the 641 pseudo-random function (PRF) as well as the AT_MAC and AT_CHECKCODE 642 attributes. 644 3.4.1. PRF' 646 The PRF' construction is the same one IKEv2 uses (see Section 2.13 of 647 [RFC7296]; this is the same function as was defined [RFC4306] that 648 RFC 5448 referred to). The function takes two arguments. K is a 649 256-bit value and S is a byte string of arbitrary length. PRF' is 650 defined as follows: 652 PRF'(K,S) = T1 | T2 | T3 | T4 | ... 654 where: 655 T1 = HMAC-SHA-256 (K, S | 0x01) 656 T2 = HMAC-SHA-256 (K, T1 | S | 0x02) 657 T3 = HMAC-SHA-256 (K, T2 | S | 0x03) 658 T4 = HMAC-SHA-256 (K, T3 | S | 0x04) 659 ... 661 PRF' produces as many bits of output as is needed. HMAC-SHA-256 is 662 the application of HMAC [RFC2104] to SHA-256. 664 3.4.2. AT_MAC 666 When used within EAP-AKA', the AT_MAC attribute is changed as 667 follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value. 668 The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256 669 value by truncating the output to the first 16 bytes. Hence, the 670 length of the MAC is 16 bytes. 672 Otherwise, the use of AT_MAC in EAP-AKA' follows Section 10.15 of 673 [RFC4187]. 675 3.4.3. AT_CHECKCODE 677 When used within EAP-AKA', the AT_CHECKCODE attribute is changed as 678 follows. First, a 32-byte value is needed to accommodate a 256-bit 679 hash output: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | AT_CHECKCODE | Length | Reserved | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | | 687 | Checkcode (0 or 32 bytes) | 688 | | 689 | | 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Second, the checkcode is a hash value, calculated with SHA-256 694 [FIPS.180-4], over the data specified in Section 10.13 of [RFC4187]. 696 3.5. Summary of Attributes for EAP-AKA' 698 Table 1 provides a guide to which attributes may be found in which 699 kinds of messages, and in what quantity. 701 Messages are denoted with numbers in parentheses as follows: 703 (1) EAP-Request/AKA-Identity, 705 (2) EAP-Response/AKA-Identity, 707 (3) EAP-Request/AKA-Challenge, 709 (4) EAP-Response/AKA-Challenge, 711 (5) EAP-Request/AKA-Notification, 713 (6) EAP-Response/AKA-Notification, 715 (7) EAP-Response/AKA-Client-Error 717 (8) EAP-Request/AKA-Reauthentication, 719 (9) EAP-Response/AKA-Reauthentication, 721 (10) EAP-Response/AKA-Authentication-Reject, and 723 (11) EAP-Response/AKA-Synchronization-Failure. 725 The column denoted with "E" indicates whether the attribute is a 726 nested attribute that MUST be included within AT_ENCR_DATA. 728 In addition,the numbered columns indicate the quantity of the 729 attribute within the message as follows: 731 "0" indicates that the attribute MUST NOT be included in the 732 message, 734 "1" indicates that the attribute MUST be included in the message, 736 "0-1" indicates that the attribute is sometimes included in the 737 message, 739 "0+" indicates that zero or more copies of the attribute MAY be 740 included in the message, 742 "1+" indicates that there MUST be at least one attribute in the 743 message but more than one MAY be included in the message, and 745 "0*" indicates that the attribute is not included in the message 746 in cases specified in this document, but MAY be included in the 747 future versions of the protocol. 749 The attribute table is shown below. The table is largely the same as 750 in the EAP-AKA attribute table ([RFC4187] Section 10.1), but changes 751 how many times AT_MAC may appear in EAP-Response/AKA'-Challenge 752 message as it does not appear there when AT_KDF has to be sent from 753 the peer to the server. The table also adds the AT_KDF and 754 AT_KDF_INPUT attributes. 756 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E 757 AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 758 AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 759 AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N 760 AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N 761 AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N 762 AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N 763 AT_RES 0 0 0 1 0 0 0 0 0 0 0 N 764 AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N 765 AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y 766 AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y 767 AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 768 AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N 769 AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y 770 AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 771 AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N 772 AT_MAC 0 0 1 0-1 0-1 0-1 0 1 1 0 0 N 773 AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y 774 AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y 775 AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y 776 AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N 777 AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N 778 AT_KDF 0 0 1+ 0+ 0 0 0 0 0 0 1+ N 779 AT_KDF_INPUT 0 0 1 0 0 0 0 0 0 0 0 N 781 Table 1: The attribute table 783 4. Bidding Down Prevention for EAP-AKA 785 As discussed in [RFC3748], negotiation of methods within EAP is 786 insecure. That is, a man-in-the-middle attacker may force the 787 endpoints to use a method that is not the strongest that they both 788 support. This is a problem, as we expect EAP-AKA and EAP-AKA' to be 789 negotiated via EAP. 791 In order to prevent such attacks, this RFC specifies a new mechanism 792 for EAP-AKA that allows the endpoints to securely discover the 793 capabilities of each other. This mechanism comes in the form of the 794 AT_BIDDING attribute. This allows both endpoints to communicate 795 their desire and support for EAP-AKA' when exchanging EAP-AKA 796 messages. This attribute is not included in EAP-AKA' messages. It 797 is only included in EAP-AKA messages. (Those messages are protected 798 with the AT_MAC attribute.) This approach is based on the assumption 799 that EAP-AKA' is always preferable (see Section 7). If during the 800 EAP-AKA authentication process it is discovered that both endpoints 801 would have been able to use EAP-AKA', the authentication process 802 SHOULD be aborted, as a bidding down attack may have happened. 804 The format of the AT_BIDDING attribute is shown below. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | AT_BIDDING | Length |D| Reserved | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 The fields are as follows: 814 AT_BIDDING 816 This is set to 136. 818 Length 820 The length of the attribute, calculated as defined in [RFC4187], 821 Section 8.1. For AT_BIDDING, the Length MUST be set to 1. 823 D 825 This bit is set to 1 if the sender supports EAP-AKA', is willing 826 to use it, and prefers it over EAP-AKA. Otherwise, it should be 827 set to zero. 829 Reserved 831 This field MUST be set to zero when sent and ignored on receipt. 833 The server sends this attribute in the EAP-Request/AKA-Challenge 834 message. If the peer supports EAP-AKA', it compares the received 835 value to its own capabilities. If it turns out that both the server 836 and peer would have been able to use EAP-AKA' and preferred it over 837 EAP-AKA, the peer behaves as if AUTN had been incorrect and fails the 838 authentication (see Figure 3 of [RFC4187]). A peer not supporting 839 EAP-AKA' will simply ignore this attribute. In all cases, the 840 attribute is protected by the integrity mechanisms of EAP-AKA, so it 841 cannot be removed by a man-in-the-middle attacker. 843 Note that we assume (Section 7) that EAP-AKA' is always stronger than 844 EAP-AKA. As a result, this specification does not provide protection 845 against bidding "down" attacks in the other direction, i.e., 846 attackers forcing the endpoints to use EAP-AKA'. 848 4.1. Summary of Attributes for EAP-AKA 850 The appearance of the AT_BIDDING attribute in EAP-AKA exchanges is 851 shown below, using the notation from Section 3.5: 853 Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E 854 AT_BIDDING 0 0 1 0 0 0 0 0 0 0 0 N 856 5. Peer Identities 858 EAP-AKA' peer identities are as specified in [RFC4187] Section 4.1, 859 with the addition of some requirements specified in this section. 861 EAP-AKA' includes optional identity privacy support that can be used 862 to hide the cleartext permanent identity and thereby make the 863 subscriber's EAP exchanges untraceable to eavesdroppers. EAP-AKA' 864 can also use the privacy friendly identifiers specified for 5G 865 networks. 867 The permanent identity is usually based on the IMSI. Exposing the 868 IMSI is undesirable, because as a permanent identity it is easily 869 trackable. In addition, since IMSIs may be used in other contexts as 870 well, there would be additional opportunities for such tracking. 872 In EAP-AKA', identity privacy is based on temporary usernames, or 873 pseudonym usernames. These are similar to but separate from the 874 Temporary Mobile Subscriber Identities (TMSI) that are used on 875 cellular networks. 877 5.1. Username Types in EAP-AKA' Identities 879 Section 4.1.1.3 of [RFC4187] specified that there are three types of 880 usernames: permanent, pseudonym, and fast re-authentication 881 usernames. This specification extends this definition as follows. 882 There are four types of usernames: 884 (1) Regular usernames. These are external names given to EAP-AKA' 885 peers. The regular usernames are further subdivided into to 886 categories: 888 (a) Permanent usernames, for instance IMSI-based usernames. 890 (b) Privacy-friendly temporary usernames, for instance 5G GUTI 891 (5G Globally Unique Temporary Identifier) or 5G privacy 892 identifiers (see Section 5.3.2), for instance SUCI 893 (Subscription Concealed Identifier). 895 (2) EAP-AKA' pseudonym usernames. For example, 896 2s7ah6n9q@example.com might be a valid pseudonym identity. In 897 this example, 2s7ah6n9q is the pseudonym username. 899 (3) EAP-AKA' fast re-authentication usernames. For example, 900 43953754@example.com might be a valid fast re-authentication 901 identity and 43953754 the fast re-authentication username. 903 The permanent, privacy-friendly temporary, and pseudonym usernames 904 are only used on full authentication, and fast re-authentication 905 usernames only on fast re-authentication. Unlike permanent usernames 906 and pseudonym usernames, privacy friendly temporary usernames and 907 fast re-authentication usernames are one-time identifiers, which are 908 not re-used across EAP exchanges. 910 5.2. Generating Pseudonyms and Fast Re-Authentication Identities 912 This section provides some additional guidance for implementations 913 for producing secure pseudonyms and fast re-authentication 914 identities. It does not impact backwards compatibility, because each 915 server consumes only the identities it itself generates. However, 916 adherence to the guidance will provide better security. 918 As specified by [RFC4187] Section 4.1.1.7, pseudonym usernames and 919 fast re-authentication identities are generated by the EAP server, in 920 an implementation-dependent manner. RFC 4187 provides some general 921 requirements on how these identities are transported, how they map to 922 the NAI syntax, how they are distinguished from each other, and so 923 on. 925 However, to enhance privacy some additional requirements need to be 926 applied. 928 The pseudonym usernames and fast re-authentication identities MUST be 929 generated in a cryptographically secure way so that that it is 930 computationally infeasible for an attacker to differentiate two 931 identities belonging to the same user from two identities belonging 932 to different users. This can be achieved, for instance, by using 933 random or pseudo-random identifiers such as random byte strings or 934 ciphertexts. See also [RFC4086] for guidance on random number 935 generation. 937 Note that the pseudonym and fast re-authentication usernames also 938 MUST NOT include substrings that can be used to relate the username 939 to a particular entity or a particular permanent identity. For 940 instance, the usernames can not include any subscriber-identifying 941 part of an IMSI or other permanent identifier. Similarly, no part of 942 the username can be formed by a fixed mapping that stays the same 943 across multiple different pseudonyms or fast re-authentication 944 identities for the same subscriber. 946 When the identifier used to identify a subscriber in an EAP-AKA' 947 authentication exchange is a privacy-friendly identifier that is used 948 only once, the EAP-AKA' peer MUST NOT use a pseudonym provided in 949 that authentication exchange in subsequent exchanges more than once. 950 To ensure that this does not happen, EAP-AKA' server MAY decline to 951 provide a pseudonym in such authentication exchanges. An important 952 case where such privacy-friendly identifiers are used is in 5G 953 networks (see Section 5.3). 955 5.3. Identifier Usage in 5G 957 In EAP-AKA', the peer identity may be communicated to the server in 958 one of three ways: 960 o As a part of link layer establishment procedures, externally to 961 EAP. 963 o With the EAP-Response/Identity message in the beginning of the EAP 964 exchange, but before the selection of EAP-AKA'. 966 o Transmitted from the peer to the server using EAP-AKA' messages 967 instead of EAP-Response/Identity. In this case, the server 968 includes an identity requesting attribute (AT_ANY_ID_REQ, 969 AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA- 970 Identity message; and the peer includes the AT_IDENTITY attribute, 971 which contains the peer's identity, in the EAP-Response/AKA- 972 Identity message. 974 The identity carried above may be a permanent identity, privacy 975 friendly identity, pseudonym identity, or fast re-authentication 976 identity as defined in Section 5.1. 978 5G supports the concept of privacy identifiers, and it is important 979 for interoperability that the right type of identifier is used. 981 5G defines the SUbscription Permanent Identifier (SUPI) and 982 SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501] 983 [TS-3GPP.33.501] [TS-3GPP.23.003]. SUPI is globally unique and 984 allocated to each subscriber. However, it is only used internally in 985 the 5G network, and is privacy sensitive. The SUCI is a privacy 986 preserving identifier containing the concealed SUPI, using public key 987 cryptography to encrypt the SUPI. 989 Given the choice between these two types of identifiers, EAP-AKA' 990 ensures interoperability as follows: 992 o Where identifiers are used within EAP-AKA' -- such as key 993 derivation -- specify what values exactly should be used, to avoid 994 ambiguity (see Section 5.3.1). 996 o Where identifiers are carried within EAP-AKA' packets -- such as 997 in the AT_IDENTITY attribute -- specify which identifiers should 998 be filled in (see Section 5.3.2). 1000 In 5G, the normal mode of operation is that identifiers are only 1001 transmitted outside EAP. However, in a system involving terminals 1002 from many generations and several connectivity options via 5G and 1003 other mechanisms, implementations and the EAP-AKA' specification need 1004 to prepare for many different situations, including sometimes having 1005 to communicate identities within EAP. 1007 The following sections clarify which identifiers are used and how. 1009 5.3.1. Key Derivation 1011 In EAP-AKA', the peer identity is used in the Section 3.3 key 1012 derivation formula. 1014 The identity needs to be represented in exact correct format for the 1015 key derivation formula to produce correct results. 1017 If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF 1018 parameter has the value 1, and this authentication is not a fast re- 1019 authentication, then the peer identity used in the key derivation 1020 MUST be as specified in Annex F.3 of [TS-3GPP.33.501] and Clause 2.2 1021 of [TS-3GPP.23.003]. This is in contrast to [RFC5448], which used 1022 the identity as communicated in EAP and represented as a NAI. Also, 1023 in contrast to [RFC5448], in 5G EAP-AKA' does not use the "0" or "6" 1024 prefix in front of the identifier. 1026 For an example of the format of the identity, see Clause 2.2 of 1027 [TS-3GPP.23.003]. 1029 In all other cases, the following applies: 1031 The identity used in the key derivation formula MUST be exactly 1032 the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, 1033 regardless of the kind of identity that it may have been. If no 1034 AT_IDENTITY was sent, the identity MUST be the exactly the one 1035 sent in the generic EAP Identity exchange, if one was made. 1037 If no identity was communicated inside EAP, then the identity is 1038 the one communicated outside EAP in link layer messaging. 1040 In this case, the used identity MUST be the identity most recently 1041 communicated by the peer to the network, again regardless of what 1042 type of identity it may have been. 1044 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 1046 The EAP authentication option is only available in 5G when the new 5G 1047 core network is also in use. However, in other networks an EAP-AKA' 1048 peer may be connecting to other types of networks and existing 1049 equipment. 1051 When the EAP server is in a 5G network, the 5G procedures for EAP- 1052 AKA' apply. When EAP server is defined to be in a 5G network is 1053 specified in [TS-3GPP.33.501]. 1055 Note: Currently, the following conditions are specified: when the 1056 EAP peer uses the 5G Non-Access Stratum (NAS) protocol 1057 [TS-3GPP.24.501] or when the EAP peer attaches to a network that 1058 advertises 5G connectivity without NAS [TS-3GPP.23.501]. Possible 1059 future conditions may also be specified by 3GPP. 1061 When the 5G procedures for EAP-AKA' apply, EAP identity exchanges are 1062 generally not used as the identity is already made available on 1063 previous link layer exchanges. 1065 In this situation, the EAP Identity Response and EAP-AKA' AT_IDENTITY 1066 attribute are handled as specified in Annex F.2 of [TS-3GPP.33.501]. 1068 When used in EAP-AKA', the format of the SUCI MUST be as specified in 1069 [TS-3GPP.23.003] Section 28.7.3, with the semantics defined in 1070 [TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G 1071 EAP-AKA' does not use the "0" or "6" prefix in front of the 1072 identifier. 1074 For an example of an IMSI in NAI format, see [TS-3GPP.23.003] 1075 Section 28.7.3. 1077 Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is 1078 configured to use. 1080 6. Exported Parameters 1082 When not using fast re-authentication, the EAP-AKA' Session-Id is the 1083 concatenation of the EAP Type Code (0x32, one byte) with the contents 1084 of the RAND field from the AT_RAND attribute, followed by the 1085 contents of the AUTN field in the AT_AUTN attribute : 1087 Session-Id = 0x32 || RAND || AUTN 1089 When using fast re-authentication, the EAP-AKA' Session-Id is the 1090 concatenation of the EAP Type Code (0x32) with the contents of the 1091 NONCE_S field from the AT_NONCE_S attribute, followed by the contents 1092 of the MAC field from the AT_MAC attribute from EAP-Request/AKA- 1093 Reauthentication: 1095 Session-Id = 0x32 || NONCE_S || MAC 1097 The Peer-Id is the contents of the Identity field from the 1098 AT_IDENTITY attribute, using only the Actual Identity Length bytes 1099 from the beginning. Note that the contents are used as they are 1100 transmitted, regardless of whether the transmitted identity was a 1101 permanent, pseudonym, or fast EAP re-authentication identity. If no 1102 AT_IDENTITY attribute was exchanged, the exported Peer-Id is the 1103 identity provided from the EAP Identity Response packet. If no EAP 1104 Identity Response was provided either, the exported Peer-Id is the 1105 null string (zero length). 1107 The Server-Id is the null string (zero length). 1109 7. Security Considerations 1111 A summary of the security properties of EAP-AKA' follows. These 1112 properties are very similar to those in EAP-AKA. We assume that HMAC 1113 SHA-256 is at least as secure as HMAC SHA-1 (see also [RFC6194]. 1114 This is called the SHA-256 assumption in the remainder of this 1115 section. Under this assumption, EAP-AKA' is at least as secure as 1116 EAP-AKA. 1118 If the AT_KDF attribute has value 1, then the security properties of 1119 EAP-AKA' are as follows: 1121 Protected ciphersuite negotiation 1123 EAP-AKA' has no ciphersuite negotiation mechanisms. It does have 1124 a negotiation mechanism for selecting the key derivation 1125 functions. This mechanism is secure against bidding down attacks 1126 from EAP-AKA' to EAP-AKA. The negotiation mechanism allows 1127 changing the offered key derivation function, but the change is 1128 visible in the final EAP-Request/AKA'-Challenge message that the 1129 server sends to the peer. This message is authenticated via the 1130 AT_MAC attribute, and carries both the chosen alternative and the 1131 initially offered list. The peer refuses to accept a change it 1132 did not initiate. As a result, both parties are aware that a 1133 change is being made and what the original offer was. 1135 Per assumptions in Section 4, there is no protection against 1136 bidding down attacks from EAP-AKA to EAP-AKA', should EAP-AKA' 1137 somehow be considered less secure some day than EAP-AKA. Such 1138 protection was not provided in RFC 5448 implementations and 1139 consequently neither does this specification provide it. If such 1140 support is needed, it would have to be added as a separate new 1141 feature. 1143 In general, it is expected that the current negotiation 1144 capabilities in EAP-AKA' are sufficient for some types of 1145 extensions, including adding Perfect Forward Secrecy 1146 ([I-D.ietf-emu-aka-pfs]) and perhaps others. But as with how EAP- 1147 AKA' itself came about, some larger changes may require a new EAP 1148 method type. One example of such change would be the introduction 1149 of new algorithms. 1151 Mutual authentication 1153 Under the SHA-256 assumption, the properties of EAP-AKA' are at 1154 least as good as those of EAP-AKA in this respect. Refer to 1155 [RFC4187], Section 12 for further details. 1157 Integrity protection 1159 Under the SHA-256 assumption, the properties of EAP-AKA' are at 1160 least as good (most likely better) as those of EAP-AKA in this 1161 respect. Refer to [RFC4187], Section 12 for further details. The 1162 only difference is that a stronger hash algorithm and keyed MAC, 1163 SHA-256 / HMAC-SHA-256, is used instead of SHA-1 / HMAC-SHA-1. 1165 Replay protection 1167 Under the SHA-256 assumption, the properties of EAP-AKA' are at 1168 least as good as those of EAP-AKA in this respect. Refer to 1169 [RFC4187], Section 12 for further details. 1171 Confidentiality 1173 The properties of EAP-AKA' are exactly the same as those of EAP- 1174 AKA in this respect. Refer to [RFC4187], Section 12 for further 1175 details. 1177 Key derivation 1179 EAP-AKA' supports key derivation with an effective key strength 1180 against brute force attacks equal to the minimum of the length of 1181 the derived keys and the length of the AKA base key, i.e., 128 1182 bits or more. The key hierarchy is specified in Section 3.3. 1184 The Transient EAP Keys used to protect EAP-AKA packets (K_encr, 1185 K_aut, K_re), the MSK, and the EMSK are cryptographically 1186 separate. If we make the assumption that SHA-256 behaves as a 1187 pseudo-random function, an attacker is incapable of deriving any 1188 non-trivial information about any of these keys based on the other 1189 keys. An attacker also cannot calculate the pre-shared secret 1190 from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any 1191 practically feasible means. 1193 EAP-AKA' adds an additional layer of key derivation functions 1194 within itself to protect against the use of compromised keys. 1195 This is discussed further in Section 7.4. 1197 EAP-AKA' uses a pseudo-random function modeled after the one used 1198 in IKEv2 [RFC7296] together with SHA-256. 1200 Key strength 1202 See above. 1204 Dictionary attack resistance 1206 Under the SHA-256 assumption, the properties of EAP-AKA' are at 1207 least as good as those of EAP-AKA in this respect. Refer to 1208 [RFC4187], Section 12 for further details. 1210 Fast reconnect 1212 Under the SHA-256 assumption, the properties of EAP-AKA' are at 1213 least as good as those of EAP-AKA in this respect. Refer to 1214 [RFC4187], Section 12 for further details. Note that 1215 implementations MUST prevent performing a fast reconnect across 1216 method types. 1218 Cryptographic binding 1220 Note that this term refers to a very specific form of binding, 1221 something that is performed between two layers of authentication. 1222 It is not the same as the binding to a particular network name. 1223 The properties of EAP-AKA' are exactly the same as those of EAP- 1224 AKA in this respect, i.e., as it is not a tunnel method, this 1225 property is not applicable to it. Refer to [RFC4187], Section 12 1226 for further details. 1228 Session independence 1229 The properties of EAP-AKA' are exactly the same as those of EAP- 1230 AKA in this respect. Refer to [RFC4187], Section 12 for further 1231 details. 1233 Fragmentation 1235 The properties of EAP-AKA' are exactly the same as those of EAP- 1236 AKA in this respect. Refer to [RFC4187], Section 12 for further 1237 details. 1239 Channel binding 1241 EAP-AKA', like EAP-AKA, does not provide channel bindings as 1242 they're defined in [RFC3748] and [RFC5247]. New skippable 1243 attributes can be used to add channel binding support in the 1244 future, if required. 1246 However, including the Network Name field in the AKA' algorithms 1247 (which are also used for other purposes than EAP-AKA') provides a 1248 form of cryptographic separation between different network names, 1249 which resembles channel bindings. However, the network name does 1250 not typically identify the EAP (pass-through) authenticator. See 1251 Section 7.4 for more discussion. 1253 7.1. Privacy 1255 [RFC6973] suggests that the privacy considerations of IETF protocols 1256 be documented. 1258 The confidentiality properties of EAP-AKA' itself have been discussed 1259 above under "Confidentiality". 1261 EAP-AKA' uses several different types of identifiers to identify the 1262 authenticating peer. It is strongly RECOMMENDED to use the privacy- 1263 friendly temporary or hidden identifiers, i.e., the 5G GUTI or SUCI, 1264 pseudonym usernames, and fast re-authentication usernames. The use 1265 of permanent identifiers such as the IMSI or SUPI may lead to an 1266 ability to track the peer and/or user associated with the peer. The 1267 use of permanent identifiers such as the IMSI or SUPI is strongly NOT 1268 RECOMMENDED. 1270 As discussed in Section 5.3, when authenticating to a 5G network, 1271 only the SUCI identifier is normally used. The use of EAP-AKA' 1272 pseudonyms in this situation is at best limited, because the SUCI 1273 already provides a stronger mechanism. In fact, the re-use of the 1274 same pseudonym multiple times will result in a tracking opportunity 1275 for observers that see the pseudonym pass by. To avoid this, the 1276 peer and server need to follow the guidelines given in Section 5.2. 1278 When authenticating to a 5G network, per Section 5.3.1, both the EAP- 1279 AKA' peer and server need to employ the permanent identifier, SUPI, 1280 as an input to key derivation. However, this use of the SUPI is only 1281 internal. As such, the SUPI need not be communicated in EAP 1282 messages. Therefore, SUPI MUST NOT be communicated in EAP-AKA' when 1283 authenticating to a 5G network. 1285 While the use of SUCI in 5G networks generally provides identity 1286 privacy, this is not true if the null-scheme encryption is used to 1287 construct the SUCI (see [TS-3GPP.33.501] Annex C). The use of this 1288 scheme turns the use of SUCI equivalent to the use of SUPI or IMSI. 1289 The use of the null scheme is NOT RECOMMENDED where identity privacy 1290 is important. 1292 The use of fast re-authentication identities when authenticating to a 1293 5G network does not have the same problems as the use of pseudonyms, 1294 as long as the 5G authentication server generates the fast re- 1295 authentication identifiers in a proper manner specified in 1296 Section 5.2. 1298 Outside 5G, the peer can freely choose between the use of permanent, 1299 pseudonym, or fast re-authentication identifiers: 1301 o A peer that has not yet performed any EAP-AKA' exchanges does not 1302 typically have a pseudonym available. If the peer does not have a 1303 pseudonym available, then the privacy mechanism cannot be used, 1304 and the permanent identity will have to be sent in the clear. 1306 The terminal SHOULD store the pseudonym in non-volatile memory so 1307 that it can be maintained across reboots. An active attacker that 1308 impersonates the network may use the AT_PERMANENT_ID_REQ attribute 1309 ([RFC4187] Section 4.1.2) to learn the subscriber's IMSI. 1310 However, as discussed in [RFC4187] Section 4.1.2, the terminal can 1311 refuse to send the cleartext permanent identity if it believes 1312 that the network should be able to recognize the pseudonym. 1314 o When pseudonyms and fast re-authentication identities are used, 1315 the peer relies on the properly created identifiers by the server. 1317 It is essential that an attacker cannot link a privacy-friendly 1318 identifier to the user in any way or determine that two 1319 identifiers belong to the same user as outlined in Section 5.2. 1320 The pseudonym usernames and fast re-authentication identities MUST 1321 NOT be used for other purposes (e.g., in other protocols). 1323 If the peer and server cannot guarantee that SUCI can be used or 1324 pseudonyms will be available, generated properly, and maintained 1325 reliably, and identity privacy is required then additional protection 1326 from an external security mechanism such as tunneled EAP methods such 1327 as TTLS [RFC5281] or TEAP [RFC7170] may be used. The benefits and 1328 the security considerations of using an external security mechanism 1329 with EAP-AKA are beyond the scope of this document. 1331 Finally, as with other EAP methods, even when privacy-friendly 1332 identifiers or EAP tunneling is used, typically the domain part of an 1333 identifier (e.g., the home operator) is visible to external parties. 1335 7.2. Discovered Vulnerabilities 1337 There have been no published attacks that violate the primary secrecy 1338 or authentication properties defined for Authentication and Key 1339 Agreement (AKA) under the originally assumed trust model. The same 1340 is true of EAP-AKA'. 1342 However, there have been attacks when a different trust model is in 1343 use, with characteristics not originally provided by the design, or 1344 when participants in the protocol leak information to outsiders on 1345 purpose, and there have been some privacy-related attacks. 1347 For instance, the original AKA protocol does not prevent supplying 1348 keys by an insider to a third party as done in, e.g., by Mjolsnes and 1349 Tsay in [MT2012] where a serving network lets an authentication run 1350 succeed, but then misuses the session keys to send traffic on the 1351 authenticated user's behalf. This particular attack is not different 1352 from any on-path entity (such as a router) pretending to send 1353 traffic, but the general issue of insider attacks can be a problem, 1354 particularly in a large group of collaborating operators. 1356 Another class of attacks is the use of tunneling of traffic from one 1357 place to another, e.g., as done by Zhang and Fang in [ZF2005] to 1358 leverage security policy differences between different operator 1359 networks, for instance. To gain something in such an attack, the 1360 attacker needs to trick the user into believing it is in another 1361 location. If policies between different locations differ, for 1362 instance, in some location it is not required to encrypt all payload 1363 traffic, the attacker may trick the user into opening a 1364 vulnerability. As an authentication mechanism, EAP-AKA' is not 1365 directly affected by most such attacks. EAP-AKA' network name 1366 binding can also help alleviate some of the attacks. In any case, it 1367 is recommended that EAP-AKA' configuration not be dependent on the 1368 location of where a request comes from, unless the location 1369 information can be cryptographically confirmed, e.g., with the 1370 network name binding. 1372 Zhang and Fang also looked at Denial-of-Service attacks [ZF2005]. A 1373 serving network may request large numbers of authentication runs for 1374 a particular subscriber from a home network. While resynchronization 1375 process can help recover from this, eventually it is possible to 1376 exhaust the sequence number space and render the subscriber's card 1377 unusable. This attack is possible for both native AKA and EAP-AKA'. 1378 However, it requires the collaboration of a serving network in an 1379 attack. It is recommended that EAP-AKA' implementations provide 1380 means to track, detect, and limit excessive authentication attempts 1381 to combat this problem. 1383 There have also been attacks related to the use of AKA without the 1384 generated session keys (e.g., [BT2013]). Some of those attacks 1385 relate to the use of originally man-in-the-middle vulnerable HTTP 1386 Digest AKAv1 [RFC3310]. This has since then been corrected in 1387 [RFC4169]. The EAP-AKA' protocol uses session keys and provides 1388 channel binding, and as such, is resistant to the above attacks 1389 except where the protocol participants leak information to outsiders. 1391 Basin et al [Basin2018] have performed formal analysis and concluded 1392 that the AKA protocol would have benefited from additional security 1393 requirements, such as key confirmation. 1395 In the context of pervasive monitoring revelations, there were also 1396 reports of compromised long term pre-shared keys used in SIM and AKA 1397 [Heist2015]. While no protocol can survive the theft of key material 1398 associated with its credentials, there are some things that alleviate 1399 the impacts in such situations. These are discussed further in 1400 Section 7.3. 1402 Arapinis et al ([Arapinis2012]) describe an attack that uses the AKA 1403 resynchronization protocol to attempt to detect whether a particular 1404 subscriber is on a given area. This attack depends on the ability of 1405 the attacker to have a false base station on the given area, and the 1406 subscriber performing at least one authentication between the time 1407 the attack is set up and run. 1409 Borgaonkar et al discovered that the AKA resynchronization protocol 1410 may also be used to predict the authentication frequency of a 1411 subscribers if non-time-based SQN generation scheme is used 1412 [Borgaonkar2018]. The attacker can force the re-use of the keystream 1413 that is used to protect the SQN in the AKA resynchronization 1414 protocol. The attacker then guesses the authentication frequency 1415 based on the lowest bits of two XORed SQNs. The researchers' concern 1416 was that the authentication frequency would reveal some information 1417 about the phone usage behavior, e.g., number of phone calls made or 1418 number of SMS messages sent. There are a number of possible triggers 1419 for authentication, so such information leak is not direct, but can 1420 be a concern. The impact of the attack is also different depending 1421 on whether time or non-time-based SQN generation scheme is used. 1423 Similar attacks are possible outside AKA in the cellular paging 1424 protocols where the attacker can simply send application layer data, 1425 short messages or make phone calls to the intended victim and observe 1426 the air-interface (e.g., [Kune2012] and [Shaik2016]). Hussain et. 1427 al. demonstrated a slightly more sophisticated version of the attack 1428 that exploits the fact that 4G paging protocol uses the IMSI to 1429 calculate the paging timeslot [Hussain2019]. As this attack is 1430 outside AKA, it does not impact EAP-AKA'. 1432 Finally, bad implementations of EAP-AKA' may not produce pseudonym 1433 usernames or fast re-authentication identities in a manner that is 1434 sufficiently secure. While it is not a problem with the protocol 1435 itself, following the recommendations in Section 5.2 mitigate this 1436 concern. 1438 7.3. Pervasive Monitoring 1440 As required by [RFC7258], work on IETF protocols needs to consider 1441 the effects of pervasive monitoring and mitigate them when possible. 1443 As described in Section 7.2, after the publication of RFC 5448, new 1444 information has come to light regarding the use of pervasive 1445 monitoring techniques against many security technologies, including 1446 AKA-based authentication. 1448 For AKA, these attacks relate to theft of the long-term shared secret 1449 key material stored on the cards. Such attacks are conceivable, for 1450 instance, during the manufacturing process of cards, through coercion 1451 of the card manufacturers, or during the transfer of cards and 1452 associated information to an operator. Since the publication of 1453 reports about such attacks, manufacturing and provisioning processes 1454 have gained much scrutiny and have improved. 1456 In particular, it is crucial that manufacturers limit access to the 1457 secret information and the cards only to necessary systems and 1458 personnel. It is also crucial that secure mechanisms be used to 1459 store and communicate the secrets between the manufacturer and the 1460 operator that adopts those cards for their customers. 1462 Beyond these operational considerations, there are also technical 1463 means to improve resistance to these attacks. One approach is to 1464 provide Perfect Forward Secrecy (PFS). This would prevent any 1465 passive attacks merely based on the long-term secrets and observation 1466 of traffic. Such a mechanism can be defined as a backwards- 1467 compatible extension of EAP-AKA', and is pursued separately from this 1468 specification [I-D.ietf-emu-aka-pfs]. Alternatively, EAP-AKA' 1469 authentication can be run inside a PFS-capable tunneled 1470 authentication method. In any case, the use of some PFS-capable 1471 mechanism is recommended. 1473 7.4. Security Properties of Binding Network Names 1475 The ability of EAP-AKA' to bind the network name into the used keys 1476 provides some additional protection against key leakage to 1477 inappropriate parties. The keys used in the protocol are specific to 1478 a particular network name. If key leakage occurs due to an accident, 1479 access node compromise, or another attack, the leaked keys are only 1480 useful when providing access with that name. For instance, a 1481 malicious access point cannot claim to be network Y if it has stolen 1482 keys from network X. Obviously, if an access point is compromised, 1483 the malicious node can still represent the compromised node. As a 1484 result, neither EAP-AKA' nor any other extension can prevent such 1485 attacks; however, the binding to a particular name limits the 1486 attacker's choices, allows better tracking of attacks, makes it 1487 possible to identify compromised networks, and applies good 1488 cryptographic hygiene. 1490 The server receives the EAP transaction from a given access network, 1491 and verifies that the claim from the access network corresponds to 1492 the name that this access network should be using. It becomes 1493 impossible for an access network to claim over AAA that it is another 1494 access network. In addition, if the peer checks that the information 1495 it has received locally over the network-access link layer matches 1496 with the information the server has given it via EAP-AKA', it becomes 1497 impossible for the access network to tell one story to the AAA 1498 network and another one to the peer. These checks prevent some 1499 "lying NAS" (Network Access Server) attacks. For instance, a roaming 1500 partner, R, might claim that it is the home network H in an effort to 1501 lure peers to connect to itself. Such an attack would be beneficial 1502 for the roaming partner if it can attract more users, and damaging 1503 for the users if their access costs in R are higher than those in 1504 other alternative networks, such as H. 1506 Any attacker who gets hold of the keys CK and IK, produced by the AKA 1507 algorithm, can compute the keys CK' and IK' and, hence, the Master 1508 Key (MK) according to the rules in Section 3.3. The attacker could 1509 then act as a lying NAS. In 3GPP systems in general, the keys CK and 1510 IK have been distributed to, for instance, nodes in a visited access 1511 network where they may be vulnerable. In order to reduce this risk, 1512 the AKA algorithm MUST be computed with the AMF separation bit set to 1513 1, and the peer MUST check that this is indeed the case whenever it 1514 runs EAP-AKA'. Furthermore, [TS-3GPP.33.402] requires that no CK or 1515 IK keys computed in this way ever leave the home subscriber system. 1517 The additional security benefits obtained from the binding depend 1518 obviously on the way names are assigned to different access networks. 1519 This is specified in [TS-3GPP.24.302]. See also [TS-3GPP.23.003]. 1520 Ideally, the names allow separating each different access technology, 1521 each different access network, and each different NAS within a 1522 domain. If this is not possible, the full benefits may not be 1523 achieved. For instance, if the names identify just an access 1524 technology, use of compromised keys in a different technology can be 1525 prevented, but it is not possible to prevent their use by other 1526 domains or devices using the same technology. 1528 8. IANA Considerations 1530 IANA should update the Extensible Authentication Protocol (EAP) 1531 Registry and the EAP-AKA and EAP-SIM Parameters so that entries 1532 pointing to RFC 5448 will point to this RFC instead. 1534 8.1. Type Value 1536 EAP-AKA' has the EAP Type value 0x32 in the Extensible Authentication 1537 Protocol (EAP) Registry under Method Types. Per Section 6.2 of 1538 [RFC3748], this allocation can be made with Designated Expert and 1539 Specification Required. 1541 8.2. Attribute Type Values 1543 EAP-AKA' shares its attribute space and subtypes with EAP-SIM 1544 [RFC4186] and EAP-AKA [RFC4187]. No new registries are needed. 1546 However, a new Attribute Type value (23) in the non-skippable range 1547 has been assigned for AT_KDF_INPUT (Section 3.1) in the EAP-AKA and 1548 EAP-SIM Parameters registry under Attribute Types. 1550 Also, a new Attribute Type value (24) in the non-skippable range has 1551 been assigned for AT_KDF (Section 3.2). 1553 Finally, a new Attribute Type value (136) in the skippable range has 1554 been assigned for AT_BIDDING (Section 4). 1556 8.3. Key Derivation Function Namespace 1558 IANA has also created a new namespace for EAP-AKA' AT_KDF Key 1559 Derivation Function Values. This namespace exists under the EAP-AKA 1560 and EAP-SIM Parameters registry. The initial contents of this 1561 namespace are given below; new values can be created through the 1562 Specification Required policy [RFC8126]. 1564 Value Description Reference 1565 --------- ---------------------- ------------------------------- 1566 0 Reserved [RFC Editor: Refer to this RFC] 1567 1 EAP-AKA' with CK'/IK' [RFC Editor: Refer to this RFC] 1568 2-65535 Unassigned 1570 9. References 1572 9.1. Normative References 1574 [TS-3GPP.23.003] 1575 3GPP, "3rd Generation Partnership Project; Technical 1576 Specification Group Core Network and Terminals; Numbering, 1577 addressing and identification (Release 16)", 1578 3GPP Technical Specification 23.003 version 16.5.0, 1579 December 2020. 1581 [TS-3GPP.23.501] 1582 3GPP, "3rd Generation Partnership Project; Technical 1583 Specification Group Services and System Aspects; 3G 1584 Security; Security architecture and procedures for 5G 1585 System; (Release 16)", 3GPP Technical Specification 23.501 1586 version 16.7.0, December 2020. 1588 [TS-3GPP.24.302] 1589 3GPP, "3rd Generation Partnership Project; Technical 1590 Specification Group Core Network and Terminals; Access to 1591 the 3GPP Evolved Packet Core (EPC) via non-3GPP access 1592 networks; Stage 3; (Release 16)", 3GPP Technical 1593 Specification 24.302 version 16.4.0, July 2020. 1595 [TS-3GPP.24.501] 1596 3GPP, "3rd Generation Partnership Project; Technical 1597 Specification Group Core Network and Terminals; Access to 1598 the 3GPP Evolved Packet Core (EPC) via non-3GPP access 1599 networks; Stage 3; (Release 16)", 3GPP Draft Technical 1600 Specification 24.501 version 16.7.0, December 2020. 1602 [TS-3GPP.33.102] 1603 3GPP, "3rd Generation Partnership Project; Technical 1604 Specification Group Services and System Aspects; 3G 1605 Security; Security architecture (Release 16)", 1606 3GPP Technical Specification 33.102 version 16.0.0, July 1607 2020. 1609 [TS-3GPP.33.402] 1610 3GPP, "3GPP System Architecture Evolution (SAE); Security 1611 aspects of non-3GPP accesses (Release 16)", 3GPP Technical 1612 Specification 33.402 version 16.0.0, July 2020. 1614 [TS-3GPP.33.501] 1615 3GPP, "3rd Generation Partnership Project; Technical 1616 Specification Group Services and System Aspects; 3G 1617 Security; Security architecture and procedures for 5G 1618 System (Release 16)", 3GPP Technical Specification 33.501 1619 version 16.5.0, December 2020. 1621 [FIPS.180-4] 1622 National Institute of Standards and Technology, "Secure 1623 Hash Standard", FIPS PUB 180-4, August 2015, 1624 . 1627 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1628 Hashing for Message Authentication", RFC 2104, 1629 DOI 10.17487/RFC2104, February 1997, . 1632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1633 Requirement Levels", BCP 14, RFC 2119, 1634 DOI 10.17487/RFC2119, March 1997, . 1637 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1638 Levkowetz, Ed., "Extensible Authentication Protocol 1639 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1640 . 1642 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1643 Protocol Method for 3rd Generation Authentication and Key 1644 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1645 January 2006, . 1647 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1648 DOI 10.17487/RFC7542, May 2015, . 1651 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1652 Writing an IANA Considerations Section in RFCs", BCP 26, 1653 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1654 . 1656 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1657 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1658 May 2017, . 1660 9.2. Informative References 1662 [TS-3GPP.35.208] 1663 3GPP, "3rd Generation Partnership Project; Technical 1664 Specification Group Services and System Aspects; 3G 1665 Security; Specification of the MILENAGE Algorithm Set: An 1666 example algorithm set for the 3GPP authentication and key 1667 generation functions f1, f1*, f2, f3, f4, f5 and f5*; 1668 Document 4: Design Conformance Test Data (Release 14)", 1669 3GPP Technical Specification 35.208 version 15.0.0, 1670 October 2018. 1672 [FIPS.180-1] 1673 National Institute of Standards and Technology, "Secure 1674 Hash Standard", FIPS PUB 180-1, April 1995, 1675 . 1677 [FIPS.180-2] 1678 National Institute of Standards and Technology, "Secure 1679 Hash Standard", FIPS PUB 180-2, August 2002, 1680 . 1683 [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer 1684 Protocol (HTTP) Digest Authentication Using Authentication 1685 and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, 1686 September 2002, . 1688 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1689 "Randomness Requirements for Security", BCP 106, RFC 4086, 1690 DOI 10.17487/RFC4086, June 2005, . 1693 [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext 1694 Transfer Protocol (HTTP) Digest Authentication Using 1695 Authentication and Key Agreement (AKA) Version-2", 1696 RFC 4169, DOI 10.17487/RFC4169, November 2005, 1697 . 1699 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 1700 Authentication Protocol Method for Global System for 1701 Mobile Communications (GSM) Subscriber Identity Modules 1702 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 1703 . 1705 [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity 1706 Selection Hints for the Extensible Authentication Protocol 1707 (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, 1708 . 1710 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 1711 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 1712 . 1714 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, 1715 "Network Discovery and Selection Problem", RFC 5113, 1716 DOI 10.17487/RFC5113, January 2008, . 1719 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1720 Authentication Protocol (EAP) Key Management Framework", 1721 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1722 . 1724 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1725 Protocol Tunneled Transport Layer Security Authenticated 1726 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1727 DOI 10.17487/RFC5281, August 2008, . 1730 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1731 Extensible Authentication Protocol Method for 3rd 1732 Generation Authentication and Key Agreement (EAP-AKA')", 1733 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1734 . 1736 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1737 Considerations for the SHA-0 and SHA-1 Message-Digest 1738 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 1739 . 1741 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1742 Morris, J., Hansen, M., and R. Smith, "Privacy 1743 Considerations for Internet Protocols", RFC 6973, 1744 DOI 10.17487/RFC6973, July 2013, . 1747 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1748 "Tunnel Extensible Authentication Protocol (TEAP) Version 1749 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1750 . 1752 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1753 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1754 2014, . 1756 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1757 Kivinen, "Internet Key Exchange Protocol Version 2 1758 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1759 2014, . 1761 [I-D.ietf-emu-aka-pfs] 1762 Arkko, J., Norrman, K., and V. Torvinen,"Perfect-Forward Secrecy 1763 for the Extensible Authentication Protocol Method for 1764 Authentication and Key Agreement (EAP-AKA' PFS)", draft- 1765 ietf-emu-aka-pfs-05 (work in progress), October 2020. 1767 [Heist2015] 1768 Scahill, J. and J. Begley, "The great SIM heist", February 1769 2015, in https://firstlook.org/theintercept/2015/02/19/ 1770 great-sim-heist/ . 1772 [MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS 1773 and LTE authentication and key agreement protocols", 1774 October 2012, in Proceedings of the 6th international 1775 conference on Mathematical Methods, Models and 1776 Architectures for Computer Network Security: computer 1777 network security. 1779 [BT2013] Beekman, J. and C. Thompson, "Breaking Cell Phone 1780 Authentication: Vulnerabilities in AKA, IMS and Android", 1781 August 2013, in 7th USENIX Workshop on Offensive 1782 Technologies, WOOT '13. 1784 [ZF2005] Zhang, M. and Y. Fang, "Breaking Cell Phone 1785 Authentication: Vulnerabilities in AKA, IMS and Android", 1786 March 2005, IEEE Transactions on Wireless Communications, 1787 Vol. 4, No. 2. 1789 [Basin2018] 1790 Basin, D., Dreier, J., Hirsch, L., Radomirovic, S., Sasse, 1791 R., and V. Stettle, "A Formal Analysis of 5G 1792 Authentication", August 2018, arXiv:1806.10360. 1794 [Arapinis2012] 1795 Arapinis, M., Mancini, L., Ritter, E., Ryan, M., Golde, 1796 N., and R. Borgaonkar, "New Privacy Issues in Mobile 1797 Telephony: Fix and Verification", October 2012, CCS'12, 1798 Raleigh, North Carolina, USA. 1800 [Borgaonkar2018] 1801 Borgaonkar, R., Hirschi, L., Park, S., and A. Shaik, "New 1802 Privacy Threat on 3G, 4G, and Upcoming 5G AKA Protocols", 1803 2018 in IACR Cryptology ePrint Archive. 1805 [Kune2012] 1806 Kune, D., Koelndorfer, J., and Y. Kim, "Location leaks on 1807 the GSM air interface", 2012 in the proceedings of NDSS 1808 '12 held 5-8 February, 2012 in San Diego, California. 1810 [Shaik2016] 1811 Shaik, A., Seifert, J., Borgaonkar, R., Asokan, N., and V. 1812 Niemi, "Practical attacks against privacy and availability 1813 in 4G/LTE mobile communication systems", 2012 in the 1814 proceedings of NDSS '16 held 21-24 February, 2016 in San 1815 Diego, California. 1817 [Hussain2019] 1818 Hussain, S., Echeverria, M., Chowdhury, O., Li, N., and E. 1819 Bertino, "Privacy Attacks to the 4G and 5G Cellular Paging 1820 Protocols Using Side Channel Information", in the 1821 Proceedings of NDSS '19, held 24-27 February, 2019, in San 1822 Diego, California. 1824 Appendix A. Changes from RFC 5448 1826 The changes consist first of all, referring to a newer version of 1827 [TS-3GPP.24.302]. The new version includes an updated definition of 1828 the Network Name field, to include 5G. 1830 Secondly, identifier usage for 5G has been specified in Section 5.3. 1831 Also, the requirements on generating pseudonym usernames and fast re- 1832 authentication identities have been updated from the original 1833 definition in RFC 5448, which referenced RFC 4187. See Section 5. 1835 Thirdly, exported parameters for EAP-AKA' have been defined in 1836 Section 6, as required by [RFC5247], including the definition of 1837 those parameters for both full authentication and fast re- 1838 authentication. 1840 The security, privacy, and pervasive monitoring considerations have 1841 been updated or added. See Section 7. 1843 The references to [RFC2119], [RFC7542], [RFC7296], [RFC8126], 1844 [FIPS.180-1] and [FIPS.180-2] have been updated to their most recent 1845 versions and language in this document changed accordingly. However, 1846 this is merely an update to a newer RFC but the actual protocol 1847 functions are the same as defined in the earlier RFCs. 1849 Similarly, references to all 3GPP technical specifications have been 1850 updated to their 5G (Release 16) versions or otherwise most recent 1851 version when there has not been a 5G-related update. 1853 Finally, a number of clarifications have been made, including a 1854 summary of where attributes may appear. 1856 Appendix B. Changes to RFC 4187 1858 In addition to specifying EAP-AKA', this document mandates also a 1859 change to another EAP method, EAP-AKA that was defined in RFC 4187. 1860 This change was mandated already in RFC 5448 but repeated here to 1861 ensure that the latest EAP-AKA' specification contains the 1862 instructions about the necessary bidding down feature in EAP-AKA as 1863 well. 1865 The changes to RFC 4187 relate only to the bidding down prevention 1866 support defined in Section 4. In particular, this document does not 1867 change how the Master Key (MK) is calculated or any other aspect of 1868 EAP-AKA. The provisions in this specification for EAP-AKA' do not 1869 apply to EAP-AKA, outside Section 4. 1871 Appendix C. Changes from Previous Version of This Draft 1873 RFC Editor: Please delete this section at the time of publication. 1875 The -00 version of the working group draft is merely a republication 1876 of an earlier individual draft. 1878 The -01 version of the working group draft clarifies updates 1879 relationship to RFC 4187, clarifies language relating to obsoleting 1880 RFC 5448, clarifies when the 3GPP references are expected to be 1881 stable, updates several past references to their more recently 1882 published versions, specifies what identifiers should be used in key 1883 derivation formula for 5G, specifies how to construct the network 1884 name in manner that is compatible with both 5G and previous versions, 1885 and has some minor editorial changes. 1887 The -02 version of the working group draft added specification of 1888 peer identity usage in EAP-AKA', added requirements on the generation 1889 of pseudonym and fast re-authentication identifiers, specified the 1890 format of 5G-identifiers when they are used within EAP-AKA', defined 1891 privacy and pervasive surveillance considerations, clarified when 5G- 1892 related procedures apply, specified what Peer-Id value is exported 1893 when no AT_IDENTITY is exchanged within EAP-AKA', and made a number 1894 of other clarifications and editorial improvements. The security 1895 considerations section also includes a summary of vulnerabilities 1896 brought up in the context of AKA or EAP-AKA', and discusses their 1897 applicability and impacts in EAP-AKA'. 1899 The -03 version of the working group draft corrected some typos, 1900 referred to the 3GPP specifications for the SUPI and SUCI formats, 1901 updated some of the references to newer versions, and reduced the 1902 strength of some of the recommendations in the security 1903 considerations section from keyword level to normal language (as they 1904 are just deployment recommendations). 1906 The -04 version of the working group draft rewrote the abstract and 1907 some of the introduction, corrected some typos, added sentence to the 1908 abstract about obsoleting RFC 5448, clarified the use of the language 1909 when referring to AT_KDF values vs. AT_KDF attribute number, provided 1910 guidance on random number generation, clarified the dangers relating 1911 to the use of permanent user identities such as IMSIs, aligned the 1912 key derivation function/mechanism terminology, aligned the key 1913 derivation/generation terminology, aligned the octet/byte 1914 terminology, clarified the text regarding strength of SHA-256, added 1915 some cross references between sections, instructed IANA to change 1916 registries to point to this RFC rather than RFC 5448, and changed 1917 Pasi's listed affiliation. 1919 The -05 version of the draft corrected the Section 7.1 statement that 1920 SUCI must not be communicated in EAP-AKA'; this statement was meant 1921 to say SUPI must not be communicated. That was a major bug, but 1922 hopefully one that previous readers understood was a mistake! 1924 The -05 version also changed keyword strengths for identifier 1925 requests in different cases in a 5G network, to match the 3GPP 1926 specifications (see Section 5.3.2. 1928 Tables of where attributes may appear has been added to the -05 1929 version of the document, see Section 3.5 and Section 4.1. The tables 1930 are based on the original table in RFC 4187. 1932 Other changes in the -05 version included the following: 1934 o The attribute appearance table entry for AT_MAC in EAP-Response/ 1935 AKA-Challenge has been specified to be 0-1 because it does not 1936 appear when AT_KDF has to be sent; this was based on implementor 1937 feedback. 1939 o Added information about attacks against the re-synchronization 1940 protocol and other attacks recently discussed in academic 1941 conferences. 1943 o Clarified length field calculations and the AT_KDF negotiation 1944 procedure. 1946 o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'- 1947 Synchronization-Failure message was clarified in Section 3.2. 1949 o Updated and added several references 1951 o Switched to use of hexadecimal for EAP Type Values for consistency 1952 with other documents. 1954 o Made editorial clarifications to a number places in the document. 1956 The version -06 included changes to updates of references to newer 1957 versions on IANA considerations guidelines, NAIs, and IKEv2. 1959 The version -07 includes the following changes, per AD and last call 1960 review comments: 1962 o The use of pseudonyms has been clarified in Section 7.1. 1964 o The document now clarifies that it specifies behaviour both for 4G 1965 and 5G. 1967 o The implications of collisions between "Access Network ID" (4G) 1968 and "Serving Network Name" (5G) have been explained in 1969 Section 3.1. 1971 o The ability of the bidding down protection to protect bidding down 1972 only in the direction from EAP-AKA' to EAP-AKA but the other way 1973 around has been noted in Section 7. 1975 o The implications of the attack described by [Borgaonkar2018] have 1976 been updated. 1978 o Section 3.1 now specifies more clearly that zero-length network 1979 name is not allowed. 1981 o Section 3.1 refers to the network name that is today specified in 1982 [TS-3GPP.24.302] for both 4G (non-3GPP access) and 5G. 1984 o Section 7 now discusses cryptographic agility. 1986 o The document now is clear that any change to key aspects of 3GPP 1987 specifications, such as key derivation for AKA, would affect this 1988 specification and implementations. 1990 o References have been updated to the latest Release 15 versions, 1991 that are now stable. 1993 o Tables have been numbered. 1995 o Adopted a number of other editorial corrections. 1997 The version -08 includes the following changes: 1999 o Alignment of the 3GPP TS Annex and this draft, so that each 2000 individual part of the specification is stated in only one place. 2001 This has lead to this draft referring to bigger parts of the 3GPP 2002 specification, instead of spelling out the details within this 2003 document. Note that this alignment change is a proposal at this 2004 stage, and will be discussed in the upcoming 3GPP meeting. 2006 o Relaxed the language on using only SUCI in 5G. While that is the 2007 mode of operation expected to be used, [TS-3GPP.33.501] does not 2008 prohibit other types of identifiers. 2010 The version -09 includes the following changes: 2012 o Updated the language relating to obsoleting/updating RFC 5448; 2013 there was an interest to ensure that RFC 5448 stays a valid 2014 specification also in the future, owing to existing 2015 implementations. 2017 o Clarified that the leading digit "6" is not used in 5G networks. 2019 o Updated the language relating to when 5G-specific procedures are 2020 in effect, to support new use cases 3GPP has defined. 2022 o Updated the reference in Section 3.3, as the identities are 2023 different in the 5G case. 2025 o Clarified that the use of the newer reference to IKEv2 RFC did not 2026 change the actual PRF' function from RFC 5448. 2028 o Clarified that the Section 5.2 text does not impact backwards 2029 compatibility. 2031 o Corrected the characterization of the attack from [ZF2005]. 2033 o Mentioned 5G GUTIs as one possible 5G-identifier in Section 5.1. 2035 o Updated the references to Release 16. These specifications are 2036 stable in 3GPP. 2038 Version -10 is the final version and made changes per IESG and 2039 directorate review comments. These changes were editorial. One 2040 duplicate requirement in Section 5.3.1 was removed, and some 2041 references were added for tunnel methods discussion in Section 7.1. 2042 The language about exported parameters was clarified in Section 6. 2044 Appendix D. Importance of Explicit Negotiation 2046 Choosing between the traditional and revised AKA key derivation 2047 functions is easy when their use is unambiguously tied to a 2048 particular radio access network, e.g., Long Term Evolution (LTE) as 2049 defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined 2050 by 3GPP2. There is no possibility for interoperability problems if 2051 this radio access network is always used in conjunction with new 2052 protocols that cannot be mixed with the old ones; clients will always 2053 know whether they are connecting to the old or new system. 2055 However, using the new key derivation functions over EAP introduces 2056 several degrees of separation, making the choice of the correct key 2057 derivation functions much harder. Many different types of networks 2058 employ EAP. Most of these networks have no means to carry any 2059 information about what is expected from the authentication process. 2060 EAP itself is severely limited in carrying any additional 2061 information, as noted in [RFC4284] and [RFC5113]. Even if these 2062 networks or EAP were extended to carry additional information, it 2063 would not affect millions of deployed access networks and clients 2064 attaching to them. 2066 Simply changing the key derivation functions that EAP-AKA [RFC4187] 2067 uses would cause interoperability problems with all of the existing 2068 implementations. Perhaps it would be possible to employ strict 2069 separation into domain names that should be used by the new clients 2070 and networks. Only these new devices would then employ the new key 2071 derivation function. While this can be made to work for specific 2072 cases, it would be an extremely brittle mechanism, ripe to result in 2073 problems whenever client configuration, routing of authentication 2074 requests, or server configuration does not match expectations. It 2075 also does not help to assume that the EAP client and server are 2076 running a particular release of 3GPP network specifications. Network 2077 vendors often provide features from future releases early or do not 2078 provide all features of the current release. And obviously, there 2079 are many EAP and even some EAP-AKA implementations that are not 2080 bundled with the 3GPP network offerings. In general, these 2081 approaches are expected to lead to hard-to-diagnose problems and 2082 increased support calls. 2084 Appendix E. Test Vectors 2086 Test vectors are provided below for four different cases. The test 2087 vectors may be useful for testing implementations. In the first two 2088 cases, we employ the MILENAGE algorithm and the algorithm 2089 configuration parameters (the subscriber key K and operator algorithm 2090 variant configuration value OP) from test set 19 in [TS-3GPP.35.208]. 2092 The last two cases use artificial values as the output of AKA, and is 2093 useful only for testing the computation of values within EAP-AKA', 2094 not AKA itself. 2096 Case 1 2098 The parameters for the AKA run are as follows: 2100 Identity: "0555444333222111" 2102 Network name: "WLAN" 2104 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 2106 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 2108 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 2110 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 2112 RES: 28d7 b0f2 a2ec 3de5 2114 Then the derived keys are generated as follows: 2116 CK': 0093 962d 0dd8 4aa5 684b 045c 9edf fa04 2118 IK': ccfc 230c a74f cc96 c0a5 d611 64f5 a76c 2120 K_encr: 766f a0a6 c317 174b 812d 52fb cd11 a179 2122 K_aut: 0842 ea72 2ff6 835b fa20 3249 9fc3 ec23 2123 c2f0 e388 b4f0 7543 ffc6 77f1 696d 71ea 2125 K_re: cf83 aa8b c7e0 aced 892a cc98 e76a 9b20 2126 95b5 58c7 795c 7094 715c b339 3aa7 d17a 2128 MSK: 67c4 2d9a a56c 1b79 e295 e345 9fc3 d187 2129 d42b e0bf 818d 3070 e362 c5e9 67a4 d544 2130 e8ec fe19 358a b303 9aff 03b7 c930 588c 2131 055b abee 58a0 2650 b067 ec4e 9347 c75a 2133 EMSK: f861 703c d775 590e 16c7 679e a387 4ada 2134 8663 11de 2907 64d7 60cf 76df 647e a01c 2135 313f 6992 4bdd 7650 ca9b ac14 1ea0 75c4 2136 ef9e 8029 c0e2 90cd bad5 638b 63bc 23fb 2138 Case 2 2140 The parameters for the AKA run are as follows: 2142 Identity: "0555444333222111" 2144 Network name: "HRPD" 2146 RAND: 81e9 2b6c 0ee0 e12e bceb a8d9 2a99 dfa5 2148 AUTN: bb52 e91c 747a c3ab 2a5c 23d1 5ee3 51d5 2150 IK: 9744 871a d32b f9bb d1dd 5ce5 4e3e 2e5a 2152 CK: 5349 fbe0 9864 9f94 8f5d 2e97 3a81 c00f 2154 RES: 28d7 b0f2 a2ec 3de5 2156 Then the derived keys are generated as follows: 2158 CK': 3820 f027 7fa5 f777 32b1 fb1d 90c1 a0da 2160 IK': db94 a0ab 557e f6c9 ab48 619c a05b 9a9f 2162 K_encr: 05ad 73ac 915f ce89 ac77 e152 0d82 187b 2164 K_aut: 5b4a caef 62c6 ebb8 882b 2f3d 534c 4b35 2165 2773 37a0 0184 f20f f25d 224c 04be 2afd 2167 K_re: 3f90 bf5c 6e5e f325 ff04 eb5e f653 9fa8 2168 cca8 3981 94fb d00b e425 b3f4 0dba 10ac 2170 MSK: 87b3 2157 0117 cd6c 95ab 6c43 6fb5 073f 2171 f15c f855 05d2 bc5b b735 5fc2 1ea8 a757 2172 57e8 f86a 2b13 8002 e057 5291 3bb4 3b82 2173 f868 a961 17e9 1a2d 95f5 2667 7d57 2900 2175 EMSK: c891 d5f2 0f14 8a10 0755 3e2d ea55 5c9c 2176 b672 e967 5f4a 66b4 bafa 0273 79f9 3aee 2177 539a 5979 d0a0 042b 9d2a e28b ed3b 17a3 2178 1dc8 ab75 072b 80bd 0c1d a612 466e 402c 2180 Case 3 2182 The parameters for the AKA run are as follows: 2184 Identity: "0555444333222111" 2186 Network name: "WLAN" 2188 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 2190 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 2192 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 2194 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 2196 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 2198 Then the derived keys are generated as follows: 2200 CK': cd4c 8e5c 68f5 7dd1 d7d7 dfd0 c538 e577 2202 IK': 3ece 6b70 5dbb f7df c459 a112 80c6 5524 2204 K_encr: 897d 302f a284 7416 488c 28e2 0dcb 7be4 2206 K_aut: c407 00e7 7224 83ae 3dc7 139e b0b8 8bb5 2207 58cb 3081 eccd 057f 9207 d128 6ee7 dd53 2209 K_re: 0a59 1a22 dd8b 5b1c f29e 3d50 8c91 dbbd 2210 b4ae e230 5189 2c42 b6a2 de66 ea50 4473 2212 MSK: 9f7d ca9e 37bb 2202 9ed9 86e7 cd09 d4a7 2213 0d1a c76d 9553 5c5c ac40 a750 4699 bb89 2214 61a2 9ef6 f3e9 0f18 3de5 861a d1be dc81 2215 ce99 1639 1b40 1aa0 06c9 8785 a575 6df7 2217 EMSK: 724d e00b db9e 5681 87be 3fe7 4611 4557 2218 d501 8779 537e e37f 4d3c 6c73 8cb9 7b9d 2219 c651 bc19 bfad c344 ffe2 b52c a78b d831 2220 6b51 dacc 5f2b 1440 cb95 1552 1cc7 ba23 2222 Case 4 2224 The parameters for the AKA run are as follows: 2226 Identity: "0555444333222111" 2228 Network name: "HRPD" 2230 RAND: e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 e0e0 2232 AUTN: a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 a0a0 2234 IK: b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 b0b0 2236 CK: c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 c0c0 2238 RES: d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 d0d0 2240 Then the derived keys are generated as follows: 2242 CK': 8310 a71c e6f7 5488 9613 da8f 64d5 fb46 2244 IK': 5adf 1436 0ae8 3819 2db2 3f6f cb7f 8c76 2246 K_encr: 745e 7439 ba23 8f50 fcac 4d15 d47c d1d9 2248 K_aut: 3e1d 2aa4 e677 025c fd86 2a4b e183 61a1 2249 3a64 5765 5714 63df 833a 9759 e809 9879 2251 K_re: 99da 835e 2ae8 2462 576f e651 6fad 1f80 2252 2f0f a119 1655 dd0a 273d a96d 04e0 fcd3 2254 MSK: c6d3 a6e0 ceea 951e b20d 74f3 2c30 61d0 2255 680a 04b0 b086 ee87 00ac e3e0 b95f a026 2256 83c2 87be ee44 4322 94ff 98af 26d2 cc78 2257 3bac e75c 4b0a f7fd feb5 511b a8e4 cbd0 2259 EMSK: 7fb5 6813 838a dafa 99d1 40c2 f198 f6da 2260 cebf b6af ee44 4961 1054 02b5 08c7 f363 2261 352c b291 9644 b504 63e6 a693 5415 0147 2262 ae09 cbc5 4b8a 651d 8787 a689 3ed8 536d 2264 Contributors 2266 The test vectors in Appendix C were provided by Yogendra Pal and 2267 Jouni Malinen, based on two independent implementations of this 2268 specification. 2270 Jouni Malinen provided suggested text for Section 6. John Mattsson 2271 provided much of the text for Section 7.1. Karl Norrman was the 2272 source of much of the information in Section 7.2. 2274 Acknowledgments 2276 The authors would like to thank Guenther Horn, Joe Salowey, Mats 2277 Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad 2278 Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni 2279 Malinen, John Mattsson, Jesus De Gregorio, Brian Weis, Russ Housley, 2280 Alfred Hoenes, Anand Palanigounder, Michael Richardsson, Roman 2281 Danyliw, Dan Romascanu, Kyle Rose, Benjamin Kaduk, Alissa Cooper, 2282 Erik Kline, Murray Kucherawy, Robert Wilton, Warren Kumari, Andreas 2283 Kunz, Marcus Wong, Kalle Jarvinen, Daniel Migault, and Mohit Sethi 2284 for their in-depth reviews and interesting discussions in this 2285 problem space. 2287 Authors' Addresses 2289 Jari Arkko 2290 Ericsson 2291 Jorvas 02420 2292 Finland 2294 Email: jari.arkko@piuha.net 2296 Vesa Lehtovirta 2297 Ericsson 2298 Jorvas 02420 2299 Finland 2301 Email: vesa.lehtovirta@ericsson.com 2303 Vesa Torvinen 2304 Ericsson 2305 Jorvas 02420 2306 Finland 2308 Email: vesa.torvinen@ericsson.com 2310 Pasi Eronen 2311 Independent 2312 Finland 2314 Email: pe@iki.fi