draft-ietf-ipsecme-ikev2-null-auth-01.txt   draft-ietf-ipsecme-ikev2-null-auth-02.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track October 22, 2014 Intended status: Standards Track P. Wouters
Expires: April 25, 2015 Expires: July 17, 2015 Red Hat
January 13, 2015
The NULL Authentication Method in IKEv2 Protocol The NULL Authentication Method in IKEv2 Protocol
draft-ietf-ipsecme-ikev2-null-auth-01 draft-ietf-ipsecme-ikev2-null-auth-02
Abstract Abstract
This document introduces the NULL authentication method for the IKEv2 This document specifies the NULL Authentication Method and the
Protocol. This method provides a way to omit peer authentication in ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This
the IKEv2. It may be used to preserve anonymity of or in the allows two IKE peers to establish single-side authenticated or mutual
situations, where no trust relationship exists between the parties. un-authenticated IKE sessions for those use cases where a peer is
unwilling or unable to authenticate itself. This ensures IKEv2 can
be used for Opportunistic Security (also known as Opportunsitic
Encryption) to defend against Pervasive Monitoring attacks without
the need to sacrifice anonimity.
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 April 25, 2015. This Internet-Draft will expire on July 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . 4
2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4
2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 4 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Audit trail and peer identification . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.2. Resource management and robustness . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 3.3. IKE configuration selection . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Networking topology changes . . . . . . . . . . . . . . . 7
3.5. Priviledged IKE operations . . . . . . . . . . . . . . . . 8
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Internet Key Exchange Protocol version 2 (IKEv2), specified in The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[IKEv2], provides a way for two parties to perform authenticated key [RFC7296], provides a way for two parties to perform an authenticated
exchange. Mutual authentication is mandatory in the IKEv2, so that key exchange. While the authentication methods used by the peers can
each party must be authenticated by the other. However the be different, there is no method for one or both parties to remain
authentication methods, used by the peers, need not be the same. unauthenticated and anonymous. This document extends the
authentication methods to support unauthenticated key exchanges.
In some situations mutual authentication is undesirable, superfluous In some situations mutual authentication is undesirable, superfluous
or impossible. For example: or impossible. The following three examples illustratate these un-
authenticated use cases:
o User wants to get anonymous access to some server. In this o A user wants to establish an anonymous secure connection to a
situation he/she should be able to authenticate the server, but to server. In this situation the user should be able to authenticate
leave out his/her own authentication to preserve anonymity. In the server without presenting or authenticating to the server with
this case one-way authentication of the responder is desirable. their own identity. This case uses a single-sided authentication
of the responder.
o Sensor, that sleeps most of the time, but periodically wakes up, o A sensor that periodically wakes up from a suspended state wants
makes some measurment (e.g. temperature) and sends the results to to send a measurement (e.g. temperature) to a collecting server.
some server. The sensor must be authenticated by the server to The sensor must be authenticated by the server to ensure
ensure authenticity of the measurment, but the server need not be authenticity of the measurment, but the sensor does not need to
authenticated by the sensor. In this case one-way authentication authenticate the server. This case uses a single-sided
of the initiator is sufficient. authentication of the initiator.
o Two peers without any trust relationship want to get some level of o Two peers without any trust relationship wish to defend against
security in their communications. Without trust relationship they widespread pervasive monitoring attacks as described in [RFC7258].
cannot prevent active Man-in-the-Middle attacks, but it is still Without a trust relationship, the peers cannot authenticate each
possible to prevent passive eavesdropping with opportunistic other. Opportunistic Security [RFC7435] states that un-
encryption. In this case they can use unauthenticated key authenticated encrypted communication is prefered over cleartext
exchange. communication. The peers want to use IKE to setup an un-
authenticated encrypted connection, that gives them protection
against pervasive monitoring attacks. An attacker that is able
and willing to send packets can still launch an Man-in-the-Middle
attack to obtain access to the decrypted communication. This case
uses a fully anonymous un-authenticated key exchange.
To meet these needs the document introduces the NULL authentication To meet these needs this document introduces the NULL authentication
method, which is a "dummy" method, that provides no authentication. method, and the ID_NULL identity type. This allows an IKE peer to
This allows peer to explicitly indicate to the other side that it is explicitly indicate that it is unwilling or unable to certify its
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. It means that any of the peers may choose itself to the other side. A peer may choose to refrain from
to omit its authentication by using the NULL authentication method. authentication by using the NULL Authentication Method. If a peer
If it is not acceptable for the other peer, it MUST return that requires authentiation receives an AUTH payload containing the
AUTHENTICATION_FAILED notification. Note, that when the initiator NULL Authentication Method type, it MUST return an
uses EAP, the responder MUST NOT use the NULL authentication method AUTHENTICATION_FAILED notification. If an initiator uses EAP, the
(in conformance with the section 2.16 of [IKEv2]). responder MUST NOT use the NULL Authentication Method (in conformance
with the section 2.16 of [RFC7296]).
The NULL authentication method affects how the Authentication and the The NULL Authentication Method affects how the Authentication and the
Identity payloads are formed in the IKE_AUTH exchange. Identity payloads are formed in the IKE_AUTH exchange.
2.1. Authentication Payload 2.1. Authentication Payload
Despite the fact that the NULL authentication method provides no The NULL Authentication Method still requires a properly formed AUTH
authentication, the AUTH payload must still be present in the payload to be present in the IKE_AUTH exchange messages, as the AUTH
IKE_AUTH exchange messages and must be properly formed, as it 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.
With the NULL authentication method the content of the AUTH payload When using the NULL Authentication Method, the content of the AUTH
MUST be computed using the syntax for pre-shared secret payload is computed using the syntax of pre-shared secret
authentication, described in Section 2.15 of [IKEv2]. The values authentication, described in Section 2.15 of [RFC7296]. The values
SK_pi and SK_pr MUST be used as shared secrets for the content of the SK_pi and SK_pr are used as shared secrets for the content of the
AUTH payloads generated by the initiator and the responder AUTH payloads generated by the initiator and the responder
respectively. Note, that this is exactly how the content of the two respectively. Note that this is identical to how the content of the
last AUTH payloads is calculated for non-key generating EAP method two last AUTH payloads is generated for the non-key-generating EAP
(see Section 2.16 of [IKEv2] for details). The value for the the methods (see Section 2.16 of [RFC7296] for details).
NULL authentication method is <TBA by IANA>.
The KEv2 Authentication Method value for the NULL Authentication
Method is 13.
2.2. Identity Payload 2.2. Identity Payload
The NULL authentication method provides no authentication of the When a remote peer is not authenticated, any ID presented in the
party using it. For that reason the Identity payload content cannot Identification Data field of the Identification Payload cannot be
be verified by the peer and MUST be ignored by the IKE. validated and MUST be ignored. A new Identification Payload ID Type
is introduced to avoid the need of sending a bogus ID Type with
placeholder data. Furthermore, sending a traditional ID field might
unwittingly compromise the anonimity of the peer.
This specification defines new ID Type - ID_NULL, which is intended This specification defines a new ID Type of ID_NULL, which SHOULD
to be used with the NULL authentication method to explicitely only be used with the NULL Authentication Method. The Identification
indicate anonymity of the peer. This ID Type MUST NOT be used with Data field of the Identification Payload MUST be empty.
authentication methods, that provide real authentication. The
Identification Data in Identity payload for the ID_NULL type MUST be The IKEv2 Identification Payload ID Type for ID_NULL is 13.
absent and the ID Type is set to <TBA by IANA>.
2.3. INITIAL_CONTACT Notification 2.3. INITIAL_CONTACT Notification
The identity of the peer which uses the NULL authentication method The identity of the peer which uses the NULL Authentication Method
cannot be used to distinguish betweed IKE SAs created by different cannot be used to distinguish between IKE SAs created by different
peers, because the peers may use the same identity (for example all peers. For that reason the INITIAL_CONTACT notifications MUST be
endpoints which use identity of type ID_NULL). For that reason the ignored for IKE SAs using the NULL Authentication Method.
INITIAL_CONTACT notification MUST be ignored if it is present by the
party using the NULL authentication method. To find out stale IKE When a new IKE SA is established using the NULL Authentication
SAs in this situation, implementations should perform Liveness Check Method, implementations MAY perform a Liveness Check on all other IKE
on all IKE SAs with the same peer idenity as the newly created IKE SAs that were established using the NULL Authentication Method. To
SA. mitigate the potential impact of sending Liveness Check messages on a
large number of IKE SAs, implementations are advised not to blindly
perform Liveness Check on every such SA, but to take into
considerations additional information, that may indicate that the
particular SA is alive. This information may include the recent
receipt of cryptographically protected message on the IKE SA or any
of its Child SAs, or a successfull Liveness Check that was performed
recently.
3. Security Considerations 3. Security Considerations
IKEv2 protocol provides mutual authentication of the peers. If one If both peers use the NULL Authentication Method, the entire key
peer uses the NULL authentication method, then this peer cannot be exchange becomes unauthenticated. This makes the IKE session
authenticated by the other side, and it makes authentication in IKEv2 vulnerable to active Man-in-the-Middle Attacks. Un-authenticated IKE
to be one-way. If both peers use the NULL Authentication method, key sessions MUST only attempted when authenticated IKE sessions are not
exchange becomes unauthenticated, that makes it susceptible to active possible for the remote host and the only alternative would be to
attacks. For that reason completely unauthenticated IKE SA must be send plaintext. See [RFC7435] for details.
used only if the alternative is to send plaintext.
The identity of the peer using the the NULL authenticated method Implementations SHOULD use the ID_NULL Identity Type with the NULL
cannot be verified by the other side and, therefore, MUST NOT be used Authenticated Method. If an un-authenticated remote IKE peer
neither for authorization purposes, nor for policy decisions. All presents an Identity Type different from ID_NULL, the Identification
peers who use the NULL Authenticated Method should be considered by Payload data MUST NOT be used for anything except logging.
the other party as "guests" and get the least possible privileges.
Implementations are advised to use the ID_NULL Identity Type with the
NULL authenticated method.
If endpoint receives a request to create an unauthenticated IKE SA Using an ID Type other than ID_NULL with the NULL Authentication
from the IP address, which is configured on the endpoint to be Method compromises the client's anonimity. This should be avoided
authenticated, the request SHOULD be rejected. for regular operation but could be temporarilly enabled, for example
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,
If the peer uses the NULL authenticated method, then the content of IKE implementations without the NULL Authentication Method have
its Traffic Selector payloads must be treated with care. In always performed mutual authentication and were not designed for use
particular, implementations are advised not to trust blindly that the with un-authenticated IKE peers. Implementations might have made
public IP addresses the peer put into TS payload are really belong to assumptions that are no longer valid. Furthermore, the host itself
it. It is RECOMMENDED for security gateways to always assign might have made trust assumptions or may not be aware of the network
internal IP addresses to unauthenticated clients as described in topology changes that resulted from IPsec SAs from un-authenticated
Section 2.19 of [IKEv2]. IKE peers.
3.1. Audit trail and peer identification
An established IKE session is no longer guaranteed to provide a
verifiable (authenticated) entity known to the system or network.
Implementations that add the NULL Authentication Method should audit
their implementation for any assumptions that depend on IKE peers
being "friendly", "trusted" or "identifiable".
3.2. Resource management and robustness
Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial
of Service" attacks by issuing COOKIES in response to resource
consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION]
offers additional counter-meassures in an attempt to distinguish
attacking IKE packets from legitimate IKE peers.
These defense mechanisms do not take into account IKE systems that
allow un-authenticated IKE peers. An attacker using the NULL
Authentication Method is a fully legitimate IKE peer that is only
distinguished from authenticated IKE peers by the Authenticaion
Method
While implementations should have been written to account for abusive
authenticated clients, any omission or error in handling abusive
clients may have gone unnoticed because abusive clients has been a
rare or non-existent problem. When enabling un-authenticated IKE
peers, these implementation omissions and errors will be found and
abused by attackers. For example, an un-authenticated IKE peer could
send an abusive amount of Liveness probes or Delete requests.
3.3. IKE configuration selection
Combining authenticated and un-authenticated IKE peers on a single
host can be dangerous, assuming the authenticated IKE peer gains more
or different access from non-authenticated peers (otherwise, why not
only allow un-authentcated peers). An un-authenticated IKE peer MUST
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
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
When a host relies on packet filters or firewall software to protect
itself, establishing an IKE SA and installing an IPsec SA might
accidentally circument these packet filters and firewall
restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP
port 4500) packets do not match the packet filters defined. IKE
peers supporting un-authenticated IKE MUST pass all decrypted traffic
through the same packet filters and security mechanisms as plaintext
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 author would like to thank Paul Wouters, Yaron Sheffer and Tero The authors would like to thank Yaron Sheffer and Tero Kivinen for
Kivinen for their reviews and valuable comments. their reviews and valuable comments.
5. IANA Considerations 5. IANA Considerations
This document defines new value in the "IKEv2 Authentication Method" This document defines a new entry in the "IKEv2 Authentication
registry: Method" registry:
<TBA> NULL Authentication Method 13 NULL Authentication Method
It also defines new value in the "IKEv2 Identification Payload ID This document also defines a new entry in the "IKEv2 Identification
Types" registry: Payload ID Types" registry:
<TBA> ID_NULL 13 ID_NULL
6. Normative References 6. 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.
[IKEv2] 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)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work (IKEv2)", STD 79, RFC 7296, October 2014.
in progress), June 2014.
Author's Address 6.2. Informative References
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, December 2014.
[DDOS-PROTECTION]
Nir, Y., "Protecting Internet Key Exchange (IKE)
Implementations from Distributed Denial of Service
Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in
progress), October 2014.
Authors' Addresses
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
Russian Federation Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
Paul Wouters
Red Hat
Email: pwouters@redhat.com
 End of changes. 35 change blocks. 
115 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/