< draft-ietf-ipsecme-ikev2-null-auth-00.txt		draft-ietf-ipsecme-ikev2-null-auth-01.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track September 15, 2014		Intended status: Standards Track October 22, 2014
	Expires: March 19, 2015		Expires: April 25, 2015
	The NULL Authentication Method in IKEv2 Protocol		The NULL Authentication Method in IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-null-auth-00		draft-ietf-ipsecme-ikev2-null-auth-01
	Abstract		Abstract
	This document introduces the NULL Authentication Method for the IKEv2		This document introduces the NULL authentication method for the IKEv2
	Protocol. This method provides a way to omit peer authentication in		Protocol. This method provides a way to omit peer authentication in
	the IKEv2. It may be used to preserve anonymity of or in the		the IKEv2. It may be used to preserve anonymity of or in the
	situations, where no trust relationship exists between the parties.		situations, where no trust relationship exists between the parties.
	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 March 19, 2015.		This Internet-Draft will expire on April 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions Used in This Document . . . . . . . . . . . . . 3		1.1. Conventions Used in This Document . . . . . . . . . . . . 3
	2. Using the NULL Authentication Method . . . . . . . . . . . . . 4		2. Using the NULL Authentication Method . . . . . . . . . . . . . 4
	2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4		2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4
	2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4		2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4
	3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 4
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Normative References . . . . . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Internet Key Exchange Protocol version 2 (IKEv2), specified in		The Internet Key Exchange Protocol version 2 (IKEv2), specified in
	[IKEv2], provides a way for two parties to perform authenticated key		[IKEv2], provides a way for two parties to perform authenticated key
	exchange. Mutual authentication is mandatory in the IKEv2, so that		exchange. Mutual authentication is mandatory in the IKEv2, so that
	each party must be authenticated by the other. However the		each party must be authenticated by the other. However the
	authentication methods, used by the peers, need not be the same.		authentication methods, used by the peers, need not be the same.
	In some situations mutual authentication is undesirable, superfluous		In some situations mutual authentication is undesirable, superfluous
	or impossible. For example:		or impossible. For example:
	o User wants to get anonymous access to some server. In this		o User wants to get anonymous access to some server. In this
	situation he/she should be able to authenticate the server, but to		situation he/she should be able to authenticate the server, but to
	leave out his/her own authentication to preserve anonymity. In		leave out his/her own authentication to preserve anonymity. In
	this case one-way authentication of the responder is desirable.		this case one-way authentication of the responder is desirable.
	o Sensor, that sleeps most of the time, but periodically wakes up,		o Sensor, that sleeps most of the time, but periodically wakes up,
	makes some measurment (e.g. temperature) and sends the results to		makes some measurment (e.g. temperature) and sends the results to
	some server. The senser must be authenticated by the server to		some server. The sensor must be authenticated by the server to
	ensure authenticity of the measurment, but the server need not be		ensure authenticity of the measurment, but the server need not be
	authenticated by the senser. In this case one-way authentication		authenticated by the sensor. In this case one-way authentication
	of the initiator is sufficient.		of the initiator is sufficient.
	o Two peers without any trust relationship want to get some level of		o Two peers without any trust relationship want to get some level of
	security in their communications. Without trust relationship they		security in their communications. Without trust relationship they
	cannot prevent active Man-in-the-Middle attacks, but it is still		cannot prevent active Man-in-the-Middle attacks, but it is still
	possible to prevent passive eavesdropping with opportunistic		possible to prevent passive eavesdropping with opportunistic
	encryption. In this case they can use unauthenticated key		encryption. In this case they can use unauthenticated key
	exchange.		exchange.
	To meet these needs the document introduces the NULL Authentication		To meet these needs the document introduces the NULL authentication
	Method, which is a "dummy" method, that provides no authentication.		method, which is a "dummy" method, that provides no authentication.
	This allows peer to explicitly indicate to the other side that it is		This allows peer to explicitly indicate to the other side that it is
	unwilling or unable to certify its identity.		unwilling or unable to certify its identity.
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	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. Using the NULL Authentication Method		2. Using the NULL Authentication Method
	In IKEv2 each peer independently selects the method to authenticate		In IKEv2 each peer independently selects the method to authenticate
	itself to the other side. It means that any of the peers may choose		itself to the other side. It means that any of the peers may choose
	to omit its authentication by using the NULL Authentication Method.		to omit its authentication by using the NULL authentication method.
	If it is not acceptable for the other peer, it MUST return		If it is not acceptable for the other peer, it MUST return
	AUTHENTICATION_FAILED Notification. Note, that when the Initiator		AUTHENTICATION_FAILED notification. Note, that when the initiator
	uses EAP, the Responder MUST NOT use the NULL Authentication Method		uses EAP, the responder MUST NOT use the NULL authentication method
	(in conformance with the section 2.16 of [IKEv2]).		(in conformance with the section 2.16 of [IKEv2]).
	The NULL Authentication Method affects how the Authentication and the		The NULL authentication method affects how the Authentication and the
	Identity payloads are formed in the IKE_AUTH Exchange.		Identity payloads are formed in the IKE_AUTH exchange.
	2.1. Authentication Payload		2.1. Authentication Payload
	Despite the fact that the NULL Authentication Method provides no		Despite the fact that the NULL authentication method provides no
	authentication, the AUTH Payload must still be present in the		authentication, the AUTH payload must still be present in the
	IKE_AUTH Exchange messages and must be properly formed, as it		IKE_AUTH exchange messages and must be properly formed, as it
	cryptographically links the IKE_SA_INIT Exchange messages with the		cryptographically links the IKE_SA_INIT exchange messages with the
	other messages sent over the IKE SA.		other messages sent over this IKE SA.
	With the NULL Authentication Method the content of the AUTH Payload		With the NULL authentication method the content of the AUTH payload
	MUST be computed using the syntax for pre-shared secret		MUST be computed using the syntax for pre-shared secret
	authentication, described in Section 2.15 of [IKEv2]. The values		authentication, described in Section 2.15 of [IKEv2]. The values
	SK_pi and SK_pr MUST be used as shared secrets for the content of the		SK_pi and SK_pr MUST be used as shared secrets for the content of the
	AUTH Payloads generated by Initiator and Responder respectively.		AUTH payloads generated by the initiator and the responder
	Note, that this is exactly how the content of the two last AUTH		respectively. Note, that this is exactly how the content of the two
	Payloads is calculated for non-key generating EAP Method (see Section		last AUTH payloads is calculated for non-key generating EAP method
	2.16 of [IKEv2] for details). The value for the the NULL		(see Section 2.16 of [IKEv2] for details). The value for the the
	Authentication Method is <TBA by IANA>.		NULL authentication method is <TBA by IANA>.
	2.2. Identity Payload		2.2. Identity Payload
	The NULL Authentication Method provides no authentication of the		The NULL authentication method provides no authentication of the
	party using it. For that reason the Identity Payload content cannot		party using it. For that reason the Identity payload content cannot
	be verified by the peer and MUST be ignored by the IKE.		be verified by the peer and MUST be ignored by the IKE.
	This specification defines new ID Type - ID_NULL, which is intended		This specification defines new ID Type - ID_NULL, which is intended
	to be used with the NULL Authentication Method to explicitely		to be used with the NULL authentication method to explicitely
	indicate anonymity of the peer. This ID Type SHOULD NOT be used with		indicate anonymity of the peer. This ID Type MUST NOT be used with
	other authentication methods. The Identification Data in Identity		authentication methods, that provide real authentication. The
	Payload for the ID_NULL type MUST be absent and the ID Type is set to		Identification Data in Identity payload for the ID_NULL type MUST be
	<TBA by IANA>.		absent and the ID Type is set to <TBA by IANA>.
			2.3. INITIAL_CONTACT Notification
			The identity of the peer which uses the NULL authentication method
			cannot be used to distinguish betweed IKE SAs created by different
			peers, because the peers may use the same identity (for example all
			endpoints which use identity of type ID_NULL). For that reason the
			INITIAL_CONTACT notification MUST be ignored if it is present by the
			party using the NULL authentication method. To find out stale IKE
			SAs in this situation, implementations should perform Liveness Check
			on all IKE SAs with the same peer idenity as the newly created IKE
			SA.
	3. Security Considerations		3. Security Considerations
	IKEv2 protocol provides mutual authentication of the peers. If one		IKEv2 protocol provides mutual authentication of the peers. If one
	peer uses the NULL Authentication Method, then this peer cannot be		peer uses the NULL authentication method, then this peer cannot be
	authenticated by the other side, and it makes authentication in IKEv2		authenticated by the other side, and it makes authentication in IKEv2
	to be one-way. If both peers use the NULL Authentication method, key		to be one-way. If both peers use the NULL Authentication method, key
	exchange becomes unauthenticated, that makes it subject to the Man-		exchange becomes unauthenticated, that makes it susceptible to active
	in-the-Middle attack.		attacks. For that reason completely unauthenticated IKE SA must be
			used only if the alternative is to send plaintext.
	The identity of the peer using the NULL Authenticated Method cannot		The identity of the peer using the the NULL authenticated method
	be verified by the other side and, therefore, MUST NOT be used		cannot be verified by the other side and, therefore, MUST NOT be used
	neither for authorization purposes, nor for policy decisions. All		neither for authorization purposes, nor for policy decisions. All
	peers who use the NULL Authenticated Method should be considered by		peers who use the NULL Authenticated Method should be considered by
	the other party as "guests" and get the least possible privileges.		the other party as "guests" and get the least possible privileges.
			Implementations are advised to use the ID_NULL Identity Type with the
			NULL authenticated method.
	If endpoint receives a request to create an unauthenticated IKE SA		If endpoint receives a request to create an unauthenticated IKE SA
	from the IP address, which is configured on the endpoint to be		from the IP address, which is configured on the endpoint to be
	authenticated, the request SHOULD be rejected.		authenticated, the request SHOULD be rejected.
	If the peer uses the NULL Authenticated Method, then the content of		If the peer uses the NULL authenticated method, then the content of
	its Traffic Selector Payloads must be treated with care. In		its Traffic Selector payloads must be treated with care. In
	particular, implementations are advised not to trust blindly that the		particular, implementations are advised not to trust blindly that the
	public IP addresses the peer put into TS Payload are really belong to		public IP addresses the peer put into TS payload are really belong to
	it. It is RECOMMENDED for security gateways to always assign		it. It is RECOMMENDED for security gateways to always assign
	internal IP addresses to unauthenticated clients as described in		internal IP addresses to unauthenticated clients as described in
	Section 2.19 of [IKEv2].		Section 2.19 of [IKEv2].
	4. Acknowledgments		4. Acknowledgments
	The author would like to thank Paul Wouters, Yaron Sheffer and Tero		The author would like to thank Paul Wouters, Yaron Sheffer and Tero
	Kivinen for their reviews and valuable comments.		Kivinen for their reviews and valuable comments.
	5. IANA Considerations		5. IANA Considerations
End of changes. 22 change blocks.
	50 lines changed or deleted		66 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/