draft-ietf-emu-aka-pfs-06.txt		draft-arkko-eap-aka-pfs.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft K. Norrman		Internet-Draft K. Norrman
	Updates: RFC5448 (if approved) V. Torvinen		Updates: RFC5448 (if approved) V. Torvinen
	Intended status: Informational Ericsson		Intended status: Informational J. Mattsson
	Expires: September 8, 2022 March 7, 2022		Expires: January 12, 2023 Ericsson
			July 11, 2022
	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-06		draft-ietf-emu-aka-pfs-07
	Abstract		Abstract
	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 smart cards, such as attacking SIM card		involved compromising the smart card supply chain, such as attacking
	manufacturers and operators in an effort to compromise shared secrets		SIM card manufacturers and operators in an effort to compromise
	stored on these cards. Since the publication of those reports,		shared secrets stored on these cards. Since the publication of those
	manufacturing and provisioning processes have gained much scrutiny		reports, manufacturing and provisioning processes have gained much
	and have improved. However, the danger of resourceful attackers for		scrutiny and have improved. However, the danger of resourceful
	these systems is still a concern.		attackers for these systems is still a concern. Always assuming
			breach such as key compromise and minimizing the impact of breach are
			essential zero-trust principles.
	This specification is an optional extension to the EAP-AKA'		This specification is an optional extension to the EAP-AKA'
	authentication method which was defined in [RFC9048]. The extension,		authentication method which was defined in [RFC9048]. The extension,
	when negotiated, provides Forward Secrecy for the session key		when negotiated, provides Forward Secrecy for the session key
	generated as a part of the authentication run in EAP-AKA'. This		generated as a part of the authentication run in EAP-AKA'. This
	prevents an attacker who has gained access to the long-term pre-		prevents an attacker who has gained access to the long-term pre-
	shared secret in a SIM card from being able to decrypt any past		shared secret in a SIM card from being able to decrypt any past
	communications. In addition, if the attacker stays merely a passive		communications. In addition, if the attacker stays merely a passive
	eavesdropper, the extension prevents attacks against future sessions.		eavesdropper, the extension prevents attacks against future sessions.
	This forces attackers to use active attacks instead.		This forces attackers to use active attacks instead.
	skipping to change at page 1, line 49		skipping to change at page 2, line 7
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 8, 2022.		This Internet-Draft will expire on January 12, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 48		skipping to change at page 3, line 4
	6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16		6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16
	6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16		6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16
	6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17		6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17
	6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17		6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17
	6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 17		6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 17
	6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18		6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18
	6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18		6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18
	6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18		6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18
	6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18		6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		7.1. Identity Privacy . . . . . . . . . . . . . . . . . . . . 23
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	9.1. Normative References . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . 23		9.1. Normative References . . . . . . . . . . . . . . . . . . 23
			9.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	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 smart cards, such as attacking SIM card		involved compromising the smart card supply chain, such as attacking
	manufacturers and operators in an effort to compromise shared secrets		SIM card manufacturers and operators in an effort to compromise
	stored on these cards. Such attacks are conceivable, for instance,		shared secrets stored on these cards. Such attacks are conceivable,
	during the manufacturing process of cards, or during the transfer of		for instance, during the manufacturing process of cards, or during
	cards and associated information to the operator. Since the		the transfer of cards and associated information to the operator.
	publication of reports about such attacks, manufacturing and		Since the publication of reports about such attacks, manufacturing
	provisioning processes have gained much scrutiny and have improved.		and provisioning processes 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 SIM cards is still a concern. They are a high-		information about SIM cards is still a concern. They are a high-
	value target and concern a large number of people. Note that the		value target and concern a large number of people. Note that the
	attacks are largely independent of the used authentication		attacks are largely independent of the used authentication
	technology; the issue is not vulnerabilities in algorithms or		technology; the issue is not vulnerabilities in algorithms or
	protocols, but rather the possibility of someone gaining unlawful		protocols, but rather the possibility of someone gaining unlawful
	access to key material. While the better protection of manufacturing		access to key material. While the better protection of manufacturing
	and other processes is essential in protecting against this, there is		and other processes is essential in protecting against this, there is
	one question that we as protocol designers can ask. Is there		one question that we as protocol designers can ask. Is there
	skipping to change at page 8, line 39		skipping to change at page 8, line 39
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	5. Protocol Overview		5. Protocol Overview
	Introducing FS for EAP-AKA' can be achieved by using an Elliptic		Introducing FS for EAP-AKA' can be achieved by using an Elliptic
	Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' FS this		Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' FS this
	exchange is run in an ephemeral manner, i.e., both sides generate		exchange is run in an ephemeral manner, i.e., both sides generate
	temporary keys as specified in [RFC7748]. This method is referred to		temporary keys as specified in [RFC7748]. This method is referred to
	as ECDHE, where the last 'E' stands for Ephemeral.		as ECDHE, where the last 'E' stands for Ephemeral. The two intially
			registered elliptic curves and their wire format is chosen to align
			with the elliptic curves and formats specified for Subscription
			Concealed Identifier (SUCI) encryption in 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 can ignore.		that legacy implementations can 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 keying 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
	skipping to change at page 18, line 33		skipping to change at page 18, line 33
	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].
	The possibility of attacks against key storage offered in SIM or		The possibility of attacks against key storage offered in SIM or
	other smart cards has been a known threat. But as the discussion in		other smart cards has been a known threat. But as the discussion in
	Section 3.3 shows, the likelihood of practically feasible attacks has		Section 3.3 shows, the likelihood of practically feasible attacks
	increased. Many of these attacks can be best dealt with improved		such as breaches in the smart card supply chain has increased. Many
	processes, e.g., limiting the access to the key material within the		of these attacks can be best dealt with improved processes, e.g.,
	factory or personnel, etc. But not all attacks can be entirely ruled		limiting the access to the key material within the factory or
	out for well-resourced adversaries, irrespective of what the		personnel, etc. But not all attacks can be entirely ruled out for
	technical algorithms and protection measures are.		well-resourced adversaries, irrespective of what the technical
			algorithms and protection measures are. Always assuming breach such
			as key compromise and minimizing the impact of breach are essential
			zero-trust principles.
			If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is
			used the effects of key compromise are devastating. The serious
			consequences of breach somewhere in the supply chain or after
			delivery that are possible when 5G-AKA or EAP-AKA' is used but not
			when something with forward secrecy like EAP-AKA-FS is used are: 1.
			A passive attacker can eavesdrop (decrypt) all future 5G
			communication (control and user plane both directions), 2. A passive
			attacker can decrypt 5G communication that they previously recorded
			in the past (control and user plane both directions), and 3. An
			active attacker can impersonate UE and Network and inject messages in
			an ongoing 5G connection between the real UE and the real network
			(control and user plane both directions).
			Best practice security today is to mandate forward secrecy (as is
			done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, etc). It is RECOMMENDED to
			long term completely phase out AKA without forward secrecy.
	This extension can provide assistance in situations where there is a		This extension can provide assistance in situations where there is a
	danger of attacks against the key material on SIM cards by		danger of attacks against the key material on SIM cards by
	adversaries that can not or who are unwilling to mount active attacks		adversaries that cannot or who are unwilling to mount active attacks
	against large number of sessions. This extension is most useful when		against large number of sessions. The extension also provides
	used in a context where EAP keys are used without further mixing that		protection against active attacks as they are forced to be a Man-In-
	can provide Forward Secrecy. For instance, when used with IKEv2		The-Middle (MITM) during the AKA run and subsequent communication
			between the parties. Without forward secrecy an an active attacker
			that has compromised the long-term key can inject messages in an
			connection betwen the real Peer and the real server without being a
			man-in-the-middle. This extension is most useful when used in a
			context where EAP keys are used without further mixing that can
			provide Forward Secrecy. For instance, when used with IKEv2
	[RFC7296], the session keys produced by IKEv2 have this property, so		[RFC7296], the session keys produced by IKEv2 have this property, so
	better characteristics of EAP keys is not that useful. However,		better characteristics of EAP keys is not that useful. However,
	typical link layer usage of EAP does not involve running Diffie-		typical link layer usage of EAP does not involve running Diffie-
	Hellman, so using EAP to authenticate access to a network is one		Hellman, so using EAP to authenticate access to a network is one
	situation where the extension defined in this document can be		situation where the extension defined in this document can be
	helpful.		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
	skipping to change at page 19, line 28		skipping to change at page 20, line 5
	there is no protection that that can be provided for future sessions.		there is no protection that that can be provided for future sessions.
	Among other things, such an active attacker can impersonate any		Among other things, such an active attacker can impersonate any
	legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the		legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the
	extension defined in this document, retrieve all keys, or turn off		extension defined in this document, retrieve all keys, or turn off
	FS. Still, past sessions where FS was in use remain protected.		FS. Still, past sessions where FS was in use remain protected.
	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 forget 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.
			Using EAP-AKA' FS once provides forward secrecy. Forward secrecy
			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 <
			T2). Protection in the other direction (compromise at time T1 does
			not compromise keys at time T2) can be achieved by rerunning ECDHE
			frequently. If a long-term authentication key has been compromised,
			rerunning EAP-AKA' FS gives protection against passive attackers.
			Using the terms in [RFC7624], forward secrecy without rerunning ECDHE
			does not stop an attacker from doing static key exfiltration.
			Frequently rerunning EC(DHE) forces an attacker to do dynamic key
			exfiltration (or content exfiltration).
	The following security properties of EAP-AKA' are impacted through		The following security properties of EAP-AKA' are impacted through
	this extension:		this extension:
	Protected ciphersuite negotiation		Protected ciphersuite negotiation
	EAP-AKA' has a negotiation mechanism for selecting the key		EAP-AKA' has a negotiation mechanism for selecting the key
	derivation functions, and this mechanism has been extended by the		derivation functions, and this mechanism has been extended by the
	extension specified in this document. The resulting mechanism		extension specified in this document. The resulting mechanism
	continues to be secure against bidding down attacks.		continues to be secure against bidding down attacks.
	skipping to change at page 22, line 20		skipping to change at page 23, line 7
	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 secret		that the parties need to show possession of the long-term secret
	in some way, and only then will the FS calculations become active.		in some way, and only then will the FS calculations become active.
	This limits the Denial-of-Service to specific, identified		This limits the Denial-of-Service to specific, identified
	subscribers. While botnets and other forms of malicious parties		subscribers. While botnets and other forms of malicious parties
	could take advantage of actual subscribers and their key material,		could take advantage of actual subscribers and their key material,
	at least such attacks are (a) limited in terms of subscribers they		at least such attacks are (a) limited in terms of subscribers they
	control, and (b) identifiable for the purposes of blocking the		control, and (b) identifiable for the purposes of blocking the
	affected subscribers.		affected subscribers.
			7.1. Identity Privacy
			Best practice privacy today is to mandate client identity protection
			as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc. A client supporting
			EAP-AKA' FS MUST NOT send its username (or any other permanent
			identifiers) in cleartext in the Identity Response (or any message
			used instead of the Identity Response).
	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 EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].		with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].
	Two new Attribute Type value (TBA1, TBA2) in the skippable range need		Two new Attribute Type value (TBA1, TBA2) in the skippable range need
	to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS		to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS
	(Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under		(Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under
	Attribute Types.		Attribute Types.
	skipping to change at page 25, line 7		skipping to change at page 25, line 43
	2015, in https://firstlook.org/theintercept/2015/02/19/		2015, in https://firstlook.org/theintercept/2015/02/19/
	great-sim-heist/ .		great-sim-heist/ .
	[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,		[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,
	"Authentication and Authenticated Key Exchanges", June		"Authentication and Authenticated Key Exchanges", June
	1992, in Designs, Codes and Cryptography 2 (2): pp.		1992, in Designs, Codes and Cryptography 2 (2): pp.
	107-125.		107-125.
	Appendix A. Change Log		Appendix A. Change Log
			The -07 version of the WG draft has the following changes:
			o The impact of forward secrecy explanation has been improved in the
			abstract and security considerations.
			o The draft now more forcefully explains why the authors believe it
			is important to migrate existing systems to use forward secrecy,
			and makes a recommendation for this migration.
			o The draft does no longer refer to issues within the smart cards
			but rather the smart card supply chain.
			o The rationale for chosen algorithms is explained.
			o Also, the authors have checked the language relating to the public
			value encoding, and believe it is exactly according to the
			references ([RFC7748] Section 6.1 and [SEC2] Section 2.7.1)
	The -06 version of the WG draft is a refresh and a reference update.		The -06 version of the WG draft is a refresh and a reference update.
	However, the following should be noted:		However, the following should be noted:
	o The draft now uses "forward secrecy" terminology and references		o The draft now uses "forward secrecy" terminology and references
	RFC 7624 per recommendations on mailing list discussion.		RFC 7624 per recommendations on mailing list discussion.
	o There's been mailing list disccussion about the encoding of the		o There's been mailing list disccussion about the encoding of the
	public values; the current text requires confirmation from the		public values; the current text requires confirmation from the
	working group that it is sufficient.		working group that it is sufficient.
	skipping to change at line 1208		skipping to change at page 28, line 10
	Stockholm 16483		Stockholm 16483
	Sweden		Sweden
	Email: karl.norrman@ericsson.com		Email: karl.norrman@ericsson.com
	Vesa Torvinen		Vesa Torvinen
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: vesa.torvinen@ericsson.com		Email: vesa.torvinen@ericsson.com
			John Mattsson
			Ericsson
			Kista 164 40
			Sweden
			Email: john.mattsson@ericsson.com
End of changes. 14 change blocks.
	34 lines changed or deleted		107 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/