draft-ietf-emu-aka-pfs-02.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: RFC5448 (if approved) V. Torvinen		Updates: RFC5448 (if approved) V. Torvinen
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: May 21, 2020 November 18, 2019		Expires: November 23, 2020 May 22, 2020
	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-02		draft-ietf-emu-aka-pfs-03
	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 49		skipping to change at page 1, line 49
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 21, 2020.		This Internet-Draft will expire on November 23, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 32		skipping to change at page 2, line 32
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Design and Deployment Objectives . . . . . . . . . . 4		2. Protocol Design and Deployment Objectives . . . . . . . . . . 4
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6		3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6
	3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 8		3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 8
	4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8		4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8
	5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8		5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
	6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11		6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11
	6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11		6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. AT_KDF_PFS . . . . . . . . . . . . . . . . . . . . . . . 11		6.2. AT_KDF_PFS . . . . . . . . . . . . . . . . . . . . . . . 12
	6.3. New Key Derivation Function . . . . . . . . . . . . . . . 14		6.3. New Key Derivation Functions . . . . . . . . . . . . . . 14
	6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15		6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15
	6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15		6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15
	6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 15		6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16
	6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16		6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16
	6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16		6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16
	6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16		6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17
	6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17		6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17
	6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17		6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17
	6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 17		6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18
	6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 17		6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18
	6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18		6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18
	6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18		6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18
	6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18		6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1. Normative References . . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . 23		9.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	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 during the transfer of		during the manufacturing process of cards, or during the transfer of
	cards and associated information to the operator. Since the		cards and associated information to the operator. Since the
	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 X25519/		This value is the sender's ECDHE public value. It is calculated
	Curve25519, the length of this value is 32 bytes, encoded in		as follows:
	binary as specified [RFC7748] Section 6.1.
			* For X25519/Curve25519, the length of this value is 32 bytes,
			encoded in binary as specified [RFC7748] Section 6.1.
			* For P-256, the length of this value is 32 bytes, encoded in
			binary as specified in [SEC2v2].
	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 5		skipping to change at page 14, line 7
	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_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 Functions
	A new Key Derivation Function type is defined for "EAP-AKA' with		Two new Key Derivation Function types are defined for "EAP-AKA' with
	ECDHE and X25519", represented by value 1. It represents a		ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE
	particular choice of key derivation function and at the same time		and P-256", represented by value 2. These represent a particular
	selects an ECDHE group to be used.		choice of key derivation function and at the same time 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
	[I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is		[I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is
	used in AT_MAC is still exactly as it was in EAP-AKA'. The only		used in AT_MAC is still exactly as it was in EAP-AKA'. The only
	skipping to change at page 15, line 31		skipping to change at page 15, line 37
	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 X25519" the group is the Curve25519		For "EAP-AKA' with ECDHE and X25519" the group is the Curve25519
	group specified in [RFC7748].		group specified in [RFC7748]. The support for this group is
			REQUIRED.
			For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group
			(SEC group secp256r1), specified in [SEC2v2]. The support for this
			group is OPTIONAL.
	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 22, line 26		skipping to change at page 22, line 40
	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 X25519"		Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519"
	type (1, see Section 6.3) needs to be assigned, along with one		and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see Section 6.3)
	reserved value. The initial contents of this namespace are therefore		need to be assigned, along with one reserved value. The initial
	as below; new values can be created through the Specification		contents of this namespace are therefore as below; new values can be
	Required policy [RFC8126].		created through the Specification 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 X25519 [TBD BY IANA: THIS RFC]		1 EAP-AKA' with ECDHE and X25519 [TBD BY IANA: THIS RFC]
	2-65535 Unassigned		2 EAP-AKA' with ECDHE and P-256 [TBD BY IANA: THIS RFC]
			3-65535 Unassigned [TBD BY IANA: THIS RFC]
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	skipping to change at page 23, line 27		skipping to change at page 23, line 41
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[I-D.ietf-emu-rfc5448bis]		[I-D.ietf-emu-rfc5448bis]
	Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,		Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
	"Improved Extensible Authentication Protocol Method for		"Improved Extensible Authentication Protocol Method for
	3GPP Mobile Network Authentication and Key Agreement (EAP-		3GPP Mobile Network Authentication and Key Agreement (EAP-
	AKA')", draft-ietf-emu-rfc5448bis-05 (work in progress),		AKA')", draft-ietf-emu-rfc5448bis-07 (work in progress),
	July 2019.		March 2020.
			[SEC2v2] Standards for Elliptic Cryptography Group, , "SEC 2:
			Recommended Elliptic Curve Domain Parameters", August
			2010, version 2.0.
	9.2. Informative References		9.2. Informative References
	[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible		[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
	Authentication Protocol Method for Global System for		Authentication Protocol Method for Global System for
	Mobile Communications (GSM) Subscriber Identity Modules		Mobile Communications (GSM) Subscriber Identity Modules
	(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,		(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
	<https://www.rfc-editor.org/info/rfc4186>.		<https://www.rfc-editor.org/info/rfc4186>.
	[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS		[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
	skipping to change at page 24, line 12		skipping to change at page 24, line 32
	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]		[I-D.ietf-emu-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-ietf-emu-eap-tls13-07 (work in progress), September		draft-ietf-emu-eap-tls13-09 (work in progress), March
	2019.		2020.
	[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]		[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/
	great-sim-heist/ .		great-sim-heist/ .
	[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,		[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,
	"Authentication and Authenticated Key Exchanges", June		"Authentication and Authenticated Key Exchanges", June
	1992, in Designs, Codes and Cryptography 2 (2): pp.		1992, in Designs, Codes and Cryptography 2 (2): pp.
	107-125.		107-125.
	Appendix A. Change Log		Appendix A. Change Log
			The -03 version of the WG draft is first of all a refresh; there are
			no issues that we think need addressing, beyond the one for which
			there is a suggestion in -03: The specification now suggests an
			alternate group/curve as an optional one besides X25519. The
			specific choice of particular groups and algorithms is still up to
			the working group.
	The -02 version of the WG draft took into account additional reviews,		The -02 version of the WG draft took into account additional reviews,
	and changed the document to update RFC 5448 (or rather, its		and changed the document to update RFC 5448 (or rather, its
	successor, [I-D.ietf-emu-rfc5448bis]), changed the wording of the		successor, [I-D.ietf-emu-rfc5448bis]), changed the wording of the
	recommendation with regards to the use of this extension, clarified		recommendation with regards to the use of this extension, clarified
	the references to the definition of X25519 and Curve25519, clarified		the references to the definition of X25519 and Curve25519, clarified
	the distinction to ECDH methods that use partially static keys, and		the distinction to ECDH methods that use partially static keys, and
	simplified the use of AKA and SIM card terminology. Some editorial		simplified the use of AKA and SIM card terminology. Some editorial
	changes were also made.		changes were also made.
	The -00 and -01 versions of the WG draft made no major changes, only		The -00 and -01 versions of the WG draft made no major changes, only
End of changes. 21 change blocks.
	36 lines changed or deleted		60 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/