draft-ietf-ipsecme-ikev2-null-auth-04.txt   draft-ietf-ipsecme-ikev2-null-auth-05.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: August 24, 2015 Red Hat Expires: September 27, 2015 Red Hat
February 20, 2015 March 26, 2015
The NULL Authentication Method in IKEv2 Protocol The NULL Authentication Method in IKEv2 Protocol
draft-ietf-ipsecme-ikev2-null-auth-04 draft-ietf-ipsecme-ikev2-null-auth-05
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 August 24, 2015. This Internet-Draft will expire on September 27, 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 5, line 45 skipping to change at page 5, line 45
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 an 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 acceptable cases to use a non-null identity type and value with of cases where a non-null identity type and value with NULL
NULL Authentication are logging, troubleshooting or in scenarios Authentication can be used are logging, troubleshooting and in
where authentication takes place out of band after the IKE SA is scenarios where authentication takes place out of band after the IKE
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 Section
2.4 for details). 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.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
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 weight 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.4 of [RFC4301] must be updated.
The NULL authentication needs to be added as one of supported NULL authentication needs to be added as one of supported
authentication methods. This method does not have any authentication authentication methods. This method does not have any authentication
data. To add support for ID_NULL, it needs to be included into the data. To add support for ID_NULL, it needs to be included into the
list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The
matching rule for ID_NULL is just whether this type is used, i.e. no matching rule for ID_NULL consists only of whether this type is used,
actual ID 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 Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched
against the SPD entries. When using the NULL authentication method against the SPD entries. When using the NULL authentication method
those matching rules MUST include matching of a new flag in the SPD those matching rules MUST include matching of a new flag in the SPD
entry specifying whether unauthenticated users are allowed to use entry specifying whether unauthenticated users are allowed to use
that entry. I.e. each SPD entry needs to be augmented to have flag that 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, specifying whether it can be used with NULL authentication or not,
and only those rules explictly having that flag turned on can be used and only those rules that explictly have that flag turned on can be
with unauthenticated connections. used with unauthenticated connections.
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 42 skipping to change at page 7, line 43
intended to hand out. Implementations SHOULD restrict and isolate intended to hand out. Implementations SHOULD restrict and isolate
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 it is not always possible, so in to-host IPsec SAs. When using IPv6 this is not always possible, so
this case implementations MUST be able to assign full /64 address 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 block to the 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 used for that traffic selector range. When mixing authenticated be allowed for that traffic selector range. When mixing
and unauthenticated IKE with the same peer, policy rules should authenticated and unauthenticated IKE with the same peer, policy
ensure the highest level of security will be used to protect the rules should ensure the highest level of security will be used to
communication between the two peers. See [RFC7435] for details. protect the communication between the two peers. See [RFC7435] for
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 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 that are no longer valid. Furthermore, the host itself assumptions remote peers are identified. With NULL Authentication
these assumptions 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 unauthenticated 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 With NULL Authentication an established IKE session is no longer
verifiable (authenticated) entity known to the system or network. guaranteed to provide a verifiable (authenticated) entity known to
Implementers that implement NULL Authentication should audit their the system or network. Implementers that implement NULL
implementation for any assumptions that depend on IKE peers being Authentication should ensure their implementation does not make any
"friendly", "trusted" or "identifiable". assumptions that depend on IKE peers being "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-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 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 unauthenticated IKE rare or non-existent problem. When adding support for
peers, these implementation omissions and errors will be found and unauthenticated IKE peers, these implementation omissions and errors
abused by attackers. For example, an unauthenticated IKE peer could will be found and abused by attackers. For example, an
send an abusive amount of Liveness probes or Delete requests. 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. 15 change blocks. 
32 lines changed or deleted 37 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/