draft-ietf-ipsecme-ikev2-null-auth-07.txt		rfc7619.txt
	Network Working Group V. Smyslov		Internet Engineering Task Force (IETF) V. Smyslov
	Internet-Draft ELVIS-PLUS		Request for Comments: 7619 ELVIS-PLUS
	Updates: 4301 (if approved) P. Wouters		Updates: 4301 P. Wouters
	Intended status: Standards Track Red Hat		Category: Standards Track Red Hat
	Expires: December 5, 2015 June 3, 2015		ISSN: 2070-1721 August 2015
	The NULL Authentication Method in IKEv2 Protocol		The NULL Authentication Method
	draft-ietf-ipsecme-ikev2-null-auth-07		in the Internet Key Exchange Protocol Version 2 (IKEv2)
	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 Internet Key Exchange
	allows two IKE peers to establish single-side authenticated or mutual		Protocol version 2 (IKEv2). This allows two IKE peers to establish
	unauthenticated IKE sessions for those use cases where a peer is		single-side authenticated or mutual unauthenticated IKE sessions for
	unwilling or unable to authenticate or identify itself. This ensures		those use cases where a peer is unwilling or unable to authenticate
	IKEv2 can be used for Opportunistic Security (also known as		or identify itself. This ensures IKEv2 can be used for Opportunistic
	Opportunistic Encryption) to defend against Pervasive Monitoring		Security (also known as Opportunistic Encryption) to defend against
	attacks without the need to sacrifice anonymity.		Pervasive Monitoring attacks without the need to sacrifice anonymity.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This is an Internet Standards Track document.
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on December 5, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7619.
	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
	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 . . . . . . . . . . . . 4
	2. Using the NULL Authentication Method . . . . . . . . . . . . . 5		2. Using the NULL Authentication Method . . . . . . . . . . . . 4
	2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5		2.1. Authentication Payload . . . . . . . . . . . . . . . . . 4
	2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5		2.2. Identification Payload . . . . . . . . . . . . . . . . . 4
	2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6		2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . 5
	2.4. Interaction with Peer Authorization Database (PAD) . . . . 6		2.4. Interaction with the Peer Authorization Database (PAD) . 5
	2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7		2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 9		3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	3.1. Audit trail and peer identification . . . . . . . . . . . 9		3.1. Audit Trail and Peer Identification . . . . . . . . . . . 7
	3.2. Resource management and robustness . . . . . . . . . . . . 9		3.2. Resource Management and Robustness . . . . . . . . . . . 8
	3.3. IKE configuration selection . . . . . . . . . . . . . . . 10		3.3. IKE Configuration Selection . . . . . . . . . . . . . . . 8
	3.4. Networking topology changes . . . . . . . . . . . . . . . 10		3.4. Networking Topology Changes . . . . . . . . . . . . . . . 8
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Normative References . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 13		5.2. Informative References . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . . 13		Appendix A. Update of PAD processing in RFC 4301 . . . . . . . . 11
	Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 14		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Internet Key Exchange Protocol version 2 (IKEv2), specified in		Internet Key Exchange Protocol version 2 (IKEv2), specified in
	[RFC7296], provides a way for two parties to perform an authenticated		[RFC7296], provides a way for two parties to perform an authenticated
	key exchange. While the authentication methods used by the peers can		key exchange. While the authentication methods used by the peers can
	be different, there is no method for one or both parties to remain		be different, there is no method for one or both parties to remain
	unauthenticated and anonymous. This document extends the		unauthenticated and anonymous. This document extends the
	authentication methods to support unauthenticated and anonymous IKE		authentication methods to support unauthenticated and anonymous IKE
	sessions.		sessions.
	In some situations mutual authentication is undesirable, superfluous		In some situations, mutual authentication is undesirable,
	or impossible. The following three examples illustrate these		superfluous, or impossible. The following three examples illustrate
	unauthenticated use cases:		these unauthenticated use cases:
	o A user wants to establish an anonymous secure connection to a		o A user wants to establish an anonymous secure connection to a
	server. In this situation the user should be able to authenticate		server. In this situation, the user should be able to
	the server without presenting or authenticating to the server with		authenticate the server without presenting or authenticating to
	their own identity. This case uses a single-sided authentication		the server with their own identity. This case uses a single-sided
	of the responder.		authentication of the responder.
	o A sensor that periodically wakes up from a suspended state wants		o A sensor that periodically wakes up from a suspended state wants
	to send a measurement (e.g. temperature) to a collecting server.		to send a measurement (e.g., temperature) to a collecting server.
	The sensor must be authenticated by the server to ensure		The sensor must be authenticated by the server to ensure
	authenticity of the measurement, but the sensor does not need to		authenticity of the measurement, but the sensor does not need to
	authenticate the server. This case uses a single-sided		authenticate the server. This case uses a single-sided
	authentication of the initiator.		authentication of the initiator.
	o Two peers without any trust relationship wish to defend against		o Two peers without any trust relationship wish to defend against
	widespread pervasive monitoring attacks as described in [RFC7258].		widespread pervasive monitoring attacks as described in [RFC7258].
	Without a trust relationship, the peers cannot authenticate each		Without a trust relationship, the peers cannot authenticate each
	other. Opportunistic Security [RFC7435] states that		other. Opportunistic Security [RFC7435] states that
	unauthenticated encrypted communication is preferred over		unauthenticated encrypted communication is preferred over
	cleartext communication. The peers want to use IKE to setup an		cleartext communication. The peers want to use IKE to setup an
	unauthenticated encrypted connection, that gives them protection		unauthenticated encrypted connection that gives them protection
	against pervasive monitoring attacks. An attacker that is able		against pervasive monitoring attacks. An attacker that is able
	and willing to send packets can still launch a Man-in-the-Middle		and willing to send packets can still launch a man-in-the-middle
	attack to obtain a copy of the unencrypted communication. This		(MITM) attack to obtain a copy of the unencrypted communication.
	case uses a fully unauthenticated key exchange.		This case uses a fully unauthenticated key exchange.
	To meet these needs, this document introduces the NULL Authentication		To meet these needs, this document introduces the NULL Authentication
	method, and the ID_NULL ID type. This allows an IKE peer to		method and the ID_NULL ID type. This allows an IKE peer to
	explicitly indicate that it is unwilling or unable to certify its		explicitly indicate that it is unwilling or unable to certify its
	identity.		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. A peer may choose to refrain from		itself to the other side. A peer may choose to refrain from
	authentication by using the NULL Authentication method. If a host's		authentication by using the NULL Authentication method. If a host's
	local policy requires that the identity of its peer be (non-null)		local policy requires that the identity of its peer be (non-null)
	authenticated, and that host receives an AUTH payload containing the		authenticated, and if that host receives an AUTH payload containing
	NULL Authentication method type, it MUST return an		the NULL Authentication method type, it MUST return an
	AUTHENTICATION_FAILED notification. If an initiator uses EAP, the		AUTHENTICATION_FAILED notification. If an initiator uses the
	responder MUST NOT use the NULL Authentication Method (in conformance		Extensible Authentication Protocol (EAP), the responder MUST NOT use
	with the section 2.16 of [RFC7296]).		the NULL Authentication method (in conformance with Section 2.16 of
			[RFC7296]).
	NULL Authentication affects how the Authentication and the		NULL authentication affects how the Authentication and the
	Identification payloads are formed in the IKE_AUTH exchange.		Identification payloads are formed in the IKE_AUTH exchange.
	2.1. Authentication Payload		2.1. Authentication Payload
	NULL Authentication still requires a properly formed AUTH payload to		NULL authentication still requires a properly formed AUTH payload to
	be present in the IKE_AUTH exchange messages, as the AUTH payload		be present in the IKE_AUTH exchange messages, as the AUTH payload
	cryptographically links the IKE_SA_INIT exchange messages with the		cryptographically links the IKE_SA_INIT exchange messages with the
	other messages sent over this IKE SA.		other messages sent over this IKE Security Association (SA).
	When using NULL Authentication, the content of the AUTH payload is		When using NULL authentication, the content of the AUTH payload is
	computed using the syntax of pre-shared secret authentication,		computed using the syntax of pre-shared secret authentication,
	described in Section 2.15 of [RFC7296]. The value of SK_pi for the		described in Section 2.15 of [RFC7296]. The value of SK_pi for the
	initiator and SK_pr for the responder is used as the shared secret		initiator and SK_pr for the responder is used as the shared secret
	for the content of the AUTH payload. Implementers should note this		for the content of the AUTH payload. Implementers should note this
	means that authentication keys used by the two peers are different in		means that authentication keys used by the two peers are different in
	each direction. This is identical to how the content of the two last		each direction. This is identical to how the contents of the two
	AUTH payloads is generated for the non-key-generating EAP methods		last AUTH payloads are generated for the non-key-generating EAP
	(see Section 2.16 of [RFC7296] for details).		methods (see Section 2.16 of [RFC7296] for details).
	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 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 cases where a non-null identity type and value with NULL		of cases where a non-null identity type and value with NULL
	Authentication can be used are logging, troubleshooting and in		authentication can be used are logging, troubleshooting, and in
	scenarios where authentication takes place out of band after the IKE		scenarios where authentication takes place out of band after the IKE
	SA is 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
	2.4 for details).		Section 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.
	The IKEv2 Identification Payload ID Type for ID_NULL is 13.		The IKEv2 Identification Payload ID Type for ID_NULL is 13.
	2.3. INITIAL_CONTACT Notification		2.3. INITIAL_CONTACT Notification
	The identity of a peer using NULL Authentication cannot be used to		The identity of a peer using NULL authentication cannot be used to
	find existing IKE SAs created by the same peer, as the peer identity		find existing IKE SAs created by the same peer, as the peer identity
	is not authenticated. For that reason the INITIAL_CONTACT		is not authenticated. For that reason, the INITIAL_CONTACT
	notifications MUST NOT be used to delete any other IKE SAs based on		notifications MUST NOT be used to delete any other IKE SAs based on
	the same peer identity without additional verification that the		the same peer identity without additional verification that the
	existing IKE SAs with matching identity are actually stale.		existing IKE SAs with matching identity are actually stale.
	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 weigh 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 the 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 the Security Policy Database
	and the IKEv2. The PAD contains an ordered list of records with		(SPD) and 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 the PAD
	described in Section 4.4.3 of [RFC4301] is updated for NULL		described in Section 4.4.3 of [RFC4301] is updated for NULL
	Authentication as follows.		authentication as follows.
	NULL authentication is added as one of supported authentication		NULL authentication is added as one of the supported authentication
	methods. This method does not have any authentication data. ID_NULL		methods. This method does not have any authentication data. ID_NULL
	is included into the list of allowed ID types. The matching rule for		is included into the list of allowed ID types. The matching rule for
	ID_NULL consists only of whether this type is used, i.e. no actual ID		ID_NULL consists only of whether this type is used, i.e., no actual
	matching is done, as ID_NULL contains no identity data.		ID matching is done as ID_NULL contains no identity data.
	When using the NULL authentication method those matching rules MUST		When using the NULL Authentication method, those matching rules MUST
	include matching of a new flag in the SPD entry specifying whether		include matching of a new flag in the SPD entry specifying whether
	unauthenticated users are allowed to use that entry. I.e. each SPD		unauthenticated users are allowed to use that entry. That is, each
	entry needs to be augmented to have a flag specifying whether it can		SPD entry needs to be augmented to have a flag specifying whether it
	be used with NULL authentication or not, and only those rules that		can be used with NULL authentication or not, and only those rules
	explicitly have that flag turned on can be used with unauthenticated		that explicitly have that flag turned on can be used with
	connections.		unauthenticated connections.
	The specific updates of text in Section 4.4.3 of [RFC4301] are listed		The specific updates of text in Section 4.4.3 of [RFC4301] are listed
	in Appendix A.		in Appendix A.
	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 is 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
	Traffic Selectors to trick a remote host into giving it IP traffic		Traffic Selectors to trick a remote host into giving it IP traffic
	that the remote host never intended to be sent to remote IKE peers.		that the remote host never intended to be sent to remote IKE peers.
	For example, if the remote host uses 192.0.2.1 as DNS server, a rogue		For example, if the remote host uses 192.0.2.1 as the DNS server, a
	IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to		rogue IKE peer could set its Traffic Selector to 192.0.2.1 in an
	receive the remote peer's DNS traffic. Implementations SHOULD		attempt to receive the remote peer's DNS traffic. Implementations
	restrict and isolate all anonymous IKE peers from each other and		SHOULD restrict and isolate all anonymous IKE peers from each other
	itself and only allow it access to itself and possibly its intended		and itself and only allow it access to itself and possibly its
	network ranges.		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 this is not always possible, so		to-host IPsec SAs. When using IPv6, this is not always possible, so
	implementations MUST be able to assign full /64 address block to the		implementations MUST be able to assign a full /64 address block to
	peer as described in [RFC5739], even if it is not authenticated.		the peer as described in [RFC5739], even if it is not 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 allowed for that traffic selector range. When mixing		be allowed for that Traffic Selector range. When mixing
	authenticated and unauthenticated IKE with the same peer, policy		authenticated and unauthenticated IKE with the same peer, policy
	rules should ensure the highest level of security will be used to		rules should ensure the highest level of security will be used to
	protect the communication between the two peers. See [RFC7435] for		protect the communication between the two peers. See [RFC7435] for
	details.		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 MITM 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 remote peers are identified. With NULL		assumptions that remote peers are identified. With NULL
	Authentication these assumptions are no longer valid. Furthermore,		authentication, these assumptions are no longer valid. Furthermore,
	the host itself might have made trust assumptions or may not be aware		the host itself might have made trust assumptions or may not be aware
	of the network topology changes that resulted from IPsec SAs from		of the network topology changes that resulted from IPsec SAs from
	unauthenticated IKE peers.		unauthenticated IKE peers.
	3.1. Audit trail and peer identification		3.1. Audit Trail and Peer Identification
	With NULL Authentication an established IKE session is no longer		With NULL authentication, an established IKE session is no longer
	guaranteed to provide a verifiable (authenticated) entity known to		guaranteed to provide a verifiable (authenticated) entity known to
	the system or network. Any logging of unproven ID payloads that were		the system or network. Any logging of unproven ID payloads that were
	not authenticated should be clearly marked and treated as		not authenticated should be clearly marked and treated as "untrusted"
	"untrusted", possibly accompanied by logging the remote IP address of		and possibly accompanied by logging the remote IP address of the IKE
	the IKE session. Rate limiting of logging might be required to		session. Rate limiting of logging might be required to prevent
	prevent excessive resource consumption causing system damage.		excessive resource consumption causing system damage.
	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 (DoS) 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 countermeasures 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.
	Implementers that implement NULL Authentication should ensure their		Implementers that implement NULL authentication should ensure their
	implementation does not make any assumptions that depend on IKE peers		implementation does not make any assumptions that depend on IKE peers
	being "friendly", "trusted" or "identifiable". While implementations		being "friendly", "trusted", or "identifiable". While
	should have been written to account for abusive authenticated		implementations should have been written to account for abusive
	clients, any omission or error in handling abusive clients may have		authenticated clients, any omission or error in handling abusive
	gone unnoticed because abusive clients has been a rare or non-		clients may have gone unnoticed because abusive clients have been a
	existent problem. When adding support for unauthenticated IKE peers,		rare or nonexistent problem. When adding support for unauthenticated
	these implementation omissions and errors will be found and abused by		IKE peers, these implementation omissions and errors will be found
	attackers. For example, an unauthenticated IKE peer could send an		and abused by attackers. For example, an unauthenticated IKE peer
	abusive amount of Liveness probes or Delete requests.		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 unauthenticated 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.
	3.4. Networking topology changes		3.4. Networking Topology Changes
	When a host relies on packet filters or firewall software to protect		When a host relies on packet filters or firewall software to protect
	itself, establishing an IKE SA and installing an IPsec SA might		itself, establishing an IKE SA and installing an IPsec SA might
	accidentally circumvent these packet filters and firewall		accidentally circumvent these packet filters and firewall
	restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP		restrictions, as the Encapsulating Security Payload (ESP, protocol
	port 4500) packets do not match the packet filters defined. IKE		50) or ESPinUDP (UDP port 4500) packets of the encrypted traffic do
			not match the packet filters defined for unencrypted traffic. IKE
	peers supporting unauthenticated IKE MUST pass all decrypted traffic		peers supporting unauthenticated IKE MUST pass all decrypted traffic
	through the same packet filters and security mechanisms as incoming		through the same packet filters and security mechanisms as incoming
	plaintext traffic.		plaintext traffic.
	4. Acknowledgments		4. IANA Considerations
	The authors would like to thank Yaron Sheffer and Tero Kivinen for
	their reviews, valuable comments and contributed text.
	5. IANA Considerations
	This document defines a new entry in the "IKEv2 Authentication		Per this document, IANA has added a new entry in the "IKEv2
	Method" registry:		Authentication Method" registry:
	13 NULL Authentication		13 NULL Authentication
	This document also defines a new entry in the "IKEv2 Identification		Per this document, IANA has added a new entry in the "IKEv2
	Payload ID Types" registry:		Identification Payload ID Types" registry:
	13 ID_NULL		13 ID_NULL
	6. References		5. References
	6.1. Normative References		5.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
			December 2005, <http://www.rfc-editor.org/info/rfc4301>.
	[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6		[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6
	Configuration in Internet Key Exchange Protocol Version 2		Configuration in Internet Key Exchange Protocol Version 2
	(IKEv2)", RFC 5739, February 2010.		(IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010,
			<http://www.rfc-editor.org/info/rfc5739>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, October 2014.		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <http://www.rfc-editor.org/info/rfc7296>.
	6.2. Informative References		5.2. Informative References
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, May 2014.		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <http://www.rfc-editor.org/info/rfc7258>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, December 2014.		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
			December 2014, <http://www.rfc-editor.org/info/rfc7435>.
	[AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work		[AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work
	in Progress, draft-sheffer-autovpn-00, February 2014.		in Progress, draft-sheffer-autovpn-00, February 2014.
	[DDOS-PROTECTION]		[DDOS-PROTECTION]
	Nir, Y., "Protecting Internet Key Exchange (IKE)		Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
	Implementations from Distributed Denial of Service		(IKE) Implementations from Distributed Denial of Service
	Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in		Attacks", Work in Progress, draft-ietf-ipsecme-ddos-
	progress), October 2014.		protection-02, July 2015.
	Appendix A. Update of PAD processing in RFC4301		Appendix A. Update of PAD processing in RFC 4301
	This appendix lists the specific updates of the text in Section 4.4.3		This appendix lists the specific updates of the text in Section 4.4.3
	of [RFC4301] that should be followed when implementing NULL		of [RFC4301] that should be followed when implementing NULL
	Authentication.		authentication.
	A new item is added to the list of supported ID types in Section		A new item is added to the list of supported ID types in
	4.4.3.1		Section 4.4.3.1 of [RFC4301]
	o NULL ID (matches ID type only)		o NULL ID (matches ID type only)
	and the following text is added at the end of the section:		and the following text is added at the end of the section:
	Added text:		Added text:
	The NULL ID type is defined as having no data. For this name type		The NULL ID type is defined as having no data. For this name
	the matching function is defined as comparing the ID type only.		type, the matching function is defined as comparing the ID type
			only.
	A new item is added to the list of authentication data types in		A new item is added to the list of authentication data types in
	Section 4.4.3.2		Section 4.4.3.2 of [RFC4301]:
	- NULL authentication		- NULL authentication
	and the next paragraph is updated as follows:		and the next paragraph is updated as follows:
	Old:		Old:
	For authentication based on an X.509 certificate [...] For		For authentication based on an X.509 certificate [...] For
	authentication based on a pre-shared secret, the PAD contains the		authentication based on a pre-shared secret, the PAD contains the
	pre-shared secret to be used by IKE.		pre-shared secret to be used by IKE.
	New:		New:
	For authentication based on an X.509 certificate [...] For		For authentication based on an X.509 certificate [...] For
	authentication based on a pre-shared secret, the PAD contains the		authentication based on a pre-shared secret, the PAD contains the
	pre-shared secret to be used by IKE. For NULL authentication the		pre-shared secret to be used by IKE. For NULL authentication the
	PAD contains no data.		PAD contains no data.
	In addition the following text is added at the end of Section 4.4.3.4		In addition, the following text is added at the end of
			Section 4.4.3.4 of [RFC4301]:
	Added text:		Added text:
	When using the NULL authentication method implementations MUST		When using the NULL Authentication method, implementations MUST
	make sure that they do not mix authenticated and not-authenticated		make sure that they do not mix authenticated and unauthenticated
	SPD rules, i.e. implementations need to keep them separately, for		SPD rules, i.e., implementations need to keep them separately; for
	example by adding flag in SPD to tell whether NULL authentication		example, by adding a flag in the SPD to tell whether NULL
	can be used or not for the entry. I.e. each SPD entry needs to be		authentication can be used or not for the entry. That is, each
	augmented to have a flag specifying whether it can be used with		SPD entry needs to be augmented to have a flag specifying whether
	NULL authentication or not, and only those rules that explictly		it can be used with NULL authentication or not, and only those
	have that flag set can be used with unauthenticated connections.		rules that explicitly have that flag set can be used with
			unauthenticated connections.
			Acknowledgments
			The authors would like to thank Yaron Sheffer and Tero Kivinen for
			their reviews, valuable comments, and contributed text.
	Authors' Addresses		Authors' Addresses
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd) 124460		Moscow (Zelenograd) 124460
	Russian Federation		Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
End of changes. 87 change blocks.
	186 lines changed or deleted		195 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/