< draft-ietf-ipsecme-ikev2-null-auth-05.txt		draft-ietf-ipsecme-ikev2-null-auth-06.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		Updates: 4301 (if approved) P. Wouters
	Expires: September 27, 2015 Red Hat		Intended status: Standards Track Red Hat
	March 26, 2015		Expires: October 22, 2015 April 20, 2015
	The NULL Authentication Method in IKEv2 Protocol		The NULL Authentication Method in IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-null-auth-05		draft-ietf-ipsecme-ikev2-null-auth-06
	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 September 27, 2015.		This Internet-Draft will expire on October 22, 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 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	3.1. Audit trail and peer identification . . . . . . . . . . . 8		3.1. Audit trail and peer identification . . . . . . . . . . . 8
	3.2. Resource management and robustness . . . . . . . . . . . . 8		3.2. Resource management and robustness . . . . . . . . . . . . 8
	3.3. IKE configuration selection . . . . . . . . . . . . . . . 9		3.3. IKE configuration selection . . . . . . . . . . . . . . . 9
	3.4. Networking topology changes . . . . . . . . . . . . . . . 9		3.4. Networking topology changes . . . . . . . . . . . . . . . 9
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 12		6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . . 12		6.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Internet Key Exchange Protocol version 2 (IKEv2), specified in		The 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.
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	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 access to the decrypted communication. This case		attack to obtain a copy of the unencrypted communication. This
	uses a fully unauthenticated key exchange.		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].
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	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 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 values SK_pi and SK_pr		described in Section 2.15 of [RFC7296]. The value of SK_pi for the
	are used as shared secrets for the content of the AUTH payloads		initiator and SK_pr for the responder is used as the shared secret
	generated by the initiator and the responder respectively. Note that		for the content of the AUTH payload. Implementers should note this
	this is identical to how the content of the two last AUTH payloads is		means that authentication keys used by the two peers are different in
	generated for the non-key-generating EAP methods (see Section 2.16 of		each direction. This is identical to how the content of the two last
	[RFC7296] for details).		AUTH payloads is generated for the non-key-generating EAP 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.
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 44 ¶
	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 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 of [RFC4301] is updated for NULL
			Authentication as follows.
	NULL authentication needs to be added as one of supported		NULL authentication is added as one of supported authentication
	authentication methods. This method does not have any authentication		methods. This method does not have any authentication data. ID_NULL
	data. To add support for ID_NULL, it needs to be included into the		is included into the list of allowed ID types. The matching rule for
	list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The		ID_NULL consists only of whether this type is used, i.e. no actual ID
	matching rule for ID_NULL consists only of whether this type is used,		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		When using the NULL authentication method those matching rules MUST
	against the SPD entries. When using the NULL authentication method		include matching of a new flag in the SPD entry specifying whether
	those matching rules MUST include matching of a new flag in the SPD		unauthenticated users are allowed to use that entry. I.e. each SPD
	entry specifying whether unauthenticated users are allowed to use		entry needs to be augmented to have a flag specifying whether it can
	that entry. I.e. each SPD entry needs to be augmented to have a flag		be used with NULL authentication or not, and only those rules that
	specifying whether it can be used with NULL authentication or not,		explicitly have that flag turned on can be used with unauthenticated
	and only those rules that explictly have that flag turned on can be		connections.
	used with unauthenticated connections.
			The specific updates of text in Section 4.4.3 of [RFC4301] are listed
			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 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 44 ¶		skipping to change at page 7, line 46 ¶
	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 this is not always possible, so		to-host IPsec SAs. When using IPv6 this is not always possible, so
	in this case implementations MUST be able to assign full /64 address		implementations MUST be able to assign full /64 address block to the
	block to the peer as described in [RFC5739], even if it is not		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 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.
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 26 ¶
	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 remote peers are identified. With NULL Authentication		assumptions that remote peers are identified. With NULL
	these assumptions are no longer valid. Furthermore, the host itself		Authentication these assumptions are no longer valid. Furthermore,
	might have made trust assumptions or may not be aware of the network		the host itself might have made trust assumptions or may not be aware
	topology changes that resulted from IPsec SAs from unauthenticated		of the network topology changes that resulted from IPsec SAs from
	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. Implementers that implement NULL		the system or network. Implementers that implement NULL
	Authentication should ensure their implementation does not make any		Authentication should ensure their implementation does not make any
	assumptions that depend on IKE peers being "friendly", "trusted" or		assumptions that depend on IKE peers being "friendly", "trusted" or
	"identifiable".		"identifiable".
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	[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., "Protecting Internet Key Exchange (IKE)
	Implementations from Distributed Denial of Service		Implementations from Distributed Denial of Service
	Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in		Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in
	progress), October 2014.		progress), October 2014.
			Appendix A. Update of PAD processing in RFC4301
			This appendix lists the specific updates of the text in Section 4.4.3
			of [RFC4301] that should be followed when implementing NULL
			Authentication.
			A new item is added to the list of supported ID types in Section
			4.4.3.1
			o NULL ID (matches ID type only)
			and the following text is added at the end of the section:
			Added text:
			The NULL ID type is defined as having no data. For this name 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
			Section 4.4.3.2
			- NULL authentication
			and the next paragraph is updated as follows:
			Old:
			For authentication based on an X.509 certificate [...] For
			authentication based on a pre-shared secret, the PAD contains the
			pre-shared secret to be used by IKE.
			New:
			For authentication based on an X.509 certificate [...] For
			authentication based on a pre-shared secret, the PAD contains the
			pre-shared secret to be used by IKE. For NULL authentication the
			PAD contains no data.
			In addition the following text is added at the end of Section 4.4.3.4
			Added text:
			When using the NULL authentication method implementations MUST
			make sure that they do not mix authenticated and not-authenticated
			SPD rules, i.e. implementations need to keep them separately, for
			example by adding flag in SPD to tell whether NULL authentication
			can be used or not for the 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, and only those rules that explictly
			have that flag set can be used with unauthenticated connections.
	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
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 14 change blocks.
	40 lines changed or deleted		89 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/