rfc9678v2.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 December 2024		ISSN: 2070-1721 January 2025
	Forward Secrecy Extension to the Improved Extensible Authentication		Forward Secrecy Extension to the Improved Extensible Authentication
	Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)		Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
	Abstract		Abstract
	This document updates RFC 9048, "Improved Extensible Authentication		This document updates RFC 9048, "Improved Extensible Authentication
	Protocol Method for 3GPP Mobile Network Authentication and Key		Protocol Method for 3GPP Mobile Network Authentication and Key
	Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional		Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional
	extension providing ephemeral key exchange. The extension EAP-AKA'		extension providing ephemeral key exchange. The extension EAP-AKA'
	Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward		Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward
	secrecy for the session keys generated as a part of the		secrecy for the session keys generated as a part of the
	authentication run in EAP-AKA'. This prevents an attacker who has		authentication run in EAP-AKA'. This prevents an attacker who has
	gained access to the long-term key from obtaining session keys		gained access to the long-term key from obtaining session keys
	established in the past, assuming these have been properly deleted.		established in the past. In addition, EAP-AKA' FS mitigates passive
	In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale		attacks (e.g., large-scale pervasive monitoring) against future
	pervasive monitoring) against future sessions. This forces attackers		sessions. This forces attackers to use active attacks instead.
	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 110 ¶		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 233 ¶		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
	subscriber's 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
	skipping to change at line 490 ¶		skipping to change at line 490 ¶
	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 548 ¶		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 Key Derivation		This is an enumerated value representing the FS Key Derivation
	Function (KDF) that the Server (or Peer) wishes to use. See		Function (KDF) that the Server (or Peer) wishes to use. See
	Section 6.3 for the functions specified in this document. Note:		Section 6.3 for the functions specified in this document. Note:
	this field has a different name space than the similar field in		this field has a different name space than the similar field in
	the AT_KDF attribute KDF defined in [RFC9048].		the AT_KDF attribute KDF defined in [RFC9048].
	skipping to change at line 686 ¶		skipping to change at line 686 ¶
	The value "EAP-AKA'" is an ASCII string that is 8 characters long.		The value "EAP-AKA'" is an ASCII string that is 8 characters long.
	It is used as is, without any trailing NUL characters. Similarly,		It is used as is, without any trailing NUL characters. Similarly,
	"EAP-AKA' FS" is an ASCII string that is 11 characters long, also		"EAP-AKA' FS" is an ASCII string that is 11 characters long, also
	used as is.		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 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]
	skipping to change at line 848 ¶		skipping to change at line 849 ¶
	6.5.8. EAP-Response/AKA'-Authentication-Reject		6.5.8. EAP-Response/AKA'-Authentication-Reject
	There are no changes for the EAP-Response/AKA'-Authentication-Reject,		There are no changes for the EAP-Response/AKA'-Authentication-Reject,
	except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be		except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be
	added to this message. The appearance of these attributes in a		added to this message. The appearance of these attributes in a
	received message MUST be ignored.		received message MUST be ignored.
	6.5.9. EAP-Response/AKA'-Client-Error		6.5.9. EAP-Response/AKA'-Client-Error
	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
	There are no changes for the EAP-Request/AKA'-Notification.		There are no changes for the EAP-Request/AKA'-Notification.
	6.5.11. EAP-Response/AKA'-Notification		6.5.11. EAP-Response/AKA'-Notification
	There are no changes for the EAP-Request/AKA'-Notification.		There are no changes for the EAP-Response/AKA'-Notification.
	7. Security Considerations		7. Security Considerations
	This section deals only with changes to security considerations for		This section deals only with changes to security considerations for
	EAP-AKA' or new information that has been gathered since the		EAP-AKA' or new information that has been gathered 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
	skipping to change at line 1360 ¶		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. 12 change blocks.
	20 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.