draft-arkko-eap-aka-pfs-03.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		Intended status: Informational V. Torvinen
	Expires: April 26, 2019 Ericsson		Expires: July 25, 2019 Ericsson
	October 23, 2018		January 21, 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-03		draft-arkko-eap-aka-pfs-04
	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
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 April 26, 2019.		This Internet-Draft will expire on July 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	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 Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	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
	something that we can do to limit the consequences of attacks, should		something that we can do to limit the consequences of attacks, should
	they occur?		they occur?
	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
	important, given the large number of users such practices may affect.		is important, given the large number of users such practices may
	It is also a stated goal of the IETF to ensure that we understand the		affect. It is also a stated goal of the IETF to ensure that we
	surveillance concerns related to IETF protocols and take appropriate		understand the surveillance concerns related to IETF protocols and
	countermeasures [RFC7258]. This document does that for EAP-AKA'.		take appropriate countermeasures [RFC7258]. This document does that
			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 [RFC5448] (to be superseded by
	[I-D.ietf-emu-rfc5448bis]). The extension, when negotiated, provides		[I-D.ietf-emu-rfc5448bis]). The extension, when negotiated, provides
	Perfect Forward Secrecy for the session key generated as a part of		Perfect Forward Secrecy for the session key 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 pre-shared secret in a SIM card		has gained access to the long-term pre-shared secret in a SIM card
	from being able to decrypt all past communications. In addition, if		from being able to decrypt all past communications. In addition, if
	the attacker stays merely a passive eavesdropper, the extension		the attacker stays merely a passive eavesdropper, the extension
	prevents attacks against future sessions. This forces attackers to		prevents attacks against future sessions. This forces attackers to
	skipping to change at page 8, line 23		skipping to change at page 8, line 23
	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 Security (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.		The-Middle (MITM) during the AKA run and subsequent communication
			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
	"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
	skipping to change at page 10, line 30		skipping to change at page 10, line 30
	| RAND, AUTN | | |		| RAND, AUTN | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| CK, IK, RES | | |		| CK, IK, RES | | |
	|-------------->| | |		|-------------->| | |
	| | | |		| | | |
	+-----------------------------------------------------+ |		+-----------------------------------------------------+ |
	| The peer now has everything to respond. If it wants | |		| The peer now has everything to respond. If it wants | |
	| to participate in the PFS extension, it will then | |		| to participate in the PFS extension, it will then | |
	| generate its key pair, calculate a shared key based | |		| generate its key pair, calculate a shared key based | |
	| on its key pair the server's public key. Finally, | |		| on its key pair and the server's public key. | |
	| it proceeds to derive all EAP-AKA' key values and | |		| Finally, it proceeds to derive all EAP-AKA' key | |
	| and constructs a full response. | |		| values and and constructs a full response. | |
	+-----------------------------------------------------+ |		+-----------------------------------------------------+ |
	| | | |		| | | |
	| | EAP-Resp/AKA'-Challenge | |		| | EAP-Resp/AKA'-Challenge | |
	| | AT_RES, AT_PUB_ECDHE, | |		| | AT_RES, AT_PUB_ECDHE, | |
	| | AT_MAC | |		| | AT_MAC | |
	| |------------------------->| |		| |------------------------->| |
	| +-------------------------------------------------+		| +-------------------------------------------------+
	| | The server now has all the necessary values. |		| | The server now has all the necessary values. |
	| | It generates the ECDHE shared secret |		| | It generates the ECDHE shared secret |
	| | and checks the RES and MAC values received |		| | and checks the RES and MAC values received |
	skipping to change at page 14, line 28		skipping to change at page 14, line 28
	internal use within one authentication run as		internal use within one authentication run as
	[I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is		[I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is
	used in AT_MAC is still exactly as it was in EAP-AKA'. The only		used in AT_MAC is still exactly as it was in EAP-AKA'. The only
	change to key derivation is in re-authentication keys and keys		change to key derivation is in re-authentication keys and keys
	exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA'		exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA'
	attributes such as AT_MAC continue to be usable even when this		attributes such as AT_MAC continue to be usable even when this
	extension is in use.		extension is in use.
	When the Key Derivation Function field in the AT_KDF_PFS attribute is		When the Key Derivation Function field in the AT_KDF_PFS attribute is
	set to 1 and the Key Derivation Function field in the AT_KDF		set to 1 and the Key Derivation Function field in the AT_KDF
	attribute is also set to 1, the Master Key (MK) is derived and as		attribute is also set to 1, the Master Key (MK) is derived as follows
	follows below.		below.
	MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)		MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
	MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' PFS"|Identity)		MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' PFS"|Identity)
	K_encr = MK[0..127]		K_encr = MK[0..127]
	K_aut = MK[128..383]		K_aut = MK[128..383]
	K_re = MK_ECDHE[0..255]		K_re = MK_ECDHE[0..255]
	MSK = MK_ECDHE[256..767]		MSK = MK_ECDHE[256..767]
	EMSK = MK_ECDHE[768..1279]		EMSK = MK_ECDHE[768..1279]
	Where SHARED_SECRET is the shared secret computed via ECDHE, as		Where SHARED_SECRET is the shared secret computed via ECDHE, as
	skipping to change at page 20, line 14		skipping to change at page 20, line 14
	Except of course, if the adversary holds the long-term shared		Except of course, if the adversary holds the long-term shared
	secret and is willing to engage in an active attack. Such an		secret and is willing to engage in an active attack. Such an
	attack can, for instance, forge the negotiation process so that		attack can, for instance, forge the negotiation process so that
	no PFS will be provided. However, as noted above, an attacker		no PFS will be provided. However, as noted above, an attacker
	with these capabilities will in any case be able to impersonate		with these capabilities will in any case be able to impersonate
	any party in the protocol and perform MITM attacks. That is		any party in the protocol and perform MITM attacks. That is
	not a situation that can be improved by a technical solution.		not a 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 a MITM on
	each AKA run, which makes mass surveillance more laborous.		each AKA run and subsequent communication, which makes mass
			surveillance more laborous.
	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 peform the extension specified in this protocol, but		willing to peform the extension specified in this protocol, but
	the other side does not wish to use the extension. Allowing		the other side does not wish to use the extension. Allowing
	this has the benefit of allowing backwards compatibility to		this has the benefit of allowing backwards compatibility to
	equipment that did not yet support the extension. When the		equipment that did not yet support the extension. When the
	extension is not supported or negotiated by the parties, no PFS		extension is not supported or negotiated by the parties, no PFS
	can obviously provided.		can obviously provided.
	skipping to change at page 21, line 9		skipping to change at page 21, line 9
	after the time that the protected communications are used. When		after the time that the protected communications are used. When
	this extension is used, communications at time t0 can be protected		this extension is used, communications at time t0 can be protected
	if at some later time t1 an adversary learns of long-term shared		if at some later time t1 an adversary learns of long-term shared
	secret and has access to a recording of the encrypted		secret and has access to a recording of the encrypted
	communications.		communications.
	Obviously, this extension is still vulnerable to attackers that		Obviously, this extension is still vulnerable to attackers that
	are willing to perform an active attack and who at the time of the		are willing to perform an active attack and who at the time of the
	attack have access to the long-term shared secret.		attack have access to the long-term shared secret.
	This extension does not change the properties of related to re-		This extension does not change the properties related to re-
	authentication. No new Diffie-Hellman run is performed during the		authentication. No new Diffie-Hellman run is performed during the
	re-authentication allowed by EAP-AKA'. However, if this extension		re-authentication allowed by EAP-AKA'. However, if this extension
	was in use when the original EAP-AKA' authentication was		was in use when the original EAP-AKA' authentication was
	performed, the keys used for re-authentication (K_re) are based on		performed, the keys used for re-authentication (K_re) are based on
	the Diffie-Hellman keys, and hence continue to be equally safe		the Diffie-Hellman keys, and hence continue to be equally safe
	against expose of the long-term secrets as the original		against expose of the long-term secrets as the original
	authentication.		authentication.
	In addition, it is worthwhile to discuss Denial-of-Service attacks		In addition, it is worthwhile to discuss Denial-of-Service attacks
	and their impact on this protocol. The calculations involved in		and their impact on this protocol. The calculations involved in
	skipping to change at page 21, line 52		skipping to change at page 21, line 52
	message will not be sent unless the user has been identified as an		message will not be sent unless the user has been identified as an
	active subscriber of the operator in question. While the initial		active subscriber of the operator in question. While the initial
	identity can be spoofed before authentication has succeeded, this		identity can be spoofed before authentication has succeeded, this
	reduces the efficiency of an attack.		reduces the efficiency of an attack.
	o Finally, this memo specifies an order in which computations and		o Finally, this memo specifies an order in which computations and
	checks must occur. When processing the EAP-Request/AKA'-Challenge		checks must occur. When processing the EAP-Request/AKA'-Challenge
	message, for instance, the AKA authentication must be checked and		message, for instance, the AKA authentication must be checked and
	succeed before the peer proceeds to calculating or processing the		succeed before the peer proceeds to calculating or processing the
	PFS related parameters (see Section 6.5.4). The same is true of		PFS related parameters (see Section 6.5.4). The same is true of
	EAP-Response/AKA'-Challenge (see Section 6.5.4. This ensures that		EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures
	the parties need to show possession of the long-term secret in		that the parties need to show possession of the long-term secret
	some way, and only then will the PFS calculations become active.		in some way, and only then will the PFS calculations become
	This limits the Denial-of-Service to specific, identified		active. 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.
	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'		with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA'
	skipping to change at page 23, line 32		skipping to change at page 23, line 32
	<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-		3rd Generation Authentication and Key Agreement (EAP-
	AKA')", draft-ietf-emu-rfc5448bis-03 (work in progress),		AKA')", draft-ietf-emu-rfc5448bis-04 (work in progress),
	October 2018.		January 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 -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 engotiation 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.
	This version also addressed comments from reviewers, including the		This version also addressed comments from reviewers, including the
	August review from Mohit Sethi, and comments made during IETF-102		August review from Mohit Sethi, and comments made during IETF-102
	discussion.		discussion.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
End of changes. 14 change blocks.
	24 lines changed or deleted		29 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/