A summary of the security properties of EAP-AKA' follows. These properties are very similar to those in EAP-AKA. We assume that HMAC SHA-256 is at least as secure as HMAC SHA-1 (see also [RFC 6194
]). This is called the SHA-256 assumption in the remainder of this section. Under this assumption, EAP-AKA' is at least as secure as EAP-AKA.
If the AT_KDF attribute has value 1, then the security properties of EAP-AKA' are as follows:
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.
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.
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.
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.
The propertiesof EAP-AKA' are exactly the same as those of EAP-AKA in thisrespect. Refer to RFC 4187, Section 12, for furtherdetails.
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.
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.
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.
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.
Theproperties of EAP-AKA' are exactly the same as those of EAP-AKA inthis respect. Refer to RFC 4187, Section 12, for furtherdetails.
The properties ofEAP-AKA' are exactly the same as those of EAP-AKA in thisrespect. Refer to RFC 4187, Section 12, for furtherdetails.
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.
] suggests that the privacy considerations of IETF protocols be documented.
The confidentiality properties of EAP-AKA' itself have been discussed above under Section 7
EAP-AKA' uses several different types of identifiers to identify the authenticating peer. It is strongly RECOMMENDED
to use the privacy-friendly temporary or hidden identifiers, i.e., the 5G GUTI or SUCI, pseudonym usernames, and fast re-authentication usernames. The use of permanent identifiers such as the IMSI or SUPI may lead to an ability to track the peer and/or user associated with the peer. The use of permanent identifiers such as the IMSI or SUPI is strongly NOT RECOMMENDED
As discussed in Section 5.3
, when authenticating to a 5G network, only the SUCI identifier is normally used. The use of EAP-AKA' pseudonyms in this situation is at best limited because the SUCI already provides a stronger mechanism. In fact, reusing the same pseudonym multiple times will result in a tracking opportunity for observers that see the pseudonym pass by. To avoid this, the peer and server need to follow the guidelines given in Section 5.2
When authenticating to a 5G network, per Section 5.3.1
, both the EAP-AKA' peer and server need to employ the permanent identifier SUPI as an input to key derivation. However, this use of the SUPI is only internal. As such, the SUPI need not be communicated in EAP messages. Therefore, SUPI MUST NOT
be communicated in EAP-AKA' when authenticating to a 5G network.
While the use of SUCI in 5G networks generally provides identity privacy, this is not true if the null-scheme encryption is used to construct the SUCI (see [TS-3GPP.33.501
], Annex C). The use of this scheme makes the use of SUCI equivalent to the use of SUPI or IMSI. The use of the null scheme is NOT RECOMMENDED
where identity privacy is important.
The use of fast re-authentication identities when authenticating to a 5G network does not have the same problems as the use of pseudonyms, as long as the 5G authentication server generates the fast re-authentication identifiers in a proper manner specified in Section 5.2
Outside 5G, the peer can freely choose between the use of permanent, pseudonym, or fast re-authentication identifiers:
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).
If the peer and server cannot guarantee that SUCI can be used or that pseudonyms will be available, generated properly, and maintained reliably, and identity privacy is required, then additional protection from an external security mechanism such as tunneled EAP methods like Tunneled Transport Layer Security (TTLS) [RFC 5281
] or Tunnel Extensible Authentication Protocol (TEAP) [RFC 7170
] may be used. The benefits and the security considerations of using an external security mechanism with EAP-AKA are beyond the scope of this document.
Finally, as with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, typically the domain part of an identifier (e.g., the home operator) is visible to external parties.
There have been no published attacks that violate the primary secrecy or authentication properties defined for Authentication and Key Agreement (AKA) under the originally assumed trust model. The same is true of EAP-AKA'.
However, there have been attacks when a different trust model is in use, with characteristics not originally provided by the design, or when participants in the protocol leak information to outsiders on purpose, and there have been some privacy-related attacks.
For instance, the original AKA protocol does not prevent an insider supplying keys to a third party, e.g., as described by Mjølsnes
and Tsay in [MT2012
] where a serving network lets an authentication run succeed, but then it misuses the session keys to send traffic on the authenticated user's behalf. This particular attack is not different from any on-path entity (such as a router) pretending to send traffic, but the general issue of insider attacks can be a problem, particularly in a large group of collaborating operators.
Another class of attacks is the use of tunneling of traffic from one place to another, e.g., as done by Zhang and Fang in [ZF2005
] to leverage security policy differences between different operator networks, for instance. To gain something in such an attack, the attacker needs to trick the user into believing it is in another location. If policies between locations differ, for instance, if payload traffic is not required to be encrypted in some location, the attacker may trick the user into opening a vulnerability. As an authentication mechanism, EAP-AKA' is not directly affected by most of these attacks. EAP-AKA' network name binding can also help alleviate some of the attacks. In any case, it is recommended that EAP-AKA' configuration not be dependent on the location of request origin, unless the location information can be cryptographically confirmed, e.g., with the network name binding.
Zhang and Fang also looked at denial-of-service attacks [ZF2005
]. A serving network may request large numbers of authentication runs for a particular subscriber from a home network. While the resynchronization process can help recover from this, eventually it is possible to exhaust the sequence number space and render the subscriber's card unusable. This attack is possible for both original AKA and EAP-AKA'. However, it requires the collaboration of a serving network in an attack. It is recommended that EAP-AKA' implementations provide the means to track, detect, and limit excessive authentication attempts to combat this problem.
There have also been attacks related to the use of AKA without the generated session keys (e.g., [BT2013
]). Some of those attacks relate to the use of HTTP Digest AKAv1 [RFC 3310
], which was originally vulnerable to man-in-the-middle attacks. This has since been corrected in [RFC 4169
]. The EAP-AKA' protocol uses session keys and provides channel binding, and as such, it is resistant to the above attacks except where the protocol participants leak information to outsiders.
Basin, et al. [Basin2018
] have performed formal analysis and concluded that the AKA protocol would have benefited from additional security requirements such as key confirmation.
In the context of pervasive monitoring revelations, there were also reports of compromised long-term pre-shared keys used in SIM and AKA [Heist2015
]. While no protocol can survive the theft of key material associated with its credentials, there are some things that alleviate the impacts in such situations. These are discussed further in Section 7.3
Arapinis, et al. [Arapinis2012
] describe an attack that uses the AKA resynchronization protocol to attempt to detect whether a particular subscriber is in a given area. This attack depends on the attacker setting up a false base station in the given area and on the subscriber performing at least one authentication between the time the attack is set up and run.
Borgaonkar, et al. discovered that the AKA resynchronization protocol may also be used to predict the authentication frequency of a subscriber if a non-time-based sequence number (SQN) generation scheme is used [Borgaonkar2018
]. The attacker can force the reuse of the keystream that is used to protect the SQN in the AKA resynchronization protocol. The attacker then guesses the authentication frequency based on the lowest bits of two XORed SQNs. The researchers' concern was that the authentication frequency would reveal some information about the phone usage behavior, e.g., number of phone calls made or number of SMS messages sent. There are a number of possible triggers for authentication, so such an information leak is not direct, but it can be a concern. The impact of the attack differs depending on whether the SQN generation scheme that is used is time-based or not.
Similar attacks are possible outside AKA in the cellular paging protocols where the attacker can simply send application-layer data, send short messages, or make phone calls to the intended victim and observe the air interface (e.g., [Kune2012
] and [Shaik2016
]). Hussain, et al. demonstrated a slightly more sophisticated version of the attack that exploits the fact that the 4G paging protocol uses the IMSI to calculate the paging timeslot [Hussain2019
]. As this attack is outside AKA, it does not impact EAP-AKA'.
Finally, bad implementations of EAP-AKA' may not produce pseudonym usernames or fast re-authentication identities in a manner that is sufficiently secure. While it is not a problem with the protocol itself, following the recommendations in Section 5.2
can mitigate this concern.
As required by [RFC 7258
], work on IETF protocols needs to consider the effects of pervasive monitoring and mitigate them when possible.
As described in Section 7.2
, after the publication of RFC 5448
, new information has come to light regarding the use of pervasive monitoring techniques against many security technologies, including AKA-based authentication.
For AKA, these attacks relate to theft of the long-term, shared-secret key material stored on the cards. Such attacks are conceivable, for instance, during the manufacturing process of cards, through coercion of the card manufacturers, or during the transfer of cards and associated information to an operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved.
In particular, it is crucial that manufacturers limit access to the secret information and the cards only to necessary systems and personnel. It is also crucial that secure mechanisms be used to store and communicate the secrets between the manufacturer and the operator that adopts those cards for their customers.
Beyond these operational considerations, there are also technical means to improve resistance to these attacks. One approach is to provide Perfect Forward Secrecy (PFS). This would prevent any passive attacks merely based on the long-term secrets and observation of traffic. Such a mechanism can be defined as a backwards-compatible extension of EAP-AKA' and is pursued separately from this specification [EMU-AKA-PFS
]. Alternatively, EAP-AKA' authentication can be run inside a PFS-capable, tunneled authentication method. In any case, the use of some PFS-capable mechanism is recommended.
The ability of EAP-AKA' to bind the network name into the used keys provides some additional protection against key leakage to inappropriate parties. The keys used in the protocol are specific to a particular network name. If key leakage occurs due to an accident, access node compromise, or another attack, the leaked keys are only useful when providing access with that name. For instance, a malicious access point cannot claim to be network Y if it has stolen keys from network X. Obviously, if an access point is compromised, the malicious node can still represent the compromised node. As a result, neither EAP-AKA' nor any other extension can prevent such attacks; however, the binding to a particular name limits the attacker's choices, allows better tracking of attacks, makes it possible to identify compromised networks, and applies good cryptographic hygiene.
The server receives the EAP transaction from a given access network, and verifies that the claim from the access network corresponds to the name that this access network should be using. It becomes impossible for an access network to claim over AAA that it is another access network. In addition, if the peer checks that the information it has received locally over the network-access link-layer matches with the information the server has given it via EAP-AKA', it becomes impossible for the access network to tell one story to the AAA network and another one to the peer. These checks prevent some "lying NAS" (Network Access Server) attacks. For instance, a roaming partner, R, might claim that it is the home network H in an effort to lure peers to connect to itself. Such an attack would be beneficial for the roaming partner if it can attract more users, and damaging for the users if their access costs in R are higher than those in other alternative networks, such as H.
Any attacker who gets hold of the keys CK and IK, produced by the AKA algorithm, can compute the keys CK' and IK' and, hence, the Master Key (MK) according to the rules in Section 3.3
. The attacker could then act as a lying NAS. In 3GPP systems in general, the keys CK and IK have been distributed to, for instance, nodes in a visited access network where they may be vulnerable. In order to reduce this risk, the AKA algorithm MUST
be computed with the AMF separation bit set to 1, and the peer MUST
check that this is indeed the case whenever it runs EAP-AKA'. Furthermore, [TS-3GPP.33.402
] requires that no CK or IK keys computed in this way ever leave the home subscriber system.
The additional security benefits obtained from the binding depend obviously on the way names are assigned to different access networks. This is specified in [TS-3GPP.24.302
]. See also [TS-3GPP.23.003
]. Ideally, the names allow separating each different access technology, each different access network, and each different NAS within a domain. If this is not possible, the full benefits may not be achieved. For instance, if the names identify just an access technology, use of compromised keys in a different technology can be prevented, but it is not possible to prevent their use by other domains or devices using the same technology.