< draft-ietf-ipsecme-ikev2-null-auth-04.txt		draft-ietf-ipsecme-ikev2-null-auth-05.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track P. Wouters		Intended status: Standards Track P. Wouters
	Expires: August 24, 2015 Red Hat		Expires: September 27, 2015 Red Hat
	February 20, 2015		March 26, 2015
	The NULL Authentication Method in IKEv2 Protocol		The NULL Authentication Method in IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-null-auth-04		draft-ietf-ipsecme-ikev2-null-auth-05
	Abstract		Abstract
	This document specifies the NULL Authentication method and the		This document specifies the NULL Authentication method and the
	ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This		ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This
	allows two IKE peers to establish single-side authenticated or mutual		allows two IKE peers to establish single-side authenticated or mutual
	unauthenticated IKE sessions for those use cases where a peer is		unauthenticated IKE sessions for those use cases where a peer is
	unwilling or unable to authenticate or identify itself. This ensures		unwilling or unable to authenticate or identify itself. This ensures
	IKEv2 can be used for Opportunistic Security (also known as		IKEv2 can be used for Opportunistic Security (also known as
	Opportunistic Encryption) to defend against Pervasive Monitoring		Opportunistic Encryption) to defend against Pervasive Monitoring
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 August 24, 2015.		This Internet-Draft will expire on September 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	The IKEv2 Authentication Method value for NULL Authentication is 13.		The IKEv2 Authentication Method value for NULL Authentication is 13.
	2.2. Identification Payload		2.2. Identification Payload
	When a remote peer is not authenticated, any ID presented in the		When a remote peer is not authenticated, any ID presented in the
	Identification Data field of the ID payload cannot be validated. To		Identification Data field of the ID payload cannot be validated. To
	avoid the need of sending a bogus ID Type with placeholder data, this		avoid the need of sending a bogus ID Type with placeholder data, this
	specification defines a new ID Type, ID_NULL. The Identification		specification defines a new ID Type, ID_NULL. The Identification
	Data field of the ID payload for this ID Type MUST be empty.		Data field of the ID payload for this ID Type MUST be empty.
	If NULL Authentication is in use and an anonymity is a concern then		If NULL Authentication is in use and anonymity is a concern then
	ID_NULL SHOULD be used in the Identification payload. Some examples		ID_NULL SHOULD be used in the Identification payload. Some examples
	of acceptable cases to use a non-null identity type and value with		of cases where a non-null identity type and value with NULL
	NULL Authentication are logging, troubleshooting or in scenarios		Authentication can be used are logging, troubleshooting and in
	where authentication takes place out of band after the IKE SA is		scenarios where authentication takes place out of band after the IKE
	created (like in [AUTOVPN]). The content of the Identification		SA is created (like in [AUTOVPN]). The content of the Identification
	payload MUST NOT be used for any trust and policy checking in		payload MUST NOT be used for any trust and policy checking in
	IKE_AUTH exchange when NULL Authentication is employed (see Section		IKE_AUTH exchange when NULL Authentication is employed (see Section
	2.4 for details).		2.4 for details).
	ID_NULL is primarily intended to be used with NULL Authentication but		ID_NULL is primarily intended to be used with NULL Authentication but
	could be used in other situations where the content of the		could be used in other situations where the content of the
	Identification Payload is not used. For example, ID_NULL could be		Identification Payload is not used. For example, ID_NULL could be
	used when authentication is performed via raw public keys and the		used when authentication is performed via raw public keys and the
	identities are the keys themselves. These alternative uses of		identities are the keys themselves. These alternative uses of
	ID_NULL should be described in their own respective documents.		ID_NULL should be described in their own respective documents.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	The standard IKE Liveness Check procedure, described in Section 2.4		The standard IKE Liveness Check procedure, described in Section 2.4
	of [RFC7296], can be used to detect stale IKE SAs created by peers		of [RFC7296], can be used to detect stale IKE SAs created by peers
	using NULL Authentication. Inactive unauthenticated IKE SAs should		using NULL Authentication. Inactive unauthenticated IKE SAs should
	be checked periodically. Additionally, the event of creating a new		be checked periodically. Additionally, the event of creating a new
	unauthenticated IKE SA can be used to trigger an out-of-order check		unauthenticated IKE SA can be used to trigger an out-of-order check
	on existing unauthenticated IKE SAs, possibly limited to identical or		on existing unauthenticated IKE SAs, possibly limited to identical or
	close-by IP addresses or to identical identities of the just created		close-by IP addresses or to identical identities of the just created
	IKE SA.		IKE SA.
	Implementations should weight the resource consumption of sending		Implementations should weigh the resource consumption of sending
	Liveness Checks against the memory usage of possible orphaned IKE		Liveness Checks against the memory usage of possible orphaned IKE
	SAs. Implementations may choose to handle situations with thousands		SAs. Implementations may choose to handle situations with thousands
	of unauthenticated IKE SAs differently from situations with very few		of unauthenticated IKE SAs differently from situations with very few
	such SAs.		such SAs.
	2.4. Interaction with Peer Authorization Database (PAD)		2.4. Interaction with Peer Authorization Database (PAD)
	Section 4.4.3 of [RFC4301] defines the Peer Authorization Database		Section 4.4.3 of [RFC4301] defines the Peer Authorization Database
	(PAD), which provides the link between Security Policy Database (SPD)		(PAD), which provides the link between Security Policy Database (SPD)
	and the IKEv2. The PAD contains an ordered list of records, with		and the IKEv2. The PAD contains an ordered list of records, with
	peers' identities along with corresponding authentication data and		peers' identities along with corresponding authentication data and
	Child SA authorization data. When the IKE SA is being established		Child SA authorization data. When the IKE SA is being established
	the PAD is consulted to determine how the peer should be		the PAD is consulted to determine how the peer should be
	authenticated and what Child SAs it is authorized to create.		authenticated and what Child SAs it is authorized to create.
	When using NULL Authentication, the peer identity is not		When using NULL Authentication, the peer identity is not
	authenticated and cannot be trusted. If ID_NULL is used with NULL		authenticated and cannot be trusted. If ID_NULL is used with NULL
	Authentication, there is no ID at all. The processing of PAD		Authentication, there is no ID at all. The processing of PAD
	described in Section 4.4.3.4 of [RFC4301] must be updated.		described in Section 4.4.3.4 of [RFC4301] must be updated.
	The NULL authentication needs to be added as one of supported		NULL authentication needs to be added as one of supported
	authentication methods. This method does not have any authentication		authentication methods. This method does not have any authentication
	data. To add support for ID_NULL, it needs to be included into the		data. To add support for ID_NULL, it needs to be included into the
	list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The		list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The
	matching rule for ID_NULL is just whether this type is used, i.e. no		matching rule for ID_NULL consists only of whether this type is used,
	actual ID matching is done, as ID_NULL contains no identity data.		i.e. no actual ID matching is done, as ID_NULL contains no identity
			data.
	Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched		Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched
	against the SPD entries. When using the NULL authentication method		against the SPD entries. When using the NULL authentication method
	those matching rules MUST include matching of a new flag in the SPD		those matching rules MUST include matching of a new flag in the SPD
	entry specifying whether unauthenticated users are allowed to use		entry specifying whether unauthenticated users are allowed to use
	that entry. I.e. each SPD entry needs to be augmented to have flag		that entry. I.e. each SPD entry needs to be augmented to have a flag
	specifying whether it can be used with NULL authentication or not,		specifying whether it can be used with NULL authentication or not,
	and only those rules explictly having that flag turned on can be used		and only those rules that explictly have that flag turned on can be
	with unauthenticated connections.		used with unauthenticated connections.
	2.5. Traffic Selectors		2.5. Traffic Selectors
	Traffic Selectors and narrowing allow two IKE peers to mutually agree		Traffic Selectors and narrowing allow two IKE peers to mutually agree
	on a traffic range for an IPsec SA. An unauthenticated peer must not		on a traffic range for an IPsec SA. An unauthenticated peer must not
	be allowed to use this mechanism to steal traffic that an IKE peer		be allowed to use this mechanism to steal traffic that an IKE peer
	intended to be for another host. This is especially problematic when		intended to be for another host. This is especially problematic when
	supporting anonymous IKE peers behind NAT, as such IKE peers build an		supporting anonymous IKE peers behind NAT, as such IKE peers build an
	IPsec SA using their pre-NAT IP address that are different from the		IPsec SA using their pre-NAT IP address that are different from the
	source IP of their IKE packets. A rogue IKE peer could use malicious		source IP of their IKE packets. A rogue IKE peer could use malicious
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 43 ¶
	intended to hand out. Implementations SHOULD restrict and isolate		intended to hand out. Implementations SHOULD restrict and isolate
	all anonymous IKE peers from each other and itself and only allow it		all anonymous IKE peers from each other and itself and only allow it
	access to itself and possibly its intended network ranges.		access to itself and possibly its intended network ranges.
	One method to achieve this is to always assign internal IP addresses		One method to achieve this is to always assign internal IP addresses
	to unauthenticated IKE clients, as described in Section 2.19 of		to unauthenticated IKE clients, as described in Section 2.19 of
	[RFC7296]. Implementations may also use other techniques, such as		[RFC7296]. Implementations may also use other techniques, such as
	internal NAT and connection tracking.		internal NAT and connection tracking.
	Implementations MAY force unauthenticated IKE peers to single host-		Implementations MAY force unauthenticated IKE peers to single host-
	to-host IPsec SAs. When using IPv6 it is not always possible, so in		to-host IPsec SAs. When using IPv6 this is not always possible, so
	this case implementations MUST be able to assign full /64 address		in this case implementations MUST be able to assign full /64 address
	block to the peer as described in [RFC5739], even if it is not		block to the peer as described in [RFC5739], even if it is not
	authenticated.		authenticated.
	3. Security Considerations		3. Security Considerations
	If authenticated IKE sessions are possible for a certain traffic		If authenticated IKE sessions are possible for a certain traffic
	selector range between the peers, then unauthenticated IKE SHOULD NOT		selector range between the peers, then unauthenticated IKE SHOULD NOT
	be used for that traffic selector range. When mixing authenticated		be allowed for that traffic selector range. When mixing
	and unauthenticated IKE with the same peer, policy rules should		authenticated and unauthenticated IKE with the same peer, policy
	ensure the highest level of security will be used to protect the		rules should ensure the highest level of security will be used to
	communication between the two peers. See [RFC7435] for details.		protect the communication between the two peers. See [RFC7435] for
			details.
	If both peers use NULL Authentication, the entire key exchange		If both peers use NULL Authentication, the entire key exchange
	becomes unauthenticated. This makes the IKE session vulnerable to		becomes unauthenticated. This makes the IKE session vulnerable to
	active Man-in-the-Middle Attacks.		active Man-in-the-Middle Attacks.
	Using an ID Type other than ID_NULL with the NULL Authentication		Using an ID Type other than ID_NULL with the NULL Authentication
	Method may compromise the client's anonymity in case of an active		Method may compromise the client's anonymity in case of an active
	MITM attack.		MITM attack.
	IKE implementations without NULL Authentication have always performed		IKE implementations without NULL Authentication have always performed
	mutual authentication and were not designed for use with		mutual authentication and were not designed for use with
	unauthenticated IKE peers. Implementations might have made		unauthenticated IKE peers. Implementations might have made
	assumptions that are no longer valid. Furthermore, the host itself		assumptions remote peers are identified. With NULL Authentication
			these assumptions are no longer valid. Furthermore, the host itself
	might have made trust assumptions or may not be aware of the network		might have made trust assumptions or may not be aware of the network
	topology changes that resulted from IPsec SAs from unauthenticated		topology changes that resulted from IPsec SAs from unauthenticated
	IKE peers.		IKE peers.
	3.1. Audit trail and peer identification		3.1. Audit trail and peer identification
	An established IKE session is no longer guaranteed to provide a		With NULL Authentication an established IKE session is no longer
	verifiable (authenticated) entity known to the system or network.		guaranteed to provide a verifiable (authenticated) entity known to
	Implementers that implement NULL Authentication should audit their		the system or network. Implementers that implement NULL
	implementation for any assumptions that depend on IKE peers being		Authentication should ensure their implementation does not make any
	"friendly", "trusted" or "identifiable".		assumptions that depend on IKE peers being "friendly", "trusted" or
			"identifiable".
	3.2. Resource management and robustness		3.2. Resource management and robustness
	Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial		Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial
	of Service" attacks by issuing COOKIES in response to resource		of Service" attacks by issuing COOKIES in response to resource
	consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION]		consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION]
	offers additional counter-measures in an attempt to distinguish		offers additional counter-measures in an attempt to distinguish
	attacking IKE packets from legitimate IKE peers.		attacking IKE packets from legitimate IKE peers.
	These defense mechanisms do not take into account IKE systems that		These defense mechanisms do not take into account IKE systems that
	allow unauthenticated IKE peers. An attacker using NULL		allow unauthenticated IKE peers. An attacker using NULL
	Authentication is a fully legitimate IKE peer that is only		Authentication is a fully legitimate IKE peer that is only
	distinguished from authenticated IKE peers by having used NULL		distinguished from authenticated IKE peers by having used NULL
	Authentication.		Authentication.
	While implementations should have been written to account for abusive		While implementations should have been written to account for abusive
	authenticated clients, any omission or error in handling abusive		authenticated clients, any omission or error in handling abusive
	clients may have gone unnoticed because abusive clients has been a		clients may have gone unnoticed because abusive clients has been a
	rare or non-existent problem. When enabling unauthenticated IKE		rare or non-existent problem. When adding support for
	peers, these implementation omissions and errors will be found and		unauthenticated IKE peers, these implementation omissions and errors
	abused by attackers. For example, an unauthenticated IKE peer could		will be found and abused by attackers. For example, an
	send an abusive amount of Liveness probes or Delete requests.		unauthenticated IKE peer could send an abusive amount of Liveness
			probes or Delete requests.
	3.3. IKE configuration selection		3.3. IKE configuration selection
	Combining authenticated and unauthenticated IKE peers on a single		Combining authenticated and unauthenticated IKE peers on a single
	host can be dangerous, assuming the authenticated IKE peer gains more		host can be dangerous, assuming the authenticated IKE peer gains more
	or different access from non-authenticated peers (otherwise, why not		or different access from non-authenticated peers (otherwise, why not
	only allow unauthenticated peers). An unauthenticated IKE peer MUST		only allow unauthenticated peers). An unauthenticated IKE peer MUST
	NOT be able to reach resources only meant for authenticated IKE peers		NOT be able to reach resources only meant for authenticated IKE peers
	and MUST NOT be able to replace the Child SAs of an authenticated IKE		and MUST NOT be able to replace the Child SAs of an authenticated IKE
	peer.		peer.
End of changes. 15 change blocks.
	32 lines changed or deleted		37 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/