[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 6467

Network Working Group                                         T. Kivinen
Internet-Draft                                                 AuthenTec
Intended status: Informational                             July 25, 2011
Expires: January 26, 2012


                  Secure Password Framework for IKEv2
         draft-kivinen-ipsecme-secure-password-framework-01.txt

Abstract

   This document creates a generic way for Internet Key Exchange (IKEv2)
   to use any of the symmetric secure password authentication methods.
   There are multiple methods already specified in other documents and
   this document does not add new one.  This document specifies a common
   way so those methods can agree on which method is to be used in
   current connection.  This document also provides a common way to
   transmit secure password authentication method specific payloads
   between peers.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 26, 2012.

Copyright Notice

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




Kivinen                 Expires January 26, 2012                [Page 1]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


   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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Method Negotiation . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Generic Secure Password Method Payload . . . . . . . . . . . .  8
   4.  IKE_AUTH Exchange  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14




























Kivinen                 Expires January 26, 2012                [Page 2]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


1.  Introduction

   The IPsecME working group was chartered to provide IKEv2 ([RFC5996])
   a symmetric secure password authentication protocol that supports
   using of low-entropy shared secrets, but which is protected against
   off-line dictionary attacks without requiring the use of certificates
   or Extensible Authentication Protocol (EAP).  There are multiple of
   such methods and working group was supposed to pick one.
   Unfortunately the working group failed to get pick one protocol and
   there are multiple candidates going forward as separate documents.
   As each of those documents used different method to negotiate the use
   of the method and also used different payload formats it is very hard
   to try to make implementation where multiple of those systems could
   co-exists.

   This document does not create new protocol or even define a protocol
   which could be used to do anything.  This document describes a
   payload formats for IKEv2 which can be used for multiple secure
   password methods to do negotiation and transmit data so each
   different method can easily co-exists in the same implementation.

   This document consists of two major parts:

   o  How to negotiate which secure password method negotiation is used.

   o  How to transmit secure password method specific data between
      peers.

   The secure password methods are not usually meant to be used in the
   normal end user (remote access VPN) cases.  In such cases the EAP
   based authentication works fine and the asymmetric nature of the EAP
   does not matter.  In such scenarios the authentication is usually
   backed up with the back-end AAA-servers and other infrastructure.
   I.e. in such scenarios neither IKEv2 peers really knows the secret,
   in one end it is typed in by the user when it is needed, and on the
   other end it is authenticated by the back-end AAA-server.

   The new secure password methods are meant to be used in cases where
   such back-end AAA-infrastructure does not exists.  An example of such
   case could be authentication between two servers or routers.  These
   scenarios are usually symmetric: both peers know the shared secret,
   no back-end authentication servers are involved, and either end can
   initiate an IKEv2 connection.

   In many cases each implementation will only use only one of the
   proposed secure password authentication methods, but in many cases
   the implementations can include support for multiple methods even
   when only one of them will be used.  For example general purpose



Kivinen                 Expires January 26, 2012                [Page 3]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


   operating system running IPsec and IKEv2 and supporting secure
   password authentication methods to protect services provided by the
   system, might need to implement support for several of the different
   methods, and it is going to be up to the adminstrator which one of
   them are going to be used.  As the server might need to connect to
   multiple other servers, each implementing different set of methods,
   there might not be possible to pick one method that would be used in
   all cases.

   The secure password methods mostly keeps the existing IKEv2
   IKE_SA_INIT exchange and modify the IKE_AUTH authentication step.  As
   those methods do not want to add new round trips that means the
   negotiation of which of the secure password methods to use needs to
   happen during the IKE_SA_INIT.  As the identity of the other end is
   only provided inside the IKE_AUTH that means that the responder end
   needs to select the list of supported methods only based on the IP-
   address of the initiator.  This could lead in to the problems if only
   certain methods would be acceptable for certain identified peers.
   Fortunately as the authentication is done based on the shared secret
   shared between both peers, that shared-secret should be usable in all
   of the methods, thus remote peer usually does not need to restrict
   selection of the method based on the initiators identity only based
   on the supported methods and adminstrative policy.

   Also as the initiator already knows to which peer it is connecting to
   it can limit which methods it proposes for the other peer.  And as
   secure password methods are meant to be used in the symmetric cases,
   both end should have similar configuration, i.e. they have same
   shared-secret, and most likely both also have list of acceptable (or
   exactly one acceptable) authentication methods to be used.  This
   could also be interpreted that there is no need to support method
   negotiation as both ends can already see this from configuration.  On
   the other hand in most cases either end does not really care which of
   the method is used, they are willing to use any secure method other
   end supports.  In such cases the automatic negotiation provides a way
   to make the configuration easy, i.e. no need to pick one method to be
   used between the peers.

   The reason for the common IKEv2 payload to be used to transmit secure
   password method specific data between peers is that the payload type
   field in the IKEv2 is only 8-bit field, and 62.5% of the range is
   already reserved (50% to the private use numbers, and 12.5% to the
   IKEv1 payload numbers).  This leaves 95 usable numbers, where 16 is
   already in use.  The current secure password authentication methods
   already propose to consume five payload type numbers.  This 6% of the
   unallocated number space is not that big on itself, but nothing says
   there will be only the current three protocols
   ([I-D.harkins-ipsecme-spsk-auth], [I-D.kuegler-ipsecme-pace-ikev2],



Kivinen                 Expires January 26, 2012                [Page 4]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


   and [I-D.shin-augmented-pake]), and those five new payload types
   would already be 31% increase to the number of currently allocated
   payload types.
















































Kivinen                 Expires January 26, 2012                [Page 5]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


2.  Method Negotiation

   Because all of the methods modify the IKE_AUTH exchange, the
   negotiation of which secure password method is used needs to happen
   during the IKE_SA_INIT exchange.  The proposed negotiation exchange
   would be:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
       Flags: Initiator, Message ID=0),
       SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)]  -->

                      <--  HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
                               Flags: Response, Message ID=0),
                               SAr1, KEr, Nr, [CERTREQ],
                               [N(SECURE_PASSWORD_METHODS)]

   If the N(SECURE_PASSWORD_METHODS) Notify Payload is missing then
   normal IKEv2 authentication methods are used.  If the Notify Payloads
   are included then the negotiation of the secure password methods
   happens inside those payloads.

   As it might be possible that future secure password method will
   modify the IKE_AUTH payload in more substantial way, it is better
   that as a end result of the negotiation we have exactly one secure
   password method which will be used.  The initiator will know which
   methods are usable for him when talking to that responder, so
   initiator will send list of acceptable methods in its IKE_SA_INIT
   request.  The responder will pick exactly one method and put that to
   its response.

   The secure password methods are identified by the 16-bit IANA
   allocated numbers stored in to the Notify Payload notification data
   field.  If method supports multiple different password preprosessing
   methods each of those may be allocated a separate number from this
   space, or the method might do its own negotiation of the
   preprosessing method later.  As initiator has already selected the
   shared secret it will be using it will also know which kind of
   preprossing might be needed for it, so it should propose only those
   preprosessing methods suitable for the selected shared secret.  This
   means that allocating multiple IANA numbers for one secure password
   method one for each preprosessing method is recommended.

   The actual Notify Payload will look like this:






Kivinen                 Expires January 26, 2012                [Page 6]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |   SPI Size    |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Security Parameter Index (SPI)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Notification Data                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Protocol ID will be zero, and the SPI Size will also be zero,
   meaning that the SPI field will be empty.  The Notify Message Type
   will be TBD.

   The Notification Data contains the list of the 16-bit secure password
   method numbers:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Secure Password Method #1     | Secure Password Method #2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Secure Password Method #3     | ...                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The response Notify Payload contains exactly one 16-bit secure
   password method number inside the Notification Data field.


















Kivinen                 Expires January 26, 2012                [Page 7]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


3.  Generic Secure Password Method Payload

   This payload will contain the secure password payload specific data.
   The IKE_AUTH exchanges might have multiple of these inside, depending
   what is required and specified by the secure password method
   selected.  As the secure password method is already selected during
   the IKE_SA_INIT, there is no need to repeat the information of the
   selected secure password method anymore, thus this payload only
   contains the method specific data.  As some secure password methods
   do require multiple different payloads they are assumed to include
   their method specific payload type inside the payload, for example
   inside the first octect of the data, but this is method specific, and
   method is free to format the payload data as it feels like.

   The generic secure passwod method payload will look like this:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~          Secure Password Method Specific Data                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Payload Type for this payload is TBD, and the name used later in
   this document is GSPM Payload.

   If the method uses secure password method specific payload sub-types
   inside the generic secure password method payload the format will be
   something like this:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SPMS Subtype  |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   ~          Secure Password Method Specific Data                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   But this picture is here only for illustrative purposes, the secure
   password method will be defining the exact format of the payload
   contents.



Kivinen                 Expires January 26, 2012                [Page 8]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


4.  IKE_AUTH Exchange

   As the negotiation happens during the IKE_SA_INIT the secure password
   methods may modify the IKE_AUTH exchange if needed.  To make
   implementing multiple methods easy it would be recommended that the
   IKE_AUTH exchange is not to be modified unnecessarely.  Adding zero,
   one or multiple Generic Secure Password Method Payloads to each
   exchange is needed, as is the modification how the AUTH payload is
   calculated, but all other changes should be kept minimal.

   The IKE_AUTH exchange should look bit like when EAP is used, meaning
   that the first request includes IDi, SAi2, TSi, TSr, and some number
   of GSPM payloads.  The response to that should include IDr and again
   some number of GSPM payloads.  There may be multiple exchanges each
   consisting of some number of GSPM payloads, and finally when
   authentication is done there should be one final exchange where the
   request includes the AUTH payload (along with some number of GSPM
   payloads) and the response contains AUTH, SAr2, TSi, TSr and some
   number of GSPM payloads.  The number of GSPM payloads is up to the
   secure password method, but usually will less than 3, but it might be
   more depending on the method.

   The AUTH payload calculation should include all the same data that is
   normally included in addition to the extra data needed by the secure
   password method.  The secure password method needs to define how the
   AUTH payload is calculated.

   As the AUTH payload calculation is changed the secure payload method
   should not use any of the existing authentication methods numbers in
   the AUTH Payload Auth Method field, but instead use the number
   allocated in this document.  This number is meant to be used by all
   secure password authentication methods.



















Kivinen                 Expires January 26, 2012                [Page 9]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


   Initiator                         Responder
   -------------------------------------------------------------------
   HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
       Flags: Initiator, Message ID=1),
       SK {IDi, [CERTREQ,]
           GSPM, [GSPM, ...,]
           [IDr,] SAi2,
           TSi, TSr}  -->

                     <--  HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
                                 Response, Message ID=1),
                                 SK {IDr, [CERT,]
                                     GSPM, [GSPM, ...]}

   HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
       Flags: Initiator, Message ID=2),
       SK {GSPM, [GSPM, ...,]}  -->

                     <--  HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
                                 Response, Message ID=2),
                                 SK {GSPM, [GSPM, ...]}
   ...

   HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
       Flags: Initiator, Message ID=x),
       SK {[GSPM, ...,], AUTH}  -->

                     <--  HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
                                 Response, Message ID=x),
                                 SK {[GSPM, ...,] AUTH, SAr2,
                                     TSi, TSr}

   Note that the number of the GSPM payloads and other payloads in each
   packet will be defined only by the secure password method
   documentation, and pictures in this document are only for
   illustrative purposes.















Kivinen                 Expires January 26, 2012               [Page 10]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


5.  Security Considerations

   As this document does not describe exact protocol the security
   considerations are not really relevant.  The secure password method
   document using payload types described here needs to describe the
   security properties of the protocol it describes.













































Kivinen                 Expires January 26, 2012               [Page 11]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


6.  IANA Considerations

   This allocates one new IKEv2 "Notify Messages Types - Status Types":

   TBD   SECURE_PASSWORD_METHODS

   This allocates one new "IKEv2 Authentication Method" number:

   TBD   Secure Password Authentication Method

   This document also adds one new "IKEv2 Payload Types":

   TBD   Generic Secure Password Method      GSPM

   This document creates new IANA registry "IKEv2 Secure Password
   Methods":

   0            RESERVED

   Values 1-1024 are reserved to IANA.  Values 1024-65535 are for
   private use among mutually consenting parties.  Changes and additions
   to this registry is by expert review.





























Kivinen                 Expires January 26, 2012               [Page 12]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


7.  References

7.1.  Normative References

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

7.2.  Informative References

   [I-D.harkins-ipsecme-spsk-auth]
              Harkins, D., "Secure PSK Authentication for IKE",
              draft-harkins-ipsecme-spsk-auth-04 (work in progress),
              April 2011.

   [I-D.kuegler-ipsecme-pace-ikev2]
              Kuegler, D. and Y. Sheffer, "Password Authenticated
              Connection Establishment with IKEv2",
              draft-kuegler-ipsecme-pace-ikev2-06 (work in progress),
              March 2011.

   [I-D.shin-augmented-pake]
              Shin, S. and K. Kobara, "Most Efficient Augmented
              Password-Only Authentication and Key Exchange for IKEv2",
              draft-shin-augmented-pake-08 (work in progress),
              July 2011.

























Kivinen                 Expires January 26, 2012               [Page 13]

Internet-Draft     Secure Password Framework for IKEv2         July 2011


Author's Address

   Tero Kivinen
   AuthenTec
   Eerikinkatu 28
   HELSINKI  FI-00180
   FI

   Email: kivinen@iki.fi










































Kivinen                 Expires January 26, 2012               [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/