draft-arkko-eap-aka-pfs-04.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
	Intended status: Informational V. Torvinen		Updates: RFC5448 (if approved) V. Torvinen
	Expires: July 25, 2019 Ericsson		Intended status: Informational Ericsson
	January 21, 2019		Expires: May 21, 2020 November 18, 2019
	Perfect-Forward Secrecy for the Extensible Authentication Protocol		Perfect-Forward Secrecy for the Extensible Authentication Protocol
	Method for Authentication and Key Agreement (EAP-AKA' PFS)		Method for Authentication and Key Agreement (EAP-AKA' PFS)
	draft-arkko-eap-aka-pfs-04		draft-ietf-emu-aka-pfs-02
	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 smart cards, such as attacking SIM card
	manufacturers and operators in an effort to compromise shared secrets		manufacturers and operators in an effort to compromise shared secrets
	stored on these cards. Since the publication of those reports,		stored on these cards. Since the publication of those reports,
	manufacturing and provisioning processes have gained much scrutiny		manufacturing and provisioning processes have gained much scrutiny
	and have improved. However, the danger of resourceful attackers for		and have improved. However, the danger of resourceful attackers for
	these systems is still a concern.		these systems is still a concern.
	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 RFC 5448 (to be superseded		authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
	by draft-ietf-emu-rfc5448bis). The extension, when negotiated,		The extension, when negotiated, provides Perfect Forward Secrecy for
	provides Perfect Forward Secrecy for the session key generated as a		the session key generated as a part of the authentication run in EAP-
	part of the authentication run in EAP-AKA'. This prevents an		AKA'. This prevents an attacker who has gained access to the long-
	attacker who has gained access to the long-term pre-shared secret in		term pre-shared secret in a SIM card from being able to decrypt any
	a SIM card from being able to decrypt all past communications. In		past communications. In addition, if the attacker stays merely a
	addition, if the attacker stays merely a passive eavesdropper, the		passive eavesdropper, the extension prevents attacks against future
	extension prevents attacks against future sessions. This forces		sessions. This forces attackers to use active attacks instead.
	attackers to use active attacks instead.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 25, 2019.
			This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 3, line 42		skipping to change at page 3, line 40
	The authors want to provide a public specification of an extension		The authors want to provide a public specification of an extension
	that helps defend against one aspect of pervasive surveillance. This		that helps defend against one aspect of pervasive surveillance. This
	is important, given the large number of users such practices may		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		affect. It is also a stated goal of the IETF to ensure that we
	understand the surveillance concerns related to IETF protocols and		understand the surveillance concerns related to IETF protocols and
	take appropriate countermeasures [RFC7258]. This document does that		take appropriate countermeasures [RFC7258]. This document does that
	for EAP-AKA'.		for EAP-AKA'.
	This specification is an optional extension to the EAP-AKA'		This specification is an optional extension to the EAP-AKA'
	authentication method [RFC5448] (to be superseded by		authentication method [I-D.ietf-emu-rfc5448bis]. While optional, the
	[I-D.ietf-emu-rfc5448bis]). The extension, when negotiated, provides		use of this extension is RECOMMENDED.
	Perfect Forward Secrecy for the session key generated as a part of
	the authentication run in EAP-AKA'. This prevents an attacker who		The extension, when negotiated, provides Perfect Forward Secrecy for
	has gained access to the long-term pre-shared secret in a SIM card		the session key generated as a part of the authentication run in EAP-
	from being able to decrypt all past communications. In addition, if		AKA'. This prevents an attacker who has gained access to the long-
	the attacker stays merely a passive eavesdropper, the extension		term pre-shared secret in a SIM card from being able to decrypt any
	prevents attacks against future sessions. This forces attackers to		past communications. In addition, if the attacker stays merely a
	use active attacks instead. As with other protocols, an active		passive eavesdropper, the extension prevents attacks against future
	attacker with access to the long-term key material will of course be		sessions. This forces attackers to use active attacks instead. As
	able to attack all future communications, but risks detection,		with other protocols, an active attacker with access to the long-term
	particularly if done at scale.		key material will of course be able to attack all future
			communications, but risks detection, particularly if done at scale.
	Attacks against AKA authentication via compromising the long-term		Attacks against AKA authentication via compromising the long-term
	secrets in the SIM cards have been an active discussion topic in many		secrets in the SIM cards have been an active discussion topic in many
	contexts. Perfect forward secrecy is on the list of features for the		contexts. Perfect forward secrecy is on the list of features for the
	next release of 3GPP (5G Phase 2), and this document provides a basis		next release of 3GPP (5G Phase 2), and this document provides a basis
	for providing this feature in a particular fashion.		for providing this feature in a particular fashion.
	It should also be noted that 5G network architecture includes the use		It should also be noted that 5G network architecture includes the use
	of the EAP framework for authentication. While any methods can be		of the EAP framework for authentication. While any methods can be
	run, the default authentication method within that context will be		run, the default authentication method within that context will be
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	practical systems perfect forward secrecy can be enabled for		practical systems perfect forward secrecy can be enabled for
	either all or significant fraction of users.		either all or significant fraction of users.
	3. Background		3. Background
	3.1. AKA		3.1. AKA
	AKA is based on challenge-response mechanisms and symmetric		AKA is based on challenge-response mechanisms and symmetric
	cryptography. AKA typically runs in a UMTS Subscriber Identity		cryptography. AKA typically runs in a UMTS Subscriber Identity
	Module (USIM) or a CDMA2000 (Removable) User Identity Module		Module (USIM) or a CDMA2000 (Removable) User Identity Module
	((R)UIM). In contrast with its earlier GSM counterparts, 3rd		((R)UIM). In contrast with its earlier GSM counterparts, AKA
	generation AKA provides long key lengths and mutual authentication.		provides long key lengths and mutual authentication.
	AKA works in the following manner:		AKA works in the following manner:
	o The identity module and the home environment have agreed on a		o The identity module and the home environment have agreed on a
	secret key beforehand.		secret key beforehand.
	o The actual authentication process starts by having the home		o The actual authentication process starts by having the home
	environment produce an authentication vector, based on the secret		environment produce an authentication vector, based on the secret
	key and a sequence number. The authentication vector contains a		key and a sequence number. The authentication vector contains a
	random part RAND, an authenticator part AUTN used for		random part RAND, an authenticator part AUTN used for
	skipping to change at page 8, line 19		skipping to change at page 8, line 19
	The general security properties and potential vulnerabilities of AKA		The general security properties and potential vulnerabilities of AKA
	and EAP-AKA' are discussed in [I-D.ietf-emu-rfc5448bis].		and EAP-AKA' are discussed in [I-D.ietf-emu-rfc5448bis].
	An important vulnerability in that discussion relates to the recent		An important vulnerability in that discussion relates to the recent
	reports of compromised long term pre-shared keys used in AKA		reports of compromised long term pre-shared keys used in AKA
	[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as		[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as
	all security systems fail at least to some extent if key material is		all security systems fail at least to some extent if key material is
	stolen. However, the reports indicate a need to look into solutions		stolen. However, the reports indicate a need to look into solutions
	that can operate at least to an extent under these types of attacks.		that can operate at least to an extent under these types of attacks.
	It is noted in [Heist2015] that some security can be retained even in		It is noted in [Heist2015] that some security can be retained even in
	the face of the attacks by providing Perfect Forward Security (PFS)		the face of the attacks by providing Perfect Forward Secrecy (PFS)
	[DOW1992] for the session key. If AKA would have provided PFS,		[DOW1992] for the session key. If AKA would have provided PFS,
	compromising the pre-shared key would not be sufficient to perform		compromising the pre-shared key would not be sufficient to perform
	passive attacks; the attacker is, in addition, forced to be a Man-In-		passive attacks; the attacker is, in addition, forced to be a Man-In-
	The-Middle (MITM) during the AKA run and subsequent communication		The-Middle (MITM) during the AKA run and subsequent communication
	between the parties.		between the parties.
	4. Requirements Language		4. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at page 23, line 31		skipping to change at page 23, line 31
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[I-D.ietf-emu-rfc5448bis]		[I-D.ietf-emu-rfc5448bis]
	Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,		Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
	"Improved Extensible Authentication Protocol Method for		"Improved Extensible Authentication Protocol Method for
	3rd Generation Authentication and Key Agreement (EAP-		3GPP Mobile Network Authentication and Key Agreement (EAP-
	AKA')", draft-ietf-emu-rfc5448bis-04 (work in progress),		AKA')", draft-ietf-emu-rfc5448bis-05 (work in progress),
	January 2019.		July 2019.
	9.2. Informative References		9.2. Informative References
	[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,
	<https://www.rfc-editor.org/info/rfc4186>.		<https://www.rfc-editor.org/info/rfc4186>.
	[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS		[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
	skipping to change at page 24, line 37		skipping to change at page 24, line 37
	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 -02 version of the WG draft took into account additional reviews,
			and changed the document to update RFC 5448 (or rather, its
			successor, [I-D.ietf-emu-rfc5448bis]), and changed the wording of the
			recommendation with regards to the use of this extension. Some
			editorial changes were also made.
			The -00 and -01 versions of the WG draft made no major changes, only
			updates to some references.
			The -05 version is merely a refresh while the draft was waiting for
			WG adoption.
	The -04 version of this draft made only editorial changes.		The -04 version of this draft made only editorial changes.
	The -03 version of this draft changed the naming of various protocol		The -03 version of this draft changed the naming of various protocol
	components, values, and notation to match with the use of ECDH in		components, values, and notation to match with the use of ECDH in
	ephemeral mode. The AT_KDF_PFS negotiation process was clarified in		ephemeral mode. The AT_KDF_PFS negotiation process was clarified in
	that exactly one key is ever sent in AT_KDF_ECDHE. The option of		that exactly one key is ever sent in AT_KDF_ECDHE. The option of
	checking for zero key values IN ECDHE was added. The format of the		checking for zero key values IN ECDHE was added. The format of the
	actual key in AT_PUB_ECDHE was specified. Denial-of-service		actual key in AT_PUB_ECDHE was specified. Denial-of-service
	considerations for the PFS process have been updated. Bidding down		considerations for the PFS process have been updated. Bidding down
	attacks against this extension itself are discussed extensively.		attacks against this extension itself are discussed extensively.
End of changes. 9 change blocks.
	32 lines changed or deleted		45 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/