draft-arkko-eap-aka-pfs-00.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: 5448 (if approved) V. Torvinen		Updates: 5448 (if approved) V. Torvinen
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: May 3, 2018 October 30, 2017		Expires: September 6, 2018 March 5, 2018
	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-00		draft-arkko-eap-aka-pfs-01
	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 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 May 3, 2018.		This Internet-Draft will expire on September 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 5		2.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 5
	2.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 6		2.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 7
	3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7		3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	5. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 9		5. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 10
	5.1. AT_PUB_DH . . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. AT_PUB_DH . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. AT_KDF_DH . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. AT_KDF_DH . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. New Key Derivation Function . . . . . . . . . . . . . . . 12		5.3. New Key Derivation Function . . . . . . . . . . . . . . . 12
	5.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 13		5.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 13
	5.5. Message Processing . . . . . . . . . . . . . . . . . . . 13		5.5. Message Processing . . . . . . . . . . . . . . . . . . . 13
	5.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 13		5.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 14
	5.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 13		5.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 14
	5.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 13		5.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 14
	5.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 14		5.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 15
	5.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 14		5.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 15
	5.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 14		5.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 15
	5.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 15		5.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 15
	5.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 15		5.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 15
	5.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 15		5.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 16
	5.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 15		5.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 16
	5.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 15		5.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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 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. Such attacks are conceivable, for instance,		stored on these cards. Such attacks are conceivable, for instance,
	during the manufacturing process of cards, or the transfer of cards		during the manufacturing process of cards, or the transfer of cards
	and associated information to the operator. Since the publication of		and associated information to the operator. Since the publication of
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	widely supported EAP-AKA' method, rather than a completely new		widely supported EAP-AKA' method, rather than a completely new
	authentication method. The extension is implemented as a set of new,		authentication method. The extension is implemented as a set of new,
	optional attributes, that are provided alongside the base attributes		optional attributes, that are provided alongside the base attributes
	in EAP-AKA'. Old implementations can ignore these attributes, but		in EAP-AKA'. Old implementations can ignore these attributes, but
	their presence will nevertheless be verified as part of base EAP-AKA'		their presence will nevertheless be verified as part of base EAP-AKA'
	integrity verification process, helping protect against bidding down		integrity verification process, helping protect against bidding down
	attacks. This extension does not increase the number of rounds		attacks. This extension does not increase the number of rounds
	necessary to complete the protocol.		necessary to complete the protocol.
	The use of this extension is at the discretion of the authenticating		The use of this extension is at the discretion of the authenticating
	parties. There are currently no requirements mandating the use of		parties. The authors want to provide a public specification of an
	this extension from 3GPP or otherwise, but the authors want to		extension that helps defend against one aspect of pervasive
	provide a public specification of an extension that helps defend		surveillance. It should be noted that PFS and defenses against
	against one aspect of pervasive surveillance. It should be noted		passive attacks are by no means a panacea, but they can provide a
	that PFS and defenses against passive attacks are by no means a		partial defense that increases the cost and risk associated with
	panacea, but they can provide a partial defense that increases the		pervasive surveillance.
	cost and risk associated with pervasive surveillance.
			Attacks against AKA authentication via compromising the long-term
			secrets in the SIM cards have been an active discussion topic in many
			contexts. Perfect forward secrecy is a potential feature in future
			specification releases in 3GPP, and this document provides a basis
			for providing this feature in a particular fashion.
			While adding perfect forward secrecy to the existing mobile network
			infrastructure can be done in multiple different ways, the authors
			believe that the approach chosen here is relatively easily
			deployable. In particular:
			o As noted above, no new credentials are needed; there is no change
			to SIM cards.
			o PFS property can be incorporated into any current or future system
			that supports EAP, without changing any network functions beyond
			the EAP endpoints.
			o Key generation happens at the endpoints, enabling highest grade
			key material to be used both by the endpoints and the intermediate
			systems (such as access points that are given access to specific
			keys).
			o While EAP-AKA' is just one EAP method, for practical purposes
			perfect forward secrecy being available for both EAP-TLS [RFC5216]
			[I-D.mattsson-eap-tls13] and EAP-AKA' ensures that for many
			practical systems perfect forward secrecy can be enabled for
			either all or significant fraction of users.
	It should also be noted that the planned 5G network architecture		It should also be noted that the planned 5G network architecture
	includes the use of the EAP framework for authentication. The		includes the use of the EAP framework for authentication. The
	default authentication method within that context will be EAP-AKA',		default authentication method within that context will be EAP-AKA',
	but other methods can certainly also be run.		but other methods can certainly also be run.
	2. Background		2. Background
	2.1. AKA		2.1. AKA
	skipping to change at page 16, line 45 ¶		skipping to change at page 17, line 30 ¶
	that a change is being made and what the original offer was.		that a change is being made and what the original offer was.
	Negotiating the use of this extension		Negotiating the use of this extension
	This extension is offered by the server through presenting		This extension is offered by the server through presenting
	the AT_KDF_DH and AT_PUB_DH attributes in the EAP-Request/		the AT_KDF_DH and AT_PUB_DH attributes in the EAP-Request/
	AKA'-Challenge message. These attributes are protected by		AKA'-Challenge message. These attributes are protected by
	AT_MAC, so attempts to change or omit them by an adversary		AT_MAC, so attempts to change or omit them by an adversary
	will be detected. (Except of course, if the adversary holds		will be detected. (Except of course, if the adversary holds
	the long-term shared secret and is willing to engage in an		the long-term shared secret and is willing to engage in an
	active attack, but that is a case that cannot be solved by		active attack, but that is a case that cannot be solved by a
	this protocol, or any protocol for that matter.) However,		technical change in this protocol.) However, as discussed
	as discussed in the introduction, even an attacker with		in the introduction, even an attacker with access to the
	access to the long-term keys is required to be MITM on each		long-term keys is required to be MITM on each AKA run, which
	AKA run, which makes mass survailance slightly more		makes mass survailance slightly more laborous.
	laborous.
	Key derivation		Key derivation
	This extension provides key material that is based on the Diffie-		This extension provides key material that is based on the Diffie-
	Hellman keys, yet bound to the authentication through the (U)SIM		Hellman keys, yet bound to the authentication through the (U)SIM
	card. This means that subsequent payload communications between		card. This means that subsequent payload communications between
	the parties are protected with keys that are not solely based on		the parties are protected with keys that are not solely based on
	information in the clear (such as the RAND) and information		information in the clear (such as the RAND) and information
	derivable from the long-term shared secrets on the (U)SIM card.		derivable from the long-term shared secrets on the (U)SIM card.
	As a result, if anyone successfully recovers shared secret		As a result, if anyone successfully recovers shared secret
	information, they are unable to decrypt communications protected		information, they are unable to decrypt communications protected
	by the keys generated through this extension. Note that the		by the keys generated through this extension. Note that the
	recovery of shared secret information could occur either before or		recovery of shared secret information could occur either before or
	skipping to change at page 19, line 23 ¶		skipping to change at page 20, line 18 ¶
	.rfc-editor.org/info/rfc8126>.		.rfc-editor.org/info/rfc8126>.
	8.2. Informative References		8.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
			Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
			March 2008, <https://www.rfc-editor.org/info/rfc5216>.
			[I-D.mattsson-eap-tls13]
			Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
			draft-mattsson-eap-tls13-01 (work in progress), January
			2018.
	[TrustCom2015]		[TrustCom2015]
	Arkko, J., Norrman, K., Naslund, M., and B. Sahlin, "A		Arkko, J., Norrman, K., Naslund, M., and B. Sahlin, "A
	USIM compatible 5G AKA protocol with perfect forward		USIM compatible 5G AKA protocol with perfect forward
	secrecy", August 2015 in Proceedings of the TrustCom 2015,		secrecy", August 2015 in Proceedings of the TrustCom 2015,
	IEEE.		IEEE.
	[CB2014] Choudhary, A. and R. Bhandari, "3GPP AKA Protocol:		[CB2014] Choudhary, A. and R. Bhandari, "3GPP AKA Protocol:
	Simplified Authentication Process", December 2014,		Simplified Authentication Process", December 2014,
	International Journal of Advanced Research in Computer		International Journal of Advanced Research in Computer
	Science and Software Engineering, Volume 4, Issue 12.		Science and Software Engineering, Volume 4, Issue 12.
	skipping to change at page 20, line 16 ¶		skipping to change at page 21, line 22 ¶
	Appendix A. Acknowledgments		Appendix A. 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. Naslund, and B. Sahlin. This document		were J. Arkko, K. Norrman, M. Naslund, and B. Sahlin. This document
	uses also a lot of material from [RFC4187] by J. Arkko and H.		uses also a lot of material from [RFC4187] by J. Arkko and H.
	Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and P.		Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and P.
	Eronen.		Eronen.
	The authors would also like to thank John Mattson, Mohit Sethi, Vesa		The authors would also like to thank Tero Kivinen, John Mattson,
	Lehtovirta, Bengt Sahlin, Prajwol Kumar Nakarmi and many people at		Mohit Sethi, Vesa Lehtovirta, Joseph Salowey, Kathleen Moriarty,
	the GSMA and 3GPP groups for interesting discussions in this problem		Zhang Fu, Bengt Sahlin, Ben Campbell, Prajwol Kumar Nakarmi, Goran
	space.		Rune, Tim Evans, Helena Vahidi Mazinani, Anand R. Prasad, and many
			other people at the GSMA and 3GPP groups for interesting discussions
			in this problem space.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
End of changes. 14 change blocks.
	43 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/