< draft-ietf-ipsecme-eap-mutual-04.txt		draft-ietf-ipsecme-eap-mutual-05.txt >
	Network Working Group P. Eronen		Network Working Group P. Eronen
	Internet-Draft Nokia		Internet-Draft Nokia
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: December 16, 2010 Nokia Siemens Networks		Expires: December 27, 2010 Nokia Siemens Networks
	Y. Sheffer		Y. Sheffer
	Independent		Independent
	June 14, 2010		June 25, 2010
	An Extension for EAP-Only Authentication in IKEv2		An Extension for EAP-Only Authentication in IKEv2
	draft-ietf-ipsecme-eap-mutual-04.txt		draft-ietf-ipsecme-eap-mutual-05.txt
	Abstract		Abstract
	IKEv2 specifies that EAP authentication must be used together with		IKEv2 specifies that EAP authentication must be used together with
	public key signature based responder authentication. This is		public key signature based responder authentication. This is
	necessary with old EAP methods that provide only unilateral		necessary with old EAP methods that provide only unilateral
	authentication using, e.g., one-time passwords or token cards.		authentication using, e.g., one-time passwords or token cards.
	This document specifies how EAP methods that provide mutual		This document specifies how EAP methods that provide mutual
	authentication and key agreement can be used to provide extensible		authentication and key agreement can be used to provide extensible
	responder authentication for IKEv2 based on methods other than public		responder authentication for IKEv2 based on methods other than public
	key signatures.		key signatures.
			Note to RFC Editor: this document updates
			draft-ietf-ipsecme-ikev2bis, and therefore depends on that document.
			Please add "Updates: RFCxxxx" to the title page, where "xxxx" is the
			RFC number assigned to IKEv2-bis.
	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 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 December 16, 2010.		This Internet-Draft will expire on December 27, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 45 ¶
	level of security in many circumstances, and in fact in some		level of security in many circumstances, and in fact in some
	deployments, IEEE 802.11i uses EAP without any PKI for authenticating		deployments, IEEE 802.11i uses EAP without any PKI for authenticating
	the WLAN access points.		the WLAN access points.
	This document specifies how EAP methods that offer mutual		This document specifies how EAP methods that offer mutual
	authentication and key agreement can be used to provide responder		authentication and key agreement can be used to provide responder
	authentication in IKEv2 completely based on EAP.		authentication in IKEv2 completely based on EAP.
	1.1. Terminology		1.1. Terminology
			All notation in this protocol extension is taken from [RFC4306].
			Numbered messages refer to the IKEv2 message sequence when using EAP.
			Thus:
			o Message 1 is the request message of IKE_SA_INIT.
			o Message 2 is the response message of IKE_SA_INIT.
			o Message 3 is the first request of IKE_AUTH.
			o Message 4 is the first response of IKE_AUTH.
	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].
	2. Scenarios		2. Scenarios
	In this section we describe two scenarios for extensible		In this section we describe two scenarios for extensible
	authentication within IKEv2. These scenarios are intended to be		authentication within IKEv2. These scenarios are intended to be
	illustrative examples rather than specifying how things should be		illustrative examples rather than specifying how things should be
	done.		done.
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 12 ¶
	the initiator MUST verify that payload and any associated		the initiator MUST verify that payload and any associated
	certificates, as per [RFC4306].		certificates, as per [RFC4306].
	When receiving message 4, the initiator MUST verify that the proposed		When receiving message 4, the initiator MUST verify that the proposed
	EAP method is allowed by this specification, and MUST abort the		EAP method is allowed by this specification, and MUST abort the
	protocol immediately otherwise.		protocol immediately otherwise.
	Both the initiator and responder MUST verify that the EAP method		Both the initiator and responder MUST verify that the EAP method
	actually used provided mutual authentication and established a shared		actually used provided mutual authentication and established a shared
	secret key. The AUTH payloads sent after EAP Success MUST use the		secret key. The AUTH payloads sent after EAP Success MUST use the
	EAP-generated key, and MUST NOT use SK_pi or SK_pr.		EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Sec. 2.15 of
			[I-D.ietf-ipsecme-ikev2bis]).
	An IKEv2 message exchange with this modification is shown below:		An IKEv2 message exchange with this modification is shown below:
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	[N(NAT_DETECTION_SOURCE_IP),		[N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP)] -->		N(NAT_DETECTION_DESTINATION_IP)] -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ],		<-- HDR, SAr1, KEr, Nr, [CERTREQ],
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 46 ¶
	HDR, SK { EAP(Response) } -->		HDR, SK { EAP(Response) } -->
	<-- HDR, SK { EAP(Success) }		<-- HDR, SK { EAP(Success) }
	HDR, SK { AUTH } -->		HDR, SK { AUTH } -->
	<-- HDR, SK { AUTH, SAr2, TSi, TSr,		<-- HDR, SK { AUTH, SAr2, TSi, TSr,
	[CP(CFG_REPLY] }		[CP(CFG_REPLY] }
			Note: all notation in the above protocol sequence and elsewhere in
			this specification is as defined in [RFC4306], and see in particular
			Sec. 1.2 of [RFC4306] for payload types.
	The NAT detection and Configuration payloads are shown for		The NAT detection and Configuration payloads are shown for
	informative purposes only; they do not change how EAP authentication		informative purposes only; they do not change how EAP authentication
	works.		works.
			An IKE SA that was set up with this extension can be resumed using
			the mechanism described in [RFC5723]. However session resumption
			does not change the authentication method. Therefore during the
			IKE_AUTH exchange of the resumed session, this extension MUST NOT be
			sent by the initiator.
	4. Safe EAP Methods		4. Safe EAP Methods
	EAP methods to be used with this extension MUST have the following		EAP methods to be used with this extension MUST have the following
	properties:		properties:
	1. The method provides mutual authentication of the peers.		1. The method provides mutual authentication of the peers.
	2. The method is key-generating.		2. The method is key-generating.
	3. The method is resistant to dictionary attack.		3. The method is resistant to dictionary attack.
	The following EAP methods are believed to be secure when used with		The authors believe that the following EAP methods are secure when
	the current extension. In addition, there are likely other safe		used with the current extension. The list is not inclusive, and
	methods which have not been listed here.		there are likely other safe methods which have not been listed here.
	+---------------------+--------------+------------------------------+		+---------------------+--------------+------------------------------+
	| Method Name | Allows | Reference |		| Method Name | Allows | Reference |
	| | Channel | |		| | Channel | |
	| | Binding? | |		| | Binding? | |
	+---------------------+--------------+------------------------------+		+---------------------+--------------+------------------------------+
	| EAP-SIM | No | [RFC4186] |		| EAP-SIM | No | [RFC4186] |
	| EAP-AKA | Yes | [RFC4187] |		| EAP-AKA | Yes | [RFC4187] |
	| EAP-AKA' | Yes | [RFC5448] |		| EAP-AKA' | Yes | [RFC5448] |
	| EAP-GPSK | Yes | [RFC5433] |		| EAP-GPSK | Yes | [RFC5433] |
	skipping to change at page 7, line 31 ¶		skipping to change at page 8, line 6 ¶
	| authentication | | |		| authentication | | |
	| variant) | | |		| variant) | | |
	| EAP-TLS | No | [RFC5216] |		| EAP-TLS | No | [RFC5216] |
	| EAP-FAST | No | [RFC4851] |		| EAP-FAST | No | [RFC4851] |
	| EAP-TTLS | No | [RFC5281] |		| EAP-TTLS | No | [RFC5281] |
	+---------------------+--------------+------------------------------+		+---------------------+--------------+------------------------------+
	The "Allows channel binding?" column denotes protocols where		The "Allows channel binding?" column denotes protocols where
	protected identity information may be sent between the EAP endpoints.		protected identity information may be sent between the EAP endpoints.
	This third, optional property of the method provides protection		This third, optional property of the method provides protection
	against certain types of attacks (see Section 6.2), and therefore in		against certain types of attacks (see Section 6.2 for an
	some scenarios, methods that allow for channel binding are to be		explanation), and therefore in some scenarios, methods that allow for
	preferred. It is noted that at the time of writing, even when such		channel binding are to be preferred. It is noted that at the time of
	capabilities are provided, they are not fully specified in an		writing, even when such capabilities are provided, they are not fully
	interoperable manner. In particular, no RFC specifies what		specified in an interoperable manner. In particular, no RFC
	identities should be sent under the protection of the channel binding		specifies what identities should be sent under the protection of the
	mechanism, or what policy is to be used to correlate identities at		channel binding mechanism, or what policy is to be used to correlate
	the different layers.		identities at the different layers.
	5. IANA considerations		5. IANA considerations
	This document defines a new IKEv2 Notification Payload type,		This document defines a new IKEv2 Notification Payload type,
	EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must		EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must
	be assigned a new type number from the "status types" range.		be assigned a new type number from the "status types" range.
	6. Security Considerations		6. Security Considerations
	Security considerations applicable to all EAP methods are discussed		Security considerations applicable to all EAP methods are discussed
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 37 ¶
	transport some identity or identities of the gateway (or WLAN access		transport some identity or identities of the gateway (or WLAN access
	point/NAS) inside the EAP method. Then the AAA server can check that		point/NAS) inside the EAP method. Then the AAA server can check that
	it is indeed sending the key to the gateway expected by the client.		it is indeed sending the key to the gateway expected by the client.
	A potential solution is described in		A potential solution is described in
	[I-D.arkko-eap-service-identity-auth], and see also		[I-D.arkko-eap-service-identity-auth], and see also
	[I-D.clancy-emu-aaapay].		[I-D.clancy-emu-aaapay].
	In some deployment configurations, AAA proxies may be present between		In some deployment configurations, AAA proxies may be present between
	the IKEv2 gateway and the backend AAA server. These AAA proxies MUST		the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
	be trusted for secure operation, and therefore SHOULD be avoided when		be trusted for secure operation, and therefore SHOULD be avoided when
	possible; see [RFC4072] and [RFC5247] for more discussion.		possible; see Sec. 2.3.4 of [RFC4072] Sec. 4.3.7 of [RFC3579] for
			more discussion.
	6.3. Protection of EAP payloads		6.3. Protection of EAP payloads
	Although the EAP payloads are encrypted and integrity protected with		Although the EAP payloads are encrypted and integrity protected with
	SK_e/SK_a, this does not provide any protection against active		SK_e/SK_a, this does not provide any protection against active
	attackers. Until the AUTH payload has been received and verified, a		attackers. Until the AUTH payload has been received and verified, a
	man-in-the-middle can change the KEi/KEr payloads and eavesdrop or		man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
	modify the EAP payloads.		modify the EAP payloads.
	In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted		In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted
	nor integrity protected (by the link layer), so EAP methods are		nor integrity protected (by the link layer), so EAP methods are
	typically designed to take that into account.		typically designed to take that into account.
	In particular, EAP methods that are vulnerable to dictionary attacks		In particular, EAP methods that are vulnerable to dictionary attacks
	when used in WLANs are still vulnerable (to active attackers) when		when used in WLANs are still vulnerable (to active attackers) when
	run inside IKEv2.		run inside IKEv2.
			The rules in Section 4 are designed to avoid this potential
			vulnerability.
	6.4. Identities and Authenticated Identities		6.4. Identities and Authenticated Identities
	When using this protocol, each of the peers sends two identity		When using this protocol, each of the peers sends two identity
	values:		values:
	1. An identity contained in the IKE ID payload.		1. An identity contained in the IKE ID payload.
	2. An identity transferred within the specific EAP method's		2. An identity transferred within the specific EAP method's
	messages.		messages.
	(The EAP Identity request/response pair is omitted, as usual in		(IKEv2 omits the EAP Identity request/response pair, see Sec. 3.16 of
	IKEv2.) The first identity value can be used by the recipient to		[I-D.ietf-ipsecme-ikev2bis].) The first identity value can be used
	route AAA messages and/or to select authentication and EAP types.		by the recipient to route AAA messages and/or to select
	But it is only the second identity that is directly authenticated by		authentication and EAP types. But it is only the second identity
	the EAP method. The reader is referred to Sec. 2.16 of		that is directly authenticated by the EAP method. The reader is
	[I-D.ietf-ipsecme-ikev2bis] regarding the need to base IPsec policy		referred to Sec. 2.16 of [I-D.ietf-ipsecme-ikev2bis] regarding the
	decisions on the authenticated identity. In the context of the		need to base IPsec policy decisions on the authenticated identity.
	extension described here, this guidance applies both to the		In the context of the extension described here, this guidance on
	authentication of the client by the gateway and vice versa.		IPsec policy applies both to the authentication of the client by the
			gateway and vice versa.
	6.5. User identity confidentiality		6.5. User identity confidentiality
	IKEv2 provides confidentiality for the initiator identity against		IKEv2 provides confidentiality for the initiator identity against
	passive eavesdroppers, but not against active attackers. The		passive eavesdroppers, but not against active attackers. The
	initiator announces its identity first (in message #3), before the		initiator announces its identity first (in message 3), before the
	responder has been authenticated. The usage of EAP in IKEv2 does not		responder has been authenticated. The usage of EAP in IKEv2 does not
	change this situation, since the ID payload in message #3 is used		change this situation, since the ID payload in message 3 is used
	instead of the EAP Identity Request/Response exchange. This is		instead of the EAP Identity Request/Response exchange. This is
	somewhat unfortunate since when EAP is used with public key		somewhat unfortunate since when EAP is used with public key
	authentication of the responder, it would be possible to provide		authentication of the responder, it would be possible to provide
	active user identity confidentiality for the initiator.		active user identity confidentiality for the initiator.
	IKEv2 protects the responder's identity even against active attacks.		IKEv2 protects the responder's identity even against active attacks.
	This property cannot be provided when using EAP. If public key		This property cannot be provided when using EAP. If public key
	responder authentication is used in addition to EAP, the responder		responder authentication is used in addition to EAP, the responder
	reveals its identity before authenticating the initiator. If only		reveals its identity before authenticating the initiator. If only
	EAP is used (as proposed in this document), the situation depends on		EAP is used (as proposed in this document), the situation depends on
	the EAP method used (in some EAP methods, the server reveals its		the EAP method used (in some EAP methods, the server reveals its
	identity first).		identity first).
	Hence, if active user identity confidentiality for the initiator is		Hence, if active user identity confidentiality for the responder is
	required then EAP methods that offer this functionality have to be		required then EAP methods that offer this functionality have to be
	used (see [RFC3748], Section 7.3).		used (see [RFC3748], Section 7.3).
	7. Acknowledgments		7. Acknowledgments
	This document borrows some text from [RFC3748], [RFC4306], and		This document borrows some text from [RFC3748], [RFC4306], and
	[RFC4072]. We would also like to thank Hugo Krawczyk for interesting		[RFC4072]. We would also like to thank Hugo Krawczyk for interesting
	discussions about this topic, and Dan Harkins for his comments.		discussions about this topic, Dan Harkins and David Harrington for
			their comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-ipsecme-ikev2bis]		[I-D.ietf-ipsecme-ikev2bis]
	Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol: IKEv2",		"Internet Key Exchange Protocol: IKEv2",
	draft-ietf-ipsecme-ikev2bis-11 (work in progress),		draft-ietf-ipsecme-ikev2bis-11 (work in progress),
	May 2010.		May 2010.
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 40 ¶
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	August 2005.		August 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
			[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
			Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
			January 2010.
	8.2. Informative References		8.2. Informative References
	[I-D.arkko-eap-service-identity-auth]		[I-D.arkko-eap-service-identity-auth]
	Arkko, J. and P. Eronen, "Authenticated Service		Arkko, J. and P. Eronen, "Authenticated Service
	Information for the Extensible Authentication Protocol		Information for the Extensible Authentication Protocol
	(EAP)", draft-arkko-eap-service-identity-auth-04 (work in		(EAP)", draft-arkko-eap-service-identity-auth-04 (work in
	progress), October 2005.		progress), October 2005.
	[I-D.clancy-emu-aaapay]		[I-D.clancy-emu-aaapay]
	Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP Method		Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP Method
	skipping to change at page 11, line 38 ¶		skipping to change at page 12, line 23 ¶
	progress), April 2010.		progress), April 2010.
	[I-D.ietf-pppext-eap-srp-03]		[I-D.ietf-pppext-eap-srp-03]
	Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1		Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
	Authentication Protocol", draft-ietf-pppext-eap-srp-03		Authentication Protocol", draft-ietf-pppext-eap-srp-03
	(work in progress), July 2001.		(work in progress), July 2001.
	[I-D.sheffer-emu-eap-eke]		[I-D.sheffer-emu-eap-eke]
	Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An		Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
	EAP Authentication Method Based on the EKE Protocol",		EAP Authentication Method Based on the EKE Protocol",
	draft-sheffer-emu-eap-eke-06 (work in progress),		draft-sheffer-emu-eap-eke-07 (work in progress),
	April 2010.		June 2010.
	[IEEE80211i]		[IEEE80211i]
	Institute of Electrical and Electronics Engineers, "IEEE		Institute of Electrical and Electronics Engineers, "IEEE
	Standard for Information technology - Telecommunications		Standard for Information technology - Telecommunications
	and information exchange between systems - Local and		and information exchange between systems - Local and
	metropolitan area networks - Specific requirements - Part		metropolitan area networks - Specific requirements - Part
	11: Wireless Medium Access Control (MAC) and Physical		11: Wireless Medium Access Control (MAC) and Physical
	Layer (PHY) specifications: Amendment 6: Medium Access		Layer (PHY) specifications: Amendment 6: Medium Access
	Control (MAC) Security Enhancements", IEEE		Control (MAC) Security Enhancements", IEEE
	Standard 802.11i-2004, July 2004.		Standard 802.11i-2004, July 2004.
	skipping to change at page 13, line 15 ¶		skipping to change at page 14, line 5 ¶
	[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, May 2009.		RFC 5448, May 2009.
	Appendix A. Change Log		Appendix A. Change Log
	Note to RFC Editor: please remove this section prior to publication.		Note to RFC Editor: please remove this section prior to publication.
	A.1. -04		A.1. -05
			Implemented IESG review comments from David Harrington and Adrian
			Farrel. In particular, this document updates
			[I-D.ietf-ipsecme-ikev2bis]. Added a paragraph on interaction with
			IKE session resumption.
			A.2. -04
	Anti-nit.		Anti-nit.
	A.2. -03		A.3. -03
	Implemented IETF LC comments from Dan Harkins and Tero Kivinen.		Implemented IETF LC comments from Dan Harkins and Tero Kivinen.
	A.3. -02		A.4. -02
	Implemented several WGLC comments. EAP methods are required to be		Implemented several WGLC comments. EAP methods are required to be
	resistant to dictionary attacks to be used here.		resistant to dictionary attacks to be used here.
	A.4. -01		A.5. -01
	List of proposed EAP methods is now informative, not normative.		List of proposed EAP methods is now informative, not normative.
	A.5. draft-ietf-ipsecme-mutual-auth-00		A.6. draft-ietf-ipsecme-mutual-auth-00
	Initial WG draft, based on draft-eronen-ipsec-ikev2-eap-auth-07, with		Initial WG draft, based on draft-eronen-ipsec-ikev2-eap-auth-07, with
	the following changes: if the responder does not support this		the following changes: if the responder does not support this
	mechanism, the initiator reverts to normal RFC 4306 behavior; the		mechanism, the initiator reverts to normal RFC 4306 behavior; the
	initiator must abort immediately if it doesn't like the proposed EAP		initiator must abort immediately if it doesn't like the proposed EAP
	method; allowed EAP methods are explicitly listed.		method; allowed EAP methods are explicitly listed.
	Appendix B. Alternative Approaches		Appendix B. Alternative Approaches
	In this section we list alternatives which have been considered		In this section we list alternatives which have been considered
	during the work on this document. We concluded that the solution		during the work on this document. We concluded that the solution
	presented in Section 3 seems to fit better into IKEv2.		presented in Section 3 seems to fit better into IKEv2.
	B.1. Ignore AUTH payload at the initiator		B.1. Ignore AUTH payload at the initiator
	With this approach, the initiator simply ignores the AUTH payload in		With this approach, the initiator simply ignores the AUTH payload in
	message #4 (but obviously must check the second AUTH payload later!).		message 4 (but obviously must check the second AUTH payload later!).
	The main advantage of this approach is that no protocol modifications		The main advantage of this approach is that no protocol modifications
	are required and no signature verification is required.		are required and no signature verification is required. A
			significant disadvantage is that the EAP method to be used cannot be
			selected to take this behavior into account.
	The initiator could signal to the responder (using a notification		The initiator could signal to the responder (using a notification
	payload) that it did not verify the first AUTH payload.		payload) that it did not verify the first AUTH payload.
	B.2. Unauthenticated public keys in AUTH payload (message 4)		B.2. Unauthenticated public keys in AUTH payload (message 4)
	Another solution approach suggests the use of unauthenticated public		Another solution approach suggests the use of unauthenticated public
	keys in the public key signature AUTH payload (for message 4).		keys in the public key signature AUTH payload (for message 4).
	That is, the initiator verifies the signature in the AUTH payload,		That is, the initiator verifies the signature in the AUTH payload,
	but does not verify that the public key indeed belongs to the		but does not verify that the public key indeed belongs to the
	intended party (using certificates)--since it doesn't have a PKI that		intended party (using certificates)--since it doesn't have a PKI that
	would allow this. This could be used with X.509 certificates (the		would allow this. This could be used with X.509 certificates (the
	initiator ignores all other fields of the certificate except the		initiator ignores all other fields of the certificate except the
	public key), or "Raw RSA Key" CERT payloads.		public key), or "Raw RSA Key" CERT payloads.
	This approach has the advantage that initiators that wish to perform		This approach has the advantage that initiators that wish to perform
	certificate-based responder authentication (in addition to EAP) may		certificate-based responder authentication (in addition to EAP) may
	do so, without requiring the responder to handle these cases		do so, without requiring the responder to handle these cases
	separately.		separately. A disadvantage here, again, is that the EAP method
			selection cannot take into account the incomplete validation of the
			responder's certificate.
	If using RSA, the overhead of signature verification is quite small,		If using RSA, the overhead of signature verification is quite small,
	compared to g^xy calculation.		compared to the g^xy calculation required by the Diffie-Hellman
			exchange.
	B.3. Using EAP derived session keys for IKEv2		B.3. Using EAP derived session keys for IKEv2
	It has been proposed that when using an EAP method that provides		It has been proposed that when using an EAP method that provides
	mutual authentication and key agreement, the IKEv2 Diffie-Hellman		mutual authentication and key agreement, the IKEv2 Diffie-Hellman
	exchange could also be omitted. This would mean that the session		exchange could also be omitted. This would mean that the session
	keys for IPsec SAs established later would rely only on EAP-provided		keys for IPsec SAs established later would rely only on EAP-provided
	keys.		keys.
	It seems the only benefit of this approach is saving some computation		It seems the only benefit of this approach is saving some computation
End of changes. 30 change blocks.
	43 lines changed or deleted		92 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/