idnits 2.17.1 draft-ietf-emu-aka-pfs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-emu-RFC5448bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-emu-rfc5448bis-07 == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft K. Norrman 4 Updates: RFC5448 (if approved) V. Torvinen 5 Intended status: Informational Ericsson 6 Expires: May 3, 2021 October 30, 2020 8 Perfect-Forward Secrecy for the Extensible Authentication Protocol 9 Method for Authentication and Key Agreement (EAP-AKA' PFS) 10 draft-ietf-emu-aka-pfs-05 12 Abstract 14 Many different attacks have been reported as part of revelations 15 associated with pervasive surveillance. Some of the reported attacks 16 involved compromising smart cards, such as attacking SIM card 17 manufacturers and operators in an effort to compromise shared secrets 18 stored on these cards. Since the publication of those reports, 19 manufacturing and provisioning processes have gained much scrutiny 20 and have improved. However, the danger of resourceful attackers for 21 these systems is still a concern. 23 This specification is an optional extension to the EAP-AKA' 24 authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. 25 The extension, when negotiated, provides Perfect Forward Secrecy for 26 the session key generated as a part of the authentication run in EAP- 27 AKA'. This prevents an attacker who has gained access to the long- 28 term pre-shared secret in a SIM card from being able to decrypt any 29 past communications. In addition, if the attacker stays merely a 30 passive eavesdropper, the extension prevents attacks against future 31 sessions. This forces attackers to use active attacks instead. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Protocol Design and Deployment Objectives . . . . . . . . . . 4 69 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6 72 3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 8 73 4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 74 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11 76 6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11 77 6.2. AT_KDF_PFS . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.3. New Key Derivation Functions . . . . . . . . . . . . . . 14 79 6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15 80 6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15 81 6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16 82 6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16 83 6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16 84 6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17 85 6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17 86 6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17 87 6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18 88 6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18 89 6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18 90 6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18 91 6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 96 9.2. Informative References . . . . . . . . . . . . . . . . . 24 97 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 98 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 Many different attacks have been reported as part of revelations 104 associated with pervasive surveillance. Some of the reported attacks 105 involved compromising smart cards, such as attacking SIM card 106 manufacturers and operators in an effort to compromise shared secrets 107 stored on these cards. Such attacks are conceivable, for instance, 108 during the manufacturing process of cards, or during the transfer of 109 cards and associated information to the operator. Since the 110 publication of reports about such attacks, manufacturing and 111 provisioning processes have gained much scrutiny and have improved. 113 However, the danger of resourceful attackers attempting to gain 114 information about SIM cards is still a concern. They are a high- 115 value target and concern a large number of people. Note that the 116 attacks are largely independent of the used authentication 117 technology; the issue is not vulnerabilities in algorithms or 118 protocols, but rather the possibility of someone gaining unlawful 119 access to key material. While the better protection of manufacturing 120 and other processes is essential in protecting against this, there is 121 one question that we as protocol designers can ask. Is there 122 something that we can do to limit the consequences of attacks, should 123 they occur? 125 The authors want to provide a public specification of an extension 126 that helps defend against one aspect of pervasive surveillance. This 127 is important, given the large number of users such practices may 128 affect. It is also a stated goal of the IETF to ensure that we 129 understand the surveillance concerns related to IETF protocols and 130 take appropriate countermeasures [RFC7258]. This document does that 131 for EAP-AKA'. 133 This specification is an optional extension to the EAP-AKA' 134 authentication method [I-D.ietf-emu-rfc5448bis]. While optional, the 135 use of this extension is RECOMMENDED. 137 The extension, when negotiated, provides Perfect Forward Secrecy for 138 the session key generated as a part of the authentication run in EAP- 139 AKA'. This prevents an attacker who has gained access to the long- 140 term pre-shared secret in a SIM card from being able to decrypt any 141 past communications. In addition, if the attacker stays merely a 142 passive eavesdropper, the extension prevents attacks against future 143 sessions. This forces attackers to use active attacks instead. This 144 is beneficial, because active attacks demand much more resources to 145 launch, and can generally be detected much easier. As with other 146 protocols, an active attacker with access to the long-term key 147 material will of course be able to attack all future communications, 148 but risks detection, particularly if done at scale. 150 Attacks against AKA authentication via compromising the long-term 151 secrets in the SIM cards have been an active discussion topic in many 152 contexts. Perfect forward secrecy is on the list of features for the 153 next release of 3GPP (5G Phase 2), and this document provides a basis 154 for providing this feature in a particular fashion. 156 It should also be noted that 5G network architecture includes the use 157 of the EAP framework for authentication. While any methods can be 158 run, the default authentication method within that context will be 159 EAP-AKA'. As a result, improvements in EAP-AKA' security have a 160 potential to improve security for large number of users. 162 2. Protocol Design and Deployment Objectives 164 This extension specified here re-uses large portions of the current 165 structure of 3GPP interfaces and functions, with the rationale that 166 this will make the construction more easily adopted. In particular, 167 the construction maintains the interface between the Universal 168 Subscriber Identification Module (USIM) and the mobile terminal 169 intact. As a consequence, there is no need to roll out new 170 credentials to existing subscribers. The work is based on an earlier 171 paper [TrustCom2015], and uses much of the same material, but applied 172 to EAP rather than the underlying AKA method. 174 It has been a goal to implement this change as an extension of the 175 widely supported EAP-AKA' method, rather than a completely new 176 authentication method. The extension is implemented as a set of new, 177 optional attributes, that are provided alongside the base attributes 178 in EAP-AKA'. Old implementations can ignore these attributes, but 179 their presence will nevertheless be verified as part of base EAP-AKA' 180 integrity verification process, helping protect against bidding down 181 attacks. This extension does not increase the number of rounds 182 necessary to complete the protocol. 184 The use of this extension is at the discretion of the authenticating 185 parties. It should be noted that PFS and defenses against passive 186 attacks are by no means a panacea, but they can provide a partial 187 defense that increases the cost and risk associated with pervasive 188 surveillance. 190 While adding perfect forward secrecy to the existing mobile network 191 infrastructure can be done in multiple different ways, the authors 192 believe that the approach chosen here is relatively easily 193 deployable. In particular: 195 o As noted above, no new credentials are needed; there is no change 196 to SIM cards. 198 o PFS property can be incorporated into any current or future system 199 that supports EAP, without changing any network functions beyond 200 the EAP endpoints. 202 o Key generation happens at the endpoints, enabling highest grade 203 key material to be used both by the endpoints and the intermediate 204 systems (such as access points that are given access to specific 205 keys). 207 o While EAP-AKA' is just one EAP method, for practical purposes 208 perfect forward secrecy being available for both EAP-TLS [RFC5216] 209 [I-D.ietf-emu-eap-tls13] and EAP-AKA' ensures that for many 210 practical systems perfect forward secrecy can be enabled for 211 either all or significant fraction of users. 213 3. Background 215 3.1. AKA 217 AKA is based on challenge-response mechanisms and symmetric 218 cryptography. AKA typically runs in a UMTS Subscriber Identity 219 Module (USIM) or a CDMA2000 (Removable) User Identity Module 220 ((R)UIM). In contrast with its earlier GSM counterparts, AKA 221 provides long key lengths and mutual authentication. 223 AKA works in the following manner: 225 o The identity module and the home environment have agreed on a 226 secret key beforehand. 228 o The actual authentication process starts by having the home 229 environment produce an authentication vector, based on the secret 230 key and a sequence number. The authentication vector contains a 231 random part RAND, an authenticator part AUTN used for 232 authenticating the network to the identity module, an expected 233 result part XRES, a 128-bit session key for integrity check IK, 234 and a 128-bit session key for encryption CK. 236 o The authentication vector is passed to the serving network, which 237 uses it to authenticate the device. 239 o The RAND and the AUTN are delivered to the identity module. 241 o The identity module verifies the AUTN, again based on the secret 242 key and the sequence number. If this process is successful (the 243 AUTN is valid and the sequence number used to generate AUTN is 244 within the correct range), the identity module produces an 245 authentication result RES and sends it to the serving network. 247 o The serving network verifies the correct result from the identity 248 module. If the result is correct, IK and CK can be used to 249 protect further communications between the identity module and the 250 home environment. 252 3.2. EAP-AKA' Protocol 254 When AKA are embedded into EAP, the authentication on the network 255 side is moved to the home environment; the serving network performs 256 the role of a pass-through authenticator. Figure 1 describes the 257 basic flow in the EAP-AKA' authentication process. The definition of 258 the full protocol behaviour, along with the definition of attributes 259 AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in 260 [I-D.ietf-emu-rfc5448bis] and [RFC4187]. 262 Peer Server 263 | EAP-Request/Identity | 264 |<------------------------------------------------------| 265 | | 266 | EAP-Response/Identity | 267 | (Includes user's Network Access Identifier, NAI) | 268 |------------------------------------------------------>| 269 | +-------------------------------------------------+ 270 | | Server determines the network name and ensures | 271 | | that the given access network is authorized to | 272 | | use the claimed name. The server then runs the | 273 | | AKA' algorithms generating RAND and AUTN, | 274 | | derives session keys from CK' and IK'. RAND and | 275 | | AUTN are sent as AT_RAND and AT_AUTN attributes,| 276 | | whereas the network name is transported in the | 277 | | AT_KDF_INPUT attribute. AT_KDF signals the used | 278 | | key derivation function. The session keys are | 279 | | used in creating the AT_MAC attribute. | 280 | +-------------------------------------------------+ 281 | EAP-Request/AKA'-Challenge | 282 | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| 283 |<------------------------------------------------------| 284 +-----------------------------------------------------+ | 285 | The peer determines what the network name should be,| | 286 | based on, e.g., what access technology it is using.| | 287 | The peer also retrieves the network name sent by | | 288 | the network from the AT_KDF_INPUT attribute. The | | 289 | two names are compared for discrepancies, and if | | 290 | necessary, the authentication is aborted. Otherwise,| | 291 | the network name from AT_KDF_INPUT attribute is | | 292 | used in running the AKA' algorithms, verifying AUTN | | 293 | from AT_AUTN and MAC from AT_MAC attributes. The | | 294 | peer then generates RES. The peer also derives | | 295 | session keys from CK'/IK'. The AT_RES and AT_MAC | | 296 | attributes are constructed. | | 297 +-----------------------------------------------------+ | 298 | EAP-Response/AKA'-Challenge | 299 | (AT_RES, AT_MAC) | 300 |------------------------------------------------------>| 301 | +-------------------------------------------------+ 302 | | Server checks the RES and MAC values received | 303 | | in AT_RES and AT_MAC, respectively. Success | 304 | | requires both to be found correct. | 305 | +-------------------------------------------------+ 306 | EAP-Success | 307 |<------------------------------------------------------| 309 Figure 1: EAP-AKA' Authentication Process 311 3.3. Attacks Against Long-Term Shared Secrets in Smart Cards 313 Current 3GPP systems use SIM pre-shared key based protocols and 314 Authentication and Key Agreement (AKA) to authenticate subscribers. 315 The general security properties and potential vulnerabilities of AKA 316 and EAP-AKA' are discussed in [I-D.ietf-emu-rfc5448bis]. 318 An important vulnerability in that discussion relates to the recent 319 reports of compromised long term pre-shared keys used in AKA 320 [Heist2015]. These attacks are not specific to AKA or EAP-AKA', as 321 all security systems fail at least to some extent if key material is 322 stolen. However, the reports indicate a need to look into solutions 323 that can operate at least to an extent under these types of attacks. 324 It is noted in [Heist2015] that some security can be retained even in 325 the face of the attacks by providing Perfect Forward Secrecy (PFS) 326 [DOW1992] for the session key. If AKA would have provided PFS, 327 compromising the pre-shared key would not be sufficient to perform 328 passive attacks; the attacker is, in addition, forced to be a Man-In- 329 The-Middle (MITM) during the AKA run and subsequent communication 330 between the parties. 332 4. Requirements Language 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 335 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 336 "OPTIONAL" in this document are to be interpreted as described in BCP 337 14 [RFC2119] [RFC8174] when, and only when, they appear in all 338 capitals, as shown here. 340 5. Protocol Overview 342 Introducing PFS for EAP-AKA' can be achieved by using an Elliptic 343 Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' PFS this 344 exchange is run in an ephemeral manner, i.e., both sides generate 345 temporary keys as specified in [RFC7748]. This method is referred to 346 as ECDHE, where the last 'E' stands for Ephemeral. 348 The enhancements in the EAP-AKA' PFS protocol are compatible with the 349 signaling flow and other basic structures of both AKA and EAP-AKA'. 350 The intent is to implement the enhancement as optional attributes 351 that legacy implementations can ignore. 353 The purpose of the protocol is to achieve mutual authentication 354 between the EAP server and peer, and to establish keying material for 355 secure communication between the two. This document specifies the 356 calculation of key material, providing new properties that are not 357 present in key material provided by EAP-AKA' in its original form. 359 Figure 2 below describes the overall process. Since our goal has 360 been to not require new infrastructure or credentials, the flow 361 diagrams also show the conceptual interaction with the USIM card and 362 the 3GPP authentication server (HSS). The details of those 363 interactions are outside the scope of this document, however, and the 364 reader is referred to the 3GPP specifications . 366 USIM Peer Server HSS 367 | | | | 368 | | EAP-Req/Identity | | 369 | |<-------------------------| | 370 | | | | 371 | | EAP-Resp/Identity | | 372 | |------------------------->| | 373 | | | | 374 | +-------------------------------------------------+ 375 | | Server now has an identity for the peer. | 376 | | The server then asks the help of | 377 | | HSS to run AKA algorithms, generating RAND, | 378 | | AUTN, XRES, CK, IK. Typically, the HSS performs | 379 | | the first part of key derivations so that the | 380 | | authentication server gets the CK' and IK' keys | 381 | | already tied to a particular network name. | 382 | +-------------------------------------------------+ 383 | | | | 384 | | | ID, | 385 | | | key deriv. | 386 | | | function, | 387 | | | network name| 388 | | |------------>| 389 | | | | 390 | | | RAND, AUTN, | 391 | | | XRES, CK', | 392 | | | IK' | 393 | | |<------------| 394 | | | | 395 | +-------------------------------------------------+ 396 | | Server now has the needed authentication vector.| 397 | | It generates an ephemeral key pair, sends the | 398 | | public key of that key pair and the first EAP | 399 | | method message to the peer. In the message the | 400 | | AT_PUB_ECDHE attribute carries the public key | 401 | | and the AT_KDF_PFS attribute carries other PFS- | 402 | | related parameters. Both of these are skippable | 403 | | attributes that can be ignored if the peer does | 404 | | not support this extension. | 405 | +-------------------------------------------------+ 406 | | | | 407 | | EAP-Req/AKA'-Challenge | | 408 | | AT_RAND, AT_AUTN, AT_KDF,| | 409 | | AT_KDF_PFS, AT_KDF_INPUT,| | 410 | | AT_PUB_ECDHE, AT_MAC | | 411 | |<-------------------------| | 412 +-----------------------------------------------------+ | 413 | The peer checks if it wants to do the PFS extension.| | 414 | If yes, it will eventually respond with AT_PUB_ECDHE| | 415 | and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | 416 | AT_KDF_PFS and base all calculations on basic | | 417 | EAP-AKA' attributes, continuing just as in EAP-AKA' | | 418 | per RFC 5448 (draft-ietf-emu-rfc5448bis) rules. | | 419 | In any case, the peer needs to query the auth | | 420 | parameters from the USIM card. | | 421 +-----------------------------------------------------+ | 422 | | | | 423 | RAND, AUTN | | | 424 |<---------------| | | 425 | | | | 426 | CK, IK, RES | | | 427 |-------------->| | | 428 | | | | 429 +-----------------------------------------------------+ | 430 | The peer now has everything to respond. If it wants | | 431 | to participate in the PFS extension, it will then | | 432 | generate its key pair, calculate a shared key based | | 433 | on its key pair and the server's public key. | | 434 | Finally, it proceeds to derive all EAP-AKA' key | | 435 | values and and constructs a full response. | | 436 +-----------------------------------------------------+ | 437 | | | | 438 | | EAP-Resp/AKA'-Challenge | | 439 | | AT_RES, AT_PUB_ECDHE, | | 440 | | AT_MAC | | 441 | |------------------------->| | 442 | +-------------------------------------------------+ 443 | | The server now has all the necessary values. | 444 | | It generates the ECDHE shared secret | 445 | | and checks the RES and MAC values received | 446 | | in AT_RES and AT_MAC, respectively. Success | 447 | | requires both to be found correct. Note that | 448 | | when this specification is used, the keys | 449 | | generated from EAP-AKA' are based on both | 450 | | CK/IK as well as the ECDHE value. Even if there | 451 | | was an attacker who held the long-term secret | 452 | | keys, only an active attacker could have | 453 | | determined the generated session keys; in basic | 454 | | EAP-AKA' the keys are only based on CK and IK. | 455 | +-------------------------------------------------+ 456 | | | | 457 | | EAP-Success | | 458 | |<-------------------------| | 460 Figure 2: EAP-AKA' PFS Authentication Process 462 6. Extensions to EAP-AKA' 464 6.1. AT_PUB_ECDHE 466 The AT_PUB_ECDHE carries an ECDHE value. 468 The format of the AT_PUB_ECDHE attribute is shown below. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | AT_PUB_ECDHE | Length | Value ... | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 The fields are as follows: 478 AT_PUB_ECDHE 480 This is set to TBA1 BY IANA. 482 Length 484 The length of the attribute, set as other attributes in EAP-AKA 485 [RFC4187]. 487 Value 489 This value is the sender's ECDHE public value. It is calculated 490 as follows: 492 * For X25519/Curve25519, the length of this value is 32 bytes, 493 encoded in binary as specified [RFC7748] Section 6.1. 495 * For P-256, the length of this value is 33 bytes, encoded in 496 binary as specified in [FIPS186-4], using the compressed form 497 from Section 2.7.1 of [SEC2]. 499 To retain the security of the keys, the sender SHALL generate a 500 fresh value for each run of the protocol. 502 6.2. AT_KDF_PFS 504 The AT_KDF_PFS indicates the used or desired key generation function, 505 if the Perfect Forward Secrecy extension is taken into use. It will 506 also at the same time indicate the used or desired ECDHE group. A 507 new attribute is needed to carry this information, as AT_KDF carries 508 the legacy KDF value for those EAP peers that cannot or do not want 509 to use this extension. 511 The format of the AT_KDF_PFS attribute is shown below. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | AT_KDF_PFS | Length | Key Derivation Function | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 The fields are as follows: 521 AT_KDF_PFS 523 This is set to TBA2 BY IANA. 525 Length 527 The length of the attribute, MUST be set to 1. 529 Key Derivation Function 531 An enumerated value representing the key derivation function that 532 the server (or peer) wishes to use. See Section 6.3 for the 533 functions specified in this document. Note: This field has a 534 different name space than the similar field in the AT_KDF 535 attribute Key Derivation Function defined in 536 [I-D.ietf-emu-rfc5448bis]. 538 Servers MUST send one or more AT_KDF_PFS attributes in the EAP- 539 Request/AKA'-Challenge message. These attributes represent the 540 desired functions ordered by preference, the most preferred function 541 being the first attribute. The most preferred function is the only 542 one that the server includes a public key value for, however. So for 543 a set of AT_KDF_PFS attributes, there is always only one AT_PUB_ECDHE 544 attribute. 546 Upon receiving a set of these attributes: 548 o If the peer supports and is willing to use the key derivation 549 function indicated by the first AT_KDF_PFS attribute, and is 550 willing and able to use the extension defined in this 551 specification, the function is taken into use without any further 552 negotiation. 554 o If the peer does not support this function or is unwilling to use 555 it, it responds to the server with an indication that a different 556 function is needed. Similarly with the negotiation process 557 defined in [I-D.ietf-emu-rfc5448bis] for AT_KDF, the peer sends 558 EAP-Response/AKA'-Challenge message that contains only one 559 attribute, AT_KDF_PFS with the value set to the desired 560 alternative function from among the ones suggested by the server 561 earlier. If there is no suitable alternative, the peer has a 562 choice of either falling back to EAP-AKA' or behaving as if AUTN 563 had been incorrect and failing authentication (see Figure 3 of 564 [RFC4187]). The peer MUST fail the authentication if there are 565 any duplicate values within the list of AT_KDF_PFS attributes 566 (except where the duplication is due to a request to change the 567 key derivation function; see below for further information). 569 o If the peer does not recognize the extension defined in this 570 specification or is unwilling to use it, it ignores the AT_KDF_PFS 571 attribute. 573 Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_PFS from 574 the peer, the server checks that the suggested AT_KDF_PFS value was 575 one of the alternatives in its offer. The first AT_KDF_PFS value in 576 the message from the server is not a valid alternative. If the peer 577 has replied with the first AT_KDF_PFS value, the server behaves as if 578 AT_MAC of the response had been incorrect and fails the 579 authentication. For an overview of the failed authentication process 580 in the server side, see Section 3 and Figure 2 in [RFC4187]. 581 Otherwise, the server re-sends the EAP-Response/AKA'-Challenge 582 message, but adds the selected alternative to the beginning of the 583 list of AT_KDF_PFS attributes, and retains the entire list following 584 it. Note that this means that the selected alternative appears twice 585 in the set of AT_KDF values. Responding to the peer's request to 586 change the key derivation function is the only legal situation where 587 such duplication may occur. 589 When the peer receives the new EAP-Request/AKA'-Challenge message, it 590 MUST check that the requested change, and only the requested change 591 occurred in the list of AT_KDF_PFS attributes. If yes, it continues. 592 If not, it behaves as if AT_MAC had been incorrect and fails the 593 authentication. If the peer receives multiple EAP-Request/AKA'- 594 Challenge messages with differing AT_KDF_PFS attributes without 595 having requested negotiation, the peer MUST behave as if AT_MAC had 596 been incorrect and fail the authentication. 598 6.3. New Key Derivation Functions 600 Two new Key Derivation Function types are defined for "EAP-AKA' with 601 ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE 602 and P-256", represented by value 2. These represent a particular 603 choice of key derivation function and at the same time selects an 604 ECDHE group to be used. 606 The Key Derivation Function type value is only used in the AT_KDF_PFS 607 attribute, and should not be confused with the different range of key 608 derivation functions that can be represented in the AT_KDF attribute 609 as defined in [I-D.ietf-emu-rfc5448bis]. 611 Key derivation in this extension produces exactly the same keys for 612 internal use within one authentication run as 613 [I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is 614 used in AT_MAC is still exactly as it was in EAP-AKA'. The only 615 change to key derivation is in re-authentication keys and keys 616 exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' 617 attributes such as AT_MAC continue to be usable even when this 618 extension is in use. 620 When the Key Derivation Function field in the AT_KDF_PFS attribute is 621 set to 1 and the Key Derivation Function field in the AT_KDF 622 attribute is also set to 1, the Master Key (MK) is derived as follows 623 below. 625 MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) 626 MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' PFS"|Identity) 627 K_encr = MK[0..127] 628 K_aut = MK[128..383] 629 K_re = MK_ECDHE[0..255] 630 MSK = MK_ECDHE[256..767] 631 EMSK = MK_ECDHE[768..1279] 633 Where SHARED_SECRET is the shared secret computed via ECDHE, as 634 specified in Section 6.1 of [RFC7748]. 636 Both the peer and the server MAY check for zero-value shared secret 637 as specified in Section 6.1 of [RFC7748]. If such checking is 638 performed and the SHARED_SECRET has a zero value, both parties MUST 639 behave as if the current EAP-AKA' authentication process starts again 640 from the beginning. 642 Note: The way that shared secret is tested for zero can, if 643 performed inappropriately, provide an ability for attackers to 644 listen to CPU power usage side channels. Refer to [RFC7748] for a 645 description of how to perform this check in a way that it does not 646 become a problem. 648 The rest of computation proceeds as defined in Section 3.3 of 649 [I-D.ietf-emu-rfc5448bis]. 651 For readability, an explanation of the notation used above is copied 652 here: [n..m] denotes the substring from bit n to m. PRF' is a new 653 pseudo-random function specified in [I-D.ietf-emu-rfc5448bis]. 654 K_encr is the encryption key, 128 bits, K_aut is the authentication 655 key, 256 bits, K_re is the re-authentication key, 256 bits, MSK is 656 the Master Session Key, 512 bits, and EMSK is the Extended Master 657 Session Key, 512 bits. MSK and EMSK are outputs from a successful 658 EAP method run [RFC3748]. 660 CK and IK are produced by the AKA algorithm. IK' and CK' are derived 661 as specified in [I-D.ietf-emu-rfc5448bis] from IK and CK. 663 The value "EAP-AKA'" is an eight-characters-long ASCII string. It is 664 used as is, without any trailing NUL characters. Similarly, "EAP- 665 AKA' PFS" is a twelve-characters-long ASCII string, also used as is. 667 Identity is the peer identity as specified in Section 7 of [RFC4187]. 669 6.4. ECDHE Groups 671 The selection of suitable groups for the elliptic curve computation 672 is necessary. The choice of a group is made at the same time as 673 deciding to use of particular key derivation function in AT_KDF_PFS. 675 For "EAP-AKA' with ECDHE and X25519" the group is the Curve25519 676 group specified in [RFC7748]. The support for this group is 677 REQUIRED. 679 For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group 680 (SEC group secp256r1), specified in [FIPS186-4]. The support for 681 this group is OPTIONAL. 683 6.5. Message Processing 685 This section specifies the changes related to message processing when 686 this extension is used in EAP-AKA'. It specifies when a message may 687 be transmitted or accepted, which attributes are allowed in a 688 message, which attributes are required in a message, and other 689 message-specific details, where those details are different for this 690 extension than the base EAP-AKA' or EAP-AKA protocol. Unless 691 otherwise specified here, the rules from [I-D.ietf-emu-rfc5448bis] or 692 [RFC4187] apply. 694 6.5.1. EAP-Request/AKA'-Identity 696 No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes 697 MUST NOT be added to this message. The appearance of these messages 698 in a received message MUST be ignored. 700 6.5.2. EAP-Response/AKA'-Identity 702 No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes 703 MUST NOT be added to this message. The appearance of these messages 704 in a received message MUST be ignored. 706 6.5.3. EAP-Request/AKA'-Challenge 708 The server sends the EAP-Request/AKA'-Challenge on full 709 authentication as specified by [RFC4187] and 710 [I-D.ietf-emu-rfc5448bis]. The attributes AT_RAND, AT_AUTN, and 711 AT_MAC MUST be included and checked on reception as specified in 712 [RFC4187]. They are also necessary for backwards compatibility. 714 In EAP-Request/AKA'-Challenge, there is no message-specific data 715 covered by the MAC for the AT_MAC attribute. The AT_KDF_PFS and 716 AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute 717 carries the server's public Diffie-Hellman key. If either AT_KDF_PFS 718 or AT_PUB_ECDHE is missing on reception, the peer MUST treat them as 719 if neither one was sent, and the assume that the extension defined in 720 this specification is not in use. 722 The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, 723 AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be 724 included as specified in Section 9.3 of [RFC4187]. 726 When processing this message, the peer MUST process AT_RAND, AT_AUTN, 727 AT_KDF_PFS, AT_PUB_ECDHE before processing other attributes. Only if 728 these attributes are verified to be valid, the peer derives keys and 729 verifies AT_MAC. If the peer is unable or unwilling to perform the 730 extension specified in this document, it proceeds as defined in 731 [I-D.ietf-emu-rfc5448bis]. Finally, the operation in case an error 732 occurs is specified in Section 6.3.1. of [RFC4187]. 734 6.5.4. EAP-Response/AKA'-Challenge 736 The peer sends EAP-Response/AKA'-Challenge in response to a valid 737 EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and 738 [I-D.ietf-emu-rfc5448bis]. If the peer supports and is willing to 739 perform the extension specified in this protocol, and the server had 740 made a valid request involving the attributes specified in 741 Section 6.5.3, the peer responds per the rules specified below. 742 Otherwise, the peer responds as specified in [RFC4187] and 743 [I-D.ietf-emu-rfc5448bis] and ignores the attributes related to this 744 extension. If the peer has not received attributes related to this 745 extension from the Server, and has a policy that requires it to 746 always use this extension, it behaves as if AUTN had been incorrect 747 and fails the authentication. 749 The AT_MAC attribute MUST be included and checked as specified in 750 [I-D.ietf-emu-rfc5448bis]. In EAP-Response/AKA'-Challenge, there is 751 no message-specific data covered by the MAC. The AT_PUB_ECDHE 752 attribute MUST be included, and carries the peer's public Diffie- 753 Hellman key. 755 The AT_RES attribute MUST be included and checked as specified in 756 [RFC4187]. When processing this message, the Server MUST process 757 AT_RES before processing other attributes. Only if these attribute 758 is verified to be valid, the Server derives keys and verifies AT_MAC. 760 If the Server has proposed the use of the extension specified in this 761 protocol, but the peer ignores and continues the basic EAP-AKA' 762 authentication, the Server makes policy decision of whether this is 763 allowed. If this is allowed, it continues the EAP-AKA' 764 authentication to completion. If it is not allowed, the Server MUST 765 behave as if authentication failed. 767 The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other 768 attributes may be included as specified in Section 9.4 of [RFC4187]. 770 6.5.5. EAP-Request/AKA'-Reauthentication 772 No changes, but note that the re-authentication process uses the keys 773 generated in the original EAP-AKA' authentication, which, if the 774 extension specified in this documents is in use, employs key material 775 from the Diffie-Hellman procedure. 777 6.5.6. EAP-Response/AKA'-Reauthentication 779 No changes, but as discussed in Section 6.5.5, re-authentication is 780 based on the key material generated by EAP-AKA' and the extension 781 defined in this document. 783 6.5.7. EAP-Response/AKA'-Synchronization-Failure 785 No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes 786 MUST NOT be added to this message. The appearance of these messages 787 in a received message MUST be ignored. 789 6.5.8. EAP-Response/AKA'-Authentication-Reject 791 No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes 792 MUST NOT be added to this message. The appearance of these messages 793 in a received message MUST be ignored. 795 6.5.9. EAP-Response/AKA'-Client-Error 797 No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes 798 MUST NOT be added to this message. The appearance of these messages 799 in a received message MUST be ignored. 801 6.5.10. EAP-Request/AKA'-Notification 803 No changes. 805 6.5.11. EAP-Response/AKA'-Notification 807 No changes. 809 7. Security Considerations 811 This section deals only with the changes to security considerations 812 as they differ from EAP-AKA', or as new information has been gathered 813 since the publication of [I-D.ietf-emu-rfc5448bis]. 815 The possibility of attacks against key storage offered in SIM or 816 other smart cards has been a known threat. But as the discussion in 817 Section 3.3 shows, the likelihood of practically feasible attacks has 818 increased. Many of these attacks can be best dealt with improved 819 processes, e.g., limiting the access to the key material within the 820 factory or personnel, etc. But not all attacks can be entirely ruled 821 out for well-resourced adversaries, irrespective of what the 822 technical algorithms and protection measures are. 824 This extension can provide assistance in situations where there is a 825 danger of attacks against the key material on SIM cards by 826 adversaries that can not or who are unwilling to mount active attacks 827 against large number of sessions. This extension is most useful when 828 used in a context where EAP keys are used without further mixing that 829 can provide Perfect Forward Secrecy. For instance, when used with 830 IKEv2 [RFC7296], the session keys produced by IKEv2 have this 831 property, so better characteristics of EAP keys is not that useful. 832 However, typical link layer usage of EAP does not involve running 833 Diffie-Hellman, so using EAP to authenticate access to a network is 834 one situation where the extension defined in this document can be 835 helpful. 837 This extension generates keying material using the ECDHE exchange in 838 order to gain the PFS property. This means that once an EAP-AKA' 839 authentication run ends, the session that it was used to protect is 840 closed, and the corresponding keys are forgotten, even someone who 841 has recorded all of the data from the authentication run and session 842 and gets access to all of the AKA long-term keys cannot reconstruct 843 the keys used to protect the session or any previous session, without 844 doing a brute force search of the session key space. 846 Even if a compromise of the long-term keys has occurred, PFS is still 847 provided for all future sessions, as long as the attacker does not 848 become an active attacker. Of course, as with other protocols, if 849 the attacker has learned the keys and does become an active attacker, 850 there is no protection that that can be provided for future sessions. 851 Among other things, such an active attacker can impersonate any 852 legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the 853 extension defined in this document, retrieve all keys, or turn off 854 PFS. Still, past sessions where PFS was in use remain protected. 856 Achieving PFS requires that when a connection is closed, each 857 endpoint MUST forget not only the ephemeral keys used by the 858 connection but also any information that could be used to recompute 859 those keys. 861 The following security properties of EAP-AKA' are impacted through 862 this extension: 864 Protected ciphersuite negotiation 866 EAP-AKA' has a negotiation mechanism for selecting the key 867 derivation functions, and this mechanism has been extended by the 868 extension specified in this document. The resulting mechanism 869 continues to be secure against bidding down attacks. 871 There are two specific needs in the negotiation mechanism: 873 Negotiating key derivation function within the extension 875 The negotiation mechanism allows changing the offered key 876 derivation function, but the change is visible in the final 877 EAP- Request/AKA'-Challenge message that the server sends to 878 the peer. This message is authenticated via the AT_MAC 879 attribute, and carries both the chosen alternative and the 880 initially offered list. The peer refuses to accept a change it 881 did not initiate. As a result, both parties are aware that a 882 change is being made and what the original offer was. 884 Negotiating the use of this extension 886 This extension is offered by the server through presenting the 887 AT_KDF_PFS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'- 888 Challenge message. These attributes are protected by AT_MAC, 889 so attempts to change or omit them by an adversary will be 890 detected. 892 Except of course, if the adversary holds the long-term shared 893 secret and is willing to engage in an active attack. Such an 894 attack can, for instance, forge the negotiation process so that 895 no PFS will be provided. However, as noted above, an attacker 896 with these capabilities will in any case be able to impersonate 897 any party in the protocol and perform MITM attacks. That is 898 not a situation that can be improved by a technical solution. 899 However, as discussed in the introduction, even an attacker 900 with access to the long-term keys is required to be a MITM on 901 each AKA run and subsequent communication, which makes mass 902 surveillance more laborous. 904 The security properties of the extension also depend on a 905 policy choice. As discussed in Section 6.5.4, both the peer 906 and the server make a policy decision of what to do when it was 907 willing to peform the extension specified in this protocol, but 908 the other side does not wish to use the extension. Allowing 909 this has the benefit of allowing backwards compatibility to 910 equipment that did not yet support the extension. When the 911 extension is not supported or negotiated by the parties, no PFS 912 can obviously provided. 914 If turning off the extension specified in this protocol is not 915 allowed by policy, the use of legacy equipment that does not 916 support this protocol is no longer possible. This may be 917 appropriate when, for instance, support for the extension is 918 sufficiently widespread, or required in a particular version of 919 a mobile network. 921 Key derivation 923 This extension provides key material that is based on the Diffie- 924 Hellman keys, yet bound to the authentication through the SIM 925 card. This means that subsequent payload communications between 926 the parties are protected with keys that are not solely based on 927 information in the clear (such as the RAND) and information 928 derivable from the long-term shared secrets on the SIM card. As a 929 result, if anyone successfully recovers shared secret information, 930 they are unable to decrypt communications protected by the keys 931 generated through this extension. Note that the recovery of 932 shared secret information could occur either before or after the 933 time that the protected communications are used. When this 934 extension is used, communications at time t0 can be protected if 935 at some later time t1 an adversary learns of long-term shared 936 secret and has access to a recording of the encrypted 937 communications. 939 Obviously, this extension is still vulnerable to attackers that 940 are willing to perform an active attack and who at the time of the 941 attack have access to the long-term shared secret. 943 This extension does not change the properties related to re- 944 authentication. No new Diffie-Hellman run is performed during the 945 re-authentication allowed by EAP-AKA'. However, if this extension 946 was in use when the original EAP-AKA' authentication was 947 performed, the keys used for re-authentication (K_re) are based on 948 the Diffie-Hellman keys, and hence continue to be equally safe 949 against expose of the long-term secrets as the original 950 authentication. 952 In addition, it is worthwhile to discuss Denial-of-Service attacks 953 and their impact on this protocol. The calculations involved in 954 public key cryptography require computing power, which could be used 955 in an attack to overpower either the peer or the server. While some 956 forms of Denial-of-Service attacks are always possible, the following 957 factors help mitigate the concerns relating to public key 958 cryptography and EAP-AKA' PFS. 960 o In 5G context, other parts of the connection setup involve public 961 key cryptography, so while performing additional operations in 962 EAP-AKA' is an additional concern, it does not change the overall 963 situation. As a result, the relevant system components need to be 964 dimensioned appropriately, and detection and management mechanisms 965 to reduce the effect of attacks need to be in place. 967 o This specification is constructed so that a separation between the 968 USIM and Peer on client side and the Server and HSS on network 969 side is possible. This ensures that the most sensitive (or 970 legacy) system components can not be the target of the attack. 971 For instance, EAP-AKA' and public key cryptography takes place in 972 the phone and not the low-power SIM card. 974 o EAP-AKA' has been designed so that the first actual message in the 975 authentication process comes from the Server, and that this 976 message will not be sent unless the user has been identified as an 977 active subscriber of the operator in question. While the initial 978 identity can be spoofed before authentication has succeeded, this 979 reduces the efficiency of an attack. 981 o Finally, this memo specifies an order in which computations and 982 checks must occur. When processing the EAP-Request/AKA'-Challenge 983 message, for instance, the AKA authentication must be checked and 984 succeed before the peer proceeds to calculating or processing the 985 PFS related parameters (see Section 6.5.4). The same is true of 986 EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures 987 that the parties need to show possession of the long-term secret 988 in some way, and only then will the PFS calculations become 989 active. This limits the Denial-of-Service to specific, identified 990 subscribers. While botnets and other forms of malicious parties 991 could take advantage of actual subscribers and their key material, 992 at least such attacks are (a) limited in terms of subscribers they 993 control, and (b) identifiable for the purposes of blocking the 994 affected subscribers. 996 8. IANA Considerations 998 This extension of EAP-AKA' shares its attribute space and subtypes 999 with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' 1000 [I-D.ietf-emu-rfc5448bis]. 1002 Two new Attribute Type value (TBA1, TBA2) in the skippable range need 1003 to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_PFS 1004 (Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under 1005 Attribute Types. 1007 Also, a new registry should be created to represent Diffie-Hellman 1008 Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519" 1009 and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see Section 6.3) 1010 need to be assigned, along with one reserved value. The initial 1011 contents of this namespace are therefore as below; new values can be 1012 created through the Specification Required policy [RFC8126]. 1014 Value Description Reference 1015 ------ ------------------------------------ --------------- 1016 0 Reserved [TBD BY IANA: THIS RFC] 1017 1 EAP-AKA' with ECDHE and X25519 [TBD BY IANA: THIS RFC] 1018 2 EAP-AKA' with ECDHE and P-256 [TBD BY IANA: THIS RFC] 1019 3-65535 Unassigned [TBD BY IANA: THIS RFC] 1021 9. References 1023 9.1. Normative References 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, 1027 DOI 10.17487/RFC2119, March 1997, . 1030 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1031 Levkowetz, Ed., "Extensible Authentication Protocol 1032 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1033 . 1035 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 1036 Protocol Method for 3rd Generation Authentication and Key 1037 Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, 1038 January 2006, . 1040 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1041 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1042 2016, . 1044 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1045 Writing an IANA Considerations Section in RFCs", BCP 26, 1046 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1047 . 1049 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1050 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1051 May 2017, . 1053 [I-D.ietf-emu-rfc5448bis] 1054 Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen, 1055 "Improved Extensible Authentication Protocol Method for 1056 3GPP Mobile Network Authentication and Key Agreement (EAP- 1057 AKA')", draft-ietf-emu-rfc5448bis-07 (work in progress), 1058 March 2020. 1060 [FIPS186-4] 1061 NIST, , "Digital Signature Standard (DSS)", July 2013. 1063 [SEC2] Certicom Research, , "SEC 2: Recommended Elliptic Curve 1064 Domain Parameters", September 2000. 1066 9.2. Informative References 1068 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 1069 Authentication Protocol Method for Global System for 1070 Mobile Communications (GSM) Subscriber Identity Modules 1071 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 1072 . 1074 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1075 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1076 March 2008, . 1078 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1079 Extensible Authentication Protocol Method for 3rd 1080 Generation Authentication and Key Agreement (EAP-AKA')", 1081 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1082 . 1084 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1085 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1086 2014, . 1088 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1089 Kivinen, "Internet Key Exchange Protocol Version 2 1090 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1091 2014, . 1093 [I-D.ietf-emu-eap-tls13] 1094 Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", 1095 draft-ietf-emu-eap-tls13-11 (work in progress), October 1096 2020. 1098 [TrustCom2015] 1099 Arkko, J., Norrman, K., Naslund, M., and B. Sahlin, "A 1100 USIM compatible 5G AKA protocol with perfect forward 1101 secrecy", August 2015 in Proceedings of the TrustCom 2015, 1102 IEEE. 1104 [Heist2015] 1105 Scahill, J. and J. Begley, "The great SIM heist", February 1106 2015, in https://firstlook.org/theintercept/2015/02/19/ 1107 great-sim-heist/ . 1109 [DOW1992] Diffie, W., vanOorschot, P., and M. Wiener, 1110 "Authentication and Authenticated Key Exchanges", June 1111 1992, in Designs, Codes and Cryptography 2 (2): pp. 1112 107-125. 1114 Appendix A. Change Log 1116 The -05 version of the WG draft takes into account feedback from the 1117 working group list, about the number of bytes needed to encode P-256 1118 values. 1120 The -04 version of the WG draft takes into account feedback from the 1121 May 2020 WG interim meeting, correcting the reference to the NIST 1122 P-256 specification. 1124 The -03 version of the WG draft is first of all a refresh; there are 1125 no issues that we think need addressing, beyond the one for which 1126 there is a suggestion in -03: The specification now suggests an 1127 alternate group/curve as an optional one besides X25519. The 1128 specific choice of particular groups and algorithms is still up to 1129 the working group. 1131 The -02 version of the WG draft took into account additional reviews, 1132 and changed the document to update RFC 5448 (or rather, its 1133 successor, [I-D.ietf-emu-rfc5448bis]), changed the wording of the 1134 recommendation with regards to the use of this extension, clarified 1135 the references to the definition of X25519 and Curve25519, clarified 1136 the distinction to ECDH methods that use partially static keys, and 1137 simplified the use of AKA and SIM card terminology. Some editorial 1138 changes were also made. 1140 The -00 and -01 versions of the WG draft made no major changes, only 1141 updates to some references. 1143 The -05 version is merely a refresh while the draft was waiting for 1144 WG adoption. 1146 The -04 version of this draft made only editorial changes. 1148 The -03 version of this draft changed the naming of various protocol 1149 components, values, and notation to match with the use of ECDH in 1150 ephemeral mode. The AT_KDF_PFS negotiation process was clarified in 1151 that exactly one key is ever sent in AT_KDF_ECDHE. The option of 1152 checking for zero key values IN ECDHE was added. The format of the 1153 actual key in AT_PUB_ECDHE was specified. Denial-of-service 1154 considerations for the PFS process have been updated. Bidding down 1155 attacks against this extension itself are discussed extensively. 1156 This version also addressed comments from reviewers, including the 1157 August review from Mohit Sethi, and comments made during IETF-102 1158 discussion. 1160 Appendix B. Acknowledgments 1162 The authors would like to note that the technical solution in this 1163 document came out of the TrustCom paper [TrustCom2015], whose authors 1164 were J. Arkko, K. Norrman, M. Naslund, and B. Sahlin. This 1165 document uses also a lot of material from [RFC4187] by J. Arkko and 1166 H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and 1167 P. Eronen. 1169 The authors would also like to thank Tero Kivinen, John Mattsson, 1170 Mohit Sethi, Vesa Lehtovirta, Russ Housley, Sean Turner, Eliot Lear, 1171 Joseph Salowey, Kathleen Moriarty, Zhang Fu, Bengt Sahlin, Ben 1172 Campbell, Prajwol Kumar Nakarmi, Goran Rune, Tim Evans, Helena Vahidi 1173 Mazinani, Anand R. Prasad, Rene Struik, and many other people at the 1174 IETF, GSMA and 3GPP groups for interesting discussions in this 1175 problem space. 1177 Authors' Addresses 1179 Jari Arkko 1180 Ericsson 1181 Jorvas 02420 1182 Finland 1184 Email: jari.arkko@piuha.net 1186 Karl Norrman 1187 Ericsson 1188 Stockholm 16483 1189 Sweden 1191 Email: karl.norrman@ericsson.com 1193 Vesa Torvinen 1194 Ericsson 1195 Jorvas 02420 1196 Finland 1198 Email: vesa.torvinen@ericsson.com