draft-ietf-emu-aka-pfs-11.txt		draft-ietf-emu-aka-pfs-latest.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft K. Norrman		Internet-Draft K. Norrman
	Updates: 5448, 9048 (if approved) J. Preuß Mattsson		Updates: 5448, 9048 (if approved) J. Preuß Mattsson
	Intended status: Informational Ericsson		Intended status: Standards Track Ericsson
	Expires: 11 January 2024 10 July 2023		Expires: 22 August 2024 19 February 2024
	Forward Secrecy for the Extensible Authentication Protocol Method for		Forward Secrecy for the Extensible Authentication Protocol Method for
	Authentication and Key Agreement (EAP-AKA' FS)		Authentication and Key Agreement (EAP-AKA' FS)
	draft-ietf-emu-aka-pfs-11		draft-ietf-emu-aka-pfs-latest
	Abstract		Abstract
	Many different attacks have been reported as part of revelations
	associated with pervasive surveillance. Some of the reported attacks
	involved compromising the smart card supply chain, such as attacking
	Universal Subscriber Identity Module (USIM) card manufacturers and
	operators in an effort to compromise long-term keys stored on these
	cards. Since the publication of those reports, manufacturing and
	provisioning processes have received much scrutiny and have improved.
	However, resourceful attackers are always a cause for concern.
	Always assuming a breach, such as long-term key compromise, and
	minimizing the impact of breach are essential zero trust principles.
	This document updates RFC 9048, the improved Extensible		This document updates RFC 9048, the improved Extensible
	Authentication Protocol Method for 3GPP Mobile Network Authentication		Authentication Protocol Method for 3GPP Mobile Network Authentication
	and Key Agreement (EAP-AKA'), with an optional extension providing		and Key Agreement (EAP-AKA'), with an optional extension providing
	ephemeral key exchange. Similarly, this document also updates the		ephemeral key exchange. Similarly, this document also updates the
	earlier version of the EAP-AKA' specification in RFC 5448. The		earlier version of the EAP-AKA' specification in RFC 5448. The
	extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,		extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,
	provides forward secrecy for the session keys generated as a part of		provides forward secrecy for the session keys generated as a part of
	the authentication run in EAP-AKA'. This prevents an attacker who		the authentication run in EAP-AKA'. This prevents an attacker who
	has 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, assuming these have been properly deleted.		established in the past, assuming these have been properly deleted.
	skipping to change at page 2, line 10		skipping to change at page 1, line 44
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 11 January 2024.		This Internet-Draft will expire on 22 August 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Design and Deployment Objectives . . . . . . . . . . 5		3. Protocol Design and Deployment Objectives . . . . . . . . . . 4
	4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 7		4.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6
	4.3. Attacks Against Long-Term Keys in Smart Cards . . . . . . 8		4.3. Attacks Against Long-Term Keys in Smart Cards . . . . . . 8
	5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9		5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
	6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11		6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11
	6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11		6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 12		6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14		6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14
	6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 16		6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 16
	6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16		6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16
	6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 17		6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16
	6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 17		6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16
	6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 17		6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 17
	6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 18		6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17
	6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 18		6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 18
	6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18		6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18
	6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 19		6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18
	6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 19		6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18
	6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 19		6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18
	6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 19		6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 19
	6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 19		6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7.1. Deployment Considerations . . . . . . . . . . . . . . . . 21		7.1. Deployment Considerations . . . . . . . . . . . . . . . . 21
	7.2. Security Properties . . . . . . . . . . . . . . . . . . . 21		7.2. Security Properties . . . . . . . . . . . . . . . . . . . 21
	7.3. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 23		7.3. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 23
	7.4. Identity Privacy . . . . . . . . . . . . . . . . . . . . 24		7.4. Identity Privacy . . . . . . . . . . . . . . . . . . . . 24
	7.5. Unprotected Data and Privacy . . . . . . . . . . . . . . 24		7.5. Unprotected Data and Privacy . . . . . . . . . . . . . . 24
	7.6. Forward Secrecy within AT_ENCR . . . . . . . . . . . . . 24		7.6. Forward Secrecy within AT_ENCR . . . . . . . . . . . . . 24
	7.7. Post-Quantum Considerations . . . . . . . . . . . . . . . 25		7.7. Post-Quantum Considerations . . . . . . . . . . . . . . . 25
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	9.1. Normative References . . . . . . . . . . . . . . . . . . 27		9.1. Normative References . . . . . . . . . . . . . . . . . . 26
	9.2. Informative References . . . . . . . . . . . . . . . . . 28		9.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	Many different attacks have been reported as part of revelations		Many different attacks have been reported as part of revelations
	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 occur		card supply chain. Attacks revealing the AKA long-term key may occur
	skipping to change at page 3, line 34		skipping to change at page 3, line 22
	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 occur		card supply chain. Attacks revealing the AKA long-term key may occur
	for instance, during the manufacturing process of USIM cards, during		for instance, during the manufacturing process of USIM cards, during
	the transfer of the cards and associated information to the operator,		the transfer of the cards and associated information to the operator,
	and when a system is running. Since the publication of reports about		and when a system is running. Since the publication of reports about
	such attacks [Heist2015], manufacturing and provisioning processes		such attacks [Heist2015], manufacturing and provisioning processes
	have gained much scrutiny and have improved.		have gained 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 many		information about long-term keys is still a concern because these
	people use the service and these keys are high-value targets. Note		keys are high-value targets. Note that the attacks are largely
	that the attacks are largely independent of the used authentication		independent of the used authentication technology; the issue is not
	technology; the issue is not vulnerabilities in algorithms or		vulnerabilities in algorithms or protocols, but rather the
	protocols, but rather the possibility of someone gaining unauthorized		possibility of someone gaining unauthorized access to key material.
	access to key material. Furthermore, an explicit goal of the IETF is		Furthermore, an explicit goal of the IETF is to ensure that we
	to ensure that we understand the surveillance concerns related to		understand the surveillance concerns related to IETF protocols and
	IETF protocols and take appropriate countermeasures [RFC7258].		take appropriate countermeasures [RFC7258].
	While strong protection of manufacturing and other processes is		While strong protection of manufacturing and other processes is
	essential in mitigating the risks, there is one question that we as		essential in mitigating surveillance and other risks associated with
	protocol designers can ask. Is there something that we can do to		AKA long-term keys, there are also protocol mechanisms that can help.
	limit the consequences of attacks, should they occur?
	This document specifies an extension that helps defend against one
	aspect of pervasive surveillance. This is important, given the large
	number of users such practices may affect. It is also a stated goal
	of the IETF to ensure that we understand the surveillance concerns
	related to IETF protocols and take appropriate countermeasures
	[RFC7258]. This document does that for the improved Extensible
	Authentication Protocol Method for 3GPP Mobile Network Authentication
	and Key Agreement (EAP-AKA').
	This document updates [RFC9048], the 3GPP Mobile Network		This document updates [RFC9048], the Improved 3GPP Mobile Network
	Authentication and Key Agreement (EAP-AKA') method, with an optional		Authentication and Key Agreement (EAP-AKA') method, with an optional
	extension providing ephemeral key exchange minimizing the impact of		extension providing ephemeral key exchange minimizing the impact of
	long-term key compromise and strengthens the identity privacy		long-term key compromise and strengthens the identity privacy
	requirements. While optional, the use of this extension is strongly		requirements. This is important, given the large number of users of
	recommended.		AKA in mobile networks.
	The extension, when negotiated, provides Forward Secrecy (FS) for the
	session key generated as a part of the authentication run in EAP-
	AKA'. This prevents an attacker who has gained access to the long-
	term key in a USIM card from getting access to past session keys. In
	addition to FS, the included Diffie-Hellman exchange, forces
	attackers to be active if they want access to future session keys
	even if they have access to the long-term key. This is beneficial,
	because active attacks demand much more resources to launch, and are
	easier to detect. As with other protocols, an active attacker with
	access to the long-term key material will of course be able to attack
	all future communications, but risks detection, particularly if done
	at scale.
	Attacks against Authentication and Key Agreement (AKA) authentication		The extension, when negotiated, provides Forward Secrecy (FS)
	via compromising the long-term keys have been an active discussion		[DOW1992] for the session key generated as a part of the
	topic in many contexts. Forward secrecy [DOW1992] is on the list of		authentication run in EAP-AKA'. This prevents an attacker who has
	features for the next release of 3GPP (5G Phase 2), and this document		gained access to the long-term key in a USIM card from getting access
	provides a basis for providing this feature.		to past session keys. In addition to FS, the included Diffie-Hellman
			exchange, forces attackers to be active if they want access to future
			session keys even if they have access to the long-term key. This is
			beneficial, because active attacks demand much more resources to
			launch, and are easier to detect. As with other protocols, an active
			attacker with access to the long-term key material will of course be
			able to attack all future communications, but risks detection,
			particularly if done at scale.
	It should also be noted that 5G network architecture [TS.33.501]		It should also be noted that 5G network architecture [TS.33.501]
	includes the use of the EAP framework for authentication. While any		includes the use of the EAP framework for authentication. While any
	methods can be run, the default authentication method within that		methods can be run, the default authentication method within that
	context will be EAP-AKA'. As a result, improvements in EAP-AKA'		context will be EAP-AKA'. As a result, improvements in EAP-AKA'
	security have a potential to improve security for many users.		security have a potential to improve security for many users.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 6, line 26		skipping to change at page 5, line 49
	4.1. AKA		4.1. AKA
	We use the term Authentication and Key Agreement (AKA) for the main		We use the term Authentication and Key Agreement (AKA) for the main
	authentication and key agreement protocol used by 3GPP mobile		authentication and key agreement protocol used by 3GPP mobile
	networks from the third generation (3G) and onward. Later		networks from the third generation (3G) and onward. Later
	generations adds new features to AKA, but the core remains the same.		generations adds new features to AKA, but the core remains the same.
	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. USIM is technically just an		typically executes AKA in a USIM. USIM is technically just an
	application that can reside on a removable UICC, an embedded UICC, or		application that can reside on a removable UICC (Universal Integrated
	integrated in a Trusted Execution Environment (TEE). In this		Circuit Card), an embedded UICC, or integrated in a Trusted Execution
	document we use the term "USIM card" to refer to any Subscriber		Environment (TEE). In this document we use the term "USIM card" to
	Identity Module capable of running AKA.		refer to any Subscriber Identity Module capable of running AKA.
	The goal of AKA is to mutually authenticate the USIM and the so-		The goal of AKA is 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.		subscribers home operator's network.
	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.
	skipping to change at page 11, line 51		skipping to change at page 11, line 27
	| 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 TBA1 BY IANA.		This is set to TBA1 BY IANA.
	Length		Length
	The length of the attribute, set as other attributes in EAP-AKA		The length of the attribute, set as other attributes in EAP-AKA
	[RFC4187].		[RFC4187]. The length is expressed in multiples of 4 bytes. The
			length includes the attribute type field, the Length 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
	AT_KDF_FS and is calculated as follows:		AT_KDF_FS and is calculated as follows:
	* For X25519, the length of this value is 32 bytes, encoded as		* For X25519, the length of this value is 32 bytes, encoded as
	specified in [RFC7748] Section 5.		specified in [RFC7748] Section 5.
	* For P-256, the length of this value is 33 bytes, encoded using		* For P-256, the length of this value is 33 bytes, encoded using
	the compressed form specified in Section 2.3.3 of [SEC1].		the compressed form specified in Section 2.3.3 of [SEC1].
			Because the length of the attribute must be a multiple of 4 bytes,
			the sender pads the Value field with zero bytes when necessary.
	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 indicates the used or desired forward secrecy key		The AT_KDF_FS indicates the used or desired forward secrecy key
	generation function, if the Forward Secrecy (FS) extension is used.		generation function, if the Forward Secrecy (FS) extension is used.
	It will also indicate the used or desired ECDHE group. A new		It will also indicate the used or desired ECDHE group. A new
	attribute is needed to carry this information, as AT_KDF carries the		attribute is needed to carry this information, as AT_KDF carries the
	basic KDF value which is still used together with the forward secrecy		basic KDF value which is still used together with the forward secrecy
	skipping to change at page 16, line 39		skipping to change at page 16, line 20
	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.
	For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group		For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group
	(SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186]		(SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186]
	or alternatively Section 2.4.2 of [SEC2]. The support for this group		or alternatively Section 2.4.2 of [SEC2]. The support for this group
	is REQUIRED.		is REQUIRED.
	The term "support" here means that the group MUST be implemented and		The term "support" here means that the group MUST be implemented.
	MUST be possible to use during a protocol run.
	6.5. Message Processing		6.5. Message Processing
	This section specifies the changes related to message processing when		This section specifies the changes related to message processing when
	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]
	skipping to change at page 19, line 37		skipping to change at page 19, line 19
	6.5.11. EAP-Response/AKA'-Notification		6.5.11. EAP-Response/AKA'-Notification
	No changes.		No changes.
	7. Security Considerations		7. Security Considerations
	This section deals only with the changes to security considerations		This section deals only with the changes to security considerations
	as they differ from EAP-AKA', or as new information has been gathered		as they differ from EAP-AKA', or as new information has been gathered
	since the publication of [RFC9048].		since the publication of [RFC9048].
	As discussed earlier (see Section 1 and Section 4.3, forward secrecy		As discussed in Section 1, forward secrecy is an important
	is an important countermeasure against well-resourced adversaries		countermeasure against adversaries who gain access to the long-term
	that who may get access to the long-term keys, see Section 1. Many		keys. The long-term keys can be best protected with good processes,
	of the attacks against these keys can be best dealt with improved		e.g., restricting access to the key material within a factory or
	processes, e.g., limiting the access to the key material within the		among personnel, etc. Even so, not all attacks can be entirely ruled
	factory or personnel, etc. But not all attacks can be entirely ruled		out. For instance, well-resourced adversaries may be able to coerce
	out for well-resourced adversaries, irrespective of what the		insiders to collaborate, despite any technical protection measures.
	technical algorithms and protection measures are. And the likelihood		The zero trust principles suggest that we assume that breaches are
	of practically feasible attacks has increased. To assume that a		inevitable or have potentially already occurred, and that we need to
	breach is inevitable or has likely already occurred [NSA-ZT], and to		minimize the impact of these breaches [NSA-ZT] [NIST-ZT]. One type
	minimize impact when breaches occur [NIST-ZT] are essential zero		of breach is key compromise or key exfiltration.
	trust principles. One type of breach is key compromise or key
	exfiltration.
	If a mechanism without ephemeral key exchange such as (5G-AKA, EAP-		If a mechanism without ephemeral key exchange such as (5G-AKA, EAP-
	AKA') is used the effects of key compromise are devastating. There		AKA') is used the effects of key compromise are devastating. There
	are serious consequences of not properly providing forward secrecy		are serious consequences of not properly providing forward secrecy
	for the key establishment. For both control and user plane, and both		for the key establishment. For both control and user plane, and 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 UE or the Network and		3. An active attacker can impersonate the UE or the Network and
	inject messages in an ongoing 5G connection between the real UE		inject messages in an ongoing 5G connection between the real UE
	and the real network.		and the real network.
	Best practice security today is to mandate forward secrecy (as is		Best practice security today is to mandate forward secrecy (as is
	done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard,		done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard,
	Signal, etc.). It is RECOMMENDED that EAP-AKA methods without		Signal, etc.). It is recommended that in deployments, EAP-AKA
	forward secrecy be phased out in the long term.		methods without forward secrecy be phased out in the long term.
	This extension provide assistance against passive attacks from		This extension provide assistance against passive attacks from
	attackers that have comprimised 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 much less resources and are much		pervasive monitoring as they require much less 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 they are forced to be a Man-In-The-Middle (MITM)		active attacks as the attacker is forced to be on path during the AKA
	during the AKA run and subsequent communication between the parties.		run and subsequent communication between the parties. Without
	Without forward secrecy an active attacker that has compromised the		forward secrecy an active attacker that has compromised the long-term
	long-term key can inject messages in an connection between the real		key can inject messages in an connection between the real Peer and
	Peer and the real server without being a man-in-the-middle. This		the real server without being on path. This extension is most useful
	extension is most useful when used in a context where the MSK/EMSK		when used in a context where the MSK/EMSK are used in protocols not
	are used in protocols not providing forward secrecy. For instance,		providing forward secrecy. For instance, if used with IKEv2
	if used with IKEv2 [RFC7296], the session keys produced by IKEv2 have		[RFC7296], the session keys produced by IKEv2 have this property, so
	this property, so better characteristics of the MSK and EMSK is not		better characteristics of the MSK and EMSK is not that useful.
	that useful. However, typical link layer usage of EAP does not		However, typical link layer usage of EAP does not involve running
	involve running another, forward secure, key exchange. Therefore,		another, forward secure, key exchange. Therefore, using EAP to
	using EAP to authenticate access to a network is one situation where		authenticate access to a network is one situation where the extension
	the extension defined in this document can be helpful.		defined in this document can be helpful.
	This extension generates keying material using the ECDHE exchange in		This extension generates keying material using the ECDHE exchange 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 forgotten, 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 a MITM attack on future		with access to the long-term key that mount an on-path attack on
	EAP-AKA' runs will be able to eavesdrop on the traffic protected by		future EAP-AKA' runs will be able to eavesdrop on the traffic
	the resulting session key(s). Still, past sessions where FS was in		protected by the resulting session key(s). Still, past sessions
	use remain protected.		where FS was in use remain protected.
	Using EAP-AKA' FS once provides forward secrecy. Forward secrecy		Using EAP-AKA' FS once provides forward secrecy. Forward secrecy
	limits the effect of key leakage in one direction (compromise of a		limits the effect of key leakage in one direction (compromise of a
	key at time T2 does not compromise some key at time T1 where T1 <		key at time T2 does not compromise some key at time T1 where T1 <
	T2). Protection in the other direction (compromise at time T1 does		T2). Protection in the other direction (compromise at time T1 does
	not compromise keys at time T2) can be achieved by rerunning ECDHE		not compromise keys at time T2) can be achieved by rerunning ECDHE
	frequently. If a long-term authentication key has been compromised,		frequently. If a long-term authentication key has been compromised,
	rerunning EAP-AKA' FS gives protection against passive attackers.		rerunning EAP-AKA' FS gives protection against passive attackers.
	Using the terms in [RFC7624], forward secrecy without rerunning ECDHE		Using the terms in [RFC7624], forward secrecy without rerunning ECDHE
	does not stop an attacker from doing static key exfiltration.		does not stop an attacker from doing static key exfiltration.
	Frequently rerunning EC(DHE) forces an attacker to do dynamic key		Frequently rerunning EC(DHE) forces an attacker to do dynamic key
	exfiltration (or content exfiltration).		exfiltration (or content exfiltration).
	7.1. Deployment Considerations		7.1. Deployment Considerations
	Achieving FS requires that when a connection is closed, each endpoint		Achieving FS requires that when a connection is closed, each endpoint
	MUST forget not only the ephemeral keys used by the connection but		MUST destroy not only the ephemeral keys used by the connection but
	also any information that could be used to recompute those keys.		also any information that could be used to recompute those keys.
	Similarly, other parts of the system matter. For instance, when the		Similarly, other parts of the system matter. For instance, when the
	keys generated by EAP are transported to a pass-through		keys generated by EAP are transported to a pass-through
	authenticator, such transport must also provide forward secure		authenticator, such transport must also provide forward secure
	encryption with respect to the long-term keys used to establish its		encryption with respect to the long-term keys used to establish its
	security. Otherwise, an adversary may attack the transport		security. Otherwise, an adversary may attack the transport
	connection used to carry keys from EAP, and use this method to gain		connection used to carry keys from EAP, and use this method to gain
	access to current and past keys from EAP, which in turn would lead to		access to current and past keys from EAP, which in turn would lead to
	the compromise of anything protected by those EAP keys.		the compromise of anything protected by those EAP keys.
	skipping to change at page 22, line 33		skipping to change at page 22, line 21
	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		Except of course, if the adversary holds the long-term key and
	is willing to engage in an active attack. Such an attack can,		is willing to engage in an active attack. Such an attack can,
	for instance, forge the negotiation process so that no FS will		for instance, forge the negotiation process so that no FS will
	be provided. However, as noted above, an attacker with these		be provided. However, as noted above, an attacker with these
	capabilities will in any case be able to impersonate any party		capabilities will in any case be able to impersonate any party
	in the protocol and perform MITM attacks. That is not a		in the protocol and perform on-path attacks. That is not a
	situation that can be improved by a technical solution.		situation that can be improved by a technical solution.
	However, as discussed in the introduction, even an attacker		However, as discussed in the introduction, even an attacker
	with access to the long-term keys is required to be a MITM on		with access to the long-term keys is required to be on path on
	each AKA run and subsequent communication, which makes mass		each AKA run and subsequent communication, which makes mass
	surveillance more laborious.		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
	skipping to change at page 26, line 20		skipping to change at page 26, line 10
	the use of a KEM might require other changes such as including the		the use of a KEM might require other changes such as including the
	ephemeral public key of the server in the key derivation to retain		ephemeral public key of the server in the key derivation to retain
	the property that both parties contribute randomness to the session		the property that both parties contribute randomness to the session
	key.		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 Extensible Authentication Protocol Method for Global System for		with Extensible Authentication Protocol Method for Global System for
	Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)		Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
	[RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].		[RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048].
	Two new values (TBA1, TBA2) in the skippable range need to be		Two new values (TBA1, TBA2) in the skippable range need to be
	assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2)		assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2)
	in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM		in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM
	Parameters" group.		Parameters" group.
	Also, IANA is requested to create a new registry "EAP-AKA' AT_KDF_FS		Also, IANA is requested to create a new registry "EAP-AKA' AT_KDF_FS
	Key Derivation Function Values" to represent FS Key Derivation		Key Derivation Function Values" to represent FS Key Derivation
	Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA'		Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA'
	with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be		with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be
	assigned, along with one reserved value. The initial contents of		assigned, along with one reserved value. The initial contents of
	this registry is illustrated in Table 1; new values can be created		this registry is illustrated in Table 1; new values can be created
	through the Specification Required policy [RFC8126].		through the Specification Required policy [RFC8126]. Expert
			reviewers should ensure that the referenced specification is clearly
			identified and stable, and that the proposed addition is reasonable
			for the given category of allocation.
	+=========+==================+=========================+		+=========+==================+=========================+
	| Value | Description | Reference |		| Value | Description | Reference |
	+=========+==================+=========================+		+=========+==================+=========================+
	| 0 | Reserved | [TBD BY IANA: THIS RFC] |		| 0 | Reserved | [TBD BY IANA: THIS RFC] |
	+---------+------------------+-------------------------+		+---------+------------------+-------------------------+
	| 1 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |		| 1 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
	| | ECDHE and X25519 | |		| | ECDHE and X25519 | |
	+---------+------------------+-------------------------+		+---------+------------------+-------------------------+
	| 2 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |		| 2 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
	skipping to change at page 29, line 46		skipping to change at page 29, line 41
	[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>.
	Appendix A. Change Log		Appendix A. Change Log
	RFC Editor: Please remove this appendix.		RFC Editor: Please remove this appendix.
			The -12 version of the WG draft has the following changes, most due
			to IESG review comments in January 2023:
			* Update the draft track to Standards Track.
			* Clarified the calculation of the Length field in the AT_ECDHE
			attribute, along with padding requirements.
			* Avoided the use of keywords in operational recommendations, e.g.,
			about deployment.
			* Changed the definition of what "supported" means to focus on
			feature being implemented, but not require that it is usable
			during a protocol run, because configuration, new security
			information, etc. might imply that a particular feature is
			implemented but disabled for policy reasons.
			* Changed the MITM terminology to be on-path attacks.
			* Corrected a reference typo in the IANA considerations section.
			* Shortened the abstract and introduction to the key aspects and
			removed duplication.
			* Several editorial changes.
	The -11 version of the WG draft has the following changes:		The -11 version of the WG draft has the following changes:
	* Addressed IETF Last Call comments from directorates, Security AD,		* Addressed IETF Last Call comments from directorates, Security AD,
	Meiling Cheng, and a detailed review from the author Karl. In		Meiling Cheng, and a detailed review from the author Karl. In
	particular:		particular:
	* Replaced the reference to the deprecated FIPS 186-4 with SP		* Replaced the reference to the deprecated FIPS 186-4 with SP
	800-186.		800-186.
	* Changed HSS to Authentication Database (AD) as HSS is a 4G term.		* Changed HSS (Home Subscriber Server) to Authentication Database
			(AD) as HSS is a 4G term.
	* Explained difference between EAP-AKA and EAP-AKA'		* Explained difference between EAP-AKA and EAP-AKA'
	* Explained that the emphemeral key exhange provide more that		* Explained that the emphemeral key exhange provide more that
	forward secrecy and how this is important to mitigate pervasive		forward secrecy and how this is important to mitigate pervasive
	monitoring.		monitoring.
	* Included links for the zero trust principles.		* Included links for the zero trust principles.
	* Explained why K_encr and K_auth not being protected by the ECDHE		* Explained why K_encr and K_auth not being protected by the ECDHE
	skipping to change at page 33, line 19		skipping to change at page 33, line 39
	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
	uses also a lot of material from [RFC4187] by J. Arkko and		uses also 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.
	The authors would also like to thank Ben Campbell, Meiling Chen,		The authors would also like to thank Ben Campbell, Meiling Chen,
	Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero Kivinen, Eliot		Roman Danyliw, Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero
	Lear, Vesa Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi,		Kivinen, Murray Kucherawy, Warren Kumari, Eliot Lear, Vesa
	Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Sahlin, Joseph		Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Francesca
	Salowey, Mohit Sethi, Rene Struik, Vesa Torvinen, Sean Turner, Helena		Palombini, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt
	Vahidi Mazinani, Paul Wouters, Bo Wu, and many other people at the		Sahlin, Joseph Salowey, Mohit Sethi, Orie Steele, Rene Struik, Vesa
	IETF, GSMA and 3GPP groups for interesting discussions in this		Torvinen, Sean Turner, Helena Vahidi Mazinani, Robert Wilton, Paul
	problem space.		Wouters, Bo Wu, Peter Yee, and many other people at the IETF, GSMA
			and 3GPP groups for interesting discussions in this problem space.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	FI-02420 Jorvas		FI-02420 Jorvas
	Finland		Finland
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
	Karl Norrman		Karl Norrman
	Ericsson		Ericsson
	SE-16483 Stockholm		SE-16483 Stockholm
	Sweden		Sweden
End of changes. 37 change blocks.
	127 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/