< draft-eronen-ipsec-ikev2-eap-auth-00.txt		draft-eronen-ipsec-ikev2-eap-auth-01.txt >
	IPSEC P. Eronen		IPSEC P. Eronen
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: August 9, 2004 H. Tschofenig		Expires: November 4, 2004 H. Tschofenig
	Siemens		Siemens
	February 9, 2004		May 6, 2004
	Extension for EAP Authentication in IKEv2		Extension for EAP Authentication in IKEv2
	draft-eronen-ipsec-ikev2-eap-auth-00.txt		draft-eronen-ipsec-ikev2-eap-auth-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 9, 2004.		This Internet-Draft will expire on November 4, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	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 other methods than		responder authentication for IKEv2 based on other methods than public
	public-key signatures.		key signatures.
	1. Introduction		1. Introduction
	The Extensible Authentication Protocol (EAP), defined in [7], is an		The Extensible Authentication Protocol (EAP), defined in [7], is an
	authentication framework which supports multiple authentication		authentication framework which supports multiple authentication
	mechanisms. Today, EAP has been implemented at end hosts and routers		mechanisms. Today, EAP has been implemented at end hosts and routers
	that connect via switched circuits or dial-up lines using PPP [16],		that connect via switched circuits or dial-up lines using PPP [16],
	IEEE 802 wired switches [10], and IEEE 802.11 wireless access points		IEEE 802 wired switches [10], and IEEE 802.11 wireless access points
	[12].		[12].
	One of the advantages of the EAP architecture is its flexibility. EAP		One of the advantages of the EAP architecture is its flexibility. EAP
	is used to select a specific authentication mechanism, typically		is used to select a specific authentication mechanism, typically
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	expensive, and it may weaken security by creating new		expensive, and it may weaken security by creating new
	vulnerabilities. Mutually authenticating EAP methods alone can		vulnerabilities. Mutually authenticating EAP methods alone can
	provide a sufficient level of security in many circumstances, and		provide a sufficient level of security in many circumstances, and
	indeed, IEEE 802.11i uses EAP without any PKI for authenticating the		indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
	WLAN access points.		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
	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 [2].		document are to be interpreted as described in [2].
	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.
	Figure 1 shows a configuration where the EAP and the IKEv2 endpoints		Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
	are co-located. Authenticating the IKEv2 responder using both EAP and		are co-located. Authenticating the IKEv2 responder using both EAP and
	public-key signatures is redundant. Offering EAP based authentication		public key signatures is redundant. Offering EAP based authentication
	has the advantage that multiple different authentication and key		has the advantage that multiple different authentication and key
	exchange protocols are available with EAP with different security		exchange protocols are available with EAP with different security
	properties (such as strong password based protocols, protocols		properties (such as strong password based protocols, protocols
	offering user identity confidentiality and many more). As an example		offering user identity confidentiality and many more). As an example
	it is possible to use GSS-API support within EAP [5] to support		it is possible to use GSS-API support within EAP [5] to support
	Kerberos based authentication which effectively replaces the need for		Kerberos based authentication which effectively replaces the need for
	KINK [17].		KINK [17].
	+------+-----+ +------------+		+------+-----+ +------------+
	O | IKEv2 | | IKEv2 |		O | IKEv2 | | IKEv2 |
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	| +-------------------------------+		| +-------------------------------+
	v		v
	+------+-----+		+------+-----+
	o | IKEv2 |		o | IKEv2 |
	/|\ | Initiator |		/|\ | Initiator |
	/ \ | VPN client |		/ \ | VPN client |
	User +------------+		User +------------+
	Figure 2: Corporate Network Access		Figure 2: Corporate Network Access
	3. Solution Approaches		3. Solution
	IKEv2 specifies that when the EAP method establishes a shared secret		IKEv2 specifies that when the EAP method establishes a shared secret
	key, that key is used by both the initiator and responder to generate		key, that key is used by both the initiator and responder to generate
	an AUTH payload (thus authenticating the IKEv2 SA set up by messages		an AUTH payload (thus authenticating the IKEv2 SA set up by messages
	1 and 2).		1 and 2).
	When used together with public-key responder authentication, the		When used together with public key responder authentication, the
	responder is in effect authenticated using two different methods: the		responder is in effect authenticated using two different methods: the
	public-key signature AUTH payload in message #4, and the EAP-based		public key signature AUTH payload in message 4, and the EAP-based
	AUTH payload later.		AUTH payload later.
	In this section we explore some possibilities for relaxing this. The		If the initiator does not wish to use public key based responder
	first three approaches require only small modifications to IKEv2.		authentication, it includes an EAP_ONLY_AUTHENTICATION notification
	One approach is more aggressive and only shown for completeness.		payload (type TBD-BY-IANA) in message 3. There is no additional data
			associated with this notification.
	It is TBD which of this approaches should be used.
	3.1 Ignore AUTH payload at the initiator
	In the first approach, the initiator simply ignores the AUTH payload
	in message #4 (but obviously must check the second AUTH payload
	later!). The main advantage of this approach is that no protocol
	modifications are required and no signature verification is required.
	It is TBD whether the initiator should signal the responder (using a
	NOTIFY payload) that it did not in fact verify the first AUTH
	payload.
	3.2 Unauthenticated PKs in AUTH payload (message 4)
	The first solution approach suggests the use of unauthenticated
	public keys in the public key signature AUTH payload (for message 4).
	That is, the initiator verifies the signature in the AUTH payload,
	but does not verify that the public key indeed belongs to the
	intended party (using certificates)--since it doesn't have a PKI that
	would allow this. This could be used with X.509 certificates (the
	initiator ignores all other fields of the certificate except the
	public key), or "Raw RSA Key" CERT payloads.
	This approach has the advantage that initiators that wish to perform
	certificate-based responder authentication (in addition to EAP) may
	do so, without requiring the responder to handle these cases
	separately.
	If using RSA, the overhead of signature verification is quite small
	(compared to g^xy calculation).
	3.3 Omit AUTH payload (message 4)		If the responder supports this notification, it omits the public key
			based AUTH payload and CERT payloads from message 4.
	With this solution approach the AUTH payload from message 4 is		If the responder does not support the EAP_ONLY_AUTHENTICATION
	completely omitted.		notification, it ignores the notification payload, and includes the
			AUTH payload in message 4. In this case the initiator can, based on
			its local policy, choose to either ignore the AUTH payload, or verify
			it and any associated certificates as usual.
	If the public key is not authenticated, it seems the AUTH payload in		Both the initiator and responder MUST verify that the EAP method
	message 4 serves no useful purpose, since other AUTH payloads, based		actually used provided mutual authentication and established a shared
	on the EAP-generated key, are sent later in both directions.		secret key. The AUTH payloads sent after EAP Success MUST use the
			EAP-generated key, and MUST NOT use SK_pi or SK_pr.
	With this approach, the responder needs to know when it can omit the		An IKEv2 message exchange with this modification is shown below:
	payload (EAP-only authentication is sufficient) and when public-key
	authentication is also needed. This could be determined by the
	responder identity chosen, or alternatively, the initiator could use
	a NOTIFY payload (e.g., EAP_ONLY_AUTHENTICATION_SUPPORTED) to signal
	the responder that it can leave out the AUTH payload if it wishes. If
	the initiator includes this payload in message #3 then the responder
	would know that the initiator does not require public-key
	authentication.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni -->		HDR, SAi1, KEi, Ni -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ]		<-- HDR, SAr1, KEr, Nr, [CERTREQ]
	HDR, SK { IDi, [IDr,], EAP_ONLY_AUTHENTICATION_SUPPORTED,		HDR, SK { IDi, [IDr,] EAP_ONLY_AUTHENTICATION,
	SAi2, TSi, TSr} -->		SAi2, TSi, TSr} -->
	<-- HDR, SK { IDr, EAP(Request) }		<-- HDR, SK { IDr, EAP(Request) }
	HDR, SK { EAP(Response) } -->		HDR, SK { EAP(Response) } -->
	<-- HDR, SK { EAP(Request) }		<-- HDR, SK { EAP(Request) }
	HDR, SK { EAP(Response) } -->		HDR, SK { EAP(Response) } -->
	<-- HDR, SK { EAP(Success), AUTH }		<-- HDR, SK { EAP(Success) }
	HDR, SK { AUTH } -->		HDR, SK { AUTH } -->
	<-- HDR, SK { SAr2, TSi, TSr }		<-- HDR, SK { AUTH, SAr2, TSi, TSr }
	Note that there is currently discussion about which messages should
	contain the AUTH payloads. The current IKEv2 specification says that
	they are included "..in the first message each end sends after having
	sufficient information to compute the key", but this might need some
	clarification. Therefore, the sequence shown above may need revision
	after this is settled.
	3.4 Use EAP derived session keys for IKEv2
	It has been proposed that when using an EAP methods that provides
	mutual authentication and key agreement, the IKEv2 Diffie-Hellman
	exchange could also be omitted. This would mean that the sessions
	keys for IPsec SAs established later would rely only on EAP-provided
	keys.
	It seems the only benefit of this approach is saving some computation
	time (g^xy calculation). However, since this approaches requires
	designing a completely new protocol (which would not resemble IKEv2
	anymore) we do not believe that it should be considered.
	Nevertheless, we include it for completeness.
	3.5 Discussion
	Currently it seems that options 1-3 have approximately the same
	security properties. The last option has somewhat weaker security,
	since it does not provide PFS against e.g. compromise of an AAA proxy
	(however, we have not analyzed option 4 in detail).
	It seems that the approach where (1) the initiator uses a NOTIFY		4. IANA considerations
	payload to signal the responder that it does not require the AUTH
	payload, and (2) if the responder includes it anyway, the initiator
	ignores it, might be a good choice. However, more discussion is
	required before deciding.
	4. IANA considerations		This document defines a new IKEv2 Notification Payload type,
			EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must be
			assigned a new type number from the "status types" range.
	A new NOTIFY message type might be required; details are TBD.		This document does not define any new namespaces to be managed by
			IANA.
	5. Security Considerations		5. Security Considerations
	Security considerations applicable to all EAP methods are discussed		Security considerations applicable to all EAP methods are discussed
	in [1]. The EAP Key Management Framework [6] deals with issues that		in [1]. The EAP Key Management Framework [6] deals with issues that
	arise when EAP is used as a part of a larger system.		arise when EAP is used as a part of a larger system.
	We believe that the security issues associated with all of the		5.1 Authentication of IKEv2 SA
	alternatives 1-3 in Section 3 are approximately the same (TBD: will
	be clarified in future versions).
	5.1 Authentication of IKEv2 SA
	It is important to note that the IKEv2 SA is not authenticated by		It is important to note that the IKEv2 SA is not authenticated by
	just running an EAP conversation: the crucial step is the AUTH		just running an EAP conversation: the crucial step is the AUTH
	payload based on the EAP-generated key. Thus, EAP methods that do not		payload based on the EAP-generated key. Thus, EAP methods that do not
	provide mutual authentication or establish a shared secret key MUST		provide mutual authentication or establish a shared secret key MUST
	NOT be used with the modifications presented in this document.		NOT be used with the modifications presented in this document.
	5.2 Authentication with separated IKEv2 responder/EAP server		5.2 Authentication with separated IKEv2 responder/EAP server
	As described in Section 2, the EAP conversation can terminate either		As described in Section 2, the EAP conversation can terminate either
	at the IKEv2 responder or at a backend AAA server.		at the IKEv2 responder or at a backend AAA server.
	If the EAP method terminates at the IKEv2 responder then no key		If the EAP method terminates at the IKEv2 responder then no key
	transport via the AAA infrastructure is required. Pre-shared secret		transport via the AAA infrastructure is required. Pre-shared secret
	and public key based authentication offered by IKEv2 is then replaced		and public key based authentication offered by IKEv2 is then replaced
	by a wider range of authentication and key exchange methods.		by a wider range of authentication and key exchange methods.
	However, typically EAP will be used with a backend AAA server. See		However, typically EAP will be used with a backend AAA server. See
	skipping to change at page 8, line 38 ¶		skipping to change at page 7, line 17 ¶
	provide what is called "connection binding" or "channel binding"		provide what is called "connection binding" or "channel binding"
	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.
	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 [7] and [6] for more discussion.		possible; see [7] and [6] for more discussion.
	5.3 Protection of EAP payloads		5.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 WLANs, the EAP payloads are neither encrypted nor		In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
	integrity protected (by the link layer), so EAP methods are typically		integrity protected (by the link layer), so EAP methods are typically
	designed to take that into account.		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.
	5.4 User identity confidentiality		5.4 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 identity even against active attacks.		IKEv2 protects the responder 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 EAP		reveals its identity before authenticating the initiator. If only EAP
	is used (as proposed in this document), the situation depends on the		is used (as proposed in this document), the situation depends on the
	EAP method used (in some EAP methods, the server reveals its identity		EAP method used (in some EAP methods, the server reveals its identity
	first).		first).
	Hence, if active user identity confidentiality for the initiator is		Hence, if active user identity confidentiality for the initiator 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 [1], Section 7.3).		used (see [1], Section 7.3).
	6. Acknowledgments		6. Acknowledgments
	This document borrows some text from [1], [3], and [7].		This document borrows some text from [1], [3], and [7]. We would also
			like to thank Hugo Krawczyk for interesting discussions about this
			topic.
	Normative References		7. References
			7.1 Normative References
	[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H.		[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003.		draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-12 (work in progress), January 2004.		draft-ietf-ipsec-ikev2-13 (work in progress), March 2004.
	Informative References		7.2 Informative References
	[4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
	In User Service) Support For Extensible Authentication Protocol		In User Service) Support For Extensible Authentication Protocol
	(EAP)", RFC 3579, September 2003.		(EAP)", RFC 3579, September 2003.
	[5] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",		[5] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
	draft-aboba-pppext-eapgss-12 (work in progress), April 2002.		draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
	[6] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key		[6] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP Key
	Management Framework", draft-ietf-eap-keying-01 (work in		Management Framework", draft-ietf-eap-keying-01 (work in
	progress), October 2003.		progress), October 2003.
	[7] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible		[7] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application",		Authentication Protocol (EAP) Application",
	draft-ietf-aaa-eap-03 (work in progress), October 2003.		draft-ietf-aaa-eap-05 (work in progress), April 2004.
	[8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin,		[8] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin,
	"Protocol for Carrying Authentication for Network Access		"Protocol for Carrying Authentication for Network Access
	(PANA)", draft-ietf-pana-pana-02 (work in progress), October		(PANA)", draft-ietf-pana-pana-03 (work in progress), February
	2003.		2004.
	[9] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication		[9] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
	Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03 (work in		Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-04 (work in
	progress), August 2003.		progress), April 2004.
	[10] Institute of Electrical and Electronics Engineers, "Local and		[10] Institute of Electrical and Electronics Engineers, "Local and
	Metropolitan Area Networks: Port-Based Network Access Control",		Metropolitan Area Networks: Port-Based Network Access Control",
	IEEE Standard 802.1X-2001, 2001.		IEEE Standard 802.1X-2001, 2001.
	[11] Institute of Electrical and Electronics Engineers, "Information		[11] Institute of Electrical and Electronics Engineers, "Information
	technology - Telecommunications and information exchange		technology - Telecommunications and information exchange
	between systems - Local and metropolitan area networks -		between systems - Local and metropolitan area networks -
	Specific Requirements Part 11: Wireless LAN Medium Access		Specific Requirements Part 11: Wireless LAN Medium Access
	Control (MAC) and Physical Layer (PHY) Specifications", IEEE		Control (MAC) and Physical Layer (PHY) Specifications", IEEE
	Standard 802.11-1999, 1999.		Standard 802.11-1999, 1999.
	[12] Institute of Electrical and Electronics Engineers, "Draft		[12] Institute of Electrical and Electronics Engineers, "IEEE
	Amendment to STANDARD FOR Telecommunications and Information		Standard for Information technology - Telecommunications and
	Exchange between Systems - LAN/MAN Specific Requirements - Part		information exchange between systems - Local and metropolitan
	11: Wireless Medium Access Control (MAC) and physical layer		area networks - Specific requirements - Part 11: Wireless
	(PHY) specifications: Medium Access Control (MAC) Security		Medium Access Control (MAC) and Physical Layer (PHY)
	Enhancements", IEEE Draft 802.11i/D7.0, 2003.		specifications: Amendment 6: Medium Access Control (MAC)
			Security Enhancements", IEEE Draft 802.11i/D10.0, April 2004.
	[13] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected		[13] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected
	EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07		EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07
	(work in progress), October 2003.		(work in progress), October 2003.
	[14] Puthenkulam, J., "The Compound Authentication Binding Problem",		[14] Puthenkulam, J., "The Compound Authentication Binding Problem",
	draft-puthenkulam-eap-binding-04 (work in progress), October		draft-puthenkulam-eap-binding-04 (work in progress), October
	2003.		2003.
	[15] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		[15] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
	skipping to change at page 11, line 11 ¶		skipping to change at page 9, line 45 ¶
	2000.		2000.
	[16] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC		[16] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
	1661, July 1994.		1661, July 1994.
	[17] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of		[17] Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of
	Keys (KINK)", draft-ietf-kink-kink-05 (work in progress),		Keys (KINK)", draft-ietf-kink-kink-05 (work in progress),
	January 2003.		January 2003.
	[18] Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2 Method		[18] Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2 Method
	(EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work in progress),		(EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in progress),
	October 2003.		February 2004.
	Authors' Addresses		Authors' Addresses
	Pasi Eronen		Pasi Eronen
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	EMail: pasi.eronen@nokia.com		EMail: pasi.eronen@nokia.com
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		EMail: Hannes.Tschofenig@siemens.com
			Appendix A. Alternative Approaches
			In this section we list alternatives which have been considered
			during the work on this document. Finally, the solution presented in
			Section 3 seems to fit better into IKEv2.
			A.1 Ignore AUTH payload at the initiator
			With this approach, the initiator simply ignores the AUTH payload in
			message #4 (but obviously must check the second AUTH payload later!).
			The main advantage of this approach is that no protocol modifications
			are required and no signature verification is required.
			The initiator could signal the responder (using a NOTIFY payload)
			that it did not verify the first AUTH payload.
			A.2 Unauthenticated PKs in AUTH payload (message 4)
			The first solution approach suggests the use of unauthenticated
			public keys in the public key signature AUTH payload (for message 4).
			That is, the initiator verifies the signature in the AUTH payload,
			but does not verify that the public key indeed belongs to the
			intended party (using certificates)--since it doesn't have a PKI that
			would allow this. This could be used with X.509 certificates (the
			initiator ignores all other fields of the certificate except the
			public key), or "Raw RSA Key" CERT payloads.
			This approach has the advantage that initiators that wish to perform
			certificate-based responder authentication (in addition to EAP) may
			do so, without requiring the responder to handle these cases
			separately.
			If using RSA, the overhead of signature verification is quite small
			(compared to g^xy calculation).
			A.3 Use EAP derived session keys for IKEv2
			It has been proposed that when using an EAP methods that provides
			mutual authentication and key agreement, the IKEv2 Diffie-Hellman
			exchange could also be omitted. This would mean that the sessions
			keys for IPsec SAs established later would rely only on EAP-provided
			keys.
			It seems the only benefit of this approach is saving some computation
			time (g^xy calculation). This approach requires designing a
			completely new protocol (which would not resemble IKEv2 anymore) we
			do not believe that it should be considered. Nevertheless, we include
			it for completeness.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 49 change blocks.
	170 lines changed or deleted		149 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/