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