draft-ietf-ipsecme-ikev2-null-auth-06.txt   draft-ietf-ipsecme-ikev2-null-auth-07.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Updates: 4301 (if approved) P. Wouters Updates: 4301 (if approved) P. Wouters
Intended status: Standards Track Red Hat Intended status: Standards Track Red Hat
Expires: October 22, 2015 April 20, 2015 Expires: December 5, 2015 June 3, 2015
The NULL Authentication Method in IKEv2 Protocol The NULL Authentication Method in IKEv2 Protocol
draft-ietf-ipsecme-ikev2-null-auth-06 draft-ietf-ipsecme-ikev2-null-auth-07
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 October 22, 2015. This Internet-Draft will expire on December 5, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . 5 2. Using the NULL Authentication Method . . . . . . . . . . . . . 5
2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5
2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5 2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6
2.4. Interaction with Peer Authorization Database (PAD) . . . . 6 2.4. Interaction with Peer Authorization Database (PAD) . . . . 6
2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7 2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
3.1. Audit trail and peer identification . . . . . . . . . . . 8 3.1. Audit trail and peer identification . . . . . . . . . . . 9
3.2. Resource management and robustness . . . . . . . . . . . . 8 3.2. Resource management and robustness . . . . . . . . . . . . 9
3.3. IKE configuration selection . . . . . . . . . . . . . . . 9 3.3. IKE configuration selection . . . . . . . . . . . . . . . 10
3.4. Networking topology changes . . . . . . . . . . . . . . . 9 3.4. Networking topology changes . . . . . . . . . . . . . . . 10
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 13 Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 5, line 9 skipping to change at page 5, line 9
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 peer authentication by using the NULL Authentication method. If a host's
that requires authentication receives an AUTH payload containing the local policy requires that the identity of its peer be (non-null)
authenticated, and that host receives an AUTH payload containing the
NULL Authentication method type, it MUST return an NULL Authentication method type, it MUST return an
AUTHENTICATION_FAILED notification. If an initiator uses EAP, the AUTHENTICATION_FAILED notification. If an initiator uses EAP, the
responder MUST NOT use the NULL Authentication Method (in conformance responder MUST NOT use the NULL Authentication Method (in conformance
with the section 2.16 of [RFC7296]). with the 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
skipping to change at page 7, line 34 skipping to change at page 7, line 35
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
Traffic Selectors to obtain access to traffic that the host never Traffic Selectors to trick a remote host into giving it IP traffic
intended to hand out. Implementations SHOULD restrict and isolate that the remote host never intended to be sent to remote IKE peers.
all anonymous IKE peers from each other and itself and only allow it For example, if the remote host uses 192.0.2.1 as DNS server, a rogue
access to itself and possibly its intended network ranges. IKE peer could set its Traffic Selector to 192.0.2.1 in an attempt to
receive the remote peer's DNS traffic. Implementations SHOULD
restrict and isolate all anonymous IKE peers from each other and
itself and only allow it 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
implementations MUST be able to assign full /64 address block to the implementations MUST be able to assign full /64 address block to the
peer as described in [RFC5739], even if it is not authenticated. peer as described in [RFC5739], even if it is not authenticated.
skipping to change at page 8, line 36 skipping to change at page 9, line 36
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. Implementers that implement NULL the system or network. Any logging of unproven ID payloads that were
Authentication should ensure their implementation does not make any not authenticated should be clearly marked and treated as
assumptions that depend on IKE peers being "friendly", "trusted" or "untrusted", possibly accompanied by logging the remote IP address of
"identifiable". the IKE session. Rate limiting of logging might be required to
prevent 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" 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 Implementers that implement NULL Authentication should ensure their
authenticated clients, any omission or error in handling abusive implementation does not make any assumptions that depend on IKE peers
clients may have gone unnoticed because abusive clients has been a being "friendly", "trusted" or "identifiable". While implementations
rare or non-existent problem. When adding support for should have been written to account for abusive authenticated
unauthenticated IKE peers, these implementation omissions and errors clients, any omission or error in handling abusive clients may have
will be found and abused by attackers. For example, an gone unnoticed because abusive clients has been a rare or non-
unauthenticated IKE peer could send an abusive amount of Liveness existent problem. When adding support for unauthenticated IKE peers,
probes or Delete requests. these implementation omissions and errors will be found and abused by
attackers. For example, an 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. 8 change blocks. 
33 lines changed or deleted 41 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/