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

Versions: 00 01 02 03 04 05 06 07 08 RFC 6617

Network Working Group                                         D. Harkins
Internet-Draft                                            Aruba Networks
Intended status: Standards Track                       November 11, 2009
Expires: May 15, 2010


                   Secure PSK Authentication for IKE
                   draft-harkins-ipsecme-spsk-auth-00

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 May 15, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo describes a secure pre-shared key authentication method for
   IKE.  It is resistant to dictionary attack and retains security even
   when used with weak pre-shared keys.



Harkins                   Expires May 15, 2010                  [Page 1]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Keyword Definitions  . . . . . . . . . . . . . . . . . . .  3
   2.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Finite Cyclic Groups . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Elliptic Curve Groups  . . . . . . . . . . . . . . . . . .  6
     4.2.  Prime Modulus Groups . . . . . . . . . . . . . . . . . . .  6
   5.  Random Numbers . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  The Random Function  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Secure Pre-Shared Key Authentication Message Exchange  . . . .  8
     8.1.  Fixing the Secret Element, SKE . . . . . . . . . . . . . .  9
       8.1.1.  Elliptic Curve SKE . . . . . . . . . . . . . . . . . .  9
       8.1.2.  Prime Modulus SKE  . . . . . . . . . . . . . . . . . . 11
     8.2.  Encoding of Elements . . . . . . . . . . . . . . . . . . . 11
     8.3.  Generation of a Commit . . . . . . . . . . . . . . . . . . 11
     8.4.  Generation of a Confirm  . . . . . . . . . . . . . . . . . 12
     8.5.  Commit Payload . . . . . . . . . . . . . . . . . . . . . . 13
     8.6.  Confirm Payload  . . . . . . . . . . . . . . . . . . . . . 13
     8.7.  IKEv1 Messaging  . . . . . . . . . . . . . . . . . . . . . 14
     8.8.  IKEv2 Messaging  . . . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     12.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19





















Harkins                   Expires May 15, 2010                  [Page 2]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


1.  Introduction

   Both [RFC2409] and [RFC4306] allow for authentication of the IKE
   peers using a pre-shared key.  The exchanges, though, are susceptible
   to dictionary attack and are therefore insecure.

   To address this security issue, [RFC4306] recommends that the pre-
   shared key used for authentication "contain as much unpredictability
   as the strongest key being negotiated".  That means any non-
   hexidecimal key would require over 100 characters to provide enough
   strength to generate a 128-bit key for AES.  This is an unrealistic
   requirement because humans have a hard time entering a string over 20
   characters without error.

   A pre-shared key authentication method built on top of a zero-
   knowledge proof will provide resistance to dictionary attack and
   still allow for security when used with weak pre-shared keys, such as
   user-chosen passwords.  Such an authentication method is described in
   this memo.

   Resistance to dictionary attack is achieved when an attacker gets
   one, and only one, guess at the secret per active attack (see for
   example, [BM92], [BMP00] and [BPR00]).  Another way of putting this
   is that any advantage the attacker can realize is through interaction
   and not through computation.  This is demonstrably different than the
   technique from [RFC4306] of using a large, random number as the pre-
   shared key.  That can only make a dictionary attack less likely to
   suceed, it does not prevent a dictionary attack.  And, as [RFC4306]
   notes, it is completely insecure when used with weak keys like user-
   generated passwords.

1.1.  Keyword Definitions

   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 RFC 2119 [RFC2119].


2.  Scenarios

   [RFC4306] describes usage scenarios for IKEv2.  These are:

   1.  "Security Gateway to Security Gateway Tunnel": the endpoints of
       the IKE (and IPsec) communication are network nodes that protect
       traffic on behalf of connected networks.  Protected traffic is
       between devices on the respective protected networks.





Harkins                   Expires May 15, 2010                  [Page 3]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   2.  "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and
       IPsec) communication are hosts according to [RFC4301].  Protected
       traffic is between the two endpoints.

   3.  "Endpoint to Securty Gateway Tunnel": one endpoint connects to a
       protected network through a network node.  The endpoints of the
       IKE (and IPsec) communication are the endpoint and network node,
       but the protected traffic is between the endpoint and another
       device on the protected network behind the node.

   [RFC4306] also defines an EAP authentication method which can use a
   pre-shared key or password in a manner that is resistant to
   dictionary attack.  But this requires the IKE Responder to have a
   certificate.  Also, EAP is strictly a client-server protocol used for
   network access where one side is, typically, has a human behind it
   and the other side is a network node.  And, for EAP to scale a server
   that terminates the EAP conversation is typically located on the
   protected network behind the network node.  Therefore EAP
   authentication is really only applicable to the "Endpoint to Security
   Gateway Tunnel" usage scenario.

   The authentication and key exchange described in this memo is
   therefore suitable for both the "Security Gateway to Security Gateway
   Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario.
   In both of those, there is no defined roles.  Either party could
   initiate an IKE connection to the other and there isn't necessarily a
   human involved.  Also, both sides will have access to the pre-shared
   key (i.e. no external authentication server) and neither side is
   required to have a certificate.  While it is certainly possible to
   use EAP authentication in these cases with an EAP method such as
   [EAPPWD], it will be a pointless and problematic encapsulation-- it
   requires implementation of both the EAP client and EAP server state
   machines, requires support of at least one EAP method, requires
   support for EAP fragmentation, etc.

   [RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has,
   traditionally, been used in the same "Security Gateway to Security
   Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport"
   scenario.  Its pre-shared key-based authentication method is
   constrained to only allow keys identified by IP address.  Also, it
   lacks a robust way to do user authentication using a password,
   prompting the definition of different insecure ways to do password
   authentication.  Therefore, a secure pre-shared key-based
   authentication method in IKEv1 will mitigate the need to do insecure
   password-based authentication and remove the requirement that a pre-
   shared key in IKEv1 needs to be based on IP address.

   There is a need to do secure pre-shared key-based authentication in



Harkins                   Expires May 15, 2010                  [Page 4]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   IKE and it makes sense to do it as part of IKE and not by requiring
   additional authentication protocols.


3.  Notation

   The following notation is used in this memo:

   psk
       The key shared between the two protocol participants.

   a = H(b)
       The binary string "b" is given to a function H which produces a
       fixed-length output "a".

   a | b
       denotes concatenation of string "a" with string "b".

   [a]b
       indicates a string consisting of the single bit "a" repeated "b"
       times.

   len(x)
       indicates the length in bits of the string x.

   LSB(x)
       returns the least-significant bit of the bitstring "x".

   The convention for this memo to represent an element in a finite
   cyclic group is to use an upper-case letter while a scalar is
   indicated with a lower-case letter.


4.  Finite Cyclic Groups

   This protocol uses the same group (from the IANA repository created
   by [RFC2409]) as the IKE exchange in which this authentication method
   is used.  Groups can be either based on exponentiation modulo a prime
   or on an elliptic curve.  These groups all define the following
   operations:

   o   "scalar operation"-- taking a scalar and an element in the group
       producing another element-- Z = scalar-op(x, Y).

   o   "element operation"-- taking two elements in the group to produce
       a third-- Z = element-op(X, Y).





Harkins                   Expires May 15, 2010                  [Page 5]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   o   "inverse operation"-- take an element an return another element
       such that the element operation on the two produces the identity
       element of the group-- Y = inverse(X).

4.1.  Elliptic Curve Groups

   ECP elliptic curves are defined by a curve equation, y^2 = x^3 + ax +
   b, for a defined "a" and "b".  ECP groups have a generator G, a prime
   p, an order r, and, optionally, a co-factor f.  The scalar operation
   is multiplication of a point on the curve by itself a number of
   times, and the element operation is addition of two points on the
   curve:

   Z = scalar-op(x, Y) = x*Y

       the point Y is multiplied x-times to produce another point on the
       curve, Z.

   Z = element-op(X, Y) = X + Y

       points X and Y are summed to produce another point on the curve,
       Z.

   Elliptic curve groups require a mapping function, q = F(Q), to
   convert a group element to an integer.  The mapping function used in
   this memo returns the x-coordinate of the point it is passed.

   If a co-factor is given in the group definition it MUST be used as
   the co-factor, f, when a co-factor is called for, otherwise the co-
   factor, f, MUST be 1.

   The inverse function for an elliptic group is defined such that the
   sum of an element and its inverse is the "point at infinity", denoted
   here as "O".  In other words,

       Q + inverse(Q) = "O"

   Only ECP elliptic curve can be used by the secure pre-shared key
   authentication method.  EC2N elliptic curves SHALL NOT be used.
   While such groups exist in the IANA registry their use is not
   defined.

4.2.  Prime Modulus Groups

   Groups formed by a prime modulus have a generator G, a prime modulus
   p, and an order r.

   The scalar operation is exponentiation of a generator modulus a



Harkins                   Expires May 15, 2010                  [Page 6]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   prime, and the element operation is modular multiplication:

   Z = scalar-op(x, Y) = Y^x mod p

       an element, Y taken to the x-th power modulo the prime returning
       another element in the group, Z.

   Z = element-op(X, Y) = (X * Y) mod p

       two elements, X and Y, are multiplied modulo the prime returning
       another element, Z.

   If the order of the generator of the group is part of the group
   definition that value MUST be used as the order of the group, r, when
   an order is called for, otherwise the order, r, MUST be computed as
   the prime minus one divided by two-- (p-1)/2.

   Unlike elliptic curve groups, prime modulus groups do not require a
   mapping function to convert an element into a scalar.  But for the
   purposes of notation in protocol definition, the function F, when
   used below, shall just return the integer representation of an
   element in a prime modulus group.

   The inverse function for a prime modulus group is defined such that
   the product of an element and its inverse modulo the group prime
   equals one (1).  In other words,

       (Q * inverse(Q)) mod p = 1


5.  Random Numbers

   As with IKE itself, the security of the secure pre-shared key
   authenticaiton method relies upon each participant in the protocol
   producing quality secret random numbers.  A poor random number chosen
   by either side in a single exchange can compromise the shared secret
   from that exchange and open up the possibility of dictionary attack.

   Producing quality random numbers without specialized hardware entails
   using a cryptographic mixing function (like a strong hash function)
   to distill entropy from multiple, uncorrelated sources of information
   and events.  A very good discussion of this can be found in
   [RFC4086].


6.  The Random Function

   The protocol described in this memo uses a random function, H. This



Harkins                   Expires May 15, 2010                  [Page 7]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   is a "random oracle" as defined in [RANDOR].  At first glance one may
   view this as a hash function.  As noted in [RANDOR], though, hash
   functions are too structured to be used directly as a random oracle.
   But they can be used to instantiate a random oracle.

   The random function, H, in this memo is instantiated by HMAC-SHA256
   (see [RFC4634]) with a key whose length is 32 octets and whose value
   is zero.  In other words,

       H(x) = HMAC-SHA-256([0]32, x)


7.  Assumptions

   The security of the protocol relies on certain assumptions.  They
   are:

   1.  Function H maps a binary string of indeterminate length onto a
       fixed binary string that is x bits in length.

           H: {0,1}^* --> {0,1}^x

   2.  Function H is a "random oracle" (see [RANDOR]).  Given knowledge
       of the input to H an adversary is unable to distinguish the
       output of H from a random data source.

   3.  The discrete logarithm problem for the chosen finite cyclic group
       is hard.  That is, given G, p and Y = G^x mod p it is
       computationally infeasible to determine x.  Similarly for an
       elliptic curve group given the curve definition, a generator G,
       and Y = x * G it is computationally infeasible to determine x.

   4.  The pre-shared key is drawn from a finite pool of potential keys.
       Each possible key in the pool has equal probability of being the
       shared key.  All potential attackers have access to this pool of
       keys.


8.  Secure Pre-Shared Key Authentication Message Exchange

   To perform secure pre-shared key authentication each side must
   generate a shared and secret element in the chosen group based on the
   pre-shared key.  This element, called the Secret Key Element, or SKE,
   is then used in an authentication and key exchange protocol.  The key
   exchange protocol consists of each side exchanging two data, a
   "Commit" and a "Confirm".

   The "Commit" contributes ephemeral information to the exchange and



Harkins                   Expires May 15, 2010                  [Page 8]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   binds the sender to a single value of the pre-shared key from the
   pool of potential pre-shared keys.  The "Confirm" proves that the
   pre-shared key is known and completes the zero-knowledge proof.

8.1.  Fixing the Secret Element, SKE

   The method of fixing SKE depends on the type of group, either MODP or
   ECP.  For the sake of convenience, we will use a single notation of
   prf+() to denote the function prf+() from [RFC4306] as well as the
   function prf() from [RFC2409], depending on whether the exchange is
   being performed in IKEv2 or IKEv1, respectively.

8.1.1.  Elliptic Curve SKE

   For a finite cyclic group based on an elliptic curve it is necessary
   to use an iterative hunt-and-peck technique to fix the secret key
   element.

   First, an 8-bit counter is set to the value one (1).  Then, the
   random function is used to generate a secret seed using the counter,
   the pre-shared key, and the two nonces exchange by the Initiator and
   the Responder:

      ske-seed = H(psk | counter | Ni | Nr)

   Then, the swe-seed is expanded using prf+ to create an ske-value:

      ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")

   where len(ske-value) is the same as len(p), the length of the prime
   of the curve.

   If the ske-value is greater than or equal to the prime, p, the
   counter is incremented, and a new ske-seed is gnerated and the
   hunting-and-pecking continues.  If ske-value is less than the prime,
   p, it is used as the x-coordinate, x, with the equation for the
   elliptic curve, with parameters a and b from the definition of the
   curve, to solve for a y-coordinate, y.  If there is no solution to
   the quadratic equation the counter is incremented, a new ske-seed is
   generated and the hunting and pecking continues.  If a solution is
   found then an ambiguity exists as there are technically two solutions
   to the equation and ske-seed is used to unambiguously select one of
   them.  If the low-order bit of ske-seed is equal to the low-order bit
   of y then a candidate SKE is defined as the point (x, y); if the low-
   order bit of ske-seed differs from the low-order bit of y then a
   candidate SKE is defined as the point (x, p - y), where p is the
   prime over which the curve is defined.  If the co-factor equals 1
   then the candidate SKE becomes the SKE and hunting and pecking



Harkins                   Expires May 15, 2010                  [Page 9]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   terminates.  If the co-factor of the curve is not equal to one the
   order of the candidate SKE is checked to make sure it can safely be
   used as a generator in the protocol.  If the co-factor of the curve
   multiplied by the candidate SKE equals the point-at-infinity then the
   candidate SKE is discarded, the counter is incremented, a new ske-
   seed is generated and the hunting and pecking continues.  If it does
   not equal the point-at-infinity the candidate SKE becomes the SKE and
   hunting and pecking terminates.  (Note: the point multiplied by the
   co-factor does not become SKE, it is only used to determine the order
   of the group defined with SKE as a generator).

   Algorithmically, the process looks like this:

         found = 0
         counter = 1
         do {
           ske-seed = H(psk | counter | Ni | Nr)
           ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking")
           if (ske-value < p)
           then
             x = ske-value
             if ( (y = sqrt(x^3 + ax + b)) != FAIL)
             then
               if (LSB(y) == LSB(ske-seed))
               then
                 SKE = (x,y)
               else
                 SKE = (x, p-y)
               fi
               if (f == 1)
               then
                 found = 1
               else
                 P = f*SKE
                 if (P != "O")
                 then
                   found = 1
                 fi
               fi
             fi
           fi
           counter = counter + 1
         } while (found == 0)

                 Figure 1: Fixing SKE for Elliptic Curves






Harkins                   Expires May 15, 2010                 [Page 10]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


8.1.2.  Prime Modulus SKE

   For a finite cyclic group based on exponentiation of a generator, G,
   modulo a large prime p it is not necessary to hunt-and-peck to find
   SKE.  An SKE can be computed in a sub-field of the group directly
   using the prime, p, and order r.

   First, the random function is used to generate a seed:

      ske-seed = H(psk | Ni | Nr)

   Then the ske-seed is expanded using prf+ to the length of the prime,
   modulo the prime.

      ske-gen = prf+(ske-seed, "IKE Affixing the SKE")

      ske-gen = ske-gen mod p

   The ske is then computed by exponentiating the ske-gen to the value
   ((p-1)/r) modulo the prime.

      SKE = ske-gen ^ ((p-1)/r) mod p

8.2.  Encoding of Elements

   Encoding of an element in a finite cyclic group depends on the type
   of group.

   For MODP groups the element is treated as an unsigned integer less
   than the prime that defines the group.  The length of each MODP
   element MUST have a bit length equal to the bit length of the prime.
   This length is enforced, if necessary, by prepending the integer with
   zeros until the required length is achieved.

   For ECP groups the element is treated as two unsigned integers, each
   less than the prime that defines the group, representing the
   coordinates of the point.  The first is the x-coordinate and the
   second is the y-coordinate.  Each of these two integers MUST have a
   bit length equal to the bit length of the prime.  This length is
   enforced, if necessary, by prepending the integer with zeros until
   the required length is achieved.

8.3.  Generation of a Commit

   A Commit has two components, a Scalar and an Element.  To generate a
   Commit, two random numbers, a "private" value and a "mask" value, are
   generated (see Section 5).  Their sum modulo the order of the group,
   r, becomes the Scalar component:



Harkins                   Expires May 15, 2010                 [Page 11]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


       Scalar = (private + mask) mod r

   and the inverse of the scalar operation with the mask and SWE becomes
   the Element component.

       Element = inverse(scalar-op(mask, SKE))

   The Commit payload consists of the Scalar followed by the Element.

8.4.  Generation of a Confirm

   After receipt of a peer's Commit and generation of one's own Commit a
   candidate shared secret to authenticate the peer is derived.  Using
   SKE, the "private" value generated as part of Commit generation, and
   the peer's Scalar and Element from its Commit, peer-scalar and peer-
   element, respectively, the shared secret, ss, is generated as:

       ss = scalar-op(private, element-op(peer-element, scalar-op(peer-
       scalar, SKE)))

   For the purposes of subsequent computation, the bit length of ss
   SHALL be equal to the bit length of the prime, p, used in either a
   MODP or ECP group.  This bit length SHALL be enforced, if necessary,
   by prepending zeros to the value until the required length is
   achieved.

   Using the shared secret, ss, and the generated Scalar and Element,
   self-scalar and self-element, respectively, and the received Scalar
   and Element, peer-scalar and peer-element, respectively, an
   authenticating Tag is generated as:

       Tag = H(self-scalar | peer-scalar | F(self-element) | F(peer-
       element) | ss)

   The Commit payload consists of the authenticating Tag.
















Harkins                   Expires May 15, 2010                 [Page 12]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


8.5.  Commit Payload


    The Commit Payload is defined as follows:

                              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        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                            Scalar                             ~
       |                                                               |
       ~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
       |                                                               |
       ~                           Element                             ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Commit Payload SHALL be indicated in both IKEv1 and IKEv2 with
   TBD1 from the [IKEV2-IANA] registry maintained by IANA.

   The Scalar SHALL be encoded as an unsigned integer with a bit length
   equal to the bit length of the order of the group used in the
   exchange.  This length is enforced, if necessary, by prepending the
   integer with zeros until the required length is achieved.  The
   Element is encoded according to Section 8.2.

8.6.  Confirm Payload


    The Confirm Payload is defined as follows:

                              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        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                                                               !
       ~                              Tag                              ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Confirm Payload SHALL be indicated in both IKEv1 and IKEv2 with
   TBD2 from the [IKEV2-IANA] registry maintained by IANA.




Harkins                   Expires May 15, 2010                 [Page 13]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


8.7.  IKEv1 Messaging

   Secure pre-shared key authentication can be used in either Main Mode
   (see Figure 2) or Aggressive Mode (see Figure 3) with IKEv1 and SHALL
   be indicated by negotiation of the TBD3 Authentication Method from
   the [IKEV1-IANA] registry maintained by IANA, in the SA payload.
   When using IKEv1 the "C" (critical) bit from Section 8.5 and
   Section 8.6 MUST be clear (i.e. a value of zero).


         Initiator                          Responder
        -----------                        -----------
         HDR, SAi                 -->
                                  <--    HDR, SAr
         HDR, KEi, Ni             -->
                                  <--    HDR, KEr, Nr
         HDR*, IDii, Commit       -->
                                  <--    HDR*, IDir, Commit, Confirm
         HDR*, Confirm, HASH_I    -->
                                  <--    HDR*, HASH_R

                     Figure 2: Secure PSK in Main Mode



          Initiator                          Responder
         -----------                        -----------
          HDR, SAi, KEi, Ni, IDii,
               Commit               -->
                                   <--    HDR, SAr, KEr, Nr, IDir,
                                          Commit, Confirm
          HDR, Confirm, HASH_I     -->
                                   <--    HDR, HASH_R

                  Figure 3: Secure PSK in Aggressive Mode

   For secure pre-shared key authentication with IKEv1 the SKEYID value
   is computed as follows:

       SKEYID = prf(Ni_b | Nr_b, g^xy)

   And HASH_I and HASH_R are computed as follows:

       HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R | SA_ib |
       IDii_b)

       HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I | SA_ib |
       IDir_b)



Harkins                   Expires May 15, 2010                 [Page 14]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   Where "ss" is the shared secret derived in Section 8.4.

8.8.  IKEv2 Messaging

   The specific authentication method being employed in IKEv2 is not
   negotiated, like in IKEv1.  It is inferred from the components of the
   message.  The presence of a Commit payload in second message sent by
   the Initiator indicates an intention to perform secure pre-shared key
   authentication (see Figure 4).  The critical bit is used in both the
   Commit and Confirm payloads to allow for backwards compatibility and
   MUST be set (i.e. a value of one).


       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni       -->
                                <--    HDR, SAr1, KEr, Nr, [CERTREQ]
       HDR, SK {IDi, Commit, [IDr,]
                SAi2, TSi, TSr} -->
                                <--    HDR, SK {IDr, Commit, Confirm}
       HDR, SK {Confirm, AUTH}  -->
                                <--    HDR, SK {AUTH, SAr2, TSi, TSr}

                       Figure 4: Secure PSK in IKEv2

   In the case of secure pre-shared key authentication the AUTH value is
   computed as:

       AUTH = prf(ss, <msg octets>)

   Where "ss" is the shared secret derived in Section 8.4.  The
   Authentication Method indicated in the AUTH payload SHALL be TBD4
   from the [IKEV2-IANA] registry maintained by IANA.


9.  IANA Considerations

   IANA SHALL assign values for the Commit payload (Section 8.5) and the
   Confirm payload (Section 8.6), and replace TBD1 and TBD2,
   respectively, above, from the [IKEV2-IANA] of "IKEv2 Payload Types".

   IANA SHALL assign a value for "Secure Shared Key Authentication",
   replacing TBD3 above, from the IPSEC Authentication Method registry
   in [IKEV1-IANA].

   IANA SHALL assign a value for "Secure Shared Key Authentication",
   replacing TBD4 above, from the IKEv2 Authentication Method registry
   in [IKEV2-IANA].



Harkins                   Expires May 15, 2010                 [Page 15]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


10.  Security Considerations

   Both the Initiator and Responder obtain a shared secret, "ss" (see
   Section 8.4) based on a secret group element and their own private
   values contributed to the exchange.  If they do not share the same
   pre-shared key they will be unable to derive the same secret group
   element and if they do not share the same secret group element they
   will be unable to derive the same shared secret.

   Resistance to dictionary attack means that the attacker must launch
   an active attack to make a single guess at the pre-shared key.  If
   the size of the pool from which the key was extracted was D, and each
   key in the pool has an equal probability of being chosen, then the
   probability of success after a single guess is 1/D. After X guesses,
   and removal of failed guesses from the pool of possible keys, the
   probability becomes 1/(D-X).  As X grows so does the probability of
   success.  Therefore it is possible for an attacker to determine the
   pre-shared key through repeated brute-force, active, guessing
   attacks.  This authentication method does not presume to be secure
   against this and implementations SHOULD ensure the size of D is
   sufficiently large to prevent this attack.  Implementations SHOULD
   also take countermeasures, for instance refusing authentication
   attempts for a certain amount of time, after the number of failed
   authentication attempts reaches a certain threshold.  No such
   threshold or amount of time is recommended in this memo.

   An active attacker can impersonate the Initiator of the exchange and
   send a forged Commit payload.  The attacker then waits until it
   receives a Commit and a Confirm from the Responder.  Now the attacker
   can attempt to run through all possible values of the pre-shared key,
   computing SKE (see Section 8.1), computing "ss" (see Section 8.4),
   and attempting to recreate the Confirm payload from the Responder.

   But the attacker committed to a single guess of the pre-shared key
   with her forged Commit.  That value was used by the Responder in his
   computation of "ss" which was used to construct his Confirm.  Any
   guess of the pre-shared key which differs from the one used in the
   forged Commit would result in each side using a different secret
   element in the computation of "ss" and therefore the Confirm could
   not be verified as correct, even if a subsequent guess, while running
   through all possible values, was correct.  The attacker gets one
   guess, and one guess only, per active attack.

   An attacker, acting as either the Initiator or Responder, can take
   the Element from the Commit message received from the other party,
   reconstruct the random "mask" value used in its construction and then
   recover the other party's "private" value from the Scalar in the
   Commit message.  But this requires the attacker to solve the discrete



Harkins                   Expires May 15, 2010                 [Page 16]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


   logarithm problem which we assumed was intractable above (Section 7).

   Instead of attempting to guess at pre-shared keys an attacker can
   attempt to determine SKE and then launch an attack.  But SKE is
   determined by the output of the random function, H, which is assumed
   to be indistinguishable from a random source (Section 7).  Therefore,
   each element of the finite cyclic group will have an equal
   probability of being the SKE.  The probability of guessing SKE will
   be 1/r, where r is the order of the group.  This is the same
   probability of guessing the solution to the discrete logarithm which
   is assumed to be intractable (Section 7).  The attacker would have a
   better chance of success at guessing the input to H, i.e. the pre-
   shared key, since the order of the group will be many orders of
   magnitude greater than the size of the pool of pre-shared keys.

   The implications of resistance to dictionary attack are significant.
   An implementation can provision a pre-shared key in a practical and
   realistic manner-- i.e. it MAY be a character string and it MAY be
   relatively short-- and still maintain security.  The nature of the
   pre-share key determines the size of the pool, D, and countermeasures
   can prevent an attacker from determining the secret in the only
   possible way: repeated, active, guessing attacks.  For example, a
   simple four character string using lower-case English characters, and
   assuming random selection of those characters, will result in D of
   over four hundred thousand.  An attacker would need to mount over one
   hundred thousand active, guessing attacks (which will easily be
   detected) before gaining any significant advantage in determining the
   pre-shared key.

   For a more detailed discussion of the security of the key exchange
   underlying this authentication method see [SAE] and [EAPPWD].


11.  Acknowledgements

   The author would like to thank Scott Fluhrer and Hideyuki Suzuki for
   their insight in discovering flaws in earlier versions of the key
   exchange that underlies this authentication method and for their
   helpful suggestions in improving it.  Lily Chen provided useful
   advice on how to "hash into an element" in a finite cyclic group.
   Hugo Krawczyk suggested the particular instantiation of the random
   function, H.


12.  References






Harkins                   Expires May 15, 2010                 [Page 17]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


12.1.  Normative References

   [IKEV1-IANA]
              "Internet Assigned Numbers Authority, Internet Key
              Exchange (IKE) Attributes",
              <http://www.iana.org/assignments/ipsec-registry>.

   [IKEV2-IANA]
              "Internet Assigned Numbers Authority, IKEv2 Parameters",
              <http://www.iana.org/assignments/ikev2_parameters>.

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

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

12.2.  Informative References

   [BM92]     Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
              Password-Based Protocols Secure Against Dictionary
              Attack", Proceedings of the IEEE Symposium on Security and
              Privacy, Oakland, 1992.

   [BMP00]    Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure
              Password Authenticated Key Exchange Using Diffie-Hellman",
              Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag,
              2000.

   [BPR00]    Bellare, M., Pointcheval, D., and P. Rogaway,
              "Authenticated Key Exchange Secure Against Dictionary
              Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture
              Notes in Computer Science Springer-Verlag, 2000.

   [EAPPWD]   Harkins, D. and G. Zorn, "EAP Authentication Using Only A
              Password", draft-harkins-emu-eap-pwd-12 (work in
              progress), October 2009.

   [RANDOR]   Bellare, M. and P. Rogaway, "Random Oracles are Practical:



Harkins                   Expires May 15, 2010                 [Page 18]

Internet-Draft      Secure PSK Authentication for IKE      November 2009


              A Paradigm for Designing Efficient Protocols", Proceedings
              of the 1st ACM Conference on Computer and Communication
              Security, ACM Press, 1993,
              <http://www.cs.ucsd.edu/~mihir/papers/ro.pdf>.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [SAE]      Harkins, D., "Simultaneous Authentication of Equals: A
              Secure, Password-Based Key Exchange for Mesh Networks",
              Proceedings of the 2008 Second International Conference on
              Sensor Technologies and Applications Volume 00, 2008.


Author's Address

   Dan Harkins
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   United States of America

   Email: dharkins@arubanetworks.com




























Harkins                   Expires May 15, 2010                 [Page 19]


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