[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-smyslov-ipsecme-ikev2-null-auth) 00 01 02 03 04 05 06 07 RFC 7619

Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Standards Track                        October 22, 2014
Expires: April 25, 2015


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

Abstract

   This document introduces the NULL authentication method for the IKEv2
   Protocol.  This method provides a way to omit peer authentication in
   the IKEv2.  It may be used to preserve anonymity of or in the
   situations, where no trust relationship exists between the parties.

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, 2015.

Copyright Notice

   Copyright (c) 2014 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.




Smyslov                  Expires April 25, 2015                 [Page 1]


Internet-Draft             NULL Auth in IKEv2               October 2014


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
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10






































Smyslov                  Expires April 25, 2015                 [Page 2]


Internet-Draft             NULL Auth in IKEv2               October 2014


1.  Introduction

   The Internet Key Exchange Protocol version 2 (IKEv2), specified in
   [IKEv2], provides a way for two parties to perform authenticated key
   exchange.  Mutual authentication is mandatory in the IKEv2, so that
   each party must be authenticated by the other.  However the
   authentication methods, used by the peers, need not be the same.

   In some situations mutual authentication is undesirable, superfluous
   or impossible.  For example:

   o  User wants to get anonymous access to some server.  In this
      situation he/she should be able to authenticate the server, but to
      leave out his/her own authentication to preserve anonymity.  In
      this case one-way authentication of the responder is desirable.

   o  Sensor, that sleeps most of the time, but periodically wakes up,
      makes some measurment (e.g. temperature) and sends the results to
      some server.  The sensor must be authenticated by the server to
      ensure authenticity of the measurment, but the server need not be
      authenticated by the sensor.  In this case one-way authentication
      of the initiator is sufficient.

   o  Two peers without any trust relationship want to get some level of
      security in their communications.  Without trust relationship they
      cannot prevent active Man-in-the-Middle attacks, but it is still
      possible to prevent passive eavesdropping with opportunistic
      encryption.  In this case they can use unauthenticated key
      exchange.

   To meet these needs the document introduces the NULL authentication
   method, which is a "dummy" method, that provides no authentication.
   This allows 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].











Smyslov                  Expires April 25, 2015                 [Page 3]


Internet-Draft             NULL Auth in IKEv2               October 2014


2.  Using the NULL Authentication Method

   In IKEv2 each peer independently selects the method to authenticate
   itself to the other side.  It means that any of the peers may choose
   to omit its authentication by using the NULL authentication method.
   If it is not acceptable for the other peer, it MUST return
   AUTHENTICATION_FAILED notification.  Note, that when the initiator
   uses EAP, the responder MUST NOT use the NULL authentication method
   (in conformance with the section 2.16 of [IKEv2]).

   The NULL 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 NULL authentication method provides no
   authentication, the AUTH payload must still be present in the
   IKE_AUTH exchange messages and must be properly formed, as it
   cryptographically links the IKE_SA_INIT exchange messages with the
   other messages sent over this IKE SA.

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

2.2.  Identity Payload

   The NULL authentication method provides no authentication of the
   party using it.  For that reason the Identity payload content cannot
   be verified by the peer and MUST be ignored by the IKE.

   This specification defines new ID Type - ID_NULL, which is intended
   to 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.  The
   Identification Data in Identity payload for the ID_NULL type MUST be
   absent and the ID Type is set to <TBA by IANA>.

2.3.  INITIAL_CONTACT Notification

   The identity of the peer which uses the NULL authentication method
   cannot be used to distinguish betweed IKE SAs created by different



Smyslov                  Expires April 25, 2015                 [Page 4]


Internet-Draft             NULL Auth in IKEv2               October 2014


   peers, because the peers may use the same identity (for example all
   endpoints which use identity of type ID_NULL).  For that reason the
   INITIAL_CONTACT notification MUST be ignored if it is present by the
   party using the NULL authentication method.  To find out stale IKE
   SAs in this situation, implementations should perform Liveness Check
   on all IKE SAs with the same peer idenity as the newly created IKE
   SA.












































Smyslov                  Expires April 25, 2015                 [Page 5]


Internet-Draft             NULL Auth in IKEv2               October 2014


3.  Security Considerations

   IKEv2 protocol provides mutual authentication of the peers.  If one
   peer uses the NULL authentication method, then this peer cannot be
   authenticated by the other side, and it makes authentication in IKEv2
   to be one-way.  If both peers use the NULL Authentication method, key
   exchange becomes unauthenticated, that makes it susceptible to active
   attacks.  For that reason completely unauthenticated IKE SA must be
   used only if the alternative is to send plaintext.

   The identity of the peer using the the NULL authenticated method
   cannot be verified by the other side and, therefore, MUST NOT be used
   neither for authorization purposes, nor for policy decisions.  All
   peers who use the NULL Authenticated Method should be considered by
   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
   from the IP address, which is configured on the endpoint to be
   authenticated, the request SHOULD be rejected.

   If the peer uses the NULL authenticated method, then the content of
   its Traffic Selector payloads must be treated with care.  In
   particular, implementations are advised not to trust blindly that the
   public IP addresses the peer put into TS payload are really belong to
   it.  It is RECOMMENDED for security gateways to always assign
   internal IP addresses to unauthenticated clients as described in
   Section 2.19 of [IKEv2].






















Smyslov                  Expires April 25, 2015                 [Page 6]


Internet-Draft             NULL Auth in IKEv2               October 2014


4.  Acknowledgments

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















































Smyslov                  Expires April 25, 2015                 [Page 7]


Internet-Draft             NULL Auth in IKEv2               October 2014


5.  IANA Considerations

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

     <TBA>       NULL Authentication Method

   It also defines new value in the "IKEv2 Identification Payload ID
   Types" registry:

     <TBA>       ID_NULL








































Smyslov                  Expires April 25, 2015                 [Page 8]


Internet-Draft             NULL Auth in IKEv2               October 2014


6.  Normative References

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

   [IKEv2]    Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work
              in progress), June 2014.










































Smyslov                  Expires April 25, 2015                 [Page 9]


Internet-Draft             NULL Auth in IKEv2               October 2014


Author's Address

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

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









































Smyslov                  Expires April 25, 2015                [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/