draft-ietf-emu-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
	Intended status: Informational V. Torvinen		Updates: RFC5448 (if approved) V. Torvinen
	Expires: May 8, 2020 Ericsson		Intended status: Informational Ericsson
	November 5, 2019		Expires: May 21, 2020 November 18, 2019
	Perfect-Forward Secrecy for the Extensible Authentication Protocol		Perfect-Forward Secrecy for the Extensible Authentication Protocol
	Method for Authentication and Key Agreement (EAP-AKA' PFS)		Method for Authentication and Key Agreement (EAP-AKA' PFS)
	draft-ietf-emu-aka-pfs-01		draft-ietf-emu-aka-pfs-02
	Abstract		Abstract
	Many different attacks have been reported as part of revelations		Many different attacks have been reported as part of revelations
	associated with pervasive surveillance. Some of the reported attacks		associated with pervasive surveillance. Some of the reported attacks
	involved compromising smart cards, such as attacking SIM card		involved compromising smart cards, such as attacking SIM card
	manufacturers and operators in an effort to compromise shared secrets		manufacturers and operators in an effort to compromise shared secrets
	stored on these cards. Since the publication of those reports,		stored on these cards. Since the publication of those reports,
	manufacturing and provisioning processes have gained much scrutiny		manufacturing and provisioning processes have gained much scrutiny
	and have improved. However, the danger of resourceful attackers for		and have improved. However, the danger of resourceful attackers for
	these systems is still a concern.		these systems is still a concern.
	This specification is an optional extension to the EAP-AKA'		This specification is an optional extension to the EAP-AKA'
	authentication method which was defined in RFC 5448 (to be superseded		authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
	by draft-ietf-emu-rfc5448bis). The extension, when negotiated,		The extension, when negotiated, provides Perfect Forward Secrecy for
	provides Perfect Forward Secrecy for the session key generated as a		the session key generated as a part of the authentication run in EAP-
	part of the authentication run in EAP-AKA'. This prevents an		AKA'. This prevents an attacker who has gained access to the long-
	attacker who has gained access to the long-term pre-shared secret in		term pre-shared secret in a SIM card from being able to decrypt any
	a SIM card from being able to decrypt all past communications. In		past communications. In addition, if the attacker stays merely a
	addition, if the attacker stays merely a passive eavesdropper, the		passive eavesdropper, the extension prevents attacks against future
	extension prevents attacks against future sessions. This forces		sessions. This forces attackers to use active attacks instead.
	attackers to use active attacks instead.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://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 8, 2020.
			This Internet-Draft will expire on May 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://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
	skipping to change at page 3, line 42		skipping to change at page 3, line 40
	The authors want to provide a public specification of an extension		The authors want to provide a public specification of an extension
	that helps defend against one aspect of pervasive surveillance. This		that helps defend against one aspect of pervasive surveillance. This
	is important, given the large number of users such practices may		is important, given the large number of users such practices may
	affect. It is also a stated goal of the IETF to ensure that we		affect. It is also a stated goal of the IETF to ensure that we
	understand the surveillance concerns related to IETF protocols and		understand the surveillance concerns related to IETF protocols and
	take appropriate countermeasures [RFC7258]. This document does that		take appropriate countermeasures [RFC7258]. This document does that
	for EAP-AKA'.		for EAP-AKA'.
	This specification is an optional extension to the EAP-AKA'		This specification is an optional extension to the EAP-AKA'
	authentication method [RFC5448] (to be superseded by		authentication method [I-D.ietf-emu-rfc5448bis]. While optional, the
	[I-D.ietf-emu-rfc5448bis]). The extension, when negotiated, provides		use of this extension is RECOMMENDED.
	Perfect Forward Secrecy for the session key generated as a part of
	the authentication run in EAP-AKA'. This prevents an attacker who		The extension, when negotiated, provides Perfect Forward Secrecy for
	has gained access to the long-term pre-shared secret in a SIM card		the session key generated as a part of the authentication run in EAP-
	from being able to decrypt all past communications. In addition, if		AKA'. This prevents an attacker who has gained access to the long-
	the attacker stays merely a passive eavesdropper, the extension		term pre-shared secret in a SIM card from being able to decrypt any
	prevents attacks against future sessions. This forces attackers to		past communications. In addition, if the attacker stays merely a
	use active attacks instead. As with other protocols, an active		passive eavesdropper, the extension prevents attacks against future
	attacker with access to the long-term key material will of course be		sessions. This forces attackers to use active attacks instead. This
	able to attack all future communications, but risks detection,		is beneficial, because active attacks demand much more resources to
	particularly if done at scale.		launch, and can generally be detected much easier. As with other
			protocols, an active attacker with access to the long-term key
			material will of course be able to attack all future communications,
			but risks detection, particularly if done at scale.
	Attacks against AKA authentication via compromising the long-term		Attacks against AKA authentication via compromising the long-term
	secrets in the SIM cards have been an active discussion topic in many		secrets in the SIM cards have been an active discussion topic in many
	contexts. Perfect forward secrecy is on the list of features for the		contexts. Perfect forward secrecy is on the list of features for the
	next release of 3GPP (5G Phase 2), and this document provides a basis		next release of 3GPP (5G Phase 2), and this document provides a basis
	for providing this feature in a particular fashion.		for providing this feature in a particular fashion.
	It should also be noted that 5G network architecture includes the use		It should also be noted that 5G network architecture includes the use
	of the EAP framework for authentication. While any methods can be		of the EAP framework for authentication. While any methods can be
	run, the default authentication method within that context will be		run, the default authentication method within that context will be
	skipping to change at page 5, line 19		skipping to change at page 5, line 19
	that supports EAP, without changing any network functions beyond		that supports EAP, without changing any network functions beyond
	the EAP endpoints.		the EAP endpoints.
	o Key generation happens at the endpoints, enabling highest grade		o Key generation happens at the endpoints, enabling highest grade
	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.ietf-emu-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.
	3. Background		3. Background
	3.1. AKA		3.1. AKA
	AKA is based on challenge-response mechanisms and symmetric		AKA is based on challenge-response mechanisms and symmetric
	cryptography. AKA typically runs in a UMTS Subscriber Identity		cryptography. AKA typically runs in a UMTS Subscriber Identity
	Module (USIM) or a CDMA2000 (Removable) User Identity Module		Module (USIM) or a CDMA2000 (Removable) User Identity Module
	((R)UIM). In contrast with its earlier GSM counterparts, 3rd		((R)UIM). In contrast with its earlier GSM counterparts, AKA
	generation AKA provides long key lengths and mutual authentication.		provides long key lengths and mutual authentication.
	AKA works in the following manner:		AKA works in the following manner:
	o The identity module and the home environment have agreed on a		o The identity module and the home environment have agreed on a
	secret key beforehand.		secret key beforehand.
	o The actual authentication process starts by having the home		o The actual authentication process starts by having the home
	environment produce an authentication vector, based on the secret		environment produce an authentication vector, based on the secret
	key and a sequence number. The authentication vector contains a		key and a sequence number. The authentication vector contains a
	random part RAND, an authenticator part AUTN used for		random part RAND, an authenticator part AUTN used for
	skipping to change at page 6, line 15		skipping to change at page 6, line 15
	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.
	3.2. EAP-AKA' Protocol		3.2. EAP-AKA' Protocol
	When AKA (and AKA') are embedded into EAP, the authentication on the		When AKA are embedded into EAP, the authentication on the network
	network side is moved to the home environment; the serving network		side is moved to the home environment; the serving network performs
	performs the role of a pass-through authenticator. Figure 1		the role of a pass-through authenticator. Figure 1 describes the
	describes the basic flow in the EAP-AKA' authentication process. The		basic flow in the EAP-AKA' authentication process. The definition of
	definition of the full protocol behaviour, along with the definition		the full protocol behaviour, along with the definition of attributes
	of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in		AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in
	[I-D.ietf-emu-rfc5448bis] and [RFC4187].		[I-D.ietf-emu-rfc5448bis] and [RFC4187].
	Peer Server		Peer Server
	| EAP-Request/Identity |		| EAP-Request/Identity |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	| |		| |
	| EAP-Response/Identity |		| EAP-Response/Identity |
	| (Includes user's Network Access Identifier, NAI) |		| (Includes user's Network Access Identifier, NAI) |
	|------------------------------------------------------>|		|------------------------------------------------------>|
	| +-------------------------------------------------+		| +-------------------------------------------------+
	skipping to change at page 8, line 7		skipping to change at page 8, line 7
	| | 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
	3.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 and		Current 3GPP systems use SIM pre-shared key based protocols and
	Authentication and Key Agreement (AKA) to authenticate subscribers.		Authentication and Key Agreement (AKA) to authenticate subscribers.
	The general security properties and potential vulnerabilities of AKA		The general security properties and potential vulnerabilities of AKA
	and EAP-AKA' are discussed in [I-D.ietf-emu-rfc5448bis].		and EAP-AKA' are discussed in [I-D.ietf-emu-rfc5448bis].
	An important vulnerability in that discussion relates to the recent		An important vulnerability in that discussion relates to the recent
	reports of compromised long term pre-shared keys used in AKA		reports of compromised long term pre-shared keys used in AKA
	[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as		[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as
	all security systems fail at least to some extent if key material is		all security systems fail at least to some extent if key material is
	stolen. However, the reports indicate a need to look into solutions		stolen. However, the reports indicate a need to look into solutions
	that can operate at least to an extent under these types of attacks.		that can operate at least to an extent under these types of attacks.
	It is noted in [Heist2015] that some security can be retained even in		It is noted in [Heist2015] that some security can be retained even in
	the face of the attacks by providing Perfect Forward Security (PFS)		the face of the attacks by providing Perfect Forward Secrecy (PFS)
	[DOW1992] for the session key. If AKA would have provided PFS,		[DOW1992] for the session key. If AKA would have provided PFS,
	compromising the pre-shared key would not be sufficient to perform		compromising the pre-shared key would not be sufficient to perform
	passive attacks; the attacker is, in addition, forced to be a Man-In-		passive attacks; the attacker is, in addition, forced to be a Man-In-
	The-Middle (MITM) during the AKA run and subsequent communication		The-Middle (MITM) during the AKA run and subsequent communication
	between the parties.		between the parties.
	4. Requirements Language		4. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	5. Protocol Overview		5. Protocol Overview
	Introducing PFS for EAP-AKA' can be achieved by using an Elliptic		Introducing PFS for EAP-AKA' can be achieved by using an Elliptic
	Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' PFS this		Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' PFS this
	exchange is run in an ephemeral manner, i.e., using temporary keys as		exchange is run in an ephemeral manner, i.e., both sides generate
	specified in [RFC8031] Section 2. This method is referred to as		temporary keys as specified in [RFC7748]. This method is referred to
	ECDHE, where the last 'E' stands for Ephemeral.		as ECDHE, where the last 'E' stands for Ephemeral.
	The enhancements in the EAP-AKA' PFS protocol are compatible with the		The enhancements in the EAP-AKA' PFS protocol are compatible with the
	signaling flow and other basic structures of both AKA and EAP-AKA'.		signaling flow and other basic structures of both AKA and EAP-AKA'.
	The intent is to implement the enhancement as optional attributes		The intent is to implement the enhancement as optional attributes
	that legacy implementations can ignore.		that legacy implementations can ignore.
	The purpose of the protocol is to achieve mutual authentication		The purpose of the protocol is to achieve mutual authentication
	between the EAP server and peer, and to establish keying material for		between the EAP server and peer, and to establish keying material for
	secure communication between the two. This document specifies the		secure communication between the two. This document specifies the
	calculation of key material, providing new properties that are not		calculation of key material, providing new properties that are not
	skipping to change at page 11, line 38		skipping to change at page 11, line 38
	This is set to TBA1 BY IANA.		This is set to TBA1 BY IANA.
	Length		Length
	The length of the attribute, set as other attributes in EAP-AKA		The length of the attribute, set as other attributes in EAP-AKA
	[RFC4187].		[RFC4187].
	Value		Value
	This value is the sender's ECDHE public value. For Curve25519,		This value is the sender's ECDHE public value. For X25519/
	the length of this value is 32 bytes, encoded in binary as		Curve25519, the length of this value is 32 bytes, encoded in
	specified [RFC7748] Section 6.1.		binary as specified [RFC7748] Section 6.1.
	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.
	6.2. AT_KDF_PFS		6.2. AT_KDF_PFS
	The AT_KDF_PFS indicates the used or desired key generation function,		The AT_KDF_PFS 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 ECDHE group. A		also at the same time indicate the used or desired ECDHE group. A
	new attribute is needed to carry this information, as AT_KDF carries		new attribute is needed to carry this information, as AT_KDF carries
	skipping to change at page 14, line 8		skipping to change at page 14, line 8
	occurred in the list of AT_KDF_PFS attributes. If yes, it continues.		occurred in the list of AT_KDF_PFS 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/AKA'-		authentication. If the peer receives multiple EAP-Request/AKA'-
	Challenge messages with differing AT_KDF_PFS attributes without		Challenge messages with differing AT_KDF_PFS attributes without
	having requested negotiation, the peer MUST behave as if AT_MAC had		having requested negotiation, the peer MUST behave as if AT_MAC had
	been incorrect and fail the authentication.		been incorrect and fail the authentication.
	6.3. New Key Derivation Function		6.3. New Key Derivation Function
	A new Key Derivation Function type is defined for "EAP-AKA' with		A new Key Derivation Function type is defined for "EAP-AKA' with
	ECDHE and Curve25519", represented by value 1. It represents a		ECDHE and X25519", represented by value 1. It represents a
	particular choice of key derivation function and at the same time		particular choice of key derivation function and at the same time
	selects an ECDHE group to be used.		selects an ECDHE group to be used.
	The Key Derivation Function type value is only used in the AT_KDF_PFS		The Key Derivation Function type value is only used in the AT_KDF_PFS
	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 [I-D.ietf-emu-rfc5448bis].		as defined in [I-D.ietf-emu-rfc5448bis].
	Key derivation in this extension produces exactly the same keys for		Key derivation in this extension produces exactly the same keys for
	internal use within one authentication run as		internal use within one authentication run as
	skipping to change at page 14, line 40		skipping to change at page 14, line 40
	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
	specified in Section 2 of [RFC8031] and Section 6.1 of [RFC7748].		specified in Section 6.1 of [RFC7748].
	Both the peer and the server MAY check for zero-value shared secret		Both the peer and the server MAY check for zero-value shared secret
	as specified in Section 6.1 of [RFC7748]. If such checking is		as specified in Section 6.1 of [RFC7748]. If such checking is
	performed and the SHARED_SECRET has a zero value, both parties MUST		performed and the SHARED_SECRET has a zero value, both parties MUST
	behave as if the current EAP-AKA' authentication process starts again		behave as if the current EAP-AKA' authentication process starts again
	from the beginning.		from the beginning.
	Note: The way that shared secret is tested for zero can, if		Note: The way that shared secret is tested for zero can, if
	performed inappropriately, provide an ability for attackers to		performed inappropriately, provide an ability for attackers to
	listen to CPU power usage side channels. Refer to [RFC7748] for a		listen to CPU power usage side channels. Refer to [RFC7748] for a
	skipping to change at page 15, line 31		skipping to change at page 15, line 31
	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].
	6.4. ECDHE Groups		6.4. ECDHE Groups
	The selection of suitable groups for the elliptic curve computation		The selection of suitable groups for the elliptic curve 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_PFS.		deciding to use of particular key derivation function in AT_KDF_PFS.
	For "EAP-AKA' with ECDHE and Curve25519" the group is the Curve25519		For "EAP-AKA' with ECDHE and X25519" the group is the Curve25519
	group specified in [RFC8031].		group specified in [RFC7748].
	6.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 [I-D.ietf-emu-rfc5448bis] or		otherwise specified here, the rules from [I-D.ietf-emu-rfc5448bis] or
	skipping to change at page 20, line 37		skipping to change at page 20, line 37
	If turning off the extension specified in this protocol is not		If turning off the extension specified in this protocol is not
	allowed by policy, the use of legacy equipment that does not		allowed by policy, the use of legacy equipment that does not
	support this protocol is no longer possible. This may be		support this protocol is no longer possible. This may be
	appropriate when, for instance, support for the extension is		appropriate when, for instance, support for the extension is
	sufficiently widespread, or required in a particular version of		sufficiently widespread, or required in a particular version of
	a mobile network.		a mobile network.
	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 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 SIM card. As a
	As a result, if anyone successfully recovers shared secret		result, if anyone successfully recovers shared secret information,
	information, they are unable to decrypt communications protected		they are unable to decrypt communications protected by the keys
	by the keys generated through this extension. Note that the		generated through this extension. Note that the recovery of
	recovery of shared secret information could occur either before or		shared secret information could occur either before or after the
	after the time that the protected communications are used. When		time that the protected communications are used. When this
	this extension is used, communications at time t0 can be protected		extension is used, communications at time t0 can be protected if
	if at some later time t1 an adversary learns of long-term shared		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 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
	skipping to change at page 22, line 25		skipping to change at page 22, line 25
	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'
	[I-D.ietf-emu-rfc5448bis].		[I-D.ietf-emu-rfc5448bis].
	Two new Attribute Type value (TBA1, TBA2) in the skippable range need		Two new Attribute Type value (TBA1, TBA2) in the skippable range need
	to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_PFS		to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_PFS
	(Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under		(Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under
	Attribute Types.		Attribute Types.
	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 ECDHE and		Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519"
	Curve25519" type (1, see Section 6.3) needs to be assigned, along		type (1, see Section 6.3) needs to be assigned, along with one
	with one reserved value. The initial contents of this namespace are		reserved value. The initial contents of this namespace are therefore
	therefore as below; new values can be created through the		as below; new values can be created through the Specification
	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 ECDHE and Curve25519 [TBD BY IANA: THIS RFC]		1 EAP-AKA' with ECDHE and X25519 [TBD BY IANA: THIS RFC]
	2-65535 Unassigned		2-65535 Unassigned
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-emu-rfc5448bis]
	Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
	"Improved Extensible Authentication Protocol Method for
	3GPP Mobile Network Authentication and Key Agreement (EAP-
	AKA')", draft-ietf-emu-rfc5448bis-05 (work in progress),
	July 2019.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<https://www.rfc-editor.org/info/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,		(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
	<https://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>.
	[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
	Internet Key Exchange Protocol Version 2 (IKEv2) Key
	Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
	<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,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		[I-D.ietf-emu-rfc5448bis]
			Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
	[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,		"Improved Extensible Authentication Protocol Method for
	"Authentication and Authenticated Key Exchanges", June		3GPP Mobile Network Authentication and Key Agreement (EAP-
	1992, in Designs, Codes and Cryptography 2 (2): pp.		AKA')", draft-ietf-emu-rfc5448bis-05 (work in progress),
	107-125.		July 2019.
	[Heist2015]
	Scahill, J. and J. Begley, "The great SIM heist", February
	2015, in https://firstlook.org/theintercept/2015/02/19/
	great-sim-heist/ .
	[I-D.mattsson-eap-tls13]		9.2. Informative References
	Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
	draft-mattsson-eap-tls13-02 (work in progress), March
	2018.
	[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>.
	skipping to change at page 24, line 30		skipping to change at page 24, line 10
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[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>.
			[I-D.ietf-emu-eap-tls13]
			Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
			draft-ietf-emu-eap-tls13-07 (work in progress), September
			2019.
	[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.
			[Heist2015]
			Scahill, J. and J. Begley, "The great SIM heist", February
			2015, in https://firstlook.org/theintercept/2015/02/19/
			great-sim-heist/ .
			[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,
			"Authentication and Authenticated Key Exchanges", June
			1992, in Designs, Codes and Cryptography 2 (2): pp.
			107-125.
	Appendix A. Change Log		Appendix A. Change Log
			The -02 version of the WG draft took into account additional reviews,
			and changed the document to update RFC 5448 (or rather, its
			successor, [I-D.ietf-emu-rfc5448bis]), changed the wording of the
			recommendation with regards to the use of this extension, clarified
			the references to the definition of X25519 and Curve25519, clarified
			the distinction to ECDH methods that use partially static keys, and
			simplified the use of AKA and SIM card terminology. Some editorial
			changes were also made.
			The -00 and -01 versions of the WG draft made no major changes, only
			updates to some references.
	The -05 version is merely a refresh while the draft was waiting for		The -05 version is merely a refresh while the draft was waiting for
	WG adoption.		WG adoption.
	The -04 version of this draft made only editorial changes.		The -04 version of this draft made only editorial changes.
	The -03 version of this draft changed the naming of various protocol		The -03 version of this draft changed the naming of various protocol
	components, values, and notation to match with the use of ECDH in		components, values, and notation to match with the use of ECDH in
	ephemeral mode. The AT_KDF_PFS negotiation process was clarified in		ephemeral mode. The AT_KDF_PFS negotiation process was clarified in
	that exactly one key is ever sent in AT_KDF_ECDHE. The option of		that exactly one key is ever sent in AT_KDF_ECDHE. The option of
	checking for zero key values IN ECDHE was added. The format of the		checking for zero key values IN ECDHE was added. The format of the
	skipping to change at page 25, line 16		skipping to change at page 25, line 22
	Appendix B. Acknowledgments		Appendix B. 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		were J. Arkko, K. Norrman, M. Naslund, and B. Sahlin. This
	document uses also a lot of material from [RFC4187] by J. Arkko and		document uses also a lot of material from [RFC4187] by J. Arkko and
	H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and		H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and
	P. Eronen.		P. Eronen.
	The authors would also like to thank Tero Kivinen, John Mattson,		The authors would also like to thank Tero Kivinen, John Mattsson,
	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
End of changes. 30 change blocks.
	94 lines changed or deleted		104 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/