rfc9678v1.txt		rfc9678.txt
	Internet Engineering Task Force (IETF) J. Arkko		Internet Engineering Task Force (IETF) J. Arkko
	Request for Comments: 9678 K. Norrman		Request for Comments: 9678 K. Norrman
	Updates: 5448, 9048 J. Preuß Mattsson		Updates: 5448, 9048 J. Preuß Mattsson
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
	ISSN: 2070-1721 October 2024		ISSN: 2070-1721 February 2025
	Forward Secrecy for the Extensible Authentication Protocol Method for		Forward Secrecy Extension to the Improved Extensible Authentication
	Authentication and Key Agreement (EAP-AKA' FS)		Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
	Abstract		Abstract
	This document updates RFC 9048, which details the improved Extensible		This document updates RFC 9048, "Improved Extensible Authentication
	Authentication Protocol Method for 3GPP Mobile Network Authentication		Protocol Method for 3GPP Mobile Network Authentication and Key
	and Key Agreement (EAP-AKA'), with an optional extension providing		Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional
	ephemeral key exchange. Similarly, this document also updates the		extension providing ephemeral key exchange. The extension EAP-AKA'
	earlier version of the EAP-AKA' specification in RFC 5448. The		Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward
	extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,		secrecy for the session keys generated as a part of the
	provides forward secrecy for the session keys generated as a part of		authentication run in EAP-AKA'. This prevents an attacker who has
	the authentication run in EAP-AKA'. This prevents an attacker who		gained access to the long-term key from obtaining session keys
	has gained access to the long-term key from obtaining session keys		established in the past. In addition, EAP-AKA' FS mitigates passive
	established in the past, assuming these have been properly deleted.		attacks (e.g., large-scale pervasive monitoring) against future
	In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale		sessions. This forces attackers to use active attacks instead.
	pervasive monitoring) against future sessions. This forces attackers
	to use active attacks instead.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9678.		https://www.rfc-editor.org/info/rfc9678.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	skipping to change at line 111 ¶		skipping to change at line 109 ¶
	associated with pervasive surveillance. Some of the reported attacks		associated with pervasive surveillance. Some of the reported attacks
	involved compromising the Universal Subscriber Identity Module (USIM)		involved compromising the Universal Subscriber Identity Module (USIM)
	card supply chain. Attacks revealing the AKA long-term key may		card supply chain. Attacks revealing the AKA long-term key may
	occur, for instance:		occur, for instance:
	* during the manufacturing process of USIM cards,		* during the manufacturing process of USIM cards,
	* during the transfer of the cards and associated information to the		* during the transfer of the cards and associated information to the
	operator, and		operator, and
	* when a system is running.		* when the system is running.
	Since the publication of reports about such attacks (see		Since the publication of reports about such attacks (see
	[Heist2015]), manufacturing and provisioning processes have gained		[Heist2015]), manufacturing and provisioning processes have gained
	much scrutiny and have improved.		much scrutiny and have improved.
	However, the danger of resourceful attackers attempting to gain		However, the danger of resourceful attackers attempting to gain
	information about long-term keys is still a concern because these		information about long-term keys is still a concern because these
	keys are high-value targets. Note that the attacks are largely		keys are high-value targets. Note that the attacks are largely
	independent of the used authentication technology; the issue is not		independent of the used authentication technology; the issue is not
	vulnerabilities in algorithms or protocols, but rather the		vulnerabilities in algorithms or protocols, but rather the
	skipping to change at line 234 ¶		skipping to change at line 232 ¶
	It is based on challenge-response mechanisms and symmetric		It is based on challenge-response mechanisms and symmetric
	cryptography. In contrast to its earlier GSM counterparts, AKA		cryptography. In contrast to its earlier GSM counterparts, AKA
	provides long key lengths and mutual authentication. The phone		provides long key lengths and mutual authentication. The phone
	typically executes AKA in a USIM. A USIM is technically just an		typically executes AKA in a USIM. A USIM is technically just an
	application that can reside on a removable Universal Integrated		application that can reside on a removable Universal Integrated
	Circuit Card (UICC), an embedded UICC, or integrated in a Trusted		Circuit Card (UICC), an embedded UICC, or integrated in a Trusted
	Execution Environment (TEE). In this document, we use the term "USIM		Execution Environment (TEE). In this document, we use the term "USIM
	card" to refer to any Subscriber Identity Module (SIM) capable of		card" to refer to any Subscriber Identity Module (SIM) capable of
	running AKA.		running AKA.
	The goal of AKA is to mutually authenticate the USIM and the so-		The goals of AKA are to mutually authenticate the USIM and the so-
	called home environment, which is the authentication server in the		called home environment, which is the authentication Server in the
	subscribers home operator's network.		subscriber's home operator's network, and to establish key material
			between the two.
	AKA works in the following manner:		AKA works in the following manner:
	* The USIM and the home environment have agreed on a long-term		* The USIM and the home environment have agreed on a long-term
	symmetric key beforehand.		symmetric key beforehand.
	* The actual authentication process starts by having the home		* The actual authentication process starts by having the home
	environment produce an authentication vector, based on the long-		environment produce an authentication vector, based on the long-
	term key and a sequence number. The authentication vector		term key and a sequence number. The authentication vector
	contains a random part RAND, an authenticator part AUTN used for		contains a random part RAND, an authenticator part AUTN used for
	authenticating the network to the USIM, an expected result part		authenticating the network to the USIM, an expected result part
	XRES, a 128-bit session key for integrity check IK, and a 128-bit		XRES, a 128-bit session key for the integrity check IK, and a
	session key for encryption CK.		128-bit session key for the encryption CK.
	* The authentication vector is passed to the serving network, which		* The authentication vector is passed to the serving network, which
	uses it to authenticate the device.		uses it to authenticate the device.
	* The RAND and the AUTN are delivered to the USIM.		* The RAND and the AUTN are delivered to the USIM.
	* The USIM verifies the AUTN, again based on the long-term key and		* The USIM verifies the AUTN, again based on the long-term key and
	the sequence number. If this process is successful (the AUTN is		the sequence number. If this process is successful (the AUTN is
	valid and the sequence number used to generate AUTN is within the		valid and the sequence number used to generate the AUTN is within
	correct range), the USIM produces an authentication result RES and		the correct range), the USIM produces an authentication result RES
	sends it to the serving network.		and sends it to the serving network.
	* The serving network verifies that the result from the USIM matches		* The serving network verifies that the result from the USIM matches
	the expected value in the authentication vector. If it does, the		the expected value in the authentication vector. If it does, the
	USIM is considered authenticated, and IK and CK can be used to		USIM is considered authenticated, and the IK and CK can be used to
	protect further communications between the USIM and the home		protect further communications between the USIM and the home
	environment.		environment.
	4.2. EAP-AKA' Protocol		4.2. EAP-AKA' Protocol
	When AKA is embedded into EAP, the authentication processing on the		When AKA is embedded into EAP, the authentication processing on the
	network side is moved to the home environment. The 3GPP		network side is moved to the home environment. The 3GPP
	Authentication Database (AD) generates authentication vectors. The		Authentication Database (AD) generates authentication vectors. The
	3GPP authentication server takes the role of EAP server. The USIM		3GPP authentication Server takes the role of EAP Server. The USIM
	combined with the mobile phone takes the role of client. The		combined with the mobile phone takes the role of client. The
	difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that		difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that
	EAP-AKA' binds the derived keys to the name of the access network.		EAP-AKA' binds the derived keys to the name of the access network.
	Figure 1 describes the basic flow in the EAP-AKA' authentication		Figure 1 describes the basic flow in the EAP-AKA' authentication
	process. The definition of the full protocol behavior, along with		process. The definition of the full protocol behavior, along with
	the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES		the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES
	can be found in [RFC9048] and [RFC4187]. Note the use of EAP		can be found in [RFC9048] and [RFC4187]. Note the use of EAP
	terminology from hereon. That is, the 3GPP serving network takes on		terminology from hereon. That is, the 3GPP serving network takes on
	the role of an EAP access network.		the role of an EAP access network.
	Peer Server		Peer Server
	| |		| |
	| EAP-Request/Identity |		| EAP-Request/Identity |
	|<-----------------------------------------------------------+		|<-----------------------------------------------------------+
	| |		| |
	| EAP-Response/Identity |		| EAP-Response/Identity |
	| (Includes user's Network Access Identifier (NAI)) |		| (Includes user's Network Access Identifier (NAI)) |
	+----------------------------------------------------------->|		+----------------------------------------------------------->|
	| +-----------------------------------------------------+--+		| +-------------------------------------------------------+--+
	| | Server determines the network name and ensures that |		| | The Server determines the network name and ensures that |
	| | the given access network is authorized to use the |		| | the given access network is authorized to use the |
	| | claimed name. The server then runs the AKA' algorithms |		| | claimed name. The Server then runs the EAP-AKA' |
	| | generating RAND and AUTN, derives session keys from |		| | algorithms generating RAND and AUTN, and derives session |
	| | CK' and IK'. RAND and AUTN are sent as AT_RAND and |		| | keys from CK' and IK'. RAND and AUTN are sent as |
	| | AT_AUTN attributes, whereas the network name is |		| | AT_RAND and AT_AUTN attributes, whereas the network name |
	| | transported in the AT_KDF_INPUT attribute. AT_KDF |		| | is transported in the AT_KDF_INPUT attribute. AT_KDF |
	| | signals the used key derivation function. The session |		| | signals the used key derivation function. The session |
	| | keys are used to create the AT_MAC attribute. |		| | keys are used to create the AT_MAC attribute. |
	| +-----------------------------------------------------+--+		| +-------------------------------------------------------+--+
	| |		| |
	| EAP-Request/AKA'-Challenge |		| EAP-Request/AKA'-Challenge |
	| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |		| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
	|<-----------------------------------------------------------+		|<-----------------------------------------------------------+
	+--+-----------------------------------------------------+ |		+--+------------------------------------------------------+ |
	| The peer determines what the network name should be, | |		| The Peer determines what the network name should be, | |
	| based on, e.g., what access technology it is using. | |		| based on, e.g., what access technology it is using. | |
	| The peer also retrieves the network name sent by the | |		| The Peer also retrieves the network name sent by the | |
	| network from the AT_KDF_INPUT attribute. The two names | |		| network from the AT_KDF_INPUT attribute. The two names | |
	| are compared for discrepancies, and if they do not | |		| are compared for discrepancies, and if they do not | |
	| match, the authentication is aborted. Otherwise, the | |		| match, the authentication is aborted. Otherwise, the | |
	| network name from AT_KDF_INPUT attribute is used in | |		| network name from the AT_KDF_INPUT attribute is used | |
	| running the AKA' algorithms, verifying AUTN from | |		| in running the EAP-AKA' algorithms, verifying AUTN from | |
	| AT_AUTN and MAC from AT_MAC attributes. The peer then | |		| AT_AUTN and Message Authentication Code (MAC) from the | |
	| generates RES. The peer also derives session keys from | |		| AT_MAC attributes. The Peer then generates RES. The | |
	| CK'/IK'. The AT_RES and AT_MAC attributes are | |		| Peer also derives session keys from CK'/IK. The AT_RES | |
	| constructed. | |		| and AT_MAC attributes are constructed. | |
	+--+-----------------------------------------------------+ |		+--+------------------------------------------------------+ |
	| |		| |
	| EAP-Response/AKA'-Challenge |		| EAP-Response/AKA'-Challenge |
	| (AT_RES, AT_MAC) |		| (AT_RES, AT_MAC) |
	+----------------------------------------------------------->|		+----------------------------------------------------------->|
	| +-----------------------------------------------------+--+		| +-----------------------------------------------------+--+
	| | Server checks the RES and MAC values received in |		| | The Server checks the RES and MAC values received in |
	| | AT_RES and AT_MAC, respectively. Success requires both |		| | AT_RES and AT_MAC, respectively. Success requires |
	| | compared values match, respectively. |		| | both compared values match, respectively. |
	| +-----------------------------------------------------+--+		| +-----------------------------------------------------+--+
	| |		| |
	| EAP-Success |		| EAP-Success |
	|<-----------------------------------------------------------+		|<-----------------------------------------------------------+
	| |		| |
	Figure 1: EAP-AKA' Authentication Process		Figure 1: EAP-AKA' Authentication Process
	4.3. Attacks Against Long-Term Keys in Smart Cards		4.3. Attacks Against Long-Term Keys in Smart Cards
	The general security properties and potential vulnerabilities of AKA		The general security properties and potential vulnerabilities of AKA
	and EAP-AKA' are discussed in [RFC9048].		and EAP-AKA' are discussed in [RFC9048].
	An important question in that discussion relates to the potential		An important question in that discussion relates to the potential
	compromise of long-term keys, as discussed earlier. Attacks on long-		compromise of long-term keys, as discussed earlier. Attacks on long-
	term keys are not specific to AKA or EAP-AKA', and all security		term keys are not specific to AKA or EAP-AKA', and all security
	systems fail, at least to some extent, if key material is stolen.		systems fail, at least to some extent, if key material is stolen.
	However, it would be preferable to retain some security even in the		However, it would be preferable to retain some security even in the
	face of such attacks. This document specifies a mechanism that		face of such attacks. This document specifies a mechanism that
	reduces risks to compromise of key material belonging to previous		reduces the risks of compromising key material belonging to previous
	sessions, before the long-term keys were compromised. It also forces		sessions, before the long-term keys were compromised. It also forces
	attackers to be active even after the compromise.		attackers to be active even after the compromise.
	5. Protocol Overview		5. Protocol Overview
	Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic		Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic
	Curve Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the		Curve Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the
	exchange must be run in an ephemeral manner, i.e., both sides		exchange must be run in an ephemeral manner, i.e., both sides
	generate temporary keys according to the negotiated ciphersuite. For		generate temporary keys according to the negotiated ciphersuite. For
	example, for X25519, this is done as specified in [RFC7748]. This		example, for X25519, this is done as specified in [RFC7748]. This
	skipping to change at line 371 ¶		skipping to change at line 370 ¶
	wire formats are chosen to align with the elliptic curves and formats		wire formats are chosen to align with the elliptic curves and formats
	specified for Subscription Concealed Identifier (SUCI) encryption in		specified for Subscription Concealed Identifier (SUCI) encryption in
	Appendix C.3.4 of 3GPP [TS.33.501].		Appendix C.3.4 of 3GPP [TS.33.501].
	The enhancements in the EAP-AKA' FS protocol are compatible with the		The enhancements in the EAP-AKA' FS protocol are compatible with the
	signaling flow and other basic structures of both AKA and EAP-AKA'.		signaling flow and other basic structures of both AKA and EAP-AKA'.
	The intent is to implement the enhancement as optional attributes		The intent is to implement the enhancement as optional attributes
	that legacy implementations ignore.		that legacy implementations ignore.
	The purpose of the protocol is to achieve mutual authentication		The purpose of the protocol is to achieve mutual authentication
	between the EAP server and peer and to establish keying material for		between the EAP Server and Peer and to establish key material for
	secure communication between the two. This document specifies the		secure communication between the two. This document specifies the
	calculation of key material, providing new properties that are not		calculation of key material, providing new properties that are not
	present in key material provided by EAP-AKA' in its original form.		present in key material provided by EAP-AKA' in its original form.
	Figure 2 describes the overall process. Since the goal has been to		Figure 2 describes the overall process. Since the goal has been to
	not require new infrastructure or credentials, the flow diagrams also		not require new infrastructure or credentials, the flow diagrams also
	show the conceptual interaction with the USIM card and the home		show the conceptual interaction with the USIM card and the home
	environment. Recall that the home environment represents the 3GPP		environment. Recall that the home environment represents the 3GPP
	Authentication Database (AD) and server. The details of those		Authentication Database (AD) and Server. The details of those
	interactions are outside the scope of this document, however, and the		interactions are outside the scope of this document; however, and the
	reader is referred to the 3GPP specifications. For 5G, this is		reader is referred to the 3GPP specifications (for 5G, this is
	specified in 3GPP [TS.33.501].		specified in 3GPP [TS.33.501]).
	USIM Peer Server AD		USIM Peer Server AD
	| | | |		| | | |
	| | EAP-Req/Identity | |		| | EAP-Req/Identity | |
	| |<---------------------------+ |		| |<---------------------------+ |
	| | | |		| | | |
	| | EAP-Resp/Identity | |		| | EAP-Resp/Identity | |
	| | (Privacy-Friendly) | |		| | (Privacy-Friendly) | |
	| +--------------------------->| |		| +--------------------------->| |
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+----+
	| | Server now has an identity for the peer. The server |		| | The Server now has an identity for the Peer. The Server |
	| | then asks the help of AD to run AKA algorithms, |		| | then asks the help of the AD to run EAP-AKA algorithms, |
	| | generating RAND, AUTN, XRES, CK, IK. Typically, the |		| | generating RAND, AUTN, XRES, CK, and IK. Typically, the |
	| | AD performs the first part of key derivations so that |		| | AD performs the first part of derivations so that the |
	| | the authentication server gets the CK' and IK' keys |		| | authentication Server gets the CK' and IK' keys already |
	| | already tied to a particular network name. |		| | tied to a particular network name. |
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+----+
	| | | |		| | | |
	| | | ID, key deriv. |		| | | ID, key deriv. |
	| | | function, |		| | | function, |
	| | | network name |		| | | network name |
	| | +--------------->|		| | +--------------->|
	| | | |		| | | |
	| | | RAND, AUTN, |		| | | RAND, AUTN, |
	| | | XRES, CK', IK' |		| | | XRES, CK', IK' |
	| | |<---------------+		| | |<---------------+
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+----+
	| | Server now has the needed authentication vector. It |		| | The Server now has the needed authentication vector. It |
	| | generates an ephemeral key pair, sends the public key |		| | generates an ephemeral key pair, and sends the public |
	| | of that key pair and the first EAP method message to |		| | key of that key pair and the first EAP method message to |
	| | the peer. In the message the AT_PUB_ECDHE attribute |		| | the Peer. In the message the AT_PUB_ECDHE attribute |
	| | carries the public key and the AT_KDF_FS attribute |		| | carries the public key and the AT_KDF_FS attribute |
	| | carries other FS-related parameters. Both of these are |		| | carries other FS-related parameters. Both of these are |
	| | skippable attributes that can be ignored if the peer |		| | skippable attributes that can be ignored if the Peer |
	| | does not support this extension. |		| | does not support this extension. |
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+----+
	| | | |		| | | |
	| | EAP-Req/AKA'-Challenge | |		| | EAP-Req/AKA'-Challenge | |
	| | AT_RAND, AT_AUTN, AT_KDF, | |		| | AT_RAND, AT_AUTN, AT_KDF, | |
	| | AT_KDF_FS, AT_KDF_INPUT, | |		| | AT_KDF_FS, AT_KDF_INPUT, | |
	| | AT_PUB_ECDHE, AT_MAC | |		| | AT_PUB_ECDHE, AT_MAC | |
	| |<---------------------------+ |		| |<---------------------------+ |
	+--+--------------+----------------------------+---------+ |		+--+--------------+----------------------------+---------+ |
	| The peer checks if it wants to do the FS extension. If | |		| The Peer checks if it wants to do the FS extension. | |
	| yes, it will eventually respond with AT_PUB_ECDHE and | |		| If yes, it will eventually respond with AT_PUB_ECDHE | |
	| AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |		| and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
	| AT_KDF_FS and base all calculations on basic EAP-AKA' | |		| AT_KDF_FS and base all calculations on basic EAP-AKA' | |
	| attributes, continuing just as in EAP-AKA' per RFC | |		| attributes, continuing just as in EAP-AKA' per RFC | |
	| 9048 rules. In any case, the peer needs to query the | |		| 9048 rules. In any case, the Peer needs to query the | |
	| auth parameters from the USIM card. | |		| auth parameters from the USIM card. | |
	+--+--------------+----------------------------+---------+ |		+--+--------------+----------------------------+---------+ |
	| | | |		| | | |
	| RAND, AUTN | | |		| RAND, AUTN | | |
	|<-------------+ | |		|<-------------+ | |
	| | | |		| | | |
	| CK, IK, RES | | |		| CK, IK, RES | | |
	+------------->| | |		+------------->| | |
	+--+--------------+----------------------------+---------+ |		+--+--------------+----------------------------+---------+ |
	| The peer now has everything to respond. If it wants to | |		| The Peer now has everything to respond. If it wants | |
	| participate in the FS extension, it will then generate | |		| to participate in the FS extension, it will then | |
	| its key pair, calculate a shared key based on its key | |		| generate its key pair, calculate a shared key based on | |
	| pair and the server's public key. Finally, it proceeds | |		| its key pair and the Server's public key. Finally, it | |
	| to derive all EAP-AKA' key values and constructs a | |		| proceeds to derive all EAP-AKA' key values and | |
	| full response. | |		| constructs a full response. | |
	+--+--------------+----------------------------+---------+ |		+--+--------------+----------------------------+---------+ |
	| | | |		| | | |
	| | EAP-Resp/AKA'-Challenge | |		| | EAP-Resp/AKA'-Challenge | |
	| | AT_RES, AT_PUB_ECDHE, | |		| | AT_RES, AT_PUB_ECDHE, | |
	| | AT_MAC | |		| | AT_MAC | |
	| +--------------------------->| |		| +--------------------------->| |
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+--+
	| | The server now has all the necessary values. It |		| | The Server now has all the necessary values. It |
	| | generates the ECDHE shared secret and checks the RES |		| | generates the ECDHE shared secret and checks the RES |
	| | and MAC values received in AT_RES and AT_MAC, |		| | and MAC values received in AT_RES and AT_MAC, |
	| | respectively. Success requires both to be found |		| | respectively. Success requires both to be found |
	| | correct. Note that when this document is used, |		| | correct. Note that when this document is used, |
	| | the keys generated from EAP-AKA' are based on CK, IK, |		| | the keys generated from EAP-AKA' are based on CK, IK, |
	| | and the ECDHE value. Even if there was an attacker who |		| | and the ECDHE value. Even if there was an attacker |
	| | held the long-term key, only an active attacker could |		| | who held the long-term key, only an active attacker |
	| | have determined the generated session keys; in basic |		| | could have determined the generated session keys; in |
	| | EAP-AKA' the generated keys are only based on CK and |		| | basic EAP-AKA' the generated keys are only based on CK |
	| | IK. |		| | and IK. |
	| +-------+----------------------------+----------------+--+		| +-------+----------------------------+----------------+--+
	| | | |		| | | |
	| | EAP-Success | |		| | EAP-Success | |
	| |<---------------------------+ |		| |<---------------------------+ |
	| | | |		| | | |
	Figure 2: EAP-AKA' FS Authentication Process		Figure 2: EAP-AKA' FS Authentication Process
	6. Extensions to EAP-AKA'		6. Extensions to EAP-AKA'
	6.1. AT_PUB_ECDHE		6.1. AT_PUB_ECDHE
	The AT_PUB_ECDHE attribute carries an ECDHE value.		The AT_PUB_ECDHE attribute carries an ECDHE value.
	The format of the AT_PUB_ECDHE attribute is shown below.		The format of the AT_PUB_ECDHE attribute is shown below.
	0 1 2 3		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		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_PUB_ECDHE | Length | Value |		| AT_PUB_ECDHE | Length | Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The fields are as follows:		The fields are as follows:
	AT_PUB_ECDHE:		AT_PUB_ECDHE:
	This is set to 152 by IANA.		This is set to 152.
	Length:		Length:
	This is the length of the attribute, set as other attributes in		This is the length of the attribute, set as other attributes in
	EAP-AKA [RFC4187]. The length is expressed in multiples of 4		EAP-AKA [RFC4187]. The length is expressed in multiples of 4
	bytes. The length includes the attribute type field, the Length		bytes. The length includes the attribute type field, the Length
	field itself, and the Value field (along with any padding).		field itself, and the Value field (along with any padding).
	Value:		Value:
	This value is the sender's ECDHE public key. The value depends on		This value is the sender's ECDHE public key. The value depends on
	the AT_KDF_FS attribute and is calculated as follows:		the AT_KDF_FS attribute and is calculated as follows:
	skipping to change at line 521 ¶		skipping to change at line 520 ¶
	To retain the security of the keys, the sender SHALL generate a		To retain the security of the keys, the sender SHALL generate a
	fresh value for each run of the protocol.		fresh value for each run of the protocol.
	6.2. AT_KDF_FS		6.2. AT_KDF_FS
	The AT_KDF_FS attribute indicates the used or desired FS key		The AT_KDF_FS attribute indicates the used or desired FS key
	generation function, if the FS extension is used. It will also		generation function, if the FS extension is used. It will also
	indicate the used or desired ECDHE group. A new attribute is needed		indicate the used or desired ECDHE group. A new attribute is needed
	to carry this information, as AT_KDF carries the basic KDF value that		to carry this information, as AT_KDF carries the basic KDF value that
	is still used together with the FS KDF value. The basic KDF value is		is still used together with the FS KDF value. The basic KDF value is
	also used by those EAP peers that cannot or do not want to use this		also used by those EAP Peers that cannot or do not want to use this
	extension.		extension.
	This document only specifies the behavior relating to the following		This document only specifies the behavior relating to the following
	combinations of basic KDF values and FS KDF values:		combinations of basic KDF values and FS KDF values:
	* the basic KDF value in AT_KDF is 1, as specified in [RFC5448] and		* the basic KDF value in AT_KDF is 1, as specified in [RFC5448] and
	[RFC9048] and		[RFC9048] and
	* the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and		* the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and
	in Section 6.3.		in Section 6.3.
	skipping to change at line 549 ¶		skipping to change at line 548 ¶
	0 1 2 3		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		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_FS | Length | FS Key Derivation Function |		| AT_KDF_FS | Length | FS Key Derivation Function |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The fields are as follows:		The fields are as follows:
	AT_KDF_FS:		AT_KDF_FS:
	This is set to 153 by IANA.		This is set to 153.
	Length:		Length:
	This is the length of the attribute; it MUST be set to 1.		This is the length of the attribute; it MUST be set to 1.
	FS Key Derivation Function:		FS Key Derivation Function:
	This is an enumerated value representing the FS KDF that the		This is an enumerated value representing the FS Key Derivation
	server (or peer) wishes to use. See Section 6.3 for the functions		Function (KDF) that the Server (or Peer) wishes to use. See
	specified in this document. Note: this field has a different name		Section 6.3 for the functions specified in this document. Note:
	space than the similar field in the AT_KDF attribute KDF defined		this field has a different name space than the similar field in
	in [RFC9048].		the AT_KDF attribute KDF defined in [RFC9048].
	Servers MUST send one or more AT_KDF_FS attributes in the EAP-		Servers MUST send one or more AT_KDF_FS attributes in the EAP-
	Request/AKA'-Challenge message. These attributes represent the		Request/AKA'-Challenge message. These attributes represent the
	desired functions ordered by preference, with the most preferred		desired functions ordered by preference, with the most preferred
	function being the first attribute. The most preferred function is		function being the first attribute. The most preferred function is
	the only one that the server includes a public key value for,		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		however. So, for a set of AT_KDF_FS attributes, there is always only
	one AT_PUB_ECDHE attribute.		one AT_PUB_ECDHE attribute.
	Upon receiving a set of these attributes:		Upon receiving a set of these attributes:
	* If the peer supports and is willing to use the FS KDF indicated by		* If the Peer supports and is willing to use the FS KDF indicated by
	the first AT_KDF_FS attribute, and is willing and able to use the		the first AT_KDF_FS attribute, and is willing and able to use the
	extension defined in this document, the function is taken into use		extension defined in this document, the function will be used
	without any further negotiation.		without any further negotiation.
	* If the peer does not support this function or is unwilling to use		* 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		it, it responds to the Server with an indication that a different
	function is needed. Similarly, with the negotiation process		function is needed. Similarly, with the negotiation process
	defined in [RFC9048] for AT_KDF, the peer sends an EAP-Response/		defined in [RFC9048] for AT_KDF, the Peer sends an EAP-Response/
	AKA'-Challenge message that contains only one attribute,		AKA'-Challenge message that contains only one attribute,
	AT_KDF_FS, with the value set to the desired alternative function		AT_KDF_FS, with the value set to the desired alternative function
	from among the ones suggested by the server earlier. If there is		from among the ones suggested by the Server earlier. If there is
	no suitable alternative, the peer has a choice of either falling		no suitable alternative, the Peer has a choice of either falling
	back to EAP-AKA' or behaving as if AUTN had been incorrect and		back to EAP-AKA' or behaving as if the AUTN had been incorrect and
	failing authentication (see Figure 3 of [RFC4187]). The peer MUST		failing authentication (see Figure 3 of [RFC4187]). The Peer MUST
	fail the authentication if there are any duplicate values within		fail the authentication if there are any duplicate values within
	the list of AT_KDF_FS attributes (except where the duplication is		the list of AT_KDF_FS attributes (except where the duplication is
	due to a request to change the key derivation function; see below		due to a request to change the KDF; see below for further
	for further information).		information).
	* If the peer does not recognize the extension defined in this		* If the Peer does not recognize the extension defined in this
	document or is unwilling to use it, it ignores the AT_KDF_FS		document or is unwilling to use it, it ignores the AT_KDF_FS
	attribute.		attribute.
	Upon receiving an EAP-Response/AKA'-Challenge message with an		Upon receiving an EAP-Response/AKA'-Challenge message with an
	AT_KDF_FS attribute from the peer, the server checks that the		AT_KDF_FS attribute from the Peer, the Server checks that the
	suggested AT_KDF_FS value was one of the alternatives in its offer.		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		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		valid alternative. If the Peer has replied with the first AT_KDF_FS
	value, the server behaves as if the AT_MAC of the response had been		value, the Server behaves as if the AT_MAC of the response had been
	incorrect and fails the authentication. For an overview of the		incorrect and fails the authentication. For an overview of the
	failed authentication process in the server side, see Section 3 and		failed authentication process in the Server side, see Section 3 and
	Figure 2 in [RFC4187]. Otherwise, the server re-sends the EAP-		Figure 2 in [RFC4187]. Otherwise, the Server re-sends the EAP-
	Response/AKA'-Challenge message, but adds the selected alternative to		Response/AKA'-Challenge message, but adds the selected alternative to
	the beginning of the list of AT_KDF_FS attributes and retains the		the beginning of the list of AT_KDF_FS attributes and retains the
	entire list following it. Note that this means that the selected		entire list following it. Note that this means that the selected
	alternative appears twice in the set of AT_KDF values. Responding to		alternative appears twice in the set of AT_KDF values. Responding to
	the peer's request to change the FS KDF is the only valid situation		the Peer's request to change the FS KDF is the only valid situation
	where such duplication may occur.		where such duplication may occur.
	When the peer receives the new EAP-Request/AKA'-Challenge message, it		When the Peer receives the new EAP-Request/AKA'-Challenge message, it
	MUST check that the requested change, and only the requested change,		MUST check that the requested change, and only the requested change,
	occurred in the list of AT_KDF_FS attributes. If so, it continues.		occurred in the list of AT_KDF_FS attributes. If so, it continues.
	If not, it behaves as if AT_MAC were incorrect and fails the		If not, it behaves as if AT_MAC were incorrect and fails the
	authentication. If the peer receives multiple EAP-Request/AKA'-		authentication. If the Peer receives multiple EAP-Request/AKA'-
	Challenge messages with differing AT_KDF_FS attributes without having		Challenge messages with differing AT_KDF_FS attributes without having
	requested negotiation, the peer MUST behave as if AT_MAC were		requested negotiation, the Peer MUST behave as if AT_MAC were
	incorrect and fail the authentication.		incorrect and fail the authentication.
	6.3. Forward Secrecy Key Derivation Functions		6.3. Forward Secrecy Key Derivation Functions
	Two new FS KDF types are defined for "EAP-AKA' with ECDHE and		Two new FS KDF types are defined for "EAP-AKA' with ECDHE and
	X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256",		X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256",
	represented by value 2. These values represent a particular choice		represented by value 2. These values represent a particular choice
	of KDF and, at the same time, select an ECDHE group to be used.		of KDF and, at the same time, select an ECDHE group to be used.
	The FS KDF type value is only used in the AT_KDF_FS attribute. When		The FS KDF type value is only used in the AT_KDF_FS attribute. When
	skipping to change at line 645 ¶		skipping to change at line 644 ¶
	Key derivation in this extension produces exactly the same keys for		Key derivation in this extension produces exactly the same keys for
	internal use within one authentication run as EAP-AKA' [RFC9048]		internal use within one authentication run as EAP-AKA' [RFC9048]
	does. For instance, the K_aut that is used in AT_MAC is still		does. For instance, the K_aut that is used in AT_MAC is still
	exactly as it was in EAP-AKA'. The only change to key derivation is		exactly as it was in EAP-AKA'. The only change to key derivation is
	in the re-authentication keys and keys exported out of the EAP		in the re-authentication keys and keys exported out of the EAP
	method, MSK and EMSK. As a result, EAP-AKA' attributes such as		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.		AT_MAC continue to be usable even when this extension is in use.
	When the FS KDF field in the AT_KDF_FS attribute is set to 1 or 2 and		When the FS KDF 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		the KDF field in the AT_KDF attribute is set to 1, the MK and
	1, the MK and accompanying keys are derived as follows:		accompanying keys are derived as follows:
	MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)		MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
	MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)		MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
	K_encr = MK[0..127]		K_encr = MK[0..127]
	K_aut = MK[128..383]		K_aut = MK[128..383]
	K_re = MK_ECDHE[0..255]		K_re = MK_ECDHE[0..255]
	MSK = MK_ECDHE[256..767]		MSK = MK_ECDHE[256..767]
	EMSK = MK_ECDHE[768..1279]		EMSK = MK_ECDHE[768..1279]
			An explanation of the notation used above is copied here:
			* [n..m] denotes the substring from bit n to m.
			* PRF' is a new pseudorandom function specified in [RFC9048].
			* 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).
			* EMSK is the Extended Master Session Key (512 bits).
			Note: MSK and EMSK are outputs from a successful EAP method run
			[RFC3748].
			The CK and IK are produced by the AKA algorithm. The IK' and CK' are
			derived as specified in [RFC9048] from the IK and CK.
			The value "EAP-AKA'" is an ASCII string that is 8 characters long.
			It is used as is, without any trailing NUL characters. Similarly,
			"EAP-AKA' FS" is an ASCII string that is 11 characters long, also
			used as is.
	Requirements for how to securely generate, validate, and process the		Requirements for how to securely generate, validate, and process the
	ephemeral public keys depend on the elliptic curve.		ephemeral public keys depend on the elliptic curve.
	For P-256, the SHARED_SECRET is the shared secret computed as		For P-256, the SHARED_SECRET is the shared secret computed as
	specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation		specified in Section 5.7.1.2 of [SP-800-56A]. Requirements are
	requirements are defined in Section 5 of [SP-800-56A]. At least		defined in Section 5 of [SP-800-56A], in particular, Sections
	partial public key validation MUST be done for the ephemeral public		5.6.2.3.4, 5.6.3.1, and 5.6.3.3. At least partial public key
	keys. The uncompressed y-coordinate can be computed as described in		validation MUST be done for the ephemeral public keys. The
			uncompressed y-coordinate can be computed as described in
	Section 2.3.4 of [SEC1].		Section 2.3.4 of [SEC1].
	For X25519, the SHARED_SECRET is the shared secret computed as		For X25519, the SHARED_SECRET is the shared secret computed as
	specified in Section 6.1 of [RFC7748]. Both the peer and the server		specified in Section 6.1 of [RFC7748]. Both the Peer and the Server
	MAY check for the zero-value shared secret as specified in		MAY check for the zero-value shared secret as specified in
	Section 6.1 of [RFC7748].		Section 6.1 of [RFC7748].
	| Note: If performed inappropriately, the way that the shared		| Note: If performed inappropriately, the way that the shared
	| secret is tested for zero can provide an ability for attackers		| secret is tested for zero can provide an ability for attackers
	| to listen to CPU power usage side channels. Refer to [RFC7748]		| to listen to CPU power usage side channels. Refer to [RFC7748]
	| for a description of how to perform this check in a way that it		| for a description of how to perform this check in a way that it
	| does not become a problem.		| does not become a problem.
	If validation of the other party's ephemeral public key or the shared		If validation of the other party's ephemeral public key or the shared
	secret fails, a party MUST behave as if the current EAP-AKA'		secret fails, a party MUST behave as if the current EAP-AKA' process
	authentication process starts again from the beginning.		starts again from the beginning.
	The rest of the computation proceeds as defined in Section 3.3 of		The rest of the computation proceeds as defined in Section 3.3 of
	[RFC9048].		[RFC9048].
	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
	pseudorandom function specified in [RFC9048]. 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
	[RFC3748].
	CK and IK are produced by the AKA algorithm. IK' and CK' are derived
	as specified in [RFC9048] from IK and CK.
	The value "EAP-AKA'" is an ASCII string that is 8 characters long.
	It is used as is, without any trailing NUL characters. Similarly,
	"EAP-AKA' FS" is an ASCII string that is 11 characters long, also
	used as is.
	Identity is the peer identity as specified in Section 7 of [RFC4187].
	A privacy-friendly identifier [RFC9048] SHALL be used.
	6.4. ECDHE Groups		6.4. ECDHE Groups
	The selection of suitable groups for the elliptic curve computation		The selection of suitable groups for the elliptic curve computation
	is necessary. The choice of a group is made at the same time as the		is necessary. The choice of a group is made at the same time as the
	decision to use a particular KDF in the AT_KDF_FS attribute.		decision to use a particular KDF in the AT_KDF_FS attribute.
	For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519		For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519
	group specified in [RFC7748]. The support for this group is		group specified in [RFC7748]. The support for this group is
	REQUIRED.		REQUIRED.
	skipping to change at line 734 ¶		skipping to change at line 741 ¶
	this extension is used in EAP-AKA'. It specifies when a message may		this extension is used in EAP-AKA'. It specifies when a message may
	be transmitted or accepted, which attributes are allowed in a		be transmitted or accepted, which attributes are allowed in a
	message, which attributes are required in a message, and other		message, which attributes are required in a message, and other
	message-specific details, where those details are different for this		message-specific details, where those details are different for this
	extension than the base EAP-AKA' or EAP-AKA protocol. Unless		extension than the base EAP-AKA' or EAP-AKA protocol. Unless
	otherwise specified here, the rules from [RFC9048] or [RFC4187]		otherwise specified here, the rules from [RFC9048] or [RFC4187]
	apply.		apply.
	6.5.1. EAP-Request/AKA'-Identity		6.5.1. EAP-Request/AKA'-Identity
	No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST		There are no changes for the EAP-Request/AKA'-Identity, except that
	NOT be added to this message. The appearance of these attributes in		the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this
	a received message MUST be ignored.		message. The appearance of these attributes in a received message
			MUST be ignored.
	6.5.2. EAP-Response/AKA'-Identity		6.5.2. EAP-Response/AKA'-Identity
	No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST		There are no changes for the EAP-Response/AKA'-Identity, except that
	NOT be added to this message. The appearance of these attributes in		the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this
	a received message MUST be ignored. The peer identifier SHALL comply		message. The appearance of these attributes in a received message
	with the privacy-friendly requirements of [RFC9190]. An example of a		MUST be ignored. The Peer identifier SHALL comply with the privacy-
	compliant way of constructing a privacy-friendly peer identifier is		friendly requirements of [RFC9190]. An example of a compliant way of
	using a non-NULL SUCI [TS.33.501].		constructing a privacy-friendly Peer identifier is using a non-null
			SUCI [TS.33.501].
	6.5.3. EAP-Request/AKA'-Challenge		6.5.3. EAP-Request/AKA'-Challenge
	The server sends the EAP-Request/AKA'-Challenge on full		The Server sends the EAP-Request/AKA'-Challenge on full
	authentication as specified by [RFC4187] and [RFC9048]. The		authentication as specified by [RFC4187] and [RFC9048]. The
	attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked		attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked
	on reception as specified in [RFC4187]. They are also necessary for		on reception as specified in [RFC4187]. They are also necessary for
	backwards compatibility.		backwards compatibility.
	In the EAP-Request/AKA'-Challenge, there is no message-specific data		In the EAP-Request/AKA'-Challenge, there is no message-specific data
	covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and		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		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		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 it as if		or AT_PUB_ECDHE is missing on reception, the Peer MUST treat it as if
	neither one was sent and assume that the extension defined in this		neither one was sent and assume that the extension defined in this
	document is not in use.		document is not in use.
	The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING,		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		AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID, and other attributes may be
	included as specified in Section 9.3 of [RFC4187].		included as specified in Section 9.3 of [RFC4187].
	When processing this message, the peer MUST process AT_RAND, AT_AUTN,		When processing this message, the Peer MUST process AT_RAND, AT_AUTN,
	AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes. The		AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes. The
	peer derives keys and verifies AT_MAC only if these attributes are		Peer derives keys and verifies AT_MAC only if these attributes are
	verified to be valid. If the peer is unable or unwilling to perform		verified to be valid. If the Peer is unable or unwilling to perform
	the extension specified in this document, it proceeds as defined in		the extension specified in this document, it proceeds as defined in
	[RFC9048]. Finally, if there is an error, see Section 6.3.1 of		[RFC9048]. Finally, if there is an error, see Section 6.3.1 of
	[RFC4187].		[RFC4187].
	6.5.4. EAP-Response/AKA'-Challenge		6.5.4. EAP-Response/AKA'-Challenge
	The peer sends an EAP-Response/AKA'-Challenge in response to a valid		The Peer sends an EAP-Response/AKA'-Challenge in response to a valid
	EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and		EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and
	[RFC9048]. If the peer supports and is willing to perform the		[RFC9048]. If the Peer supports and is willing to perform the
	extension specified in this protocol, and the server had made a valid		extension specified in this protocol, and the Server had made a valid
	request involving the attributes specified in Section 6.5.3, the peer		request involving the attributes specified in Section 6.5.3, the Peer
	responds per the rules specified below. Otherwise, the peer responds		responds per the rules specified below. Otherwise, the Peer responds
	as specified in [RFC4187] and [RFC9048] and ignores the attributes		as specified in [RFC4187] and [RFC9048] and ignores the attributes
	related to this extension. If the peer has not received attributes		related to this extension. If the Peer has not received attributes
	related to this extension from the Server, and has a policy that		related to this extension from the Server, and has a policy that
	requires it to always use this extension, it behaves as if AUTN were		requires it to always use this extension, it behaves as if the AUTN
	incorrect and fails the authentication.		were incorrect and fails the authentication.
	The AT_MAC attribute MUST be included and checked as specified in		The AT_MAC attribute MUST be included and checked as specified in
	[RFC9048]. In the EAP-Response/AKA'-Challenge, there is no message-		[RFC9048]. In the EAP-Response/AKA'-Challenge, there is no message-
	specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be		specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be
	included and carries the peer's public Diffie-Hellman key.		included and carries the Peer's public Diffie-Hellman key.
	The AT_RES attribute MUST be included and checked as specified in		The AT_RES attribute MUST be included and checked as specified in
	[RFC4187]. When processing this message, the Server MUST process		[RFC4187]. When processing this message, the Server MUST process
	AT_RES before processing other attributes. The Server derives keys		AT_RES before processing other attributes. The Server derives keys
	and verifies AT_MAC only when this attribute is verified to be valid.		and verifies AT_MAC only when this attribute is verified to be valid.
	If the Server has proposed the use of the extension specified in this		If the Server has proposed the use of the extension specified in this
	protocol, but the peer ignores and continues the basic EAP-AKA'		protocol, but the Peer ignores and continues the basic EAP-AKA'
	authentication, the Server makes a policy decision of whether this is		authentication, the Server makes a policy decision of whether this is
	allowed. If this is allowed, it continues the EAP-AKA'		allowed. If this is allowed, it continues the EAP-AKA'
	authentication to completion. If it is not allowed, the Server MUST		authentication to completion. If it is not allowed, the Server MUST
	behave as if authentication failed.		behave as if authentication failed.
	The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other		The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other
	attributes may be included as specified in Section 9.4 of [RFC4187].		attributes may be included as specified in Section 9.4 of [RFC4187].
	6.5.5. EAP-Request/AKA'-Reauthentication		6.5.5. EAP-Request/AKA'-Reauthentication
	No changes, but note that the re-authentication process uses the keys		There are no changes for the EAP-Request/AKA'-Reauthentication, but
	generated in the original EAP-AKA' authentication, which employs key		note that the re-authentication process uses the keys generated in
	material from the Diffie-Hellman procedure if the extension specified		the original EAP-AKA' authentication, which employs key material from
	in this document is in use.		the Diffie-Hellman procedure if the extension specified in this
			document is in use.
	6.5.6. EAP-Response/AKA'-Reauthentication		6.5.6. EAP-Response/AKA'-Reauthentication
	No changes, but as discussed in Section 6.5.5, re-authentication is		There are no changes for the EAP-Response/AKA'-Reauthentication, but
	based on the key material generated by EAP-AKA' and the extension		as discussed in Section 6.5.5, re-authentication is based on the key
	defined in this document.		material generated by EAP-AKA' and the extension defined in this
			document.
	6.5.7. EAP-Response/AKA'-Synchronization-Failure		6.5.7. EAP-Response/AKA'-Synchronization-Failure
	No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST		There are no changes for the EAP-Response/AKA'-Synchronization-
			Failure, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
	NOT be added to this message. The appearance of these attributes in		NOT be added to this message. The appearance of these attributes in
	a received message MUST be ignored.		a received message MUST be ignored.
	6.5.8. EAP-Response/AKA'-Authentication-Reject		6.5.8. EAP-Response/AKA'-Authentication-Reject
	No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST		There are no changes for the EAP-Response/AKA'-Authentication-Reject,
	NOT be added to this message. The appearance of these attributes in		except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be
	a received message MUST be ignored.		added to this message. The appearance of these attributes in a
			received message MUST be ignored.
	6.5.9. EAP-Response/AKA'-Client-Error		6.5.9. EAP-Response/AKA'-Client-Error
	No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST		There are no changes for the EAP-Response/AKA'-Client-Error, except
	NOT be added to this message. The appearance of these attributes in		that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to
	a received message MUST be ignored.		this message. The appearance of these attributes in a received
			message MUST be ignored.
	6.5.10. EAP-Request/AKA'-Notification		6.5.10. EAP-Request/AKA'-Notification
	No changes.		There are no changes for the EAP-Request/AKA'-Notification.
	6.5.11. EAP-Response/AKA'-Notification		6.5.11. EAP-Response/AKA'-Notification
	No changes.		There are no changes for the EAP-Response/AKA'-Notification.
	7. Security Considerations		7. Security Considerations
	This section deals only with the changes to security considerations		This section deals only with changes to security considerations for
	as they differ from EAP-AKA', or as new information has been gathered		EAP-AKA' or new information that has been gathered since the
	since the publication of [RFC9048].		publication of [RFC9048].
	As discussed in Section 1, FS is an important countermeasure against		As discussed in Section 1, FS is an important countermeasure against
	adversaries who gain access to long-term keys. The long-term keys		adversaries who gain access to long-term keys. The long-term keys
	can be best protected with good processes, e.g., restricting access		can be best protected with good processes, e.g., restricting access
	to the key material within a factory or among personnel, etc. Even		to the key material within a factory or among personnel, etc. Even
	so, not all attacks can be entirely ruled out. For instance, well-		so, not all attacks can be entirely ruled out. For instance, well-
	resourced adversaries may be able to coerce insiders to collaborate,		resourced adversaries may be able to coerce insiders to collaborate,
	despite any technical protection measures. The zero trust principles		despite any technical protection measures. The zero trust principles
	suggest that we assume that breaches are inevitable or have		suggest that we assume that breaches are inevitable or have
	potentially already occurred and that we need to minimize the impact		potentially already occurred and that we need to minimize the impact
	skipping to change at line 879 ¶		skipping to change at line 893 ¶
	establishment, for the control plane and the user plane, and for both		establishment, for the control plane and the user plane, and for both
	directions:		directions:
	1. An attacker can decrypt 5G communication that they previously		1. An attacker can decrypt 5G communication that they previously
	recorded.		recorded.
	2. A passive attacker can eavesdrop (decrypt) all future 5G		2. A passive attacker can eavesdrop (decrypt) all future 5G
	communication.		communication.
	3. An active attacker can impersonate the User Equipment (UE) or the		3. An active attacker can impersonate the User Equipment (UE) or the
	Network and inject messages in an ongoing 5G connection between		network and inject messages in an ongoing 5G connection between
	the real UE and the real network.		the real UE and the real network.
	At the time of writing, best practice security is to mandate FS (as		At the time of writing, best practice security is to mandate FS (as
	is done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS		is done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS
	1.3, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell		1.3, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell
	(SSH), QUIC, WireGuard, Signal, etc.). In deployments, it is		(SSH), QUIC, WireGuard, Signal, etc.). In deployments, it is
	recommended that EAP-AKA methods without FS be phased out in the long		recommended that EAP-AKA methods without FS be phased out in the long
	term.		term.
	The FS extension provides assistance against passive attacks from		The FS extension provides assistance against passive attacks from
	attackers that have compromised the key material on USIM cards.		attackers that have compromised the key material on USIM cards.
	Passive attacks are attractive for attackers performing large-scale		Passive attacks are attractive for attackers performing large-scale
	pervasive monitoring as they require far fewer resources and are much		pervasive monitoring as they require far fewer resources and are much
	harder to detect. The extension also provides protection against		harder to detect. The extension also provides protection against
	active attacks as the attacker is forced to be on-path during the AKA		active attacks as the attacker is forced to be on-path during the AKA
	run and subsequent communication between the parties. Without FS, an		run and subsequent communication between the parties. Without FS, an
	active attacker that has compromised the long-term key can inject		active attacker that has compromised the long-term key can inject
	messages in a connection between the real Peer and the real server		messages in a connection between the real Peer and the real Server
	without being on-path. This extension is most useful when		without being on-path. This extension is most useful when
	implemented in a context where the MSK/EMSK are used in protocols not		implemented in a context where the MSK or EMSK are used in protocols
	providing FS. For instance, if used with IKEv2 [RFC7296], the		not providing FS. For instance, if used with IKEv2 [RFC7296], the
	session keys produced by IKEv2 have this property, so better		session keys produced by IKEv2 will in any case have this property,
	characteristics of the MSK and EMSK is not that useful. However,		so the improvements from the use of EAP-AKA' FS are not that useful.
	typical link-layer usage of EAP does not involve running another,		However, typical link-layer usage of EAP does not involve running
	forward secure, key exchange. Therefore, using EAP to authenticate		another key exchange with forward secrecy. Therefore, using EAP to
	access to a network is one situation where the extension defined in		authenticate access to a network is one situation where the extension
	this document can be helpful.		defined in this document can be helpful.
	The FS extension generates keying material using the ECDHE exchange		The FS extension generates key material using the ECDHE exchange in
	in order to gain the FS property. This means that once an EAP-AKA'		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		authentication run ends, the session that it was used to protect is
	closed, and the corresponding keys are destroyed. Even someone who		closed, and the corresponding keys are destroyed. Even someone who
	has recorded all of the data from the authentication run and session		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		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		the keys used to protect the session or any previous session, without
	doing a brute-force search of the session key space.		doing a brute-force search of the session key space.
	Even if a compromise of the long-term keys has occurred, FS is still		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		provided for all future sessions, as long as the attacker does not
	become an active attacker.		become an active attacker.
	The extension does not provide protection against active attackers		The extension does not provide protection against active attackers
	with access to the long-term key that mount an on-path attack on		that mount an on-path attack on future EAP-AKA' runs and have access
	future EAP-AKA' runs will be able to eavesdrop on the traffic		to the long-term key. They will be able to eavesdrop on the traffic
	protected by the resulting session key(s). Still, past sessions		protected by the resulting session key(s). Still, past sessions
	where FS was in use remain protected.		where FS was in use remain protected.
	Using EAP-AKA' FS once provides FS. FS limits the effect of key		Using EAP-AKA' FS once provides FS. FS limits the effect of key
	leakage in one direction (compromise of a key at time T2 does not		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		compromise some key at time T1 where T1 < T2). Protection in the
	other direction (compromise at time T1 does not compromise keys at		other direction (compromise at time T1 does not compromise keys at
	time T2) can be achieved by rerunning ECDHE frequently. If a long-		time T2) can be achieved by rerunning ECDHE frequently. If a long-
	term authentication key has been compromised, rerunning EAP-AKA' FS		term authentication key has been compromised, rerunning EAP-AKA' FS
	gives protection against passive attackers. Using the terms in		gives protection against passive attackers. Using the terms in
	skipping to change at line 973 ¶		skipping to change at line 987 ¶
	EAP-AKA' has a negotiation mechanism for selecting the KDFs, and		EAP-AKA' has a negotiation mechanism for selecting the KDFs, and
	this mechanism has been extended by the extension specified in		this mechanism has been extended by the extension specified in
	this document. The resulting mechanism continues to be secure		this document. The resulting mechanism continues to be secure
	against bidding-down attacks.		against bidding-down attacks.
	There are two specific needs in the negotiation mechanism:		There are two specific needs in the negotiation mechanism:
	Negotiating KDFs within the extension:		Negotiating KDFs within the extension:
	The negotiation mechanism allows changing the offered KDF, but		The negotiation mechanism allows changing the offered KDF, but
	the change is visible in the final EAP-Request/AKA'-Challenge		the change is visible in the final EAP-Request/AKA'-Challenge
	message that the server sends to the peer. This message is		message that the Server sends to the Peer. This message is
	authenticated via the AT_MAC attribute, and carries both the		authenticated via the AT_MAC attribute, and carries both the
	chosen alternative and the initially offered list. The peer		chosen alternative and the initially offered list. The Peer
	refuses to accept a change it did not initiate. As a result,		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		both parties are aware that a change is being made and what the
	original offer was.		original offer was.
	Negotiating the use of this extension:		Negotiating the use of this extension:
	This extension is offered by the server through presenting the		This extension is offered by the Server through presenting the
	AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-		AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-
	Challenge message. These attributes are protected by AT_MAC,		Challenge message. These attributes are protected by AT_MAC,
	so attempts to change or omit them by an adversary will be		so attempts to change or omit them by an adversary will be
	detected.		detected.
	Except of course, if the adversary holds the long-term key and		These attempts will be detected, except of course, if the
	is willing to engage in an active attack. For instance, such		adversary holds the long-term key and is willing to engage in
	an attack can forge the negotiation process so that no FS will		an active attack. For instance, such an attack can forge the
	be provided. However, as noted above, an attacker with these		negotiation process so that no FS will be provided. However,
	capabilities will, in any case, be able to impersonate any		as noted above, an attacker with these capabilities will, in
	party in the protocol and perform on-path attacks. That is not		any case, be able to impersonate any party in the protocol and
	a situation that can be improved by a technical solution.		perform on-path attacks. That is not a situation that can be
	However, as discussed in the Introduction, even an attacker		improved by a technical solution. However, as discussed in the
	with access to the long-term keys is required to be on-path on		Introduction, even an attacker with access to the long-term
	each AKA run and subsequent communication, which makes mass		keys is required to be on-path on each AKA run and subsequent
	surveillance more laborious.		communication, which makes mass surveillance more laborious.
	The security properties of the extension also depend on a		The security properties of the extension also depend on a
	policy choice. As discussed in Section 6.5.4, both the peer		policy choice. As discussed in Section 6.5.4, both the Peer
	and the server make a policy decision of what to do when it was		and the Server make a policy decision of what to do when it was
	willing to perform the extension specified in this protocol,		willing to perform the extension specified in this protocol,
	but the other side does not wish to use the extension.		but the other side does not wish to use the extension.
	Allowing this has the benefit of allowing backwards		Allowing this has the benefit of allowing backwards
	compatibility to equipment that did not yet support the		compatibility to equipment that did not yet support the
	extension. When the extension is not supported or negotiated		extension. When the extension is not supported or negotiated
	by the parties, no FS can obviously be provided.		by the parties, no FS can obviously be provided.
	If turning off the extension specified in this protocol is not		If turning off the extension specified in this protocol is not
	allowed by policy, the use of legacy equipment that does not		allowed by policy, the use of legacy equipment that does not
	support this protocol is no longer possible. This may be		support this protocol is no longer possible. This may be
	skipping to change at line 1032 ¶		skipping to change at line 1046 ¶
	properties related to re-authentication. No new Diffie-Hellman		properties related to re-authentication. No new Diffie-Hellman
	run is performed during the re-authentication allowed by EAP-AKA'.		run is performed during the re-authentication allowed by EAP-AKA'.
	However, if this extension was in use when the original EAP-AKA'		However, if this extension was in use when the original EAP-AKA'
	authentication was performed, the keys used for re-authentication		authentication was performed, the keys used for re-authentication
	(K_re) are based on the Diffie-Hellman keys; hence, they continue		(K_re) are based on the Diffie-Hellman keys; hence, they continue
	to be equally safe against exposure of the long-term key as the		to be equally safe against exposure of the long-term key as the
	original authentication.		original authentication.
	7.3. Denial of Service		7.3. Denial of Service
	In addition, it is worthwhile to discuss Denial-of-Service (DoS)		It is worthwhile to discuss Denial-of-Service (DoS) attacks and their
	attacks and their impact on this protocol. The calculations involved		impact on this protocol. The calculations involved in public key
	in public key cryptography require computing power, which could be		cryptography require computing power, which could be used in an
	used in an attack to overpower either the peer or the server. While		attack to overpower either the Peer or the Server. While some forms
	some forms of DoS attacks are always possible, the following factors		of DoS attacks are always possible, the following factors help
	help mitigate the concerns relating to public key cryptography and		mitigate the concerns relating to public key cryptography and EAP-
	EAP-AKA' FS.		AKA' FS.
	* In a 5G context, other parts of the connection setup involve		* In a 5G context, other parts of the connection setup involve
	public key cryptography, so while performing additional operations		public key cryptography, so while performing additional operations
	in EAP-AKA' is an additional concern, it does not change the		in EAP-AKA' is an additional concern, it does not change the
	overall situation. As a result, the relevant system components		overall situation. As a result, the relevant system components
	need to be dimensioned appropriately, and detection and management		need to be dimensioned appropriately, and detection and management
	mechanisms to reduce the effect of attacks need to be in place.		mechanisms to reduce the effect of attacks need to be in place.
	* This specification is constructed so that a separation between the		* This specification is constructed so that it is possible to have a
	USIM and Peer on the client side and the Server and AD on the		separation between the USIM and Peer on the client side and
	network side is possible. This ensures that the most sensitive		between the Server and AD on the network side. This ensures that
	(or legacy) system components cannot be the target of the attack.		the most sensitive (or legacy) system components cannot be the
	For instance, EAP-AKA' and public key cryptography takes place in		target of the attack. For instance, EAP-AKA' and public key
	the phone and not the low-power USIM card.		cryptography both take place in the phone and not the low-power
			USIM card.
	* EAP-AKA' has been designed so that the first actual message in the		* EAP-AKA' has been designed so that the first actual message in the
	authentication process comes from the Server, and that this		authentication process comes from the Server, and that this
	message will not be sent unless the user has been identified as an		message will not be sent unless the user has been identified as an
	active subscriber of the operator in question. While the initial		active subscriber of the operator in question. While the initial
	identity can be spoofed before authentication has succeeded, this		identity can be spoofed before authentication has succeeded, this
	reduces the efficiency of an attack.		reduces the efficiency of an attack.
	* Finally, this memo specifies an order in which computations and		* Finally, this memo specifies an order in which computations and
	checks must occur. For instance, when processing the EAP-Request/		checks must occur. For instance, when processing the EAP-Request/
	AKA'-Challenge message, the AKA authentication must be checked and		AKA'-Challenge message, the AKA authentication must be checked and
	succeed before the peer proceeds to calculating or processing the		succeed before the Peer proceeds to calculating or processing the
	FS-related parameters (see Section 6.5.4). The same is true of an		FS-related parameters (see Section 6.5.4). The same is true of an
	EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures		EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures
	that the parties need to show possession of the long-term key in		that the parties need to show possession of the long-term key in
	some way, and only then will the FS calculations become active.		some way, and only then will the FS calculations become active.
	This limits the DoS to specific, identified subscribers. While		This limits the DoS to specific, identified subscribers. While
	botnets and other forms of malicious parties could take advantage		botnets and other forms of malicious parties could take advantage
	of actual subscribers and their key material, at least such		of actual subscribers and their key material, at least such
	attacks are:		attacks are:
	a. limited in terms of subscribers they control, and		a. limited in terms of subscribers they control, and
	b. identifiable for the purposes of blocking the affected		b. identifiable for the purposes of blocking the affected
	subscribers.		subscribers.
	7.4. Identity Privacy		7.4. Identity Privacy
	As specified in Section 6.5, the peer identity sent in the Identity		As specified in Section 6.5, the Peer identity sent in the Identity
	Response message needs to follow the privacy-friendly requirements in		Response message needs to follow the privacy-friendly requirements in
	[RFC9190].		[RFC9190].
	7.5. Unprotected Data and Privacy		7.5. Unprotected Data and Privacy
	Unprotected data and metadata can reveal sensitive information and		Unprotected data and metadata can reveal sensitive information and
	need to be selected with care. In particular, this applies to		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, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF,
	AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms;		AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms;
	if these depend on the peer identity, they leak information about the		if these depend on the Peer identity, they leak information about the
	peer. AT_KDF_INPUT reveals the network name, although that is done		Peer. AT_KDF_INPUT reveals the network name, although that is done
	on purpose to bind the authentication to a particular context.		on purpose to bind the authentication to a particular context.
	An attacker observing network traffic may use the above types of		An attacker observing network traffic may use the above types of
	information for traffic flow analysis or to track an endpoint.		information for traffic flow analysis or to track an endpoint.
	7.6. Forward Secrecy within AT_ENCR		7.6. Forward Secrecy within AT_ENCR
	The keys K_encr and K_aut are calculated and used before the shared		The keys K_encr and K_aut are calculated and used before the shared
	secret from the ephemeral key exchange is available.		secret from the ephemeral key exchange is available.
	K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/		K_encr and K_aut are used to encrypt and calculate a MAC in the EAP-
	AKA'-Challenge message, especially the DH g^x ephemeral pub key. At		Req/AKA'-Challenge message, especially the DH g^x ephemeral pub key.
	that point, the server does not yet have the corresponding g^y from		At that point, the Server does not yet have the corresponding g^y
	the peer and cannot compute the shared secret. K_aut is then used as		from the Peer and cannot compute the shared secret. K_aut is then
	the authentication key for the shared secret.		used as the authentication key for the shared secret.
	However, for K_encr, none of the encrypted data sent in the EAP-Req/		However, for K_encr, none of the encrypted data sent in the EAP-Req/
	AKA'-Challenge message in the AT_ENCR attribute will be a forward		AKA'-Challenge message in the AT_ENCR attribute will be a forward
	secret. That data may include re-authentication pseudonyms, so an		secret. That data may include re-authentication pseudonyms, so an
	adversary compromising the long-term key would be able to link re-		adversary compromising the long-term key would be able to link re-
	authentication protocol runs when pseudonyms are used, within a		authentication protocol runs when pseudonyms are used, within a
	sequence of runs followed after a full EAP-AKA' authentication. No		sequence of runs followed after a full EAP-AKA' authentication. No
	such linking would be possible across different full authentication		such linking would be possible across different full authentication
	runs. If the pseudonym linkage risk is not acceptable, one way to		runs. If the pseudonym linkage risk is not acceptable, one way to
	avoid the linkage is to always require full EAP-AKA' authentication.		avoid the linkage is to always require full EAP-AKA' authentication.
	skipping to change at line 1137 ¶		skipping to change at line 1152 ¶
	limitations compared to ECC, and the data sizes could be problematic		limitations compared to ECC, and the data sizes could be problematic
	for some constrained systems. If a Cryptographically Relevant		for some constrained systems. If a Cryptographically Relevant
	Quantum Computer (CRQC) is built, it could recover the SHARED_SECRET		Quantum Computer (CRQC) is built, it could recover the SHARED_SECRET
	from the ECDHE public keys.		from the ECDHE public keys.
	However, this would not affect the ability of EAP-AKA', with or		However, this would not affect the ability of EAP-AKA', with or
	without this extension, to authenticate properly. As symmetric key		without this extension, to authenticate properly. As symmetric key
	cryptography is safe even if CRQCs are built, an adversary still will		cryptography is safe even if CRQCs are built, an adversary still will
	not be able to disrupt authentication as it requires computing a		not be able to disrupt authentication as it requires computing a
	correct AT_MAC value. This computation requires the K_aut key, which		correct AT_MAC value. This computation requires the K_aut key, which
	is based on MK, CK', and IK', but not SHARED_SECRET.		is based on the MK, CK', and IK', but not SHARED_SECRET.
	Other output keys do include SHARED_SECRET via MK_ECDHE, but they		Other output keys do include SHARED_SECRET via MK_ECDHE, but they
	still include CK' and IK', which are entirely based on symmetric		still include the CK' and IK', which are entirely based on symmetric
	cryptography. As a result, an adversary with a quantum computer		cryptography. As a result, an adversary with a quantum computer
	still cannot compute the other output keys either.		still cannot compute the other output keys either.
	However, if the adversary has also obtained knowledge of the long-		However, if the adversary has also obtained knowledge of the long-
	term key, they could then compute CK', IK', SHARED_SECRET, and any		term key, they could then compute the CK', IK', SHARED_SECRET, and
	derived output keys. This means that the introduction of a powerful		any derived output keys. This means that the introduction of a
	enough quantum computer would disable this protocol extension's		powerful enough quantum computer would disable this protocol
	ability to provide the forward security capability. This would make		extension's ability to provide the forward secrecy capability. This
	it necessary to update the current ECC algorithms in this document to		would make it necessary to update the current ECC algorithms in this
	PQC algorithms. This document does not add such algorithms, but a		document to PQC algorithms. This document does not add such
	future update can do that.		algorithms, but a future update can do that.
	Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and		Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and
	the algorithms used to generate AT_AUTN and AT_RES, are practically		the algorithms used to generate AT_AUTN and AT_RES, are practically
	secure against even large, robust quantum computers. EAP-AKA' FS is		secure against even large, robust quantum computers. EAP-AKA' FS is
	currently only specified for use with ECDHE key exchange algorithms,		currently only specified for use with ECDHE key exchange algorithms,
	but use of any Key Encapsulation Method (KEM), including PQC KEMs,		but use of any Key Encapsulation Method (KEM), including PQC KEMs,
	can be specified in the future. While the key exchange is specified		can be specified in the future. While the key exchange is specified
	with terms of the Diffie-Hellman protocol, the key exchange adheres		with terms of the Diffie-Hellman protocol, the key exchange adheres
	to a KEM interface. AT_PUB_ECDHE would then contain either the		to a KEM interface. AT_PUB_ECDHE would then contain either the
	ephemeral public key of the server or the SHARED_SECRET encapsulated		ephemeral public key of the Server or the SHARED_SECRET encapsulated
	with the server's public key. Note that the use of a KEM might		with the Server's public key. Note that the use of a KEM might
	require other changes, such as including the ephemeral public key of		require other changes, such as including the ephemeral public key of
	the server in the key derivation to retain the property that both		the Server in the key derivation to retain the property that both
	parties contribute randomness to the session key.		parties contribute randomness to the session key.
	8. IANA Considerations		8. IANA Considerations
	This extension of EAP-AKA' shares its attribute space and subtypes		This extension of EAP-AKA' shares its attribute space and subtypes
	with the "Extensible Authentication Protocol Method for Global System		with the following:
	for Mobile Communications (GSM) Subscriber Identity Modules (EAP-
	SIM)" [RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048].		* "Extensible Authentication Protocol Method for Global System for
			Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)"
			[RFC4186],
			* "Extensible Authentication Protocol Method for 3rd Generation
			Authentication and Key Agreement (EAP-AKA)" [RFC4187], and
			* "Improved Extensible Authentication Protocol Method for 3GPP
			Mobile Network Authentication and Key Agreement (EAP-AKA')"
			[RFC9048].
	IANA has assigned two new values in the "Attribute Types (Skippable		IANA has assigned two new values in the "Attribute Types (Skippable
	Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM		Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM
	Parameters" group as follows:		Parameters" group as follows:
	152: AT_PUB_ECDHE (Section 6.1)		152: AT_PUB_ECDHE (Section 6.1)
	153: AT_KDF_FS (Section 6.2)		153: AT_KDF_FS (Section 6.2)
	IANA has also created the "EAP-AKA' AT_KDF_FS Key Derivation Function		IANA has also created the "EAP-AKA' AT_KDF_FS Key Derivation Function
	skipping to change at line 1294 ¶		skipping to change at line 1318 ¶
	Codes and Cryptography, vol. 2, pp. 107-125,		Codes and Cryptography, vol. 2, pp. 107-125,
	DOI 10.1007/BF00124891, June 1992,		DOI 10.1007/BF00124891, June 1992,
	<https://doi.org/10.1007/BF00124891>.		<https://doi.org/10.1007/BF00124891>.
	[Heist2015]		[Heist2015]
	Scahill, J. and J. Begley, "The Great SIM Heist", February		Scahill, J. and J. Begley, "The Great SIM Heist", February
	2015,		2015,
	<https://theintercept.com/2015/02/19/great-sim-heist/>.		<https://theintercept.com/2015/02/19/great-sim-heist/>.
	[NIST-ZT] National Institute of Standards and Technology,		[NIST-ZT] National Institute of Standards and Technology,
	"Implementing a Zero Trust Architecture", NIST SP		"Implementing a Zero Trust Architecture", NIST SP 1800-35,
	1800-35B, December 2022,		July 2024, <https://www.nccoe.nist.gov/sites/default/
	<https://www.nccoe.nist.gov/sites/default/files/2022-12/		files/2024-07/zta-nist-sp-1800-35-preliminary-draft-
	zta-nist-sp-1800-35b-preliminary-draft-2.pdf>.		4.pdf>.
	[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security		[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security
	Model", February 2021, <https://media.defense.gov/2021/		Model", February 2021, <https://media.defense.gov/2021/
	Feb/25/2002588479/-1/-1/0/		Feb/25/2002588479/-1/-1/0/
	CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.		CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.
	[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible		[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
	Authentication Protocol Method for Global System for		Authentication Protocol Method for Global System for
	Mobile Communications (GSM) Subscriber Identity Modules		Mobile Communications (GSM) Subscriber Identity Modules
	(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,		(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
	skipping to change at line 1338 ¶		skipping to change at line 1362 ¶
	[TrustCom2015]		[TrustCom2015]
	Arkko, J., Norrman, K., Näslund, M., and B. Sahlin, "A		Arkko, J., Norrman, K., Näslund, M., and B. Sahlin, "A
	USIM Compatible 5G AKA Protocol with Perfect Forward		USIM Compatible 5G AKA Protocol with Perfect Forward
	Secrecy", IEEE International Conference on Trust, Security		Secrecy", IEEE International Conference on Trust, Security
	and Privacy in Computing and Communications (TrustCom),		and Privacy in Computing and Communications (TrustCom),
	DOI 10.1109/Trustcom.2015.506, August 2015,		DOI 10.1109/Trustcom.2015.506, August 2015,
	<https://doi.org/10.1109/Trustcom.2015.506>.		<https://doi.org/10.1109/Trustcom.2015.506>.
	[TS.33.501]		[TS.33.501]
	3GPP, "Security architecture and procedures for 5G		3GPP, "Security architecture and procedures for 5G
	System", Version 18.1.0, 3GPP TS 33.501, March 2023.		System", Version 19.0.0, 3GPP TS 33.501, September 2024.
	Acknowledgments		Acknowledgments
	The authors would like to note that the technical solution in this		The authors would like to note that the technical solution in this
	document came out of the TrustCom paper [TrustCom2015], whose authors		document came out of the TrustCom paper [TrustCom2015], whose authors
	were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document		were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document
	also uses a lot of material from [RFC4187] by J. Arkko and		also uses a lot of material from [RFC4187] by J. Arkko and
	H. Haverinen, as well as [RFC5448] by J. Arkko, V. Lehtovirta, and		H. Haverinen, as well as [RFC5448] by J. Arkko, V. Lehtovirta, and
	P. Eronen.		P. Eronen.
End of changes. 87 change blocks.
	325 lines changed or deleted		349 lines changed or added
This html diff was produced by rfcdiff 1.48.