• Updates the reference that specifies how the Network Name field is constructed in the protocol. This update ensures that EAP-AKA' is compatible with 5G deployments. RFC 5448 referred to the Release 8 version of [TS-3GPP.24.302]. This document points to the first 5G version, Release 16.
• Specifies how EAP and EAP-AKA' use identifiers in 5G. Additional identifiers are introduced in 5G, and for interoperability, it is necessary that the right identifiers are used as inputs in the key derivation. In addition, for identity privacy it is important that when privacy-friendly identifiers in 5G are used, no trackable, permanent identifiers are passed in EAP-AKA', either.
• Specifies session identifiers and other exported parameters, as those were not specified in [RFC 5448] despite requirements set forward in [RFC 5247] to do so. Also, while [RFC 5247] specified session identifiers for EAP-AKA, it only did so for the full authentication case, not for the case of fast re-authentication.
• Updates the requirements on generating pseudonym usernames and fast re-authentication identities to ensure identity privacy.
• Describes what has been learned about any vulnerabilities in AKA or EAP-AKA'.
• Describes the privacy and pervasive monitoring considerations related to EAP-AKA'.
• Adds summaries of the attributes.

• It uses the Type code 0x32, not 0x17 (which is used by EAP-AKA).
• It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, to ensure that both the peer and server know the name of the access network.
• It supports key derivation function negotiation via the AT_KDF attribute (Section 3.2) to allow for future extensions.
• It calculates keys as defined in Section 3.3, not as defined in EAP-AKA.
• It employs SHA-256 / HMAC-SHA-256 [FIPS.180-4], not SHA-1 / HMAC-SHA-1 [RFC 2104] (see Section 3.4).

 Peer                                                    Server
    |                       EAP-Request/Identity             |
    |<-------------------------------------------------------|
    |                                                        |
    |  EAP-Response/Identity                                 |
    |  (Includes user's Network Access Identifier, NAI)      |
    |------------------------------------------------------->|
    |         +--------------------------------------------------+
    |         | 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, and    |
    |         | 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  |
    |<-------------------------------------------------------|

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_KDF_INPUT  | Length        | Actual Network Name Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                        Network Name                           .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AT_KDF_INPUT

This is set to 23.

Length

The length of theattribute, calculated as defined in RFC 4187, Section 8.1.

Actual Network Name Length

This isa 2-byte actual length field, needed due to the requirement thatthe previous field is expressed in multiples of 4 bytes per the usualEAP-AKA rules. The Actual Network Name Length fieldprovides the length of the network name in bytes.

Network Name

This field containsthe network name of the access network for which the authentication isbeing performed. The name does not include any terminating nullcharacters. Because the length of the entire attribute must be amultiple of 4 bytes, the sender pads the name with 1, 2, or 3bytes of all zero bits when necessary.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_KDF        | Length        |    Key Derivation Function    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AT_KDF

This is set to 24.

Length

The length of theattribute, calculated as defined in RFC 4187, Section 8.1. For AT_KDF, the Length field MUST be set to 1.

Key Derivation Function

Anenumerated value representing the key derivation function that theserver (or peer) wishes to use. Value 1 represents the default keyderivation function for EAP-AKA', i.e., employing CK' and IK' asdefined in Section 3.3.

AT_KDF parameter has the value 1

In this case, MK is derived and used as follows:

    MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
    K_encr = MK[0..127]
    K_aut  = MK[128..383]
    K_re   = MK[384..639]
    MSK    = MK[640..1151]
    EMSK   = MK[1152..1663]

Here [n..m] denotes the substring from bit n to m, including bits n and m. PRF' is a new pseudorandom function specified in Section 3.4. The first 1664 bits from its output are used for K_encr (encryption key, 128 bits), K_aut (authentication key, 256 bits), K_re (re-authentication key, 256 bits), MSK (Master Session Key, 512 bits), and EMSK (Extended Master Session Key, 512 bits). These keys are used by the subsequent EAP-AKA' process. K_encr is used by the AT_ENCR_DATA attribute, and K_aut by the AT_MAC attribute. K_re is used later in this section. MSK and EMSK are outputs from a successful EAP method run [RFC 3748].

IK' and CK' are derived as specified in [TS-3GPP.33.402]. The functions that derive IK' and CK' take the following parameters: CK and IK produced by the AKA algorithm, and value of the Network Name field comes from the AT_KDF_INPUT attribute (without length or padding).

The value "EAP-AKA'" is an eight-characters-long ASCII string. It is used as is, without any trailing NUL characters.

Identity is the peer identity as specified in Section 7 of RFC 4187 and in Section 5.3.2 of in this document for the 5G cases.

When the server creates an AKA challenge and corresponding AUTN, CK, CK', IK, and IK' values, it MUST set the Authentication Management Field (AMF) separation bit to 1 in the AKA algorithm [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF separation bit is set to 1. If the bit is not set to 1, the peer behaves as if the AUTN had been incorrect and fails the authentication.

On fast re-authentication, the following keys are calculated:

    MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S)
    MSK  = MK[0..511]
    EMSK = MK[512..1023]

MSK and EMSK are the resulting 512-bit keys, taking the first 1024 bits from the result of PRF'. Note that K_encr and K_aut are not re-derived on fast re-authentication. K_re is the re-authentication key from the preceding full authentication and stays unchanged over any fast re-authentication(s) that may happen based on it. The value "EAP-AKA' re-auth" is a sixteen-characters-long ASCII string, again represented without any trailing NUL characters. Identity is the fast re-authentication identity, counter is the value from the AT_COUNTER attribute, NONCE_S is the nonce value from the AT_NONCE_S attribute, all as specified in Section 7 of RFC 4187. To prevent the use of compromised keys in other places, it is forbidden to change the network name when going from the full to the fast re-authentication process. The peer SHOULD NOT attempt fast re-authentication when it knows that the network name in the current access network is different from the one in the initial, full authentication. Upon seeing a re-authentication request with a changed network name, the server SHOULD behave as if the re-authentication identifier had been unrecognized, and fall back to full authentication. The server observes the change in the name by comparing where the fast re-authentication and full authentication EAP transactions were received at the Authentication, Authorization, and Accounting (AAA) protocol level.

AT_KDF has any other value

Future variations of key derivation functions may be defined, and theywill be represented by new values of AT_KDF. If the peer does notrecognize the value, it cannot calculate the keys and behaves asexplained in Section 3.2.

AT_KDF is missing

The peer behaves as if the AUTN had been incorrect and MUST fail theauthentication.

1

EAP-Request/AKA-Identity

2

EAP-Response/AKA-Identity

3

EAP-Request/AKA-Challenge

4

EAP-Response/AKA-Challenge

5

EAP-Request/AKA-Notification

6

EAP-Response/AKA-Notification

7

EAP-Response/AKA-Client-Error

8

EAP-Request/AKA-Reauthentication

9

EAP-Response/AKA-Reauthentication

10

EAP-Response/AKA-Authentication-Reject

11

EAP-Response/AKA-Synchronization-Failure

"0"

Indicates that the attribute MUST NOT be included in the message.

"1"

Indicates that the attribute MUST be included in the message.

"0-1"

Indicates that the attribute is sometimes included in the message

"0+"

Indicates that zero or more copies of the attribute MAY be included in the message.

"1+"

Indicates that there MUST be at least one attribute in the message but more than one MAY be included in the message.

"0*"

Indicates that the attribute is not included in the message in cases specified in this document, but MAY be included in the future versions of the protocol.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AT_BIDDING    | Length        |D|          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AT_BIDDING

This is set to 136.

Length

The length of theattribute, calculated as defined in RFC 4187, Section 8.1. For AT_BIDDING, the Length MUST be set to 1.

D

This bit is set to 1 if thesender supports EAP-AKA', is willing to use it, and prefers itover EAP-AKA. Otherwise, it should be set to zero.

Reserved

This field MUST be setto zero when sent and ignored on receipt.

(1)

Regular usernames. These are external names given to EAP-AKA' peers. The regular usernames are further subdivided into to categories:

(a)

Permanent usernames, for instance, IMSI-based usernames.

(b)

Privacy-friendly temporary usernames, for instance, 5G GUTI (5G Globally Unique Temporary Identifier) or 5G privacy identifiers (see Section 5.3.2) such as SUCI (Subscription Concealed Identifier).

(2)

EAP-AKA' pseudonym usernames. For example, 2s7ah6n9q@example.com might be a valid pseudonym identity. In this example, 2s7ah6n9q is the pseudonym username.

(3)

EAP-AKA' fast re-authentication usernames. For example, 43953754@example.com might be a valid fast re-authentication identity and 43953754 the fast re-authentication username.

• As a part of link-layer establishment procedures, externally to EAP.
• With the EAP-Response/Identity message in the beginning of the EAP exchange, but before the selection of EAP-AKA'.
• Transmitted from the peer to the server using EAP-AKA' messages instead of EAP-Response/Identity. In this case, the server includes an identity-requesting attribute (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA-Identity message, and the peer includes the AT_IDENTITY attribute, which contains the peer's identity, in the EAP-Response/AKA-Identity message.

• Where identifiers are used within EAP-AKA' (such as key derivation) determine the exact values of the identity to be used, to avoid ambiguity (see Section 5.3.1).
• Where identifiers are carried within EAP-AKA' packets (such as in the AT_IDENTITY attribute) determine which identifiers should be filled in (see Section 5.3.2).

Protected ciphersuite negotiation

EAP-AKA' has no ciphersuite negotiation mechanisms. It does have a negotiation mechanism for selecting the key derivation functions. This mechanism is secure against bidding down attacks from EAP-AKA' to EAP-AKA. 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.

Per assumptions in Section 4, there is no protection against bidding down attacks from EAP-AKA to EAP-AKA' should EAP-AKA' somehow be considered less secure some day than EAP-AKA. Such protection was not provided in RFC 5448 implementations and consequently neither does this specification provide it. If such support is needed, it would have to be added as a separate new feature.

In general, it is expected that the current negotiation capabilities in EAP-AKA' are sufficient for some types of extensions, including adding Perfect Forward Secrecy [EMU-AKA-PFS] and perhaps others. However, some larger changes may require a new EAP method type, which is how EAP-AKA' itself happened. One example of such change would be the introduction of new algorithms.

Mutual authentication

Under theSHA-256 assumption, the properties of EAP-AKA' are at least as good asthose of EAP-AKA in this respect. Refer to RFC 4187, Section 12, for further details.

Integrity protection

Under theSHA-256 assumption, the properties of EAP-AKA' are at least as good(most likely better) as those of EAP-AKA in this respect. Refer toRFC 4187, Section 12, for further details. The onlydifference is that a stronger hash algorithm and keyed MAC, SHA-256 /HMAC-SHA-256, is used instead of SHA-1 / HMAC-SHA-1.

Replay protection

Under theSHA-256 assumption, the properties of EAP-AKA' are at least as good asthose of EAP-AKA in this respect. Refer to RFC 4187, Section 12, for further details.

Confidentiality

The propertiesof EAP-AKA' are exactly the same as those of EAP-AKA in thisrespect. Refer to RFC 4187, Section 12, for furtherdetails.

Key derivation

EAP-AKA' supports key derivation with an effective key strength against brute-force attacks equal to the minimum of the length of the derived keys and the length of the AKA base key, i.e., 128 bits or more. The key hierarchy is specified in Section 3.3.

The Transient EAP Keys used to protect EAP-AKA packets (K_encr, K_aut, K_re), the MSK, and the EMSK are cryptographically separate. If we make the assumption that SHA-256 behaves as a pseudorandom function, an attacker is incapable of deriving any non-trivial information about any of these keys based on the other keys. An attacker also cannot calculate the pre-shared secret from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any practically feasible means.

EAP-AKA' adds an additional layer of key derivation functions within itself to protect against the use of compromised keys. This is discussed further in Section 7.4.

EAP-AKA' uses a pseudorandom function modeled after the one used in IKEv2 [RFC 7296] together with SHA-256.

Key strength

See above.

Dictionary attack resistance

Under the SHA-256 assumption, the properties of EAP-AKA' are at leastas good as those of EAP-AKA in this respect. Refer toRFC 4187, Section 12, for further details.

Fast reconnect

Under the SHA-256assumption, the properties of EAP-AKA' are at least as good as thoseof EAP-AKA in this respect. Refer to RFC 4187, Section 12, for further details. Note that implementations MUST preventperforming a fast reconnect across method types.

Cryptographic binding

Note thatthis term refers to a very specific form of binding, something that isperformed between two layers of authentication. It is not the same asthe binding to a particular network name. The properties of EAP-AKA'are exactly the same as those of EAP-AKA in this respect, i.e., as it is not atunnel method, this property is not applicable to it. Refer toRFC 4187, Section 12, for further details.

Session independence

Theproperties of EAP-AKA' are exactly the same as those of EAP-AKA inthis respect. Refer to RFC 4187, Section 12, for furtherdetails.

Fragmentation

The properties ofEAP-AKA' are exactly the same as those of EAP-AKA in thisrespect. Refer to RFC 4187, Section 12, for furtherdetails.

Channel binding

EAP-AKA', like EAP-AKA, does not provide channel bindings as they're defined in [RFC 3748] and [RFC 5247]. New skippable attributes can be used to add channel binding support in the future, if required.

However, including the Network Name field in the AKA' algorithms (which are also used for other purposes than EAP-AKA') provides a form of cryptographic separation between different network names, which resembles channel bindings. However, the network name does not typically identify the EAP (pass-through) authenticator. See Section 7.4 for more discussion.

• A peer that has not yet performed any EAP-AKA' exchanges does not typically have a pseudonym available. If the peer does not have a pseudonym available, then the privacy mechanism cannot be used, and the permanent identity will have to be sent in the clear. The terminal SHOULD store the pseudonym in nonvolatile memory so that it can be maintained across reboots. An active attacker that impersonates the network may use the AT_PERMANENT_ID_REQ attribute (RFC 4187, Section 4.1.2) to learn the subscriber's IMSI. However, as discussed in RFC 4187, Section 4.1.2, the terminal can refuse to send the cleartext permanent identity if it believes that the network should be able to recognize the pseudonym.
• When pseudonyms and fast re-authentication identities are used, the peer relies on the properly created identifiers by the server. It is essential that an attacker cannot link a privacy-friendly identifier to the user in any way or determine that two identifiers belong to the same user as outlined in Section 5.2. The pseudonym usernames and fast re-authentication identities MUST NOT be used for other purposes (e.g., in other protocols).

[FIPS.180-4]

National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[RFC2104]

H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3748]

B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.

[RFC4187]

J. Arkko, and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, January 2006,
<https://www.rfc-editor.org/info/rfc4187>.

[RFC7542]

A. DeKok, "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[TS-3GPP.23.003]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 16)", 3GPP Technical Specification 23.003, June 2021.

[TS-3GPP.23.501]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); (Release 16)", 3GPP Technical Specification 23.501, June 2021.

[TS-3GPP.24.302]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3; (Release 16)", 3GPP Technical Specification 24.302, July 2020.

[TS-3GPP.24.501]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)", 3GPP Draft Technical Specification 24.501, June 2021.

[TS-3GPP.33.102]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture (Release 16)", 3GPP Technical Specification 33.102, July 2020.

[TS-3GPP.33.402]

3GPP, "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses (Release 16)", 3GPP Technical Specification 33.402, July 2020.

[TS-3GPP.33.501]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture and procedures for 5G System (Release 16)", 3GPP Technical Specification 33.501, July 2021.

[Arapinis2012]

M. Arapinis, L. Mancini, E. Ritter, M. Ryan, N. Golde, R. Redon, and R. Borgaonkar, "New Privacy Issues in Mobile Telephony: Fix and Verification", DOI 10.1145/2382196.2382221, October 2012,
<https://doi.org/10.1145/2382196.2382221>.

[Basin2018]

D. Basin, J. Dreier, L. Hirschi, S. Radomirović, R. Sasse, and V. Stettler, "A Formal Analysis of 5G Authentication", DOI 10.1145/3243734.3243846, August 2018,
<https://doi.org/10.1145/3243734.3243846>.

[Borgaonkar2018]

R. Borgaonkar, L. Hirschi, S. Park, and A. Shaik, "New Privacy Threat on 3G, 4G, and Upcoming 5G AKA Protocols", 2018.

[BT2013]

J. G. Beekman, and C. Thompson, "Breaking Cell Phone Authentication: Vulnerabilities in AKA, IMS and Android", August 2013.

[EMU-AKA-PFS]

Ericsson, , , and , "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", Internet-Draft draft-ietf-emu-aka-pfs-05, October 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-05>.

[FIPS.180-1]

National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, DOI 10.6028/NIST.FIPS.180-1, April 1995,
<https://csrc.nist.gov/publications/detail/fips/180/1/archive/1995-04-17>.

[FIPS.180-2]

National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002,
<https://csrc.nist.gov/publications/detail/fips/180/2/archive/2002-08-01>.

[Heist2015]

J. Scahill, and J. Begley, "How Spies Stole the Keys to the Encryption Castle", February 2015,
<https://firstlook.org/theintercept/2015/02/19/great-sim-heist/>.

[Hussain2019]

S. Hussain, M. Echeverria, O. Chowdhury, N. Li, and E. Bertino, "Privacy Attacks to the 4G and 5G Cellular Paging Protocols Using Side Channel Information", 2019.

[Kune2012]

D. Kune, J. Koelndorfer, N. Hopper, and Y. Kim, "Location Leaks on the GSM Air Interface", 2012.

[MT2012]

S. F. Mjølsnes, and J-K. Tsay, "A Vulnerability in the UMTS and LTE Authentication and Key Agreement Protocols", DOI 10.1007/978-3-642-33704-8_6, October 2012,
<https://doi.org/10.1007/978-3-642-33704-8_6>.

[RFC3310]

A. Niemi, J. Arkko, and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, September 2002,
<https://www.rfc-editor.org/info/rfc3310>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC4169]

V. Torvinen, J. Arkko, and M. Naslund, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", RFC 4169, DOI 10.17487/RFC4169, November 2005,
<https://www.rfc-editor.org/info/rfc4169>.

[RFC4186]

H. Haverinen, and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>.

[RFC4284]

F. Adrangi, V. Lortz, F. Bari, and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006,
<https://www.rfc-editor.org/info/rfc4284>.

[RFC4306]

C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<https://www.rfc-editor.org/info/rfc4306>.

[RFC5113]

J. Arkko, B. Aboba, J. Korhonen, and F. Bari, "Network Discovery and Selection Problem", RFC 5113, DOI 10.17487/RFC5113, January 2008,
<https://www.rfc-editor.org/info/rfc5113>.

[RFC5247]

B. Aboba, D. Simon, and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.

[RFC5281]

P. Funk, and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.

[RFC5448]

J. Arkko, V. Lehtovirta, and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.

[RFC6194]

T. Polk, L. Chen, S. Turner, and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.

[RFC6973]

A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.

[RFC7170]

H. Zhou, N. Cam-Winget, J. Salowey, and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.

[RFC7258]

S. Farrell, and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014,
<https://www.rfc-editor.org/info/rfc7258>.

[RFC7296]

C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014,
<https://www.rfc-editor.org/info/rfc7296>.

[Shaik2016]

A. Shaik, J. Seifert, R. Borgaonkar, N. Asokan, and V. Niemi, "Practical attacks against Privacy and Availability in 4G/LTE Mobile Communication Systems", 2012.

[TS-3GPP.35.208]

3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Specification of the MILENAGE Algorithm Set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document 4: Design Conformance Test Data (Release 14)", 3GPP Technical Specification 35.208, July 2020.

[ZF2005]

M. Zhang, and Y. Fang, "Security analysis and enhancements of 3GPP authentication and key agreement protocol", DOI 10.1109/TWC.2004.842941, March 2005,
<https://doi.org/10.1109/TWC.2004.842941>.

Jari Arkko

Vesa Lehtovirta

Vesa Torvinen

Pasi Eronen