draft-arkko-eap-aka-pfs-01.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: September 6, 2018 March 5, 2018		Expires: January 3, 2019 July 2, 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-01		draft-arkko-eap-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
	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 September 6, 2018.		This Internet-Draft will expire on January 3, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Protocol Design and Deployment Objectives . . . . . . . . . . 4
	2.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 5		3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 7		3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6
	3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7		3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 8
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8
	5. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 10		5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. AT_PUB_DH . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11
	5.2. AT_KDF_DH . . . . . . . . . . . . . . . . . . . . . . . . 10		6.1. AT_PUB_DH . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.3. New Key Derivation Function . . . . . . . . . . . . . . . 12		6.2. AT_KDF_DH . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 13		6.3. New Key Derivation Function . . . . . . . . . . . . . . . 13
	5.5. Message Processing . . . . . . . . . . . . . . . . . . . 13		6.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 14
	5.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 14		6.5. Message Processing . . . . . . . . . . . . . . . . . . . 14
	5.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 14		6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 15
	5.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 14		6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 15
	5.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 15		6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 15
	5.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 15		6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16
	5.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 15		6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 16
	5.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 15		6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 16
	5.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 15		6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 16
	5.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 16		6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 16
	5.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 16		6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 17
	5.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 16		6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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 during the transfer of
	and associated information to the operator. Since the publication of		cards and associated information to the operator. Since the
	reports about such attacks, manufacturing and provisioning processes		publication of reports about such attacks, manufacturing and
	have gained much scrutiny and have improved.		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 designs can ask. Is there something		one question that we as protocol designs can ask. Is there something
	that we can do to limit the consequences of attacks, should they		that we can do to limit the consequences of attacks, should they
	occur?		occur?
			The authors want to provide a public specification of an extension
			that helps defend against one aspect of pervasive surveillance. This
			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 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]. The extension provides Perfect		authentication method [RFC5448]. The extension provides Perfect
	Forward Secrecy for the session key generated as a part of the		Forward Secrecy for the session key generated as a part of the
	authentication run in EAP-AKA'. This prevents an attacker who has		authentication run in EAP-AKA'. This prevents an attacker who has
	gained access to the long-term pre-shared secret in a SIM card from		gained access to the long-term pre-shared secret in a SIM card from
	merely passively eavesdropping the EAP-AKA' exchanges and deriving		merely passively eavesdropping the EAP-AKA' exchanges and deriving
	associated session keys, forcing attackers to use active attacks		associated session keys, forcing attackers to use active attacks
	instead.		instead.
			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 on the list of features for the
			next release of 3GPP (5G Phase 2), and this document provides a basis
			for providing this feature in a particular fashion.
			It should also be noted that 5G network architecture includes the use
			of the EAP framework for authentication. While any methods can be
			run, the default authentication method within that context will be
			EAP-AKA. As a result, improvements in EAP-AKA' security have a
			potential to improve security for large number of users.
			2. Protocol Design and Deployment Objectives
	This extension specified here re-uses large portions of the current		This extension specified here re-uses large portions of the current
	structure of 3GPP interfaces and functions, with the rationale that		structure of 3GPP interfaces and functions, with the rationale that
	this will make the construction more easily adopted. In particular,		this will make the construction more easily adopted. In particular,
	the construction maintains the interface between the Universal		the construction maintains the interface between the Universal
	Subscriber Identification Module (USIM) and the mobile terminal		Subscriber Identification Module (USIM) and the mobile terminal
	intact. As a consequence, there is no need to roll out new		intact. As a consequence, there is no need to roll out new
	credentials to existing subscribers. The work is based on an earlier		credentials to existing subscribers. The work is based on an earlier
	paper [TrustCom2015], and uses much of the same material, but applied		paper [TrustCom2015], and uses much of the same material, but applied
	to EAP rather than the underlying AKA method. This 00 version of the		to EAP rather than the underlying AKA method. This specification is
	specification is an initial proposal for ensuring SIM-based		an initial proposal for ensuring SIM-based authentication in EAP
	authentication in EAP makes attacks difficult. Comments and		makes attacks difficult. Comments and suggestions are much
	suggestions are much appreciated, including design improvements.		appreciated, including design improvements.
	It has been a goal to implement this change as an extension of the		It has been a goal to implement this change as an extension of the
	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. The authors want to provide a public specification of an		parties. It should be noted that PFS and defenses against passive
	extension that helps defend against one aspect of pervasive		attacks are by no means a panacea, but they can provide a partial
	surveillance. It should be noted that PFS and defenses against		defense that increases the cost and risk associated with pervasive
	passive attacks are by no means a panacea, but they can provide a		surveillance.
	partial defense that increases the 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		While adding perfect forward secrecy to the existing mobile network
	infrastructure can be done in multiple different ways, the authors		infrastructure can be done in multiple different ways, the authors
	believe that the approach chosen here is relatively easily		believe that the approach chosen here is relatively easily
	deployable. In particular:		deployable. In particular:
	o As noted above, no new credentials are needed; there is no change		o As noted above, no new credentials are needed; there is no change
	to SIM cards.		to SIM cards.
	o PFS property can be incorporated into any current or future system		o PFS property can be incorporated into any current or future system
	skipping to change at page 5, line 5		skipping to change at page 5, line 16
	key material to be used both by the endpoints and the intermediate		key material to be used both by the endpoints and the intermediate
	systems (such as access points that are given access to specific		systems (such as access points that are given access to specific
	keys).		keys).
	o While EAP-AKA' is just one EAP method, for practical purposes		o While EAP-AKA' is just one EAP method, for practical purposes
	perfect forward secrecy being available for both EAP-TLS [RFC5216]		perfect forward secrecy being available for both EAP-TLS [RFC5216]
	[I-D.mattsson-eap-tls13] and EAP-AKA' ensures that for many		[I-D.mattsson-eap-tls13] and EAP-AKA' ensures that for many
	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.
	It should also be noted that the planned 5G network architecture		3. Background
	includes the use of the EAP framework for authentication. The
	default authentication method within that context will be EAP-AKA',
	but other methods can certainly also be run.
	2. Background
	2.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, 3rd
	generation AKA provides long key lengths and mutual authentication.		generation AKA 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
	skipping to change at page 5, line 49		skipping to change at page 6, line 7
	key and the sequence number. If this process is successful (the		key and the sequence number. If this process is successful (the
	AUTN is valid and the sequence number used to generate AUTN is		AUTN is valid and the sequence number used to generate AUTN is
	within the correct range), the identity module produces an		within the correct range), the identity module produces an
	authentication result RES and sends it to the serving network.		authentication result RES and sends it to the serving network.
	o The serving network verifies the correct result from the identity		o The serving network verifies the correct result from the identity
	module. If the result is correct, IK and CK can be used to		module. If the result is correct, IK and CK can be used to
	protect further communications between the identity module and the		protect further communications between the identity module and the
	home environment.		home environment.
	2.2. EAP-AKA' Protocol		3.2. EAP-AKA' Protocol
	When AKA (and AKA') are embedded into EAP, the authentication on the		When AKA (and AKA') are embedded into EAP, the authentication on the
	network side is moved to the home environment; the serving network		network side is moved to the home environment; the serving network
	perdorms the role of a pass-through authenticator. Figure 1		performs the role of a pass-through authenticator. Figure 1
	describes the basic flow in the EAP-AKA' authentication process. The		describes the basic flow in the EAP-AKA' authentication process. The
	definition of the full protocol behaviour, along with the definition		definition of the full protocol behaviour, along with the definition
	of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in		of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in
	[RFC5448] and [RFC4187].		[RFC5448] and [RFC4187].
	Peer Server		Peer Server
	| EAP-Request/Identity |		| EAP-Request/Identity |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	| |		| |
	| EAP-Response/Identity |		| EAP-Response/Identity |
	skipping to change at page 7, line 11		skipping to change at page 8, line 5
	| +-------------------------------------------------+		| +-------------------------------------------------+
	| | Server checks the RES and MAC values received |		| | Server checks the RES and MAC values received |
	| | in AT_RES and AT_MAC, respectively. Success |		| | in AT_RES and AT_MAC, respectively. Success |
	| | requires both to be found correct. |		| | requires both to be found correct. |
	| +-------------------------------------------------+		| +-------------------------------------------------+
	| EAP-Success |		| EAP-Success |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	Figure 1: EAP-AKA' Authentication Process		Figure 1: EAP-AKA' Authentication Process
	2.3. Attacks Against Long-Term Shared Secrets in Smart Cards		3.3. Attacks Against Long-Term Shared Secrets in Smart Cards
	Current 3GPP systems use (U)SIM pre-shared key based protocols to		Current 3GPP systems use (U)SIM pre-shared key based protocols to
	authenticate subscribers. Since the addition of replay protection		authenticate subscribers. Since the addition of replay protection
	and mutual authentication in the third generation 3GPP systems, there		and mutual authentication in the third generation 3GPP systems, there
	have been no published attacks that violate the security properties		have been no published attacks that violate the security properties
	defined for the Authentication and Key Agreement (AKA) in, at least		defined for the Authentication and Key Agreement (AKA) in, at least
	not within the assumed trust model. (However, there have been		not within the assumed trust model. (However, there have been
	attacks using a different trust model [CB2014] [MT2012]; the protocol		attacks using a different trust model [CB2014] [MT2012]; the protocol
	was not designed to counter those situations. There have also been		was not designed to counter those situations. There have also been
	attacks against systems where AKA is used in a different setting than		attacks against systems where AKA is used in a different setting than
	initially intended, e.g. [BT2013].)		initially intended, e.g. [BT2013].)
	Recent reports of compromised long term pre-shared keys used in AKA		Recent reports of compromised long term pre-shared keys used in AKA
	[Heist2015] indicate a need to look into solutions that allow a		[Heist2015] indicate a need to look into solutions that allow a
	weaker trust model, in particular for future 5G systems. It is also		weaker trust model, in particular for future 5G systems. It is also
	noted in [Heist2015] that, even if the current trust model is kept,		noted in [Heist2015] that, even if the current trust model is kept,
	some security can be retained in this situation by providing Perfect		some security can be retained in this situation by providing Perfect
	Forward Security (PFS) [DOW1992] for the session key. If AKA would		Forward Security (PFS) [DOW1992] for the session key. If AKA would
	have provided PFS, compromising the pre-shared key would not be		have provided PFS, compromising the pre-shared key would not be
	sufficient to perform passive attacks; the attacker is, in addition,		sufficient to perform passive attacks; the attacker is, in addition,
	forced to be a Man-In-The-Middle (MITM) during the AKA run.		forced to be a Man-In-The-Middle (MITM) during the AKA run.
	Introducing PFS for authentication in 3GPP systems can be achieved by		Introducing PFS for authentication in 3GPP systems can be achieved by
	adding a Diffie-Hellman (DH) exchange.		adding a Diffie-Hellman (DH) exchange.
	3. 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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	4. Protocol Overview		5. Protocol Overview
	The enhancements in the protocol specified here are compatible with		The enhancements in the protocol specified here are compatible with
	the signaling flow and other basic structures of both AKA and EAP-		the signaling flow and other basic structures of both AKA and EAP-
	AKA'. The intent is to implement the enhancement as optional		AKA'. The intent is to implement the enhancement as optional
	attributes that legacy implementations can ignore.		attributes 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. The enhancements brought in		secure communication between the two. The enhancements brought in
	this document change the calculation of key material, providing new		this document change the calculation of key material, providing new
	properties that are not present in key material provided by EAP-AKA'		properties that are not present in key material provided by EAP-AKA'
	in its original form.		in its original form.
	Figure 2 below describes the overall process. Since our goal has		Figure 2 below describes the overall process. Since our goal has
	been to not require new infrastructure or credentials, the flow		been to not require new infrastructure or credentials, the flow
	diagrams also show the conceptual interaction with the USIM card and		diagrams also show the conceptual interaction with the USIM card and
	the 3GPP authentication server (HSS). The details of those		the 3GPP authentication server (HSS). The details of those
	interactions are outside the scope of this document, however, and the		interactions are outside the scope of this document, however, and the
	reader is referred to the the 3GPP specifications .		reader is referred to the 3GPP specifications .
	USIM Peer Server HSS		USIM Peer Server HSS
	| | | |		| | | |
	| | EAP-Req/Identity | |		| | EAP-Req/Identity | |
	| |<-------------------------| |		| |<-------------------------| |
	| | | |		| | | |
	| | EAP-Resp/Identity | |		| | EAP-Resp/Identity | |
	| |------------------------->| |		| |------------------------->| |
	| | | |		| | | |
	| +-------------------------------------------------+		| +-------------------------------------------------+
	skipping to change at page 10, line 8		skipping to change at page 11, line 5
	| | This implies that only an active attacker can |		| | This implies that only an active attacker can |
	| | determine the used session keys; in basic |		| | determine the used session keys; in basic |
	| | EAP-AKA' the keys are only based on CK and IK. |		| | EAP-AKA' the keys are only based on CK and IK. |
	| +-------------------------------------------------+		| +-------------------------------------------------+
	| | | |		| | | |
	| | EAP-Success | |		| | EAP-Success | |
	| |<-------------------------| |		| |<-------------------------| |
	Figure 2: EAP-AKA' PFS Authentication Process		Figure 2: EAP-AKA' PFS Authentication Process
	5. Extensions to EAP-AKA'		6. Extensions to EAP-AKA'
	5.1. AT_PUB_DH		6.1. AT_PUB_DH
	The AT_PUB_DH carries a Diffie-Hellman value.		The AT_PUB_DH carries a Diffie-Hellman value.
	The format of the AT_PUB_DH attribute is shown below.		The format of the AT_PUB_DH attribute is shown below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AT_PUB_DH | Length | Value ... |		| AT_PUB_DH | Length | Value ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 42		skipping to change at page 11, line 39
	Value		Value
	This value is the sender's Diffie-Hellman public value. For		This value is the sender's Diffie-Hellman public value. For
	Curve25519, the length of this value is 32 bytes, represented as		Curve25519, the length of this value is 32 bytes, represented as
	specified in [RFC8031] and [RFC7748].		specified in [RFC8031] and [RFC7748].
	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.
	5.2. AT_KDF_DH		6.2. AT_KDF_DH
	The AT_KDF_DH indicates the used or desired key generation function,		The AT_KDF_DH indicates the used or desired key generation function,
	if the Perfect Forward Secrecy extension is taken into use. It will		if the Perfect Forward Secrecy extension is taken into use. It will
	also at the same time indicate the used or desired Diffie-Hellman		also at the same time indicate the used or desired Diffie-Hellman
	group. A new attribute is needed to carry this information, as		group. A new attribute is needed to carry this information, as
	AT_KDF carries the legacy KDF value for those EAP peers that cannot		AT_KDF carries the legacy KDF value for those EAP peers that cannot
	or do not want to use this extension.		or do not want to use this extension.
	The format of the AT_KDF_DH attribute is shown below.		The format of the AT_KDF_DH attribute is shown below.
	skipping to change at page 11, line 26		skipping to change at page 12, line 24
	This is set to TBA2 BY IANA.		This is set to TBA2 BY IANA.
	Length		Length
	The length of the attribute, MUST be set to 1.		The length of the attribute, MUST be set to 1.
	Key Derivation Function		Key Derivation Function
	An enumerated value representing the key derivation function that		An enumerated value representing the key derivation function that
	the server (or peer) wishes to use. See Section 5.3 for the		the server (or peer) wishes to use. See Section 6.3 for the
	functions specified in this document. Note: This field has a		functions specified in this document. Note: This field has a
	different name space than the similar field in the AT_KDF		different name space than the similar field in the AT_KDF
	attribute Key Derivation Function defined in [RFC5448].		attribute Key Derivation Function defined in [RFC5448].
	Servers MUST send one or more AT_KDF_DH attributes in the EAP-Request		Servers MUST send one or more AT_KDF_DH attributes in the EAP-
	/AKA'-Challenge message. These attributes represent the desired		Request/AKA'-Challenge message. These attributes represent the
	functions ordered by preference, the most preferred function being		desired functions ordered by preference, the most preferred function
	the first attribute.		being the first attribute.
	Upon receiving a set of these attributes, if the peer supports and is		Upon receiving a set of these attributes, if the peer supports and is
	willing to use the key derivation function indicated by the first		willing to use the key derivation function indicated by the first
	attribute, and is willing and able to use the extension defined in		attribute, and is willing and able to use the extension defined in
	this specification, the function is taken into use without any		this specification, the function is taken into use without any
	further negotiation. However, if the peer does not support this		further negotiation. However, if the peer does not support this
	function or is unwilling to use it, it responds to the server with an		function or is unwilling to use it, it responds to the server with an
	indication that a different function is needed. Similarly with the		indication that a different function is needed. Similarly with the
	negotiation process defined in [RFC5448] for AT_KDF, the peer sends		negotiation process defined in [RFC5448] for AT_KDF, the peer sends
	EAP-Response/AKA'-Challenge message that contains only one attribute,		EAP-Response/AKA'-Challenge message that contains only one attribute,
	skipping to change at page 12, line 31		skipping to change at page 13, line 29
	list of AT_KDF_DH attributes, and retains the entire list following		list of AT_KDF_DH attributes, and retains the entire list following
	it. Note that this means that the selected alternative appears twice		it. Note that this means that the selected alternative appears twice
	in the set of AT_KDF values. Responding to the peer's request to		in the set of AT_KDF values. Responding to the peer's request to
	change the key derivation function is the only legal situation where		change the key derivation function is the only legal situation where
	such duplication may occur.		such duplication may occur.
	When the peer receives the new EAP-Request/AKA'-Challenge message, it		When the peer receives the new EAP-Request/AKA'-Challenge message, it
	MUST check that the requested change, and only the requested change		MUST check that the requested change, and only the requested change
	occurred in the list of AT_KDF_DH attributes. If yes, it continues.		occurred in the list of AT_KDF_DH attributes. If yes, it continues.
	If not, it behaves as if AT_MAC had been incorrect and fails the		If not, it behaves as if AT_MAC had been incorrect and fails the
	authentication. If the peer receives multiple EAP-Request/		authentication. If the peer receives multiple EAP-Request/AKA'-
	AKA'-Challenge messages with differing AT_KDF_DH attributes without		Challenge messages with differing AT_KDF_DH attributes without having
	having requested negotiation, the peer MUST behave as if AT_MAC had		requested negotiation, the peer MUST behave as if AT_MAC had been
	been incorrect and fail the authentication.		incorrect and fail the authentication.
	5.3. New Key Derivation Function		6.3. New Key Derivation Function
	A new Key Derivation Function type is defined for "EAP-AKA' with DH		A new Key Derivation Function type is defined for "EAP-AKA' with DH
	and Curve25519", represented by value 1. It represents a particular		and Curve25519", represented by value 1. It represents a particular
	choice of key derivation function and at the same time selects a		choice of key derivation function and at the same time selects a
	Diffie-Hellman group to be used.		Diffie-Hellman group to be used.
	The Key Derivation Function type value is only used in the AT_KDF_DH		The Key Derivation Function type value is only used in the AT_KDF_DH
	attribute, and should not be confused with the different range of key		attribute, and should not be confused with the different range of key
	derivation functions that can be represented in the AT_KDF attribute		derivation functions that can be represented in the AT_KDF attribute
	as defined in [RFC5448].		as defined in [RFC5448].
	skipping to change at page 13, line 13		skipping to change at page 14, line 10
	in EAP-AKA'. The only change to key derivation is in re-		in EAP-AKA'. The only change to key derivation is in re-
	authentication keys and keys exported out of the EAP method, MSK and		authentication keys and keys exported out of the EAP method, MSK and
	EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be		EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be
	usable even when this extension is in use.		usable even when this extension is in use.
	When the Key Derivation Function field in the AT_KDF_DH attribute is		When the Key Derivation Function field in the AT_KDF_DH 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 and as
	follows below.		follows below.
	MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)		MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
	MK_DH = PRF'(IK'|CK'|G^xy,"EAP-AKA' PFS"|Identity)		MK_DH = PRF'(IK'|CK'|G^xy,"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_DH[0..255]		K_re = MK_DH[0..255]
	MSK = MK_DH[256..767]		MSK = MK_DH[256..767]
	EMSK = MK_DH[768..1279]		EMSK = MK_DH[768..1279]
	The rest of computation proceeds as defined in Section 3.3 of		The rest of computation proceeds as defined in Section 3.3 of
	[RFC5448].		[RFC5448].
	For readability, an explanation of the notation used above is copied		For readability, an explanation of the notation used above is copied
	here: [n..m] denotes the substring from bit n to m. PRF' is a new		here: [n..m] denotes the substring from bit n to m. PRF' is a new
	pseudo-random function specified in [RFC5448]. K_encr is the		pseudo-random function specified in [RFC5448]. K_encr is the
	encryption key, 128 bits, K_aut is the authentication key, 256 bits,		encryption key, 128 bits, K_aut is the authentication key, 256 bits,
	K_re is the re-authentication key, 256 bits, MSK is the Master		K_re is the re-authentication key, 256 bits, MSK is the Master
	Session Key, 512 bits, and EMSK is the Extended Master Session Key,		Session Key, 512 bits, and EMSK is the Extended Master Session Key,
	skipping to change at page 13, line 42		skipping to change at page 14, line 39
	CK and IK are produced by the AKA algorithm. IK' and CK' are derived		CK and IK are produced by the AKA algorithm. IK' and CK' are derived
	as specified in [RFC5448] from IK and CK.		as specified in [RFC5448] from IK and CK.
	The value "EAP-AKA'" is an eight-characters-long ASCII string. It is		The value "EAP-AKA'" is an eight-characters-long ASCII string. It is
	used as is, without any trailing NUL characters. Similarly, "EAP-		used as is, without any trailing NUL characters. Similarly, "EAP-
	AKA' PFS" is a twelve-characters-long ASCII string, also used as is.		AKA' PFS" is a twelve-characters-long ASCII string, also used as is.
	Identity is the peer identity as specified in Section 7 of [RFC4187].		Identity is the peer identity as specified in Section 7 of [RFC4187].
	5.4. Diffie-Hellman Groups		6.4. Diffie-Hellman Groups
	The selection of suitable groups for the Diffie-Hellman computation		The selection of suitable groups for the Diffie-Hellman computation
	is necessary. The choice of a group is made at the same time as		is necessary. The choice of a group is made at the same time as
	deciding to use of particular key derivation function in AT_KDF_DH.		deciding to use of particular key derivation function in AT_KDF_DH.
	For "EAP-AKA' with DH and Curve25519" the Diffie-Hellman group is the		For "EAP-AKA' with DH and Curve25519" the Diffie-Hellman group is the
	Curve25519 group specified in [RFC8031].		Curve25519 group specified in [RFC8031].
	5.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 [RFC5448] or [RFC4187]		otherwise specified here, the rules from [RFC5448] or [RFC4187]
	apply.		apply.
	5.5.1. EAP-Request/AKA'-Identity		6.5.1. EAP-Request/AKA'-Identity
	No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST		No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST
	NOT be added to this message. The appearance of these messages in a		NOT be added to this message. The appearance of these messages in a
	received message MUST be ignored.		received message MUST be ignored.
	5.5.2. EAP-Response/AKA'-Identity		6.5.2. EAP-Response/AKA'-Identity
	No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST		No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST
	NOT be added to this message. The appearance of these messages in a		NOT be added to this message. The appearance of these messages in a
	received message MUST be ignored.		received message MUST be ignored.
	5.5.3. EAP-Request/AKA'-Challenge		6.5.3. EAP-Request/AKA'-Challenge
	The server sends the EAP-Request/AKA'-Challenge on full		The server sends the EAP-Request/AKA'-Challenge on full
	authentication as specified by [RFC4187] and [RFC5448]. The		authentication as specified by [RFC4187] and [RFC5448]. The
	attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked		attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked
	on reception as specified in in [RFC4187]. They are also necessary		on reception as specified in in [RFC4187]. They are also necessary
	for backwards compatibility.		for backwards compatibility.
	In EAP-Request/AKA'-Challenge, there is no message-specific data		In EAP-Request/AKA'-Challenge, there is no message-specific data
	covered by the MAC for the AT_MAC attribute. The AT_KDF_DH and		covered by the MAC for the AT_MAC attribute. The AT_KDF_DH and
	AT_PUB_DH attributes MUST be included. The AT_PUB_DH attribute		AT_PUB_DH attributes MUST be included. The AT_PUB_DH attribute
	skipping to change at page 15, line 5		skipping to change at page 16, line 5
	included as specified in Section 9.3 of [RFC4187].		included as specified in Section 9.3 of [RFC4187].
	When processing this message, the peer MUST process AT_RAND, AT_AUTN,		When processing this message, the peer MUST process AT_RAND, AT_AUTN,
	AT_KDF_DH, AT_PUB_DH before processing other attributes. Only if		AT_KDF_DH, AT_PUB_DH before processing other attributes. Only if
	these attributes are verified to be valid, the peer derives keys and		these attributes are verified to be valid, the peer derives keys and
	verifies AT_MAC. If the peer is unable or unwilling to perform the		verifies AT_MAC. If the peer is unable or unwilling to perform the
	extension specified in this document, it proceeds as defined in		extension specified in this document, it proceeds as defined in
	[RFC5448]. Finally, the operation in case an error occurs is		[RFC5448]. Finally, the operation in case an error occurs is
	specified in Section 6.3.1. of [RFC4187].		specified in Section 6.3.1. of [RFC4187].
	5.5.4. EAP-Response/AKA'-Challenge		6.5.4. EAP-Response/AKA'-Challenge
	The peer sends EAP-Response/AKA'-Challenge in response to a valid		The peer sends EAP-Response/AKA'-Challenge in response to a valid
	EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and		EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and
	[RFC5448]. If the peer supports and is willing to perform the		[RFC5448]. If the peer supports and is willing to perform the
	extension specified in this protocol, and the server had made a valid		extension specified in this protocol, and the server had made a valid
	request involving the attributes specified in Section 5.5.3, the peer		request involving the attributes specified in Section 6.5.3, the peer
	responds per the rules specified below. Otherwise, the peer responds		responds per the rules specified below. Otherwise, the peer responds
	as specified in [RFC4187] and [RFC5448] and ignores the attributes		as specified in [RFC4187] and [RFC5448] and ignores the attributes
	related to this extension.		related to this extension.
	The AT_MAC attribute MUST be included and checked as specified in		The AT_MAC attribute MUST be included and checked as specified in
	[RFC5448]. In EAP-Response/AKA'-Challenge, there is no message-		[RFC5448]. In EAP-Response/AKA'-Challenge, there is no message-
	specific data covered by the MAC. The AT_PUB_DH attribute MUST be		specific data covered by the MAC. The AT_PUB_DH attribute MUST be
	included, and carries the peer's public Diffie-Hellman key.		included, and carries the peer's public Diffie-Hellman key.
	The AT_RES attribute MUST be included and checked as specified in		The AT_RES attribute MUST be included and checked as specified in
	[RFC4187].		[RFC4187].
	The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other		The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other
	attributes may be included as specified in Section 9.4 of [RFC4187].		attributes may be included as specified in Section 9.4 of [RFC4187].
	5.5.5. EAP-Request/AKA'-Reauthentication		6.5.5. EAP-Request/AKA'-Reauthentication
	No changes, but note that the re-authentication process uses the keys		No changes, but note that the re-authentication process uses the keys
	generated in the original EAP-AKA' authentication, which, if the		generated in the original EAP-AKA' authentication, which, if the
	extension specified in this documents is in use, employs key material		extension specified in this documents is in use, employs key material
	from the Diffie-Hellman procedure.		from the Diffie-Hellman procedure.
	5.5.6. EAP-Response/AKA'-Reauthentication		6.5.6. EAP-Response/AKA'-Reauthentication
	No changes, but as discussed in Section 5.5.5, re-authentication is		No changes, but as discussed in Section 6.5.5, re-authentication is
	based on the key material generated by EAP-AKA' and the extension		based on the key material generated by EAP-AKA' and the extension
	defined in this document.		defined in this document.
	5.5.7. EAP-Response/AKA'-Synchronization-Failure		6.5.7. EAP-Response/AKA'-Synchronization-Failure
	No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST		No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST
	NOT be added to this message. The appearance of these messages in a		NOT be added to this message. The appearance of these messages in a
	received message MUST be ignored.		received message MUST be ignored.
	5.5.8. EAP-Response/AKA'-Authentication-Reject		6.5.8. EAP-Response/AKA'-Authentication-Reject
	No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST		No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST
	NOT be added to this message. The appearance of these messages in a		NOT be added to this message. The appearance of these messages in a
	received message MUST be ignored.		received message MUST be ignored.
	5.5.9. EAP-Response/AKA'-Client-Error		6.5.9. EAP-Response/AKA'-Client-Error
	No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST		No changes, except that the AT_KDF_DH or AT_PUB_DH attributes MUST
	NOT be added to this message. The appearance of these messages in a		NOT be added to this message. The appearance of these messages in a
	received message MUST be ignored.		received message MUST be ignored.
	5.5.10. EAP-Request/AKA'-Notification		6.5.10. EAP-Request/AKA'-Notification
	No changes.		No changes.
	5.5.11. EAP-Response/AKA'-Notification		6.5.11. EAP-Response/AKA'-Notification
	No changes.		No changes.
	6. 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 [RFC5448].		since the publication of [RFC5448].
	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 2.3 shows, the likelihood of practically feasible attacks has		Section 3.3 shows, the likelihood of practically feasible attacks has
	increased. Many of these attacks can be best dealt with improved		increased. Many of these attacks can be best dealt with improved
	processes, e.g., limiting the access to the key material within the		processes, e.g., limiting the access to the key material within the
	factory or personnel, etc. But not all attacks can be entirely ruled		factory or personnel, etc. But not all attacks can be entirely ruled
	out for well-resourced adversaries, irrespective of what the		out for well-resourced adversaries, irrespective of what the
	technical algorithms and protection measures are.		technical algorithms and protection measures are.
	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 can not or who are unwilling to mount active attacks
	against large number of sessions. This extension is most useful when		against large number of sessions. This extension is most useful when
	skipping to change at page 17, line 13		skipping to change at page 18, line 13
	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.
	There are two specific needs in the negotiation mechanism:		There are two specific needs in the negotiation mechanism:
	Negotiating key derivation function within the extension		Negotiating key derivation function within the extension
	The negotiation mechanism allows changing the offered key		The negotiation mechanism allows changing the offered key
	derivation function, but the change is visible in the final		derivation function, but the change is visible in the final
	EAP- Request/AKA'-Challenge message that the server sends to		EAP- Request/AKA'-Challenge message that the server sends to
	the peer. This message is authenticated via the AT_MAC		the peer. This message is authenticated via the AT_MAC
	attribute, and carries both the chosen alternative and the		attribute, and carries both the chosen alternative and the
	initially offered list. The peer refuses to accept a change		initially offered list. The peer refuses to accept a change it
	it did not initiate. As a result, both parties are aware		did not initiate. As a result, both parties are aware that a
	that a change is being made and what the original offer was.		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
	the AT_KDF_DH and AT_PUB_DH attributes in the EAP-Request/		AT_KDF_DH and AT_PUB_DH attributes in the EAP-Request/AKA'-
	AKA'-Challenge message. These attributes are protected by		Challenge message. These attributes are protected by AT_MAC,
	AT_MAC, so attempts to change or omit them by an adversary		so attempts to change or omit them by an adversary will be
	will be detected. (Except of course, if the adversary holds		detected. (Except of course, if the adversary holds the long-
	the long-term shared secret and is willing to engage in an		term shared secret and is willing to engage in an active
	active attack, but that is a case that cannot be solved by a		attack, but that is a case that cannot be solved by a technical
	technical change in this protocol.) However, as discussed		change in this protocol.) However, as discussed in the
	in the introduction, even an attacker with access to the		introduction, even an attacker with access to the long-term
	long-term keys is required to be MITM on each AKA run, which		keys is required to be MITM on each AKA run, which makes mass
	makes mass survailance slightly more laborous.		survailance slightly more 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 18, line 33		skipping to change at page 19, line 20
	This extension does not change the properties of related to re-		This extension does not change the properties of 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.
	7. 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' [RFC5448].		with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC5448].
	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_DH (Section 5.1) and AT_KDF_DH (Section 5.2		to be assigned for AT_PUB_DH (Section 6.1) and AT_KDF_DH (Section 6.2
	in the EAP-AKA and EAP-SIM Parameters registry under Attribute Types.		in the EAP-AKA and EAP-SIM Parameters registry under Attribute Types.
	Also, a new registry should be created to represent Diffie-Hellman		Also, a new registry should be created to represent Diffie-Hellman
	Key Derivation Function types. The "EAP-AKA' with DH and Curve25519"		Key Derivation Function types. The "EAP-AKA' with DH and Curve25519"
	type (1, see Section 5.3) needs to be assigned, along with one		type (1, see Section 6.3) needs to be assigned, along with one
	reserved value. The initial contents of this namespace are therefore		reserved value. The initial contents of this namespace are therefore
	as below; new values can be created through the Specification		as below; new values can be created through the Specification
	Required policy [RFC8126].		Required policy [RFC8126].
	Value Description Reference		Value Description Reference
	-------- --------------------------------- ---------------		-------- --------------------------------- ---------------
	0 Reserved [TBD BY IANA: THIS RFC]		0 Reserved [TBD BY IANA: THIS RFC]
	1 EAP-AKA' with DH and Curve25519 [TBD BY IANA: THIS RFC]		1 EAP-AKA' with DH and Curve25519 [TBD BY IANA: THIS RFC]
	2-65535 Unassigned		2-65535 Unassigned
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, DOI		Hashing for Message Authentication", RFC 2104,
	10.17487/RFC2104, February 1997, <https://www.rfc-		DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
	editor.org/info/rfc2104>.		editor.org/info/rfc2104>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	rfc2119>.		editor.org/info/rfc2119>.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, Ed., "Extensible Authentication Protocol		Levkowetz, Ed., "Extensible Authentication Protocol
	(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https:		(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
	//www.rfc-editor.org/info/rfc3748>.		<https://www.rfc-editor.org/info/rfc3748>.
	[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication		[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
	Protocol Method for 3rd Generation Authentication and Key		Protocol Method for 3rd Generation Authentication and Key
	Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,		Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
	January 2006, <https://www.rfc-editor.org/info/rfc4187>.		January 2006, <https://www.rfc-editor.org/info/rfc4187>.
	[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved		[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
	Extensible Authentication Protocol Method for 3rd		Extensible Authentication Protocol Method for 3rd
	Generation Authentication and Key Agreement (EAP-AKA')",		Generation Authentication and Key Agreement (EAP-AKA')",
	RFC 5448, DOI 10.17487/RFC5448, May 2009, <https://www		RFC 5448, DOI 10.17487/RFC5448, May 2009,
	.rfc-editor.org/info/rfc5448>.		<https://www.rfc-editor.org/info/rfc5448>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <https://www.rfc-editor.org/info/rfc7748>.		2016, <https://www.rfc-editor.org/info/rfc7748>.
	[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the		[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
	Internet Key Exchange Protocol Version 2 (IKEv2) Key		Internet Key Exchange Protocol Version 2 (IKEv2) Key
	Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,		Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
	<https://www.rfc-editor.org/info/rfc8031>.		<https://www.rfc-editor.org/info/rfc8031>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	8.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
	Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,		Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
	March 2008, <https://www.rfc-editor.org/info/rfc5216>.		March 2008, <https://www.rfc-editor.org/info/rfc5216>.
			[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <https://www.rfc-editor.org/info/rfc7258>.
	[I-D.mattsson-eap-tls13]		[I-D.mattsson-eap-tls13]
	Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",		Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
	draft-mattsson-eap-tls13-01 (work in progress), January		draft-mattsson-eap-tls13-02 (work in progress), March
	2018.		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,
	skipping to change at page 21, line 17		skipping to change at page 22, line 9
	[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. 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
	uses also a lot of material from [RFC4187] by J. Arkko and H.		document uses also a lot of material from [RFC4187] by J. Arkko and
	Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and P.		H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and
	Eronen.		P. Eronen.
	The authors would also like to thank Tero Kivinen, John Mattson,		The authors would also like to thank Tero Kivinen, John Mattson,
	Mohit Sethi, Vesa Lehtovirta, Joseph Salowey, Kathleen Moriarty,		Mohit Sethi, Vesa Lehtovirta, Joseph Salowey, Kathleen Moriarty,
	Zhang Fu, Bengt Sahlin, Ben Campbell, Prajwol Kumar Nakarmi, Goran		Zhang Fu, Bengt Sahlin, Ben Campbell, Prajwol Kumar Nakarmi, Goran
	Rune, Tim Evans, Helena Vahidi Mazinani, Anand R. Prasad, and many		Rune, Tim Evans, Helena Vahidi Mazinani, Anand R. Prasad, and many
	other people at the GSMA and 3GPP groups for interesting discussions		other people at the GSMA and 3GPP groups for interesting discussions
	in this problem space.		in this problem space.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
End of changes. 61 change blocks.
	146 lines changed or deleted		161 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/