Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Standards Track                        October 22, 2014                              P. Wouters
Expires: April 25, July 17, 2015                                           Red Hat
                                                        January 13, 2015

            The NULL Authentication Method in IKEv2 Protocol
                 draft-ietf-ipsecme-ikev2-null-auth-01
                 draft-ietf-ipsecme-ikev2-null-auth-02

Abstract

   This document introduces specifies the NULL authentication method Authentication Method and the
   ID_NULL Identification Payload ID Type for the IKEv2 Protocol.  This method provides a way
   allows two IKE peers to omit establish single-side authenticated or mutual
   un-authenticated IKE sessions for those use cases where a peer authentication in
   the IKEv2.  It may is
   unwilling or unable to authenticate itself.  This ensures IKEv2 can
   be used for Opportunistic Security (also known as Opportunsitic
   Encryption) to preserve anonymity of or in the
   situations, where no trust relationship exists between defend against Pervasive Monitoring attacks without
   the parties. need to sacrifice anonimity.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, July 17, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Using the NULL Authentication Method . . . . . . . . . . . . .  4
     2.1.  Authentication Payload . . . . . . . . . . . . . . . . . .  4
     2.2.  Identity Payload . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  INITIAL_CONTACT Notification . . . . . . . . . . . . . . .  4  5
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Audit trail and peer identification  . . . . . . . . . . .  6
     3.2.  Resource management and robustness . . . . . . . . . . . .  6
     3.3.  IKE configuration selection  . . . . . . . . . . . . . . .  7
     3.4.  Networking topology changes  . . . . . . . . . . . . . . .  7
     3.5.  Priviledged IKE operations . . . . . . . . . . . . . . . .  8
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . .  9
   Author's Address . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . 10 . . . . . . . . . . . . . . 12

1.  Introduction

   The Internet Key Exchange Protocol version 2 (IKEv2), specified in
   [IKEv2],
   [RFC7296], provides a way for two parties to perform an authenticated
   key exchange.  Mutual authentication is mandatory in the IKEv2, so that
   each party must be authenticated by the other.  However  While the authentication methods, methods used by the peers, need not peers can
   be different, there is no method for one or both parties to remain
   unauthenticated and anonymous.  This document extends the same.
   authentication methods to support unauthenticated key exchanges.

   In some situations mutual authentication is undesirable, superfluous
   or impossible.  For example:  The following three examples illustratate these un-
   authenticated use cases:

   o  User  A user wants to get establish an anonymous access secure connection to some a
      server.  In this situation he/she the user should be able to authenticate
      the server, but server without presenting or authenticating to
      leave out his/her the server with
      their own authentication to preserve anonymity.  In
      this identity.  This case one-way uses a single-sided authentication
      of the responder is desirable. responder.

   o  Sensor,  A sensor that sleeps most of the time, but periodically wakes up,
      makes some measurment up from a suspended state wants
      to send a measurement (e.g. temperature) and sends the results to
      some a collecting server.
      The sensor must be authenticated by the server to ensure
      authenticity of the measurment, but the server need sensor does not be
      authenticated by need to
      authenticate the sensor.  In this server.  This case one-way uses a single-sided
      authentication of the initiator is sufficient. initiator.

   o  Two peers without any trust relationship want wish to get some level of
      security defend against
      widespread pervasive monitoring attacks as described in their communications. [RFC7258].
      Without a trust relationship they relationship, the peers cannot prevent active Man-in-the-Middle attacks, but it authenticate each
      other.  Opportunistic Security [RFC7435] states that un-
      authenticated encrypted communication is prefered over cleartext
      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
      possible launch an Man-in-the-Middle
      attack to prevent passive eavesdropping with opportunistic
      encryption.  In this obtain access to the decrypted communication.  This case they can use unauthenticated
      uses a fully anonymous un-authenticated key exchange.

   To meet these needs the this document introduces the NULL authentication
   method, which is a "dummy" method, that provides no authentication. and the ID_NULL identity type.  This allows an IKE peer to
   explicitly indicate to the other side that it is unwilling or unable to certify its
   identity.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Using the NULL Authentication Method

   In IKEv2 IKEv2, each peer independently selects the method to authenticate
   itself to the other side.  It means that any of the peers  A peer may choose to omit its refrain from
   authentication by using the NULL authentication method. Authentication Method.  If it is not acceptable for a peer
   that requires authentiation receives an AUTH payload containing the other peer,
   NULL Authentication Method type, it MUST return an
   AUTHENTICATION_FAILED notification.  Note, that when the  If an initiator uses EAP, the
   responder MUST NOT use the NULL authentication method Authentication Method (in conformance
   with the section 2.16 of [IKEv2]). [RFC7296]).

   The NULL authentication method Authentication Method affects how the Authentication and the
   Identity payloads are formed in the IKE_AUTH exchange.

2.1.  Authentication Payload

   Despite the fact that the

   The NULL authentication method provides no
   authentication, the Authentication Method still requires a properly formed AUTH
   payload must still to be present in the IKE_AUTH exchange messages and must be properly formed, messages, as it the AUTH
   payload cryptographically links the IKE_SA_INIT exchange messages
   with the other messages sent over this IKE SA.

   With

   When using the NULL authentication method Authentication Method, the content of the AUTH
   payload
   MUST be is computed using the syntax for of pre-shared secret
   authentication, described in Section 2.15 of [IKEv2]. [RFC7296].  The values
   SK_pi and SK_pr MUST be are used as shared secrets for the content of the
   AUTH payloads generated by the initiator and the responder
   respectively.  Note,  Note that this is exactly identical to how the content of the
   two last AUTH payloads is calculated generated for non-key generating the non-key-generating EAP method
   methods (see Section 2.16 of [IKEv2] [RFC7296] for details).

   The KEv2 Authentication Method value for the the NULL authentication method Authentication
   Method is <TBA by IANA>. 13.

2.2.  Identity Payload

   The NULL authentication method provides no authentication of

   When a remote peer is not authenticated, any ID presented in the
   party using it.  For that reason
   Identification Data field of the Identity payload content Identification Payload cannot be verified by the peer
   validated and MUST be ignored by 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 IKE. peer.

   This specification defines a new ID Type - of ID_NULL, which is intended
   to SHOULD
   only be used with the NULL authentication method to explicitely
   indicate anonymity of the peer.  This ID Type MUST NOT be used with
   authentication methods, that provide real authentication. Authentication Method.  The Identification
   Data in Identity payload for field of the ID_NULL type Identification Payload MUST be
   absent and the empty.

   The IKEv2 Identification Payload ID Type for ID_NULL is set to <TBA by IANA>. 13.

2.3.  INITIAL_CONTACT Notification

   The identity of the peer which uses the NULL authentication method Authentication Method
   cannot be used to distinguish betweed between IKE SAs created by different
   peers, because the peers may use the same identity (for example all
   endpoints which use identity of type ID_NULL).
   peers.  For that reason the INITIAL_CONTACT notification notifications MUST be
   ignored if it is present by the
   party for IKE SAs using the NULL authentication method.  To find out stale Authentication Method.

   When a new IKE
   SAs in this situation, SA is established using the NULL Authentication
   Method, implementations should MAY perform a Liveness Check on all other IKE
   SAs with that were established using the same peer idenity as NULL Authentication Method.  To
   mitigate the newly created IKE
   SA.

3.  Security Considerations

   IKEv2 protocol provides mutual authentication 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 peers.  If one
   peer uses
   particular SA is alive.  This information may include the NULL authentication method, then this peer cannot be
   authenticated by recent
   receipt of cryptographically protected message on the other side, and it makes authentication in IKEv2
   to be one-way. IKE SA or any
   of its Child SAs, or a successfull Liveness Check that was performed
   recently.

3.  Security Considerations

   If both peers use the NULL Authentication method, Method, the entire key
   exchange becomes unauthenticated, that unauthenticated.  This makes it susceptible the IKE session
   vulnerable to active
   attacks.  For that reason completely unauthenticated Man-in-the-Middle Attacks.  Un-authenticated IKE SA must be
   used
   sessions MUST only if attempted when authenticated IKE sessions are not
   possible for the remote host and the only alternative is would be to
   send plaintext.

   The identity of the peer using  See [RFC7435] for details.

   Implementations SHOULD use the ID_NULL Identity Type with the NULL authenticated method
   cannot be verified by
   Authenticated Method.  If an un-authenticated remote IKE peer
   presents an Identity Type different from ID_NULL, the other side and, therefore, Identification
   Payload data MUST NOT be used
   neither for authorization purposes, nor anything except logging.

   Using an ID Type other than ID_NULL with the NULL Authentication
   Method compromises the client's anonimity.  This should be avoided
   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,

   IKE implementations without the NULL Authentication Method have
   always performed mutual authentication and were not designed for policy decisions.  All
   peers who use
   with un-authenticated IKE peers.  Implementations might have made
   assumptions that are no longer valid.  Furthermore, the host itself
   might have made trust assumptions or may not be aware of the network
   topology changes that resulted from IPsec SAs from un-authenticated
   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 Authenticated 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 considered by
   the other party as "guests" able to reach resources only meant for authenticated IKE peers
   and get the least possible privileges.
   Implementations are advised MUST NOT be able to use the ID_NULL Identity Type with replace the
   NULL IPsec SAs of an authenticated method. IKE
   peer.

   If endpoint 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 request host relies on packet filters or firewall software to create protect
   itself, establishing an unauthenticated IKE SA
   from and installing an IPsec SA might
   accidentally circument these packet filters and firewall
   restrictions, as the IP address, which is configured on encrypted ESP (protocol 50) or ESPinUDP (UDP
   port 4500) packets do not match the endpoint to be
   authenticated, packet filters defined.  IKE
   peers supporting un-authenticated IKE MUST pass all decrypted traffic
   through the request SHOULD 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 rejected.

   If the allowed to use this mechanism to steal traffic that an IKE
   peer uses the NULL authenticated method, then 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 content source IP of
   its their IKE packets.  A rogue IKE peer could use
   malicious Traffic Selector payloads must be treated with care.  In
   particular, implementations are advised not Selectors to trust blindly obtain access to traffic that the
   public IP addresses 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 peer put into TS payload are really belong ways to
   it.  It achive that is RECOMMENDED for security gateways to always assign internal IP
   addresses to unauthenticated clients un-authenticated IKE clients, as described in Section
   2.19 of [IKEv2]. [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

   The author authors would like to thank Paul Wouters, Yaron Sheffer and Tero Kivinen for
   their reviews and valuable comments.

5.  IANA Considerations

   This document defines a new value entry in the "IKEv2 Authentication
   Method" registry:

     <TBA>

     13       NULL Authentication Method

   It

   This document also defines a new value entry in the "IKEv2 Identification
   Payload ID Types" registry:

     <TBA>

     13       ID_NULL

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IKEv2]

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 STD 79, RFC 7296, October 2014.

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), June October 2014.

Author's Address

Authors' Addresses

   Valery Smyslov
   ELVIS-PLUS
   PO Box 81
   Moscow (Zelenograd)  124460
   Russian Federation

   Phone: +7 495 276 0211
   Email: svan@elvis.ru

   Paul Wouters
   Red Hat

   Email: pwouters@redhat.com