]> Ericsson

Jorvas 02420 Finland jari.arkko@piuha.net

Ericsson

Stockholm 16483 Sweden karl.norrman@ericsson.com

Ericsson

Jorvas 02420 Finland vesa.torvinen@ericsson.com

Ericsson

Kista 164 40 Sweden john.mattsson@ericsson.com

EAP AKA AKA' 3GPP Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication method, with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.

Introduction Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Such attacks are conceivable, for instance, during the manufacturing process of cards, or during the transfer of cards and associated information to the operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern. They are a high-value target and concern a large number of people. Note that the attacks are largely independent of the used authentication technology; the issue is not vulnerabilities in algorithms or protocols, but rather the possibility of someone gaining unlawful access to key material. While the better protection of manufacturing and other processes is essential in protecting against this, there is one question that we as protocol designers can ask. Is there something that we can do to limit the consequences of attacks, should they occur? The authors want to provide a public specification of an extension that helps defend against one aspect of pervasive surveillance. This is important, given the large number of users such practices may affect. It is also a stated goal of the IETF to ensure that we understand the surveillance concerns related to IETF protocols and take appropriate countermeasures . This document does that for EAP-AKA'. This specification updates , the EAP-AKA' authentication method, with an optional extension. While optional, the use of this extension is strongly RECOMMENDED. The extension, when negotiated, provides Forward Secrecy (FS) for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. This is beneficial, because active attacks demand much more resources to launch, and can generally be detected much easier. As with other protocols, an active attacker with access to the long-term key material will of course be able to attack all future communications, but risks detection, particularly if done at scale. The attacker is forced to attempt to exfiltrate key material, if it can, on a continuous basis, as opposed to learning it once . Attacks against AKA authentication via compromising the long-term secrets in the SIM cards have been an active discussion topic in many contexts. Forward secrecy is on the list of features for the next release of 3GPP (5G Phase 2), and this document provides a basis for providing this feature in a particular fashion. It should also be noted that 5G network architecture includes the use of the EAP framework for authentication. While any methods can be run, the default authentication method within that context will be EAP-AKA'. As a result, improvements in EAP-AKA' security have a potential to improve security for large number of users.

Protocol Design and Deployment Objectives The extension specified here re-uses large portions of the current structure of 3GPP interfaces and functions, with the rationale that this will make the construction more easily adopted. In particular, the construction maintains the interface between the Universal Subscriber Identification Module (USIM) and the mobile terminal intact. As a consequence, there is no need to roll out new credentials to existing subscribers. The work is based on an earlier paper , and uses much of the same material, but applied to EAP rather than the underlying AKA method. It has been a goal to implement this change as an extension of the widely supported EAP-AKA' method, rather than a completely new authentication method. The extension is implemented as a set of new, optional attributes, that are provided alongside the base attributes in EAP-AKA'. Old implementations can ignore these attributes, but their presence will nevertheless be verified as part of base EAP-AKA' integrity verification process, helping protect against bidding down attacks. This extension does not increase the number of rounds necessary to complete the protocol. The use of this extension is at the discretion of the authenticating parties. It should be noted that FS and defenses against passive attacks are by no means a panacea, but they can provide a partial defense that increases the cost and risk associated with pervasive surveillance. While adding forward secrecy to the existing mobile network infrastructure can be done in multiple different ways, the authors believe that the approach chosen here is relatively easily deployable. In particular:

• As noted above, no new credentials are needed; there is no change to SIM cards.
• FS property can be incorporated into any current or future system that supports EAP, without changing any network functions beyond the EAP endpoints.
• Key generation happens at the endpoints, enabling highest grade key material to be used both by the endpoints and the intermediate systems (such as access points that are given access to specific keys).
• While EAP-AKA' is just one EAP method, for practical purposes forward secrecy being available for both EAP-TLS and EAP-AKA' ensures that for many practical systems forward secrecy can be enabled for either all or significant fraction of users.

Background

AKA Authentication and Key Agreement (AKA) is based on challenge-response mechanisms and symmetric cryptography. In contrast with its earlier GSM counterparts, AKA provides long key lengths and mutual authentication. AKA typically runs in a UMTS Subscriber Identity Module (USIM). USIM is technically just an application that can reside on a removable UICC, an embedded UICC, or integrated in a Trusted Execution Environment (TEE). In this document we use the term "SIM card" to refer to any Subscriber Identity Module capable of running AKA. AKA works in the following manner:

• The identity module and the home environment have agreed on a secret key beforehand.
• The actual authentication process starts by having the home environment produce an authentication vector, based on the secret key and a sequence number. The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the identity module, an expected result part XRES, a 128-bit session key for integrity check IK, and a 128-bit session key for encryption CK.
• The authentication vector is passed to the serving network, which uses it to authenticate the device.
• The RAND and the AUTN are delivered to the identity module.
• The identity module verifies the AUTN, again based on the secret key and the sequence number. If this process is successful (the AUTN is valid and the sequence number used to generate AUTN is within the correct range), the identity module produces an authentication result RES and sends it to the serving network.
• The serving network verifies the correct result from the identity module. If the result is correct, IK and CK can be used to protect further communications between the identity module and the home environment.

EAP-AKA' Protocol When AKA are embedded into EAP, the authentication on the network side is moved to the home environment; the serving network performs the role of a pass-through authenticator. describes the basic flow in the EAP-AKA' authentication process. The definition of the full protocol behaviour, along with the definition of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in and .

EAP-AKA' Authentication Process | | +--------------------------------------------------------+ | | Server determines the network name and ensures that | | | the given access network is authorized to use the | | | claimed name. The server then runs the AKA' algorithms | | | generating RAND and AUTN, derives session keys from | | | CK' and IK'. RAND and AUTN are sent as AT_RAND and | | | AT_AUTN attributes, whereas the network name is | | | transported in the AT_KDF_INPUT attribute. AT_KDF | | | signals the used key derivation function. The session | | | keys are used in creating the AT_MAC attribute. | | +--------------------------------------------------------+ | | | EAP-Request/AKA'-Challenge | | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) | |<-----------------------------------------------------------| +--------------------------------------------------------+ | | The peer determines what the network name should be, | | | based on, e.g., what access technology it is using. | | | The peer also retrieves the network name sent by the | | | network from the AT_KDF_INPUT attribute. The two names | | | are compared for discrepancies, and if necessary, the | | | authentication is aborted. Otherwise, the network name | | | from AT_KDF_INPUT attribute is used in running the | | | AKA' algorithms, verifying AUTN from AT_AUTN and MAC | | | from AT_MAC attributes. The peer then generates RES. | | | The peer also derives session keys from CK'/IK'. The | | | AT_RES and AT_MAC attributes are constructed. | | +--------------------------------------------------------+ | | | | EAP-Response/AKA'-Challenge | | (AT_RES, AT_MAC) | |----------------------------------------------------------->| | +--------------------------------------------------------+ | | Server checks the RES and MAC values received in | | | AT_RES and AT_MAC, respectively. Success requires both | | | to be found correct. | | +--------------------------------------------------------+ | | | EAP-Success | |<-----------------------------------------------------------| ]]>

Attacks Against Long-Term Shared Secrets in Smart Cards Current 3GPP systems use SIM pre-shared key based protocols and Authentication and Key Agreement (AKA) to authenticate subscribers. The general security properties and potential vulnerabilities of AKA and EAP-AKA' are discussed in . An important vulnerability in that discussion relates to the recent reports of compromised long term pre-shared keys used in AKA . These attacks are not specific to AKA or EAP-AKA', as all security systems fail at least to some extent if key material is stolen. However, the reports indicate a need to look into solutions that can operate at least to an extent under these types of attacks. It is noted in that some security can be retained even in the face of the attacks by providing Forward Secrecy (FS) for the session key. If AKA would have provided FS, compromising the pre-shared key would not be sufficient to perform passive attacks; the attacker is, in addition, forced to be a Man-In-The-Middle (MITM) during the AKA run and subsequent communication between the parties.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol Overview Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange . To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate temporary keys according to the negotiated ciphersuite, e.g., for X25519 this is done as specified in . This method is referred to as ECDHE, where the last 'E' stands for Ephemeral. The two initially registered elliptic curves and their wire format is chosen to align with the elliptic curves and formats specified for Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS 33.501 . The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The intent is to implement the enhancement as optional attributes that legacy implementations can ignore. The purpose of the protocol is to achieve mutual authentication between the EAP server and peer, and to establish keying material for secure communication between the two. This document specifies the calculation of key material, providing new properties that are not present in key material provided by EAP-AKA' in its original form. below describes the overall process. Since our goal has been to not require new infrastructure or credentials, the flow diagrams also show the conceptual interaction with the USIM card and the 3GPP authentication server (HSS). The details of those interactions are outside the scope of this document, however, and the reader is referred to the 3GPP specifications.

EAP-AKA' FS Authentication Process | | | +--------------------------------------------------------+ | | Server now has an identity for the peer. The server | | | then asks the help of HSS to run AKA algorithms, | | | generating RAND, AUTN, XRES, CK, IK. Typically, the | | | HSS performs the first part of key derivations so that | | | the authentication server gets the CK' and IK' keys | | | already tied to a particular network name. | | +--------------------------------------------------------+ | | | | | | | ID, key deriv. | | | | function, | | | | network name | | | |--------------->| | | | | | | | RAND, AUTN, | | | | XRES, CK', IK' | | | |<---------------| | +--------------------------------------------------------+ | | Server now has the needed authentication vector. It | | | generates an ephemeral key pair, sends the public key | | | of that key pair and the first EAP method message to | | | the peer. In the message the AT_PUB_ECDHE attribute | | | carries the public key and the AT_KDF_FS attribute | | | carries other FS-related parameters. Both of these are | | | skippable attributes that can be ignored if the peer | | | does not support this extension. | | +--------------------------------------------------------+ | | | | | | EAP-Req/AKA'-Challenge | | | | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_PUB_ECDHE, AT_MAC | | | |<---------------------------| | +--------------------------------------------------------+ | | The peer checks if it wants to do the FS extension. If | | | yes, it will eventually respond with AT_PUB_ECDHE and | | | AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | | AT_KDF_FS and base all calculations on basic EAP-AKA' | | | attributes, continuing just as in EAP-AKA' per RFC | | | 9048 rules. In any case, the peer needs to query the | | | auth parameters from the USIM card. | | +--------------------------------------------------------+ | | | | | | RAND, AUTN | | | |<-------------| | | | | | | | CK, IK, RES | | | |------------->| | | +--------------------------------------------------------+ | | The peer now has everything to respond. If it wants to | | | participate in the FS extension, it will then generate | | | its key pair, calculate a shared key based on its key | | | pair and the server's public key. Finally, it proceeds | | | to derive all EAP-AKA' key values and constructs a | | | full response. | | +--------------------------------------------------------+ | | | | | | | EAP-Resp/AKA'-Challenge | | | | AT_RES, AT_PUB_ECDHE, | | | | AT_MAC | | | |--------------------------->| | | +--------------------------------------------------------+ | | The server now has all the necessary values. It | | | generates the ECDHE shared secret and checks the RES | | | and MAC values received in AT_RES and AT_MAC, | | | respectively. Success requires both to be found | | | correct. Note that when this specification is used, | | | the keys generated from EAP-AKA' are based on both | | | CK/IK as well as the ECDHE value. Even if there was an | | | attacker who held the long-term secret keys, only an | | | active attacker could have determined the generated | | | session keys; in basic EAP-AKA' the keys are only | | | based on CK and IK. | | +--------------------------------------------------------+ | | | | | | EAP-Success | | | |<---------------------------| | ]]>

Extensions to EAP-AKA'

AT_PUB_ECDHE The AT_PUB_ECDHE carries an ECDHE value. The format of the AT_PUB_ECDHE attribute is shown below. The fields are as follows:

AT_PUB_ECDHE

This is set to TBA1 BY IANA.

Length

The length of the attribute, set as other attributes in EAP-AKA .

Value

This value is the sender's ECDHE public key. The value depends on AT_KDF_FS and is calculated as follows:

• For X25519/Curve25519, the length of this value is 32 bytes, encoded as specified in Section 5.
• For P-256, the length of this value is 33 bytes, encoded using the compressed form specified in Section 2.3.3 of .

To retain the security of the keys, the sender SHALL generate a fresh value for each run of the protocol.

AT_KDF_FS The AT_KDF_FS indicates the used or desired forward secrecy key generation function, if the Forward Secrecy extension is taken into use. It will also at the same time indicate the used or desired ECDHE group. A new attribute is needed to carry this information, as AT_KDF carries the basic KDF value which is still used together with the forward secrecy KDF value. The basic KDF value is also used by those EAP peers that cannot or do not want to use this extension. This specification only specifies the behaviour relating to the following combinations of basic KDF values and forward secrecy KDF values: The basic KDF value in AT_KDF is 1, as specified in and , and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified below and in . Any future specifications that add either new basic KDF or new forward secrecy KDF values need to specify how they are treated and what combinations are allowed. This requirement is an update to how and may be extended in the future. The format of the AT_KDF_FS attribute is shown below. The fields are as follows:

AT_KDF_FS

This is set to TBA2 BY IANA.

Length

The length of the attribute, MUST be set to 1.

FS Key Derivation Function

An enumerated value representing the forward secrecy key derivation function that the server (or peer) wishes to use. See for the functions specified in this document. Note: This field has a different name space than the similar field in the AT_KDF attribute Key Derivation Function defined in .

Servers MUST send one or more AT_KDF_FS attributes in the EAP-Request/AKA'-Challenge message. These attributes represent the desired functions ordered by preference, the most preferred function being the first attribute. The most preferred function is the only one that the server includes a public key value for, however. So for a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE attribute. Upon receiving a set of these attributes:

• If the peer supports and is willing to use the FS Key Derivation Function indicated by the first AT_KDF_FS attribute, and is willing and able to use the extension defined in this specification, the function is taken into use without any further negotiation.
• If the peer does not support this function or is unwilling to use it, it responds to the server with an indication that a different function is needed. Similarly with the negotiation process defined in for AT_KDF, the peer sends EAP-Response/AKA'-Challenge message that contains only one attribute, AT_KDF_FS with the value set to the desired alternative function from among the ones suggested by the server earlier. If there is no suitable alternative, the peer has a choice of either falling back to EAP-AKA' or behaving as if AUTN had been incorrect and failing authentication (see Figure 3 of ). The peer MUST fail the authentication if there are any duplicate values within the list of AT_KDF_FS attributes (except where the duplication is due to a request to change the key derivation function; see below for further information).
• If the peer does not recognize the extension defined in this specification or is unwilling to use it, it ignores the AT_KDF_FS attribute.

Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from the peer, the server checks that the suggested AT_KDF_FS value was one of the alternatives in its offer. The first AT_KDF_FS value in the message from the server is not a valid alternative. If the peer has replied with the first AT_KDF_FS value, the server behaves as if AT_MAC of the response had been incorrect and fails the authentication. For an overview of the failed authentication process in the server side, see Section 3 and Figure 2 in . Otherwise, the server re-sends the EAP-Response/AKA'-Challenge message, but adds the selected alternative to the beginning of the list of AT_KDF_FS attributes, and retains the entire list following it. Note that this means that the selected alternative appears twice in the set of AT_KDF values. Responding to the peer's request to change the FS Key Derivation Function is the only legal situation where such duplication may occur. When the peer receives the new EAP-Request/AKA'-Challenge message, it MUST check that the requested change, and only the requested change occurred in the list of AT_KDF_FS attributes. If yes, it continues. If not, it behaves as if AT_MAC had been incorrect and fails the authentication. If the peer receives multiple EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS attributes without having requested negotiation, the peer MUST behave as if AT_MAC had been incorrect and fail the authentication.

Forward Secrecy Key Derivation Functions Two new FS Key Derivation Function types are defined for "EAP-AKA' with ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256", represented by value 2. These represent a particular choice of key derivation function and at the same time selects an ECDHE group to be used. The FS Key Derivation Function type value is only used in the AT_KDF_FS attribute. When the forward secrecy extension is used, the AT_KDF_FS attribute determines how to derive the keys MK_ECDHE, K_re, MSK, and EMSK. The AT_KDF_FS attribute should not be confused with the different range of key derivation functions that can be represented in the AT_KDF attribute as defined in . When the forward secrecy extension is used, the AT_KDF attribute only specifies how to derive the keys MK, K_encr, and K_aut. Key derivation in this extension produces exactly the same keys for internal use within one authentication run as EAP-AKA' does. For instance, K_aut that is used in AT_MAC is still exactly as it was in EAP-AKA'. The only change to key derivation is in re-authentication keys and keys exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be usable even when this extension is in use. When the FS Key Derivation Function field in the AT_KDF_FS attribute is set to 1 or 2 and the Key Derivation Function field in the AT_KDF attribute is set to 1, the Master Key (MK) is derived as follows below. Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve. For P-256 the SHARED_SECRET is the shared secret computed as specified in Section 5.7.1.2 of . Public key validation requirements are defined in Section 5 of . At least partial public-key validation MUST be done. For X25519 the SHARED_SECRET is the shared secret computed as specified in Section 6.1 of . Both the peer and the server MAY check for zero-value shared secret as specified in Section 6.1 of .

• Note: The way that shared secret is tested for zero can, if performed inappropriately, provide an ability for attackers to listen to CPU power usage side channels. Refer to for a description of how to perform this check in a way that it does not become a problem.

If validation of the public key or the shared secret fails, both parties MUST behave as if the current EAP-AKA' authentication process starts again from the beginning. The rest of computation proceeds as defined in Section 3.3 of . For readability, an explanation of the notation used above is copied here: [n..m] denotes the substring from bit n to m. PRF' is a new pseudo-random function specified in . K_encr is the encryption key, 128 bits, K_aut is the authentication key, 256 bits, K_re is the re-authentication key, 256 bits, MSK is the Master Session Key, 512 bits, and EMSK is the Extended Master Session Key, 512 bits. MSK and EMSK are outputs from a successful EAP method run . CK and IK are produced by the AKA algorithm. IK' and CK' are derived as specified in from IK and CK. The value "EAP-AKA'" is an eight-characters-long ASCII string. It is used as is, without any trailing NUL characters. Similarly, "EAP-AKA' FS" is an eleven-characters-long ASCII string, also used as is. Identity is the peer identity as specified in Section 7 of . A privacy-friendly identifier SHALL be used.

ECDHE Groups The selection of suitable groups for the elliptic curve computation is necessary. The choice of a group is made at the same time as deciding to use of particular key derivation function in AT_KDF_FS. For "EAP-AKA' with ECDHE and X25519" the group is the Curve25519 group specified in . The support for this group is REQUIRED. For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group (SEC group secp256r1), specified in Appendix D.1.2.3 of or alternatively Section 2.4.2 of . The support for this group is REQUIRED.

Message Processing This section specifies the changes related to message processing when this extension is used in EAP-AKA'. It specifies when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details, where those details are different for this extension than the base EAP-AKA' or EAP-AKA protocol. Unless otherwise specified here, the rules from or apply.

EAP-Request/AKA'-Identity No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these messages in a received message MUST be ignored.

EAP-Response/AKA'-Identity No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message and that a privacy-friendly identifier MUST be used. The appearance of these messages in a received message MUST be ignored.

EAP-Request/AKA'-Challenge The server sends the EAP-Request/AKA'-Challenge on full authentication as specified by and . The attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked on reception as specified in . They are also necessary for backwards compatibility. In EAP-Request/AKA'-Challenge, there is no message-specific data covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute carries the server's public Diffie-Hellman key. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception, the peer MUST treat them as if neither one was sent, and the assume that the extension defined in this specification is not in use. The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be included as specified in Section 9.3 of . When processing this message, the peer MUST process AT_RAND, AT_AUTN, AT_KDF_FS, AT_PUB_ECDHE before processing other attributes. Only if these attributes are verified to be valid, the peer derives keys and verifies AT_MAC. If the peer is unable or unwilling to perform the extension specified in this document, it proceeds as defined in . Finally, the operation in case an error occurs is specified in Section 6.3.1. of .

EAP-Response/AKA'-Challenge The peer sends EAP-Response/AKA'-Challenge in response to a valid EAP-Request/AKA'-Challenge message, as specified by and . If the peer supports and is willing to perform the extension specified in this protocol, and the server had made a valid request involving the attributes specified in , the peer responds per the rules specified below. Otherwise, the peer responds as specified in and and ignores the attributes related to this extension. If the peer has not received attributes related to this extension from the Server, and has a policy that requires it to always use this extension, it behaves as if AUTN had been incorrect and fails the authentication. The AT_MAC attribute MUST be included and checked as specified in . In EAP-Response/AKA'-Challenge, there is no message-specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be included, and carries the peer's public Diffie-Hellman key. The AT_RES attribute MUST be included and checked as specified in . When processing this message, the Server MUST process AT_RES before processing other attributes. Only if these attribute is verified to be valid, the Server derives keys and verifies AT_MAC. If the Server has proposed the use of the extension specified in this protocol, but the peer ignores and continues the basic EAP-AKA' authentication, the Server makes policy decision of whether this is allowed. If this is allowed, it continues the EAP-AKA' authentication to completion. If it is not allowed, the Server MUST behave as if authentication failed. The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other attributes may be included as specified in Section 9.4 of .

EAP-Request/AKA'-Reauthentication No changes, but note that the re-authentication process uses the keys generated in the original EAP-AKA' authentication, which, if the extension specified in this document is in use, employs key material from the Diffie-Hellman procedure.

EAP-Response/AKA'-Reauthentication No changes, but as discussed in , re-authentication is based on the key material generated by EAP-AKA' and the extension defined in this document.

EAP-Response/AKA'-Synchronization-Failure No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these messages in a received message MUST be ignored.

EAP-Response/AKA'-Authentication-Reject No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these messages in a received message MUST be ignored.

EAP-Response/AKA'-Client-Error No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these messages in a received message MUST be ignored.

EAP-Request/AKA'-Notification No changes.

EAP-Response/AKA'-Notification No changes.

Security Considerations This section deals only with the changes to security considerations as they differ from EAP-AKA', or as new information has been gathered since the publication of . The possibility of attacks against key storage offered in SIM or other smart cards has been a known threat. But as the discussion in shows, the likelihood of practically feasible attacks such as breaches in the smart card supply chain has increased. Many of these attacks can be best dealt with improved processes, e.g., limiting the access to the key material within the factory or personnel, etc. But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is used the effects of key compromise are devastating. The serious consequences of breach somewhere in the supply chain or after delivery that are possible when 5G-AKA or EAP-AKA' is used but not when something with forward secrecy like EAP-AKA-FS is used are:

1. A passive attacker can eavesdrop (decrypt) all future 5G communication (control and user plane both directions),
2. A passive attacker can decrypt 5G communication that they previously recorded in the past (control and user plane both directions), and
3. An active attacker can impersonate UE and Network and inject messages in an ongoing 5G connection between the real UE and the real network (control and user plane both directions).

Best practice security today is to mandate forward secrecy (as is done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard, Signal, etc.). It is RECOMMENDED to long term completely phase out AKA without forward secrecy. This extension can provide assistance in situations where there is a danger of attacks against the key material on SIM cards by adversaries that cannot or who are unwilling to mount active attacks against large number of sessions. The extension also provides protection against active attacks as they are forced to be a Man-In-The-Middle (MITM) during the AKA run and subsequent communication between the parties. Without forward secrecy an active attacker that has compromised the long-term key can inject messages in an connection between the real Peer and the real server without being a man-in-the-middle. This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy. For instance, when used with IKEv2 , the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful. However, typical link layer usage of EAP does not involve running Diffie-Hellman, so using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful. This extension generates keying material using the ECDHE exchange in order to gain the FS property. This means that once an EAP-AKA' authentication run ends, the session that it was used to protect is closed, and the corresponding keys are forgotten, even someone who has recorded all of the data from the authentication run and session and gets access to all of the AKA long-term keys cannot reconstruct the keys used to protect the session or any previous session, without doing a brute force search of the session key space. Even if a compromise of the long-term keys has occurred, FS is still provided for all future sessions, as long as the attacker does not become an active attacker. Of course, as with other protocols, if the attacker has learned the keys and does become an active attacker, there is no protection that that can be provided for future sessions. Among other things, such an active attacker can impersonate any legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the extension defined in this document, retrieve all keys, or turn off FS. Still, past sessions where FS was in use remain protected. Achieving FS requires that when a connection is closed, each endpoint MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys. Using EAP-AKA' FS once provides forward secrecy. Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequently. If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in , forward secrecy without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration).

Security Properties The following security properties of EAP-AKA' are impacted through this extension:

Protected ciphersuite negotiation

EAP-AKA' has a negotiation mechanism for selecting the key derivation functions, and this mechanism has been extended by the extension specified in this document. The resulting mechanism continues to be secure against bidding down attacks. There are two specific needs in the negotiation mechanism:

Negotiating key derivation function within the extension

The negotiation mechanism allows changing the offered key derivation function, but the change is visible in the final EAP- Request/AKA'-Challenge message that the server sends to the peer. This message is authenticated via the AT_MAC attribute, and carries both the chosen alternative and the initially offered list. The peer refuses to accept a change it did not initiate. As a result, both parties are aware that a change is being made and what the original offer was.

Negotiating the use of this extension

This extension is offered by the server through presenting the AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-Challenge message. These attributes are protected by AT_MAC, so attempts to change or omit them by an adversary will be detected. Except of course, if the adversary holds the long-term shared secret and is willing to engage in an active attack. Such an attack can, for instance, forge the negotiation process so that no FS will be provided. However, as noted above, an attacker with these capabilities will in any case be able to impersonate any party in the protocol and perform MITM attacks. That is not a situation that can be improved by a technical solution. However, as discussed in the introduction, even an attacker with access to the long-term keys is required to be a MITM on each AKA run and subsequent communication, which makes mass surveillance more laborous. The security properties of the extension also depend on a policy choice. As discussed in , both the peer and the server make a policy decision of what to do when it was willing to peform the extension specified in this protocol, but the other side does not wish to use the extension. Allowing this has the benefit of allowing backwards compatibility to equipment that did not yet support the extension. When the extension is not supported or negotiated by the parties, no FS can obviously provided. If turning off the extension specified in this protocol is not allowed by policy, the use of legacy equipment that does not support this protocol is no longer possible. This may be appropriate when, for instance, support for the extension is sufficiently widespread, or required in a particular version of a mobile network.

Key derivation

This extension provides key material that is based on the Diffie-Hellman keys, yet bound to the authentication through the SIM card. This means that subsequent payload communications between the parties are protected with keys that are not solely based on information in the clear (such as the RAND) and information derivable from the long-term shared secrets on the SIM card. As a result, if anyone successfully recovers shared secret information, they are unable to decrypt communications protected by the keys generated through this extension. Note that the recovery of shared secret information could occur either before or after the time that the protected communications are used. When this extension is used, communications at time t0 can be protected if at some later time t1 an adversary learns of long-term shared secret and has access to a recording of the encrypted communications. Obviously, this extension is still vulnerable to attackers that are willing to perform an active attack and who at the time of the attack have access to the long-term shared secret. This extension does not change the properties related to re-authentication. No new Diffie-Hellman run is performed during the re-authentication allowed by EAP-AKA'. However, if this extension was in use when the original EAP-AKA' authentication was performed, the keys used for re-authentication (K_re) are based on the Diffie-Hellman keys, and hence continue to be equally safe against expose of the long-term secrets as the original authentication.

Denial-of-Service In addition, it is worthwhile to discuss Denial-of-Service attacks and their impact on this protocol. The calculations involved in public key cryptography require computing power, which could be used in an attack to overpower either the peer or the server. While some forms of Denial-of-Service attacks are always possible, the following factors help mitigate the concerns relating to public key cryptography and EAP-AKA' FS.

• In 5G context, other parts of the connection setup involve public key cryptography, so while performing additional operations in EAP-AKA' is an additional concern, it does not change the overall situation. As a result, the relevant system components need to be dimensioned appropriately, and detection and management mechanisms to reduce the effect of attacks need to be in place.
• This specification is constructed so that a separation between the USIM and Peer on client side and the Server and HSS on network side is possible. This ensures that the most sensitive (or legacy) system components can not be the target of the attack. For instance, EAP-AKA' and public key cryptography takes place in the phone and not the low-power SIM card.
• EAP-AKA' has been designed so that the first actual message in the authentication process comes from the Server, and that this message will not be sent unless the user has been identified as an active subscriber of the operator in question. While the initial identity can be spoofed before authentication has succeeded, this reduces the efficiency of an attack.
• Finally, this memo specifies an order in which computations and checks must occur. When processing the EAP-Request/AKA'-Challenge message, for instance, the AKA authentication must be checked and succeed before the peer proceeds to calculating or processing the FS related parameters (see ). The same is true of EAP-Response/AKA'-Challenge (see ). This ensures that the parties need to show possession of the long-term secret in some way, and only then will the FS calculations become active. This limits the Denial-of-Service to specific, identified subscribers. While botnets and other forms of malicious parties could take advantage of actual subscribers and their key material, at least such attacks are (a) limited in terms of subscribers they control, and (b) identifiable for the purposes of blocking the affected subscribers.

Identity Privacy Best practice privacy today is to mandate client identity protection as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc. A client supporting EAP-AKA' FS MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response).

Unprotected Data and Privacy Unprotected data and metadata can reveal sensitive information and need to be selected with care. In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms, if these depend on the peer identity they leak information about the peer. AT_KDF_INPUT reveals the network name, although that is done on purpose to bind the authentication to a particular context. An attacker observing network traffic may use the above types of information for traffic flow analysis or to track an endpoint.

Post-Quantum Considerations As of the publication of this specification, it is unclear when or even if a quantum computer of sufficient size and power to exploit elliptic curve cryptography will exist. Deployments that need to consider risks decades into the future should transition to Post- Quantum Cryptography (PQC) in the not-too-distant future. Other systems may employ PQC when the quantum threat is more imminent. Current PQC algorithms have limitations compared to Elliptic Curve Cryptography (ECC) and the data sizes could be problematic for some constrained systems. If a Cryptographically Relevant Quantum Computer (CRQC) is built it could recover the SHARED_SECRET from the ECDHE public keys. This would not affect the ability of EAP-AKA' - with or without this extension - to authenticate properly, however. As symmetric key cryptography is safe even if CRQCs are built, an adversary still will not be able to disrupt authentication as it requires computing a correct AT_MAC value. This computation requires the K_aut key which is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET. Other output keys do include SHARED_SECRET via MK_ECDHE, but still include also CK' and IK' which are entirely based on symmetricy cryptography. As a result, an adversary with a quantum computer still cannot compute the other output keys either. However, if the adversary has also obtained knowledge of the secrets associated with the SIM card, they could then compute CK', IK', and SHARED_SECRET, and any derived output keys. This means that the the introduction of a powerful enough quantum computer would disable this protocol extension's ability to provide the forward security capability. This would make it necessary to update the current ECC algorithms in this specification to PQC algorithms. This specification does not add such algorithms, but a future update can do that. Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the algorithms use to generate AT_AUTN and AT_RES are practically secure against even large robust quantum computers. EAP-AKA' FS is currently only specified for use with ECDHE key exchange algorithms, but use of any Key Encapsulation Method (KEM), including Post-Quantum Cryptography (PQC) KEMs, can be specified in the future. While the key exchange is specified with terms of the Diffie-Hellman protocol, the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then contain either the ephemeral public key of the server or the SHARED_SECRET encapsulated with the server's public key.

IANA Considerations This extension of EAP-AKA' shares its attribute space and subtypes with EAP-SIM , EAP-AKA , and EAP-AKA' . Two new Attribute Type value (TBA1, TBA2) in the skippable range need to be assigned for AT_PUB_ECDHE () and AT_KDF_FS ( in the EAP-AKA and EAP-SIM Parameters registry under Attribute Types. Also, a new registry should be created to represent FS Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see ) need to be assigned, along with one reserved value. The initial contents of this namespace are therefore as below; new values can be created through the Specification Required policy .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card. EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community. Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA. This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448. NIST Certicom Research Certicom Research Informative References This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. 3GPP

Change Log RFC Editor: Please remove this appendix. The -08 version of the WG draft has the following changes:

• Further clarification of key calculation in .
• Support for the NIST P-256 group has been made mandatory in , in order to align the requirements with 3GPP SUCI encryption requirements.
• The interaction between AT_KDF and AT_KDF_FS has been specified more clearly, including specifying how future specifications need to specify the treatment of new combinations.
• Addition of a discussion about the impacts of potential future quantum computing attacks with specific impacts to this extension.
• Addition of a discussion about metadata/unproctected data in .
• Reference updates.
• Various editorial improvements.

The -07 version of the WG draft has the following changes:

• The impact of forward secrecy explanation has been improved in the abstract and security considerations.
• The draft now more forcefully explains why the authors believe it is important to migrate existing systems to use forward secrecy, and makes a recommendation for this migration.
• The draft does no longer refer to issues within the smart cards but rather the smart card supply chain.
• The rationale for chosen algorithms is explained.
• Also, the authors have checked the language relating to the public value encoding, and believe it is exactly according to the references ( Section 6.1 and Section 2.7.1)

The -06 version of the WG draft is a refresh and a reference update. However, the following should be noted:

• The draft now uses "forward secrecy" terminology and references RFC 7624 per recommendations on mailing list discussion.
• There's been mailing list disccussion about the encoding of the public values; the current text requires confirmation from the working group that it is sufficient.

The -05 version of the WG draft takes into account feedback from the working group list, about the number of bytes needed to encode P-256 values. The -04 version of the WG draft takes into account feedback from the May 2020 WG interim meeting, correcting the reference to the NIST P-256 specification. The -03 version of the WG draft is first of all a refresh; there are no issues that we think need addressing, beyond the one for which there is a suggestion in -03: The specification now suggests an alternate group/curve as an optional one besides X25519. The specific choice of particular groups and algorithms is still up to the working group. The -02 version of the WG draft took into account additional reviews, and changed the document to update RFC 5448 (or rather, its successor, ), changed the wording of the recommendation with regards to the use of this extension, clarified the references to the definition of X25519 and Curve25519, clarified the distinction to ECDH methods that use partially static keys, and simplified the use of AKA and SIM card terminology. Some editorial changes were also made. The -00 and -01 versions of the WG draft made no major changes, only updates to some references. The -05 version is merely a refresh while the draft was waiting for WG adoption. The -04 version of this draft made only editorial changes. The -03 version of this draft changed the naming of various protocol components, values, and notation to match with the use of ECDH in ephemeral mode. The AT_KDF_FS negotiation process was clarified in that exactly one key is ever sent in AT_KDF_ECDHE. The option of checking for zero key values IN ECDHE was added. The format of the actual key in AT_PUB_ECDHE was specified. Denial-of-service considerations for the FS process have been updated. Bidding down attacks against this extension itself are discussed extensively. This version also addressed comments from reviewers, including the August review from Mohit Sethi, and comments made during IETF-102 discussion.

Acknowledgments The authors would like to note that the technical solution in this document came out of the TrustCom paper , whose authors were J. Arkko, K. Norrman, , and B. Sahlin. This document uses also a lot of material from by J. Arkko and H. Haverinen as well as by J. Arkko, V. Lehtovirta, and P. Eronen. The authors would also like to thank , , , , , , , , , , , , , , , , , and many other people at the IETF, GSMA and 3GPP groups for interesting discussions in this problem space.