Network Working Group                                         D. Harkins
Internet-Draft                                            Aruba Networks
Intended status: Experimental                              June 30, 2010
Expires: January 1, 2011


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

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 1, 2011.

Copyright Notice

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

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 January 1, 2011                [Page 1]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Keyword Definitions  . . . . . . . . . . . . . . . . . . .  3
   2.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Discrete Logarithm Cryptography  . . . . . . . . . . . . . . .  5
     4.1.  Elliptic Curve Cryptography (ECP) Groups . . . . . . . . .  6
     4.2.  Finite Field Cryptography (MODP) Groups  . . . . . . . . .  7
   5.  Random Numbers . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Using Passwords as a Pre-Shared Key  . . . . . . . . . . . . .  8
   7.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Secure PSK Authentication Message Exchange . . . . . . . . . .  9
     8.1.  Fixing the Secret Element, SKE . . . . . . . . . . . . . . 10
       8.1.1.  ECP Operation to Select SKE  . . . . . . . . . . . . . 11
       8.1.2.  MODP Operation to Select SKE . . . . . . . . . . . . . 12
     8.2.  Encoding and Decoding of Group Elements and Scalars  . . . 13
       8.2.1.  Encoding and Decoding of Scalars . . . . . . . . . . . 13
       8.2.2.  Encoding and Decoding of ECP Elements  . . . . . . . . 13
       8.2.3.  Encoding and Decoding of MODP Elements . . . . . . . . 14
     8.3.  Message Generation and Processing  . . . . . . . . . . . . 14
       8.3.1.  Generation of a Commit . . . . . . . . . . . . . . . . 14
       8.3.2.  Processing of a Commit . . . . . . . . . . . . . . . . 15
         8.3.2.1.  Validation of an ECP Element . . . . . . . . . . . 15
         8.3.2.2.  Validation of a MODP Element . . . . . . . . . . . 15
         8.3.2.3.  Commit Processing Steps  . . . . . . . . . . . . . 15
       8.3.3.  Authentication of the Exchange . . . . . . . . . . . . 16
     8.4.  Payload Format . . . . . . . . . . . . . . . . . . . . . . 16
       8.4.1.  Commit Payload . . . . . . . . . . . . . . . . . . . . 17
     8.5.  IKEv1 Messaging  . . . . . . . . . . . . . . . . . . . . . 17
     8.6.  IKEv2 Messaging  . . . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     12.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24













Harkins                  Expires January 1, 2011                [Page 2]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


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.  In addition,
   [RFC2409] requires that a pre-shared key be identified by IP address
   and this severely constrains its usefulness.  These are obvious
   drawbacks to using pre-shared key authentication in IKEv1 and IKEv2.

   To address the 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.  Consequently, pre-shared key
   authentication in [RFC2409] and [RFC4306] are used insecurely today.

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



Harkins                  Expires January 1, 2011                [Page 3]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


       traffic on behalf of connected networks.  Protected traffic is
       between devices on the respective protected networks.

   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.

   The authentication and key exchange described in this memo is
   suitable for all the usage scenarios described in [RFC4306].  In the
   "Security Gateway to Security Gateway Tunnel" scenario and the
   "Endpoint-to-Endpoint Transport" scenario it provides a secure method
   of authentication without requiring a certificate.  For the "Endpoint
   to Security Gateway Tunnel" scenario it provides for secure username+
   password authentication that is popular in remote access VPN
   situations.

   [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 and therefore
   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 obviate the need to do insecure
   password-based authentication, such as [XAUTH], and remove the
   requirement that a pre-shared key in IKEv1 needs to be based on IP
   address.


3.  Notation

   The following notation is used in this memo:

   psk
       A shared, secret and potentially low-entropy word, phrase, code
       or key used as a credential to mutually authenticate the peers.

   a = prf(b, c)
       The string "b" and "c" are given to a pseudo-random function to
       produce a fixed-length output "a".




Harkins                  Expires January 1, 2011                [Page 4]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   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 or acronym, while a
   scalar is indicated with a lower-case letter or acronym.


4.  Discrete Logarithm Cryptography

   This protocol uses Discrete Logarithm Cryptography to achieve
   authentication.  Each party to the exchange derives ephemeral public
   and private keys with respect to a particular set of domain
   parameters (referred to here as a "group").  Groups can be either
   based on finite field cryptography (MODP groups) or elliptic curve
   cryptography (ECP groups).

   This protocol uses the same group as the IKE exchange in which it is
   being used for authentication, with the exception of characteristic-
   two elliptic curve groups (EC2N).  Use of such groups is undefined
   for this authentication method and an IKE exchange that negotiates
   one of these groups MUST NOT use this method of authentication.

   For each group the following operations are defined:

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

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







Harkins                  Expires January 1, 2011                [Page 5]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


4.1.  Elliptic Curve Cryptography (ECP) Groups

   The key exchange defined in this memo uses fundamental algorithms of
   ECP groups as described in [FUN-ECC].

   Domain parameters for ECP elliptic curves used for secure pre-shared
   key-based authentication include:

   o  A prime, p, determining a prime field GF(p).  The cryptographic
      group will be a subgroup of the full elliptic curve group which
      consists points on an elliptic curve-- elements from GF(p) that
      satisfy the curve's equation-- together with the "point at
      infinity" (denoted here as "O") that serves as the identity
      element.

   o  Elements a and b from GF(p) that define the curve's equation.  The
      point (x,y) is on the elliptic curve if and only if (y^2 - x^3 -
      a*x - b) mod p equals zero (0).

   o  A prime, r, which is the order of G, and thus is also the size of
      the cryptographic subgroup that is generated by G.

   The scalar operation is multiplication of a point on the curve by
   itself a number of times.  The point Y is multiplied x-times to
   produce another point Z:

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

   The element operation is addition of two points on the curve.  Points
   X and Y are summed to produce another point Z:

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

   The inverse function is defined such that the sum of an element and
   its inverse is "0":

       Q + inverse(Q) = "O"

   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.

   scalar-op(x, Y) can be viewed as x iterations of element-op(Y, Y) by
   defining:

       Y = scalar-op(x, Y), for x = 1





Harkins                  Expires January 1, 2011                [Page 6]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


       Y = scalar-op(x, Y) = element-op(scalar-op(x-1, Y), for x > 1

   A definition of how to add two points on an elliptic curve (i.e.
   element-op(X, Y)) can be found in [FUN-ECC].

   Note: There is another ECP domain parameter, a co-factor, h, that is
   defined by the requirement that the size of the full elliptic curve
   group (including "O") be the product of h and r.  ECP groups used for
   secure pre-shared key-based authentication MUST have a co-factor of
   one (1).  At the time of publication of this memo, all ECP groups in
   the IANA registry used by IKE had a co-factor of one (1).

4.2.  Finite Field Cryptography (MODP) Groups

   Domain parameters for MODP groups used for secure pre-shared key-
   based authentication include:

   o  A prime, p, determining a prime field GF(p), the integers modulo
      p.

   o  A prime, r, which is the multiplicative order of G, and thus also
      the size of the cryptographic subgroup of GF(p)* that is generated
      by G.

   The scalar operation is exponentiation of a generator modulus a
   prime.  An element Y is taken to the x-th power modulo the prime
   returning another element, Z:

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

   The element operation is modular multiplication.  Two elementx, X and
   Y, are multiplied modulo the prime returning another element, Z:

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

   The inverse function for a MODP 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

   Unlike ECP groups, MODP 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 that was passed to it-- i.e.  F(i) = i.

   Some MODP groups in the IANA registry for use by IKE (and the secure
   pre-shared key authentication method) are based on safe primes and



Harkins                  Expires January 1, 2011                [Page 7]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   the order is not included in the group's domain parameter set.  In
   this case only, the order, r, MUST be computed as the prime minus one
   divided by two-- (p-1)/2.  If an order is included in the group's
   domain parameter set that value MUST be used in this exchange when an
   order is called for.  If a MODP group does not include an order in
   its domain parameter set and is not based on a safe prime it MUST NOT
   be used with this exchange.


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.  Using Passwords as a Pre-Shared Key

   This protocol requires the pre-shared key to be represented as a
   binary string.  When passwords are used it is necessary to transform
   the password into a binary string in a manner that will produce
   identitcal binary strings on the Initiator and the Responder.  This
   imposes processing requirements on a password prior to its use.

   Three techniques for password pre-processing exist for Secure PSK
   Authentication:

   o   None: The input password string SHALL be treated as an ASCII
       string or a hexadecimal string with no treatment or normalization
       performed.  The output SHALL be the binary representation of the
       input string.

   o   RFC2759: The input password string SHALL be processed to produce
       the output PasswordHashHash, as defined in [RFC2759], including
       any approved errata to [RFC2759].  This technique is useful when
       at least one side does not have access to the plaintext password.

   o   SASLprep: The input password string is processed according to the
       rules of the [RFC4013] profile of [RFC3454].  A password SHALL be
       considered a "stored string" per [RFC3454] and unassigned code



Harkins                  Expires January 1, 2011                [Page 8]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


       points are therefore prohibited.  The output SHALL be the binary
       representation of the processed UTF-8 character string.
       Prohibited output and unassigned codepoints encountered in
       SASLprep pre-processing SHALL cause a failure of pre-processing
       and the output SHALL NOT be used with Secure Password
       Authentication.

   For the purposes of interoperability, a password pre-processing
   technique of "None" MUST be supported.  "RFC2759" and "SASLprep"
   SHOULD be supported.

   Changing a password is out-of-scope of this memo but due to the
   ambiguities in the way internationalized character strings are
   handled it SHOULD be done using SASLprep ensure a canonical
   representation of the new password is stored and subsequent
   invocations of Secure PSK Authentication SHOULD use SASLprep to
   ensure that both sides generate an identical binary string from the
   input password.


7.  Assumptions

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

   1.  The pseudo-random function, prf, defined in IKE (either [RFC2409]
       or [RFC4306]) acts as an "extractor" by concentrating the entropy
       from a secret input into a short, fixed, string.  The output of
       prf is indistinguishable from a random source.

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

   3.  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 PSK Authentication Message Exchange

   The key exchange described in this memo is based on the "Dragonfly"
   key exchange which has also been proposed in 802.11 wireless networks
   (see [SAE]) and as an EAP method (see [EAPPWD]).  "Dragonfly" is
   patent-free and royalty-free.  It has been defined here for use in



Harkins                  Expires January 1, 2011                [Page 9]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   both IKEv1 ([RFC2409]) and IKEv2 ([RFC4306]).  It makes use of the
   same pseudo-random function (prf) and the same Diffie-Hellman group
   that are negotiated for use in the IKE exchange that "dragonfly" is
   authenticating.

   A pseudo-random function which uses a block cipher is NOT RECOMMENDED
   for use with Secure PSK Authentication due to its poor job operating
   as an "extractor" (see Section 7).  Pseudo-random functions based on
   hash functions using the HMAC construct from [RFC2104] SHOULD be
   used.

   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 a "Commit" payload
   and then proving knowledge of the resulting shared secret.

   The "Commit" payload contributes ephemeral information to the
   exchange and binds the sender to a single value of the pre-shared key
   from the pool of potential pre-shared keys.  An authentication
   payload (either the HASH or AUTH payload depending on whether IKEv1
   or IKEv2, respectively, is being used) 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.  The function "prf+" from [RFC4306] is used as a key derivation
   function.  This is true even if performing secure pre-shared key
   authentication with IKEv1.

   Fixing SKE involves an iterative hunting-and-pecking technique using
   the prime from the negotiated group's domain parameter set and an
   ECP- or MODP-specific operation depending on the negotiated group.
   This technique requires the pre-shared key to be a binary string,
   therefore any password pre-processing transformation (see Section 6)
   MUST be performed on a password prior to fixing SKE.

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

      ske-seed = prf(Ni | Nr, psk | counter)

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




Harkins                  Expires January 1, 2011               [Page 10]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


      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
   from the domain parameter set of the negotiated group.

   If the ske-seed is greater than or equal to the prime, p, the counter
   is incremented and a new ske-seed is generated and the hunting-and-
   pecking continues.  If ske-seed is less than the prime, p, it is
   passed to the group-specific operation to select the SKE or fail.  If
   the group-specific operation fails, the counter is incremented, a new
   ske-seed is generated and the hunting-and-pecking continues.

8.1.1.  ECP Operation to Select SKE

   The group-specific operation for ECP groups uses ske-value, ske-seed
   and the equation of the curve to produce SKE.  First ske-value is
   used directly as the x-coordinate, x, with the equation of the
   elliptic curve, with parameters a and b from the domain parameter set
   of the curve, to solve for a y-coordinate, y.

   If there is no solution to the equation the operation fails (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 from the
   negotiated group's domain parameter set.  The candidate SKE becomes
   the SKE and the ECP-specific operation completes successfully.

   Algorithmically, the process looks like this:



















Harkins                  Expires January 1, 2011               [Page 11]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


         found = 0
         counter = 1
         do {
           ske-seed = prf(Ni | Nr, psk | counter)
           ske-value = prf+(ske-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
               found = 1
             fi
           fi
           counter = counter + 1
         } while (found == 0)

                    Figure 1: Fixing SKE for ECP Groups

8.1.2.  MODP Operation to Select SKE

   The group-specific operation for MODP groups takes ske-value, and the
   prime, p, and order, r, from the group's domain parameter set to
   directly produce a candidate SKE by exponentiating the ske-value to
   the value ((p-1)/r) modulo the prime.  If the candidate SKE is
   greater than one (1) the candidate SKE becomes the SKE and the MODP-
   specific operation completes successfully.  Otherwise, the MODP-
   specific operation fails (and the hunting-and-pecking continues).

   Algorithmically, the process looks like this:
















Harkins                  Expires January 1, 2011               [Page 12]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


         found = 0
         counter = 1
         do {
           ske-seed = prf(Ni | Nr, psk | counter)
           ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking")
           if (ske-value < p)
           then
             SKE = ske-value ^ ((p-1)/r) mod p
             if (SKE > 1)
             then
               found = 1
             fi
           fi
           counter = counter + 1
         } while (found == 0)

                   Figure 2: Fixing SKE for MODP Groups

8.2.  Encoding and Decoding of Group Elements and Scalars

   The payloads used in the secure pre-shared key authentication method
   contain elements from the negotiated group and scalar values.  To
   ensure interoperability, scalars and field elements MUST be
   represented in payloads in accordance with the requirements in this
   section.

8.2.1.  Encoding and Decoding of Scalars

   Scalars MUST be represented (in binary form) as unsigned integers
   that are strictly less than r, the order of the generator of the
   agreed-upon cryptographic group.  The binary representation of each
   scalar MUST have a bit length equal to the bit length of the binary
   representation of r.  This requirement is enforced, if necessary, by
   prepending the binary representation of the integer with zeros until
   the required length is achieved.

   Scalars in the form of unsigned integers are converted into octet-
   strings and back again using the technique described in [FUN-ECC].

8.2.2.  Encoding and Decoding of ECP Elements

   Elements in ECP groups are points on the negotiated elliptic curve.
   Each such element MUST be represented by the concatenation of two
   components, an x-coordinate and a y-coordinate.

   Each of the two components, the x-coordinate and the y-coordinate,
   MUST be represented (in binary form) as an unsigned integer that is
   strictly less than the prime, p, from the group's domain parameter



Harkins                  Expires January 1, 2011               [Page 13]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   set.  The binary representation of each component MUST have a bit
   length equal to the bit length of the binary representation of p.
   This length requirement is enforced, if necessary, by prepending the
   binary representation of the integer with zeros until the required
   length is achieved.

   The unsigned integers that represent the coordinates of the point are
   converted into octet-strings and back again using the technique
   described in [FUN-ECC].

   Since the field element is represented in a payload by the
   x-coordinate followed by the y-coordinate it follows, then, that the
   length of the element in the payload MUST be twice the bit length of
   p.

8.2.3.  Encoding and Decoding of MODP Elements

   Elements in MODP groups MUST be represented (in binary form) as
   unsigned integers that are strictly less than the prime, p, from the
   group's domain parameter set.  The binary representation of each
   group element MUST have a bit length equal to the bit length of the
   binary representation of p.  This length requirement is enforced, if
   necessary, by prepending the binary representation of the interger
   with zeros until the required length is achieved.

   The unsigned integer that represents a MODP element is converted into
   an octet-string and back using the technique described in [FUN-ECC].

8.3.  Message Generation and Processing

8.3.1.  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:

       scalar = (private + mask) mod r

   If the scalar is not greater than one (1), the private and mask
   values MUST be thrown away and new values randomly generated.  If the
   scalar is greater than one (1), the inverse of the scalar operation
   with the mask and SKE becomes the Element component.

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

   The Commit payload consists of the scalar followed by the Element and
   the scalar and Element are encoded in the Commit payload according to



Harkins                  Expires January 1, 2011               [Page 14]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   Section 8.2.

8.3.2.  Processing of a Commit

   Upon receipt of a peer's Commit the scalar and element MUST be
   validated.  The processing of an element depends on the type, either
   an ECP element or a MODP element.

8.3.2.1.  Validation of an ECP Element

   Validating a received ECP Element involves: 1) checking whether the
   two coordinates, x and y, are both greater than zero (0) and less
   than the prime defining the underlying field; and 2) checking whether
   the x- and y-coordinates satisfy the equation of the curve (that is,
   that they produce a valid point on the curve that is not "0").  If
   either of these conditions are not met the received Element is
   invalid, otherwise the received Element is valid.

8.3.2.2.  Validation of a MODP Element

   A received MODP Element is valid if: 1) it is between one (1) and the
   prime, p, exclusive; and 2) if modular exponentiation of the Element
   by the group order, r, equals one (1).  If either of these conditions
   are not true the received Element is invalid.

8.3.2.3.  Commit Processing Steps

   Commit validation is accomplished by the following steps:

   1.  The length of the Commit payload is checked against the
       anticipated size (the length of the scalar plus the length of the
       element for the negotiated group.  If it is incorrect, the Commit
       is invalidated, otherwise processing continues.

   2.  The peer's scalar is extracted from the Commit payload according
       to Section 8.2.1 and checked to ensure it is between one (1) and
       r, the order of the negotiated group, exclusive.  If it is not,
       the Commit is invalidated, otherwise processing continues.

   3.  The peer's Element is extracted from the Commit payload according
       to Section 8.2.2 and checked in a manner that depends on the type
       of group negotiated.  If the group is ECP the element is
       validated according to Section 8.3.2.1, if the group is MODP the
       element is validated according to Section 8.3.2.2.  If the
       Element is not valid then the Commit is invalidated, otherwise
       the Commit is validated.





Harkins                  Expires January 1, 2011               [Page 15]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   4.  The Initiator of the IKE exchange has an added requirement to
       verify that the received element and scalar from the Commit
       payload differ from the element and scalar sent to the Responder.
       If they are identical, it signifies a reflection attack and the
       Commit is invalidated.

   If the Commit is invalidated the payload MUST be discarded and the
   IKE exchange aborted.

8.3.3.  Authentication of the Exchange

   After a Commit has been generated and a peer's Commit has been
   processed a shared secret used 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, named
   here peer-scalar and peer-element, respectively, a preliminary shared
   secret, skey, is generated as:

        skey = F(scalar-op(private,
                           element-op(peer-element,
                                      scalar-op(peer-scalar, SKE))))

   For the purposes of subsequent computation, the bit length of skey
   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.

   A shared secret, ss, is then computed from skey using prf():

        ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")

   The shared secret, ss, is used in an authentication payload (either
   AUTH or HASH payload depending on whether IKEv1 or IKEv2,
   respectively, is being used) to prove possession of the shared
   secret, and therefore knowledge of the pre-shared key.

8.4.  Payload Format













Harkins                  Expires January 1, 2011               [Page 16]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


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

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

   The Prep field represents the password pre-processing technique (see
   Section 6) to be used prior to generating the ske-seed (see
   Section 8.1).  This document defines the following values for the
   Prep field:

   o   0x00 : None

   o   0x01 : RFC2759

   o   0x02 : SASLprep

   All other values of the Prep field are reserved to IANA.

   The Scalar and Element SHALL be encoded in the Commit payload
   according to Section 8.2.

8.5.  IKEv1 Messaging

   Secure PSK Authentication can be used in either Main Mode (see
   Figure 3) or Aggressive Mode (see Figure 4) with IKEv1 and SHALL be
   indicated by negotiation of the TBD2 Authentication Method from
   [IKEV1-IANA], in the SA payload.  When using IKEv1 the "C" (critical)
   bit from Section 8.4.1 MUST be clear (i.e. a value of zero).




Harkins                  Expires January 1, 2011               [Page 17]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


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

   where COMi is the Commit payload sent by the Initiator and COMr is
   the Commit payload sent by the Responder.

                     Figure 3: Secure PSK in Main Mode



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

   where COMi is the Commit payload sent by the Initiator and COMr is
   the Commit payload sent by the Responder.

                  Figure 4: Secure PSK in Aggressive Mode

   For Secure PSK Authentication with IKEv1 the SKEYID value is computed
   as follows:

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

   Note that in Main Mode, SKEYID_a and SKEYID_e are used to protect the
   messages containing the identities and Commit payloads.  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)

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




Harkins                  Expires January 1, 2011               [Page 18]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


8.6.  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 5).  The critical bit is used in the
   Commit payload to prevent a peer that does not support Secure PSK
   Authentication from inadvertantly attempting the insecure form of PSK
   authentication in [RFC4306]; it MUST be set (i.e. a value of one).


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

   where COMi is the Commit payload sent by the Initiator and COMr is
   the Commit payload sent by the Responder.

                       Figure 5: 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.3.3.  The
   Authentication Method indicated in the AUTH payload SHALL be TBD3
   from [IKEV2-IANA].


9.  IANA Considerations

   This memo contains a new numberspace to be managed by IANA, a
   registry used to indicate a password preprocessing technique.  The
   initial layout of this registry SHALL be:

   o   0x00 : None

   o   0x01 : RFC2759





Harkins                  Expires January 1, 2011               [Page 19]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   o   0x02 : SASLprep

   The Prep field is 8 bits long and all other values are available
   through assignment by IANA.  IANA is instructed to assign values
   based on "Specification Required" (see [RFC5226]).

   IANA SHALL assign a value for the Commit payload (Section 8.4.1), and
   replace TBD1 above, from the [IKEV2-IANA] of "IKEv2 Payload Types"
   with the notation of "COM".

   IANA SHALL assign a value for "Secure Shared Key Authentication",
   replacing TBD2 above, from the IPSEC Authentication Method registry
   in [IKEV1-IANA] with the method name of "Secure PSK Authentication."

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


10.  Security Considerations

   Both the Initiator and Responder obtain a shared secret, "ss" (see
   Section 8.3.3) 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 Responder of the exchange and
   send a forged Commit payload after receiving the Initiator's Commit.



Harkins                  Expires January 1, 2011               [Page 20]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   The attacker then waits until it receives the authentication payload
   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.3.3), 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 in the authentication payload.
   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 authentication
   payload 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
   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 pseudo-random function, prf,, 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 prf, 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



Harkins                  Expires January 1, 2011               [Page 21]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   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.  Thanks to Lily Chen for useful
   advice on the hunting-and-pecking technique to "hash into" an element
   in a group and to Jin-Meng Ho for a discussion on countering a small
   sub-group attack.  Rich Davis suggested several checks on received
   messages that greatly increase the security of the underlying key
   exchange.  Hugo Krawczyk suggested using the prf as an extractor.


12.  References

12.1.  Normative References

   [FUN-ECC]  McGrew, D., "Fundamental Elliptic Curve Cryptography
              Algorithms", draft-mcgrew-fundamental-ecc-01 (work in
              progress), October 2009.

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

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
              RFC 2759, January 2000.



Harkins                  Expires January 1, 2011               [Page 22]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
              and Passwords", RFC 4013, February 2005.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

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.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 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.

   [XAUTH]    Pereira, R. and S. Beaulieu, "Extended Authenticaiton
              within ISAKMP/Oakley (XAUTH)",



Harkins                  Expires January 1, 2011               [Page 23]


Internet-Draft      Secure PSK Authentication for IKE          June 2010


              draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress),
              December 1999.


Author's Address

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

   Email: dharkins@arubanetworks.com






































Harkins                  Expires January 1, 2011               [Page 24]