draft-ietf-ipsecme-ikev2-null-auth-02.txt   draft-ietf-ipsecme-ikev2-null-auth-03.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: July 17, 2015 Red Hat Expires: August 1, 2015 Red Hat
January 13, 2015 January 28, 2015
The NULL Authentication Method in IKEv2 Protocol The NULL Authentication Method in IKEv2 Protocol
draft-ietf-ipsecme-ikev2-null-auth-02 draft-ietf-ipsecme-ikev2-null-auth-03
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
un-authenticated 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 itself. This ensures IKEv2 can unwilling or unable to authenticate or identify itself. This ensures
be used for Opportunistic Security (also known as Opportunsitic IKEv2 can be used for Opportunistic Security (also known as
Encryption) to defend against Pervasive Monitoring attacks without Opportunistic Encryption) to defend against Pervasive Monitoring
the need to sacrifice anonimity. attacks without the need to sacrifice anonymity.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 17, 2015. This Internet-Draft will expire on August 1, 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
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 . . . . . . . . . . . . 3
2. Using the NULL Authentication Method . . . . . . . . . . . . . 4 2. Using the NULL Authentication Method . . . . . . . . . . . . . 5
2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 5
2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 2.2. Identification Payload . . . . . . . . . . . . . . . . . . 5
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 5 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 2.4. Interaction with Peer Authorization Database (PAD) . . . . 6
3.1. Audit trail and peer identification . . . . . . . . . . . 6 2.5. Traffic Selectors . . . . . . . . . . . . . . . . . . . . 7
3.2. Resource management and robustness . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.3. IKE configuration selection . . . . . . . . . . . . . . . 7 3.1. Audit trail and peer identification . . . . . . . . . . . 8
3.4. Networking topology changes . . . . . . . . . . . . . . . 7 3.2. Resource management and robustness . . . . . . . . . . . . 8
3.5. Priviledged IKE operations . . . . . . . . . . . . . . . . 8 3.3. IKE configuration selection . . . . . . . . . . . . . . . 9
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Networking topology changes . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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 key exchanges. authentication methods to support unauthenticated and anonymous IKE
sessions.
In some situations mutual authentication is undesirable, superfluous In some situations mutual authentication is undesirable, superfluous
or impossible. The following three examples illustratate these un- or impossible. The following three examples illustrate these
authenticated use cases: 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 authenticate
the server without presenting or authenticating to the server with the server without presenting or authenticating to the server with
their own identity. This case uses a single-sided authentication their own identity. This case uses a single-sided authentication
of the responder. 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 measurment, 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 un- other. Opportunistic Security [RFC7435] states that
authenticated encrypted communication is prefered over cleartext unauthenticated encrypted communication is preferred over
communication. The peers want to use IKE to setup an un- cleartext communication. The peers want to use IKE to setup an
authenticated 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 an Man-in-the-Middle and willing to send packets can still launch an Man-in-the-Middle
attack to obtain access to the decrypted communication. This case attack to obtain access to the decrypted communication. This case
uses a fully anonymous un-authenticated key exchange. 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 identity 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 peer authentication by using the NULL Authentication method. If a peer
that requires authentiation receives an AUTH payload containing the that requires authentication 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]).
The NULL Authentication Method affects how the Authentication and the NULL Authentication affects how the Authentication and the
Identity 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
The NULL Authentication Method still requires a properly formed AUTH NULL Authentication still requires a properly formed AUTH payload to
payload to be present in the IKE_AUTH exchange messages, as the AUTH be present in the IKE_AUTH exchange messages, as the AUTH payload
payload cryptographically links the IKE_SA_INIT exchange messages cryptographically links the IKE_SA_INIT exchange messages with the
with the other messages sent over this IKE SA. other messages sent over this IKE SA.
When using the NULL Authentication Method, the content of the AUTH When using NULL Authentication, the content of the AUTH payload is
payload is computed using the syntax of pre-shared secret computed using the syntax of pre-shared secret authentication,
authentication, described in Section 2.15 of [RFC7296]. The values described in Section 2.15 of [RFC7296]. The values SK_pi and SK_pr
SK_pi and SK_pr are used as shared secrets for the content of the are used as shared secrets for the content of the AUTH payloads
AUTH payloads generated by the initiator and the responder generated by the initiator and the responder respectively. Note that
respectively. Note that this is identical to how the content of the this is identical to how the content of the two last AUTH payloads is
two last AUTH payloads is generated for the non-key-generating EAP generated for the non-key-generating EAP methods (see Section 2.16 of
methods (see Section 2.16 of [RFC7296] for details). [RFC7296] for details).
The KEv2 Authentication Method value for the NULL Authentication The IKEv2 Authentication Method value for NULL Authentication is 13.
Method is 13.
2.2. Identity 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 Identification Payload cannot be Identification Data field of the ID payload cannot be validated. To
validated and MUST be ignored. A new Identification Payload ID Type avoid the need of sending a bogus ID Type with placeholder data, this
is introduced to avoid the need of sending a bogus ID Type with specification defines a new ID Type, ID_NULL. The Identification
placeholder data. Furthermore, sending a traditional ID field might Data field of the ID payload for this ID Type MUST be empty.
unwittingly compromise the anonimity of the peer.
This specification defines a new ID Type of ID_NULL, which SHOULD If NULL Authentication is in use and an anonymity is a concern then
only be used with the NULL Authentication Method. The Identification ID_NULL SHOULD be used in Identification payload. In some cases
Data field of the Identification Payload MUST be empty. there may be good reasons to use non-null identities (and ID Types
other than ID_NULL) with NULL Authentication. The identities may be
used for logging, troubleshooting or in scenarios when authentication
takes place out of band after the IKE SA is created (like in
[AUTOVPN]). In any case, when NULL Authentication is employed, the
content of Identification payload MUST NOT be used for any trust and
policy checking in IKE_AUTH exchange.
ID_NULL is primarily intended to be used with the NULL
Authentication, but it MAY also be used in other situations, when the
content of Identification payload does not matter. For example,
ID_NULL can be used when authentication is performed via raw public
keys and the identities are these keys themselves. Another example
is EAP authentication when the client identity in ID payload is not
used.
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 the peer which uses the NULL Authentication Method The identity of a peer using NULL Authentication cannot be used to
cannot be used to distinguish between IKE SAs created by different distinguish from IKE SAs created by other peers using the NULL
peers. For that reason the INITIAL_CONTACT notifications MUST be Authentication method. For that reason the INITIAL_CONTACT
ignored for IKE SAs using the NULL Authentication Method. notifications MUST be ignored for IKE SAs using NULL Authentication.
When a new IKE SA is established using the NULL Authentication The standard IKE Liveness Check procedure, decribed in Section 2.4 of
Method, implementations MAY perform a Liveness Check on all other IKE [RFC7296], can be used to detect stale IKE SAs created by peers using
SAs that were established using the NULL Authentication Method. To NULL Authentication. Inactive unauthenticated IKE SAs should be
mitigate the potential impact of sending Liveness Check messages on a checked periodically. Additionally, the event of creating a new
large number of IKE SAs, implementations are advised not to blindly unauthenticated IKE SA can be used to trigger an out-of-order check
perform Liveness Check on every such SA, but to take into on existing unauthenticated IKE SAs, possibly limited to identical or
considerations additional information, that may indicate that the close-by IP addresses or to identical identities of the just created
particular SA is alive. This information may include the recent IKE SA.
receipt of cryptographically protected message on the IKE SA or any
of its Child SAs, or a successfull Liveness Check that was performed Implementations should weight the resource consumption of sending
recently. Liveness Checks against the memory usage of possible orphaned IKE
SAs. Implementations may choose to handle situations with thousands
of unauthenticated IKE SAs differently from situations with very few
such SAs.
2.4. Interaction with Peer Authorization Database (PAD)
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database
(PAD), which provides the link between Security Policy Database (SPD)
and the IKEv2. The PAD contains an ordered list of records, with
peers' identities along with corresponding authentication data and
Child SA authorization data. When the IKE SA is being established
the PAD is consulted to determine how the peer should be
authenticated and what Child SAs it is authorized to create.
When using NULL Authentication, the peer identity is not
authenticated and cannot be used. If ID_NULL is used with NULL
Authentication, there is no ID at all. The processing of PAD
described in Section 4.4.3.4 of [RFC4301] must be updated.
If NULL Authentication is supported and allowed, then a special entry
MUST be included in the PAD. This entry MUST contain no
authentication data. It MAY contain a set of constraints for
creating Child SAs as described in Section 4.4.3 of [RFC4301]. When
a peer uses NULL Authentication, regular matching rules for the PAD
MUST be ignored and this special entry MUST be selected regardless of
the peer identity. Likewise, if a peer uses any other authentication
method, then this special entry MUST NOT be selected regardless of
the peer identity and the regular search of the PAD described in
Section 4.4.3.4 of [RFC4301] MUST be performed.
Implementations SHOULD allow to be configured so, that when a peer
requests NULL Authentication, then regular PAD entries are searched
before selecting the special entry, to ensure that there is no entry,
containing peer's IP address. In this case implementations MUST
reject the IKE_AUTH exchange by sending an AUTHENTICATION_FAILED
notification if such an entry is found.
2.5. Traffic Selectors
Traffic Selectors and narrowing allow two IKE peers to mutually agree
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
intended to be for another host. This is especially problematic when
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
source IP of their IKE packets. A rogue IKE peer could use malicious
Traffic Selectors to obtain access to traffic that the host never
intended to hand out. 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
to unauthenticated IKE clients, as described in Section 2.19 of
[RFC7296]. Implementations may also use other techniques, such as
internal NAT and connection tracking.
Implementations MAY force unauthenticated IKE peers to single host-
to-host IPsec SAs. When using IPv6 it is not always possible, so in
this case implementations MUST be able to assign full /64 address
block to the peer as described in [RFC5739], even if it is not
authenticated.
3. Security Considerations 3. Security Considerations
If both peers use the NULL Authentication Method, the entire key If authenticated IKE sessions are possible between the peers, then
exchange becomes unauthenticated. This makes the IKE session unauthenticated IKE SHOULD NOT be used, unless implementations make
vulnerable to active Man-in-the-Middle Attacks. Un-authenticated IKE sure to keep authenticated and unauthenticated IKE sessions separate,
sessions MUST only attempted when authenticated IKE sessions are not and has policy rules to specify when to use which IKE session. See
possible for the remote host and the only alternative would be to [RFC7435] for details.
send plaintext. See [RFC7435] for details.
Implementations SHOULD use the ID_NULL Identity Type with the NULL If both peers use NULL Authentication, the entire key exchange
Authenticated Method. If an un-authenticated remote IKE peer becomes unauthenticated. This makes the IKE session vulnerable to
presents an Identity Type different from ID_NULL, the Identification active Man-in-the-Middle Attacks.
Payload data MUST NOT be used for anything except logging.
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 compromises the client's anonimity. This should be avoided Method may compromise the client's anonimity in case of an active
for regular operation but could be temporarilly enabled, for example MITM attack.
to aid with troubleshooting diagnostics. Sending an unverifiable
identification for any other purpose is strongly discouraged as it
leads to a false sense of security,
IKE implementations without the NULL Authentication Method have IKE implementations without NULL Authentication have always performed
always performed mutual authentication and were not designed for use mutual authentication and were not designed for use with
with un-authenticated IKE peers. Implementations might have made unauthenticated IKE peers. Implementations might have made
assumptions that are no longer valid. Furthermore, the host itself assumptions that are no longer valid. Furthermore, the host itself
might have made trust assumptions or may not be aware of the network might have made trust assumptions or may not be aware of the network
topology changes that resulted from IPsec SAs from un-authenticated topology changes that resulted from IPsec SAs from unauthenticated
IKE peers. IKE peers.
3.1. Audit trail and peer identification 3.1. Audit trail and peer identification
An established IKE session is no longer guaranteed to provide a An established IKE session is no longer guaranteed to provide a
verifiable (authenticated) entity known to the system or network. verifiable (authenticated) entity known to the system or network.
Implementations that add the NULL Authentication Method should audit Implementers that implement NULL Authentication should audit their
their implementation for any assumptions that depend on IKE peers implementation for any assumptions that depend on IKE peers being
being "friendly", "trusted" or "identifiable". "friendly", "trusted" or "identifiable".
3.2. Resource management and robustness 3.2. Resource management and robustness
Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial
of Service" attacks by issuing COOKIES in response to resource of Service" attacks by issuing COOKIES in response to resource
consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION]
offers additional counter-meassures 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 un-authenticated IKE peers. An attacker using the NULL allow unauthenticated IKE peers. An attacker using NULL
Authentication Method 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 the Authenticaion distinguished from authenticated IKE peers by having used NULL
Method Authentication.
While implementations should have been written to account for abusive While implementations should have been written to account for abusive
authenticated clients, any omission or error in handling abusive authenticated clients, any omission or error in handling abusive
clients may have gone unnoticed because abusive clients has been a clients may have gone unnoticed because abusive clients has been a
rare or non-existent problem. When enabling un-authenticated IKE rare or non-existent problem. When enabling unauthenticated IKE
peers, these implementation omissions and errors will be found and peers, these implementation omissions and errors will be found and
abused by attackers. For example, an un-authenticated IKE peer could abused by attackers. For example, an unauthenticated IKE peer could
send an abusive amount of Liveness probes or Delete requests. send an abusive amount of Liveness probes or Delete requests.
3.3. IKE configuration selection 3.3. IKE configuration selection
Combining authenticated and un-authenticated 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 un-authentcated peers). An un-authenticated 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 IPsec SAs of an authenticated IKE and MUST NOT be able to replace the Child SAs of an authenticated IKE
peer. peer.
If an IKE peer receives an IKE_AUTH exchange requesting a NULL
Authentication Method from an IP address that matches a configured
connection for an authenticated IKE session, it MUST reject the
IKE_AUTH exchange by sending an AUTHENTICATION_FAILED notification.
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 circument 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 encrypted ESP (protocol 50) or ESPinUDP (UDP
port 4500) packets do not match the packet filters defined. IKE port 4500) packets do not match the packet filters defined. IKE
peers supporting un-authenticated IKE MUST pass all decrypted traffic peers supporting unauthenticated IKE MUST pass all decrypted traffic
through the same packet filters and security mechanisms as plaintext through the same packet filters and security mechanisms as plaintext
traffic. traffic.
Traffic Selectors and narrowing allow two IKE peers to mutually agree
on a traffic range for an IPsec SA. An un-authenticated peer MUST
NOT be allowed to use this mechanism to steal traffic that an IKE
peer intended to be for another host. This is especially problematic
when 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 source IP of their IKE packets. A rogue IKE peer could use
malicious Traffic Selectors to obtain access to traffic that the host
never intended to hand out. 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 of the ways to achive that is to always assign internal IP
addresses to un-authenticated IKE clients, as described in Section
2.19 of [RFC7296]. Implementations may also use other techniques,
such as internal NAT and connection tracking. Implementations MAY
force un-authenticated IKE peers to single host-to-host IPsec SAs.
3.5. Priviledged IKE operations
Some IKE features are not appropriate for un-authenticated IKE peers
and should be restricted or forbidden.
4. Acknowledgments 4. Acknowledgments
The authors would like to thank Yaron Sheffer and Tero Kivinen for The authors would like to thank Yaron Sheffer and Tero Kivinen for
their reviews and valuable comments. their reviews and valuable comments.
5. IANA Considerations 5. IANA Considerations
This document defines a new entry in the "IKEv2 Authentication This document defines a new entry in the "IKEv2 Authentication
Method" registry: Method" registry:
13 NULL Authentication Method 13 NULL Authentication
This document also defines a new entry in the "IKEv2 Identification This document also defines a new entry in the "IKEv2 Identification
Payload ID Types" registry: Payload ID Types" registry:
13 ID_NULL 13 ID_NULL
6. References 6. References
6.1. Normative References 6.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, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010.
[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, October 2014.
6.2. Informative References 6.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, May 2014.
[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, December 2014.
[AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work
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.
Authors' Addresses Authors' Addresses
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
 End of changes. 42 change blocks. 
143 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/