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/