draft-ietf-emu-rfc5448bis-05.txt		draft-ietf-emu-rfc5448bis-06.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft V. Lehtovirta		Internet-Draft V. Lehtovirta
	Obsoletes: 5448 (if approved) V. Torvinen		Obsoletes: 5448 (if approved) V. Torvinen
	Updates: 4187 (if approved) Ericsson		Updates: 4187 (if approved) Ericsson
	Intended status: Informational P. Eronen		Intended status: Informational P. Eronen
	Expires: January 9, 2020 Independent		Expires: May 21, 2020 Independent
	July 8, 2019		November 18, 2019
	Improved Extensible Authentication Protocol Method for 3GPP Mobile		Improved Extensible Authentication Protocol Method for 3GPP Mobile
	Network Authentication and Key Agreement (EAP-AKA')		Network Authentication and Key Agreement (EAP-AKA')
	draft-ietf-emu-rfc5448bis-05		draft-ietf-emu-rfc5448bis-06
	Abstract		Abstract
	The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the		The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
	primary authentication mechanism for devices wishing to access mobile		primary authentication mechanism for devices wishing to access mobile
	networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible		networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible
	within the Extensible Authentication Protocol (EAP) framework. RFC		within the Extensible Authentication Protocol (EAP) framework. RFC
	5448 (EAP-AKA') was an improved version of EAP-AKA.		5448 (EAP-AKA') was an improved version of EAP-AKA.
	This memo replaces the specification of EAP-AKA'. EAP-AKA' was		This memo replaces the specification of EAP-AKA'. EAP-AKA' was
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 January 9, 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	7.4. Security Properties of Binding Network Names . . . . . . 33		7.4. Security Properties of Binding Network Names . . . . . . 33
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35		8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35
	8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35		8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35
	8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35		8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.1. Normative References . . . . . . . . . . . . . . . . . . 35		9.1. Normative References . . . . . . . . . . . . . . . . . . 35
	9.2. Informative References . . . . . . . . . . . . . . . . . 37		9.2. Informative References . . . . . . . . . . . . . . . . . 37
	Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41		Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41
	Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 41		Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 41
	Appendix C. Changes from Previous Version of This Draft . . . . 42		Appendix C. Changes from Previous Version of This Draft . . . . 41
	Appendix D. Importance of Explicit Negotiation . . . . . . . . . 43		Appendix D. Importance of Explicit Negotiation . . . . . . . . . 43
	Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44		Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the		The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
	primary authentication mechanism for devices wishing to access mobile		primary authentication mechanism for devices wishing to access mobile
	skipping to change at page 15, line 19 ¶		skipping to change at page 15, line 19 ¶
	3.4. Hash Functions		3.4. Hash Functions
	EAP-AKA' uses SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 (see		EAP-AKA' uses SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 (see
	[FIPS.180-4] [RFC2104]) as in EAP-AKA. This requires a change to the		[FIPS.180-4] [RFC2104]) as in EAP-AKA. This requires a change to the
	pseudo-random function (PRF) as well as the AT_MAC and AT_CHECKCODE		pseudo-random function (PRF) as well as the AT_MAC and AT_CHECKCODE
	attributes.		attributes.
	3.4.1. PRF'		3.4.1. PRF'
	The PRF' construction is the same one IKEv2 uses (see Section 2.13 of		The PRF' construction is the same one IKEv2 uses (see Section 2.13 of
	[RFC4306]). The function takes two arguments. K is a 256-bit value		[RFC7296]). The function takes two arguments. K is a 256-bit value
	and S is a byte string of arbitrary length. PRF' is defined as		and S is a byte string of arbitrary length. PRF' is defined as
	follows:		follows:
	PRF'(K,S) = T1 | T2 | T3 | T4 | ...		PRF'(K,S) = T1 | T2 | T3 | T4 | ...
	where:		where:
	T1 = HMAC-SHA-256 (K, S | 0x01)		T1 = HMAC-SHA-256 (K, S | 0x01)
	T2 = HMAC-SHA-256 (K, T1 | S | 0x02)		T2 = HMAC-SHA-256 (K, T1 | S | 0x02)
	T3 = HMAC-SHA-256 (K, T2 | S | 0x03)		T3 = HMAC-SHA-256 (K, T2 | S | 0x03)
	T4 = HMAC-SHA-256 (K, T3 | S | 0x04)		T4 = HMAC-SHA-256 (K, T3 | S | 0x04)
	skipping to change at page 23, line 46 ¶		skipping to change at page 23, line 46 ¶
	If no identity was communicated inside EAP, then the identity is		If no identity was communicated inside EAP, then the identity is
	the one communicated outside EAP in link layer messaging.		the one communicated outside EAP in link layer messaging.
	In this case, the used identity MUST be the identity most recently		In this case, the used identity MUST be the identity most recently
	communicated by the peer to the network, again regardless of what		communicated by the peer to the network, again regardless of what
	type of identity it may have been.		type of identity it may have been.
	5.3.1.1. Format of the SUPI		5.3.1.1. Format of the SUPI
	A SUPI is either an IMSI or a Network Access Identifier [RFC4282].		A SUPI is either an IMSI or a Network Access Identifier [RFC7542].
	When used in EAP-AKA', the format of the SUPI MUST be as specified in		When used in EAP-AKA', the format of the SUPI MUST be as specified in
	[TS-3GPP.23.003] Section 28.7.2, with the semantics defined in		[TS-3GPP.23.003] Section 28.7.2, with the semantics defined in
	[TS-3GPP.23.003] Section 2.2A. Also, in contrast to [RFC5448], in 5G		[TS-3GPP.23.003] Section 2.2A. Also, in contrast to [RFC5448], in 5G
	EAP-AKA' does not use the "0" or "6" prefix in front of the entire		EAP-AKA' does not use the "0" or "6" prefix in front of the entire
	IMSI.		IMSI.
	For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),		For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),
	the NAI format for the SUPI takes the form:		the NAI format for the SUPI takes the form:
	skipping to change at page 27, line 49 ¶		skipping to change at page 27, line 49 ¶
	non-trivial information about any of these keys based on the other		non-trivial information about any of these keys based on the other
	keys. An attacker also cannot calculate the pre-shared secret		keys. An attacker also cannot calculate the pre-shared secret
	from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any		from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any
	practically feasible means.		practically feasible means.
	EAP-AKA' adds an additional layer of key derivation functions		EAP-AKA' adds an additional layer of key derivation functions
	within itself to protect against the use of compromised keys.		within itself to protect against the use of compromised keys.
	This is discussed further in Section 7.4.		This is discussed further in Section 7.4.
	EAP-AKA' uses a pseudo-random function modeled after the one used		EAP-AKA' uses a pseudo-random function modeled after the one used
	in IKEv2 [RFC4306] together with SHA-256.		in IKEv2 [RFC7296] together with SHA-256.
	Key strength		Key strength
	See above.		See above.
	Dictionary attack resistance		Dictionary attack resistance
	Under the SHA-256 assumption, the properties of EAP-AKA' are at		Under the SHA-256 assumption, the properties of EAP-AKA' are at
	least as good as those of EAP-AKA in this respect. Refer to		least as good as those of EAP-AKA in this respect. Refer to
	[RFC4187], Section 12 for further details.		[RFC4187], Section 12 for further details.
	skipping to change at page 37, line 25 ¶		skipping to change at page 37, line 25 ¶
	[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>.
	[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The		[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
	Network Access Identifier", RFC 4282,		DOI 10.17487/RFC7542, May 2015, <https://www.rfc-
	DOI 10.17487/RFC4282, December 2005, <https://www.rfc-		editor.org/info/rfc7542>.
	editor.org/info/rfc4282>.
	[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>.
	skipping to change at page 38, line 43 ¶		skipping to change at page 38, line 43 ¶
	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>.
	[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity		[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
	Selection Hints for the Extensible Authentication Protocol		Selection Hints for the Extensible Authentication Protocol
	(EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006,		(EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006,
	<https://www.rfc-editor.org/info/rfc4284>.		<https://www.rfc-editor.org/info/rfc4284>.
	[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
	Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
	<https://www.rfc-editor.org/info/rfc4306>.
	[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,		[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,
	"Network Discovery and Selection Problem", RFC 5113,		"Network Discovery and Selection Problem", RFC 5113,
	DOI 10.17487/RFC5113, January 2008, <https://www.rfc-		DOI 10.17487/RFC5113, January 2008, <https://www.rfc-
	editor.org/info/rfc5113>.		editor.org/info/rfc5113>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
	editor.org/info/rfc5226>.
	[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible		[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
	Authentication Protocol (EAP) Key Management Framework",		Authentication Protocol (EAP) Key Management Framework",
	RFC 5247, DOI 10.17487/RFC5247, August 2008,		RFC 5247, DOI 10.17487/RFC5247, August 2008,
	<https://www.rfc-editor.org/info/rfc5247>.		<https://www.rfc-editor.org/info/rfc5247>.
	[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,		RFC 5448, DOI 10.17487/RFC5448, May 2009,
	<https://www.rfc-editor.org/info/rfc5448>.		<https://www.rfc-editor.org/info/rfc5448>.
	skipping to change at page 39, line 36 ¶		skipping to change at page 39, line 26 ¶
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013, <https://www.rfc-		DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
	editor.org/info/rfc6973>.		editor.org/info/rfc6973>.
	[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.
			Kivinen, "Internet Key Exchange Protocol Version 2
			(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <https://www.rfc-editor.org/info/rfc7296>.
	[I-D.arkko-eap-aka-pfs]		[I-D.arkko-eap-aka-pfs]
	Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward		Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward
	Secrecy for the Extensible Authentication Protocol Method		Secrecy for the Extensible Authentication Protocol Method
	for Authentication and Key Agreement (EAP-AKA' PFS)",		for Authentication and Key Agreement (EAP-AKA' PFS)",
	draft-arkko-eap-aka-pfs-04 (work in progress), January		draft-arkko-eap-aka-pfs-04 (work in progress), January
	2019.		2019.
	[Heist2015]		[Heist2015]
	Scahill, J. and J. Begley, "The great SIM heist", February		Scahill, J. and J. Begley, "The great SIM heist", February
	2015, in https://firstlook.org/theintercept/2015/02/19/		2015, in https://firstlook.org/theintercept/2015/02/19/
	skipping to change at page 41, line 31 ¶		skipping to change at page 41, line 24 ¶
	definition in RFC 5448, which referenced RFC 4187. See Section 5.		definition in RFC 5448, which referenced RFC 4187. See Section 5.
	Thirdly, exported parameters for EAP-AKA' have been defined in		Thirdly, exported parameters for EAP-AKA' have been defined in
	Section 6, as required by [RFC5247], including the definition of		Section 6, as required by [RFC5247], including the definition of
	those parameters for both full authentication and fast re-		those parameters for both full authentication and fast re-
	authentication.		authentication.
	The security, privacy, and pervasive monitoring considerations have		The security, privacy, and pervasive monitoring considerations have
	been updated or added. See Section 7.		been updated or added. See Section 7.
	The references to [RFC2119], [RFC5226], [FIPS.180-1] and [FIPS.180-2]		The references to [RFC2119], [RFC7542], [RFC7296], [RFC8126],
	have been updated to their most recent versions and language in this		[FIPS.180-1] and [FIPS.180-2] have been updated to their most recent
	document changed accordingly. Similarly, references to all 3GPP		versions and language in this document changed accordingly.
	technical specifications have been updated to their 5G (Release 15)		Similarly, references to all 3GPP technical specifications have been
	versions or otherwise most recent version when there has not been a		updated to their 5G (Release 15) versions or otherwise most recent
	5G-related update.		version when there has not been a 5G-related update.
	Finally, a number of clarifications have been made, including a		Finally, a number of clarifications have been made, including a
	summary of where attributes may appear.		summary of where attributes may appear.
	Appendix B. Changes from RFC 4187 to RFC 5448		Appendix B. Changes from RFC 4187 to RFC 5448
	The changes to RFC 4187 relate only to the bidding down prevention		The changes to RFC 4187 relate only to the bidding down prevention
	support defined in Section 4. In particular, this document does not		support defined in Section 4. In particular, this document does not
	change how the Master Key (MK) is calculated in RFC 4187 (it uses CK		change how the Master Key (MK) is calculated in RFC 4187 (it uses CK
	and IK, not CK' and IK'); neither is any processing of the AMF bit		and IK, not CK' and IK'); neither is any processing of the AMF bit
	skipping to change at page 43, line 42 ¶		skipping to change at page 43, line 33 ¶
	o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'-		o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'-
	Synchronization-Failure message was clarified in Section 3.2.		Synchronization-Failure message was clarified in Section 3.2.
	o Updated and added several references		o Updated and added several references
	o Switched to use of hexadecimal for EAP Type Values for consistency		o Switched to use of hexadecimal for EAP Type Values for consistency
	with other documents.		with other documents.
	o Made editorial clarifications to a number places in the document.		o Made editorial clarifications to a number places in the document.
			The version -06 included changes to updates of references to newer
			versions on IANA considerations guidelines, NAIs, and IKEv2.
	Appendix D. Importance of Explicit Negotiation		Appendix D. Importance of Explicit Negotiation
	Choosing between the traditional and revised AKA key derivation		Choosing between the traditional and revised AKA key derivation
	functions is easy when their use is unambiguously tied to a		functions is easy when their use is unambiguously tied to a
	particular radio access network, e.g., Long Term Evolution (LTE) as		particular radio access network, e.g., Long Term Evolution (LTE) as
	defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined		defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined
	by 3GPP2. There is no possibility for interoperability problems if		by 3GPP2. There is no possibility for interoperability problems if
	this radio access network is always used in conjunction with new		this radio access network is always used in conjunction with new
	protocols that cannot be mixed with the old ones; clients will always		protocols that cannot be mixed with the old ones; clients will always
	know whether they are connecting to the old or new system.		know whether they are connecting to the old or new system.
End of changes. 13 change blocks.
	27 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/