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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6631

Network Working Group                                         D. Kuegler
Internet-Draft                          Bundesamt fuer Sicherheit in der
Intended status: Experimental                  Informationstechnik (BSI)
Expires: January 12, 2011                                     Y. Sheffer
                                                             Independent
                                                           July 11, 2010


       Password Authenticated Connection Establishment with IKEv2
                  draft-kuegler-ipsecme-pace-ikev2-02

Abstract

   IKEv2 does not allow secure peer authentication when using short
   credential strings, i.e. passwords.  Several proposals have been made
   to integrate password-authentication protocols into IKE.  This
   document provides an adaptation of PACE (Password Authenticated
   Connection Establishment) to the setting of IKEv2 and demonstrates
   the advantages of this integration.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 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.  Code Components extracted from this document must



Kuegler & Sheffer       Expires January 12, 2011                [Page 1]

Internet-Draft               IKEv2 with PACE                   July 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Sequence  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . .  5
     3.2.  The IKE_PACE Exchange  . . . . . . . . . . . . . . . . . .  5
     3.3.  The IKE_PACE_AUTH Exchange . . . . . . . . . . . . . . . .  7
   4.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  MODP Diffie Hellman  . . . . . . . . . . . . . . . . . . .  8
     4.2.  Elliptic Curve Diffie Hellman  . . . . . . . . . . . . . .  8
     4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Password Processing  . . . . . . . . . . . . . . . . . . .  9
     5.2.  The PACE_SUPPORTED Notification  . . . . . . . . . . . . .  9
     5.3.  The ENONCE Payload . . . . . . . . . . . . . . . . . . . .  9
     5.4.  The PKE (PKEi/PKEr) Payloads . . . . . . . . . . . . . . . 10
     5.5.  PACE and Session Resumption  . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
     6.1.  Credential Security Assumptions  . . . . . . . . . . . . . 10
     6.2.  Vulnerability to Passive and Active Attacks  . . . . . . . 10
     6.3.  Perfect Forward Secrecy  . . . . . . . . . . . . . . . . . 11
     6.4.  Randomness . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.5.  Identity Protection  . . . . . . . . . . . . . . . . . . . 11
     6.6.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 11
     6.7.  Choice of Encryption Algorithms  . . . . . . . . . . . . . 11
     6.8.  Security Model and Security Proof  . . . . . . . . . . . . 11
     6.9.  Long-Term Credential Storage . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Protocol Selection Criteria . . . . . . . . . . . . . 13
     A.1.  Security Criteria  . . . . . . . . . . . . . . . . . . . . 14
     A.2.  Intellectual Property Criteria . . . . . . . . . . . . . . 14
     A.3.  Miscellaneous Criteria . . . . . . . . . . . . . . . . . . 14
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15







Kuegler & Sheffer       Expires January 12, 2011                [Page 2]

Internet-Draft               IKEv2 with PACE                   July 2010


1.  Introduction

   PACE [TR03110] is a security protocol that establishes a mutually
   authenticated (and encrypted) channel between two parties based on
   weak (short) passwords.  PACE provides strong session keys that are
   independent of the strength of the password.  This draft describes
   the integration of PACE into IKEv2 ([RFC4306] and
   [I-D.ietf-ipsecme-ikev2bis]) as a new authentication mode, analogous
   to the existing certificate and PSK authentication modes.

   Some of the advantages of our approach, compared to the existing
   IKEv2, include:
   o  The current best practice to implement password authentication in
      IKE involves certificate-based authentication of the server plus
      some EAP method to authenticate the client.  This involves two
      non-trivial infrastructure components (PKI and EAP/AAA).
      Moreover, certificate authentication is hard to get right, and
      often depends for its security on unreliable user behavior.
   o  Alternatively, native IKEv2 shared secret authentication can be
      used with passwords.  This usage however is insecure, specifically
      it is vulnerable to active attackers.
   o  Some newer EAP methods can be used for mutual authentication, and
      combined with [I-D.ietf-ipsecme-eap-mutual] can be well integrated
      into IKEv2.  This is certainly an option in some cases, but the
      current proposal may be simpler to implement.
   Compared to other protocols aiming at similar goals, PACE has several
   advantages.  PACE was designed to be free of patents, and to allow
   for a high level of flexibility with respect to cryptographic
   algorithms, e.g. it can be implemented based on standard Diffie
   Hellman as well as Elliptic Curve Diffie Hellman without any
   restrictions on the mathematical group to be used other than the
   requirement that the group is cryptographically secure.  The protocol
   itself is also proven to be cryptographically secure [PACEsec].

   The integration aims at keeping as much as possible of IKEv2
   unchanged, e.g. the mechanisms used to establish Child SAs as
   provided by IKEv2 are maintained with no change.

1.1.  Terminology

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

   The following notation is used in this draft:



Kuegler & Sheffer       Expires January 12, 2011                [Page 3]

Internet-Draft               IKEv2 with PACE                   July 2010


   E()    Symmetric encryption
   D()    Symmetric decryption
   KA()   Key agreement
   Map()  Mapping function
   Pwd    Shared Password
   KPwd   Symmetric key derived from a password Pwd
   G      Static group generator
   GE     Ephemeral group generator
   ENONCE Encrypted nonce
   PKEi   Ephemeral public key of the initiator
   SKEi   Ephemeral secret key of the initiator
   PKEr   Ephemeral public key of the responder
   SKEr   Ephemeral secret key of the responder
   AUTH   Authentication token


   At a high level the following steps are performed by the initiator
   and the responder.  They result in exchanges IKE_PACE and
   IKE_PACE_AUTH as described in Section 3 that are performed directly
   after IKE_SA_INIT and fully replace IKE_AUTH.
   1.  The initiator randomly and uniformly chooses a nonce, encrypts
       the nonce using the password, and sends the ciphertext ENONCE to
       the responder.
   2.  The responder recovers the plaintext nonce with the help of the
       shared password Pwd.
   3.  The initiator and the responder perform the following steps:
       A.  A mapping function Map() is used to derive an ephemeral
           generator GE = Map(G,s) from the exchanged nonce s and the
           generator G of the used group.
       B.  They perform an anonymous Diffie-Hellman key agreement based
           on the ephemeral generator and compute the shared secret
           PACESharedSecret.
       C.  They generate, exchange, and verify the authentication token
           AUTH using the shared secret PACESharedSecret.


3.  Protocol Sequence

   The protocol consists of three exchanges, IKE_SA_INIT, IKE_PACE, and
   IKE_PACE_AUTH as follows:











Kuegler & Sheffer       Expires January 12, 2011                [Page 4]

Internet-Draft               IKEv2 with PACE                   July 2010


    Initiator                      Responder
    ---------                      ---------

    IKE_SA_INIT:

    HDR, SAi1, KEi, Ni, N(PACE_SUPPORTED)  ->

                                <- HDR, SAr1, KEr, Nr, N(PACE_SUPPORTED)

    IKE_PACE:

    HDR, SK{IDi, [IDr,], SAi2,
            TSi, TSr, ENONCE, PKEi} ->

                                <- HDR, SK{IDr, PKEr}

    IKE_PACE_AUTH:

    HDR, SK{AUTH} ->

                                <- HDR, SK{AUTH, SAr2, TSi, TSr}


                     Figure 1: IKE SA Setup with PACE

3.1.  The IKE_SA_INIT Exchange

   The initiator sends a PACE_SUPPORTED notification to indicate its
   support of this extension, and its wish to authenticate using a
   password.  If the responder accepts, it responds with the same
   notification.  Otherwise, it omits the notification to indicate a
   preference for a regular IKE exchange.  In the case of anti-DOS
   cookies (Sec. 2.6 of [RFC4306]), the notification MUST be resent by
   each peer every time it sends its IKE_SA_INIT message.

   If PACE is supported, the algorithms negotiated in SAi1 and SAr1 are
   also used for the execution of PACE, i.e. the key agreement protocol
   (standard Diffie Hellman or Elliptic Curve Diffie Hellman), the group
   to be used, and the encryption algorithm.

3.2.  The IKE_PACE Exchange

   This new exchange (number TBD by IANA) is the first part of the PACE
   authentication of the peers.

   This exchange MUST NOT be used unless both peers indicated support of
   this protocol.  On the other hand, to allow for future extensibility,
   the initiator MAY choose to proceed with IKE_AUTH instead of



Kuegler & Sheffer       Expires January 12, 2011                [Page 5]

Internet-Draft               IKEv2 with PACE                   July 2010


   IKE_PACE, in which case the peers revert to a normal IKE exchange.

   The initiator selects a random nonce s and encrypts it to form ENONCE
   using the password Pwd, as described next.

   The shared password is not used as-is.  Instead, it SHOULD be
   converted into a "stored password" SPwd, so that the plaintext
   password does not need to be stored for long periods.  SPwd is
   defined as:
      SPwd = prf("IKE with PACE", Pwd)
   where the literal string consists of ASCII characters with no zero
   terminator.  If the negotiated prf requires a fixed-size key, the
   literal string is as needed either truncated or padded with zero
   octets on the right.
      KPwd = prf+(Ni | Nr, SPwd)
   where Ni and Nr are the regular IKE nonces, stripped of any headers.
   If the negotiated prf takes a fixed-length key and the lengths of Ni
   and Nr do not add up to that length, half the bits must come from Ni
   and half from Nr, taking the first bits of each. "prf+" is defined in
   Sec. 2.13 of [RFC4306].  The length of KPwd is determined by the key
   length of the negotiated encryption algorithm.

   A nonce s is randomly selected by the initiator (see Section 6.4 for
   additional considerations).  The length of s is the block size of the
   encryption algorithm that was negotiated for the IKE SA, or 32 octets
   if no such block size exists.  To clarify, stream ciphers constructed
   by applying a block cipher in counter mode, are to be treated as
   having no block size.

   Note: in the case of block ciphers, is critical to the security of
   the protocol that the nonce be encrypted with no padding.

   KPwd is now used with the encryption transform to encrypt the nonce:
      ENONCE = E(KPwd, s)
   If an Initialization Vector (IV) is required by the cipher, it MUST
   be random and is included in the ENONCE payload.

   The initiator maps the nonce to an ephemeral generator of the group
   as described in Section 4, chooses randomly and uniformly an
   ephemeral key pair (SKEi,PKEi) based on the ephemeral generator and
   finally generates the payloads ENONCE containing the encrypted nonce
   and PKEi containing the ephemeral public key.

   The responder decrypts the received encrypted nonce s = D(KPwd,
   ENONCE), performs the mapping and randomly and uniformly chooses an
   ephemeral key pair (SKEr,PKEr) based on the ephemeral generator.  The
   responder generates the PKEr payload containing the ephemeral public
   key.



Kuegler & Sheffer       Expires January 12, 2011                [Page 6]

Internet-Draft               IKEv2 with PACE                   July 2010


   During the Diffie-Hellman key agreement, each party MUST check that
   the two public keys PKEi and PKEr differ.  Otherwise, it MUST abort
   the protocol.

   The IKE_PACE request is equivalent to the IKE_AUTH request in a
   normal IKEv2 exchange, i.e. any payload which is valid in an IKE_AUTH
   request is valid (with the same semantics) in the IKE_PACE request.
   In particular, certificate-related payloads are allowed, even though
   their use may not be practical within this mode.

3.3.  The IKE_PACE_AUTH Exchange

   This new exchange (number TBD by IANA) is the second part of the PACE
   authentication of the peers.

   The initiator and the responder calculate the shared secret
   PACESharedSecret:
      PACESharedSecret = KA(SKEi, PKEi, GE) = KA(SKEr, PKEr, GE),
   where KA denotes the Diffie Hellman key agreement, e.g. (for MODP
   groups) modular exponentiation.  Then they calculate the
   authentication tokens AUTHi and AUTHr.

   The initiator calculates:

      AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
      <InitiatorSignedOctets> | PKEr)
   See Sec. 2.15 of [RFC4306] (further clarified in Sec. 2.15 of
   [I-D.ietf-ipsecme-ikev2bis]) for the definition of signed octets.

   The responder calculates:
      AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
      <ResponderSignedOctets> | PKEi)
   The authentication tokens are then exchanged and each of them MUST be
   verified by the other party.  The behavior when this verification
   fails is unchanged from [RFC4306].

   The IKE_PACE_AUTH response is equivalent to the IKE_AUTH response in
   a normal IKEv2 exchange, i.e. any payload which is valid in an
   IKE_AUTH response is valid (with the same semantics) in the
   IKE_PACE_AUTH response.

   Following authentication, all temporary values MUST be deleted by the
   peers, including in particular s, the ephemeral generator and public
   keys, and PACESharedSecret.







Kuegler & Sheffer       Expires January 12, 2011                [Page 7]

Internet-Draft               IKEv2 with PACE                   July 2010


4.  Mapping

   The mapping is based on a second anonymous Diffie-Hellman key
   agreement protocol to create a shared secret which is used together
   with the exchanged nonce to calculate a common secret generator of
   the group.

   While in [TR03110] the generation of the shared secret is part of the
   mapping, in the setting of IKEv2 a shared secret SASharedSecret has
   already been generated as part of the IKE_SA_INIT step.  Using the
   notation of [RFC4306],
      SASharedSecret = g^ir

   Let G and GE be the generator of the negotiated DH group, and the
   calculated ephemeral generator, respectively.  The following
   subsections describe the mapping for different Diffie Hellman
   variants.

4.1.  MODP Diffie Hellman

   The function Map:G->GE is defined as GE = G^s * SASharedSecret.

   Note that the protocol will fail if G^s = 1/SASharedSecret.  If s is
   chosen randomly, this event occurs with negligible probability.  In
   implementations that detect such a failure, the initiator SHOULD
   choose s again.

4.2.  Elliptic Curve Diffie Hellman

   The function Map:G->GE is defined as GE = s*G + SASharedSecret.

   Note that the protocol will fail if s*G = -SharedSecret.  If s is
   chosen randomly, this event occurs with negligible probability.  In
   implementations that detect such a failure, the initiator SHOULD
   choose s again.

4.3.  Validation

   Implementations MUST verify that the shared secrets SASharedSecret
   and PACESharedSecret are elements of the group generated by G to
   prevent small subgroup attacks.

   It is RECOMMENDED to use the public key validation method (or an
   Elliptic Curve equivalent) described in Section 2.1.5 of [RFC2631].

   For Elliptic Curves compatible cofactor multiplication [TR03111] MAY
   be used instead of public key validation.  In this case
   implementations MUST check that PACESharedSecret is not the point at



Kuegler & Sheffer       Expires January 12, 2011                [Page 8]

Internet-Draft               IKEv2 with PACE                   July 2010


   infinity.

   Any failure in the validation MUST be interpreted as an attack, and
   the protocol aborted.


5.  Protocol Details

5.1.  Password Processing

   The input password string SHOULD be processed according to the rules
   of the [RFC4013] profile of [RFC3454].  A password SHOULD be
   considered a "stored string" per [RFC3454] and unassigned code points
   are therefore prohibited.  The output is the binary representation of
   the processed UTF-8 character string.  Prohibited output and
   unassigned codepoints encountered in SASLprep preprocessing SHOULD
   cause a preprocessing failure and the output SHOULD NOT be used.

5.2.  The PACE_SUPPORTED Notification

   This protocol defines a new PACE_SUPPORTED notification, with type
   number TBD by IANA.  This is an empty notification: The Protocol ID
   and SPI size fields are set to zero, and there is no additional data
   associated with this notification.

5.3.  The ENONCE Payload

   This protocol defines a new ENONCE (encrypted nonce) payload, with
   payload type TBD by IANA.  Its format is as follows:



    0                   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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |    (optional, length is block size for encryption algorithm)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Encrypted Nonce                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 2: ENONCE Payload Structure




Kuegler & Sheffer       Expires January 12, 2011                [Page 9]

Internet-Draft               IKEv2 with PACE                   July 2010


   The length of the nonce MUST be an integer multiple of the selected
   encryption algorithm's block size (if any).  Note that the payload
   format does not support any padding of the encrypted data.

5.4.  The PKE (PKEi/PKEr) Payloads

   These payloads have an identical format to the IKEv2 KE payload.
   However, this protocol defines a new payload type named PKE (Public
   Key - Ephemeral), whose value is TBD by IANA.  Since only one Diffie
   Hellman group is negotiated, the group denoted by these payloads MUST
   be identical to the one used in the KE payloads.

5.5.  PACE and Session Resumption

   A session resumption [RFC5723] ticket may be requested during the
   IKE_PACE/IKE_PACE_AUTH exchanges.  The request MUST be sent in the
   IKE_PACE request, and any response MUST be sent in the IKE_PACE_AUTH
   response.

   PACE should be considered an "authentication method", in the sense of
   Sec. 5 of [RFC5723], which means that its use MUST be noted in the
   protected ticket.

   Note that even if the initial authentication used PACE and its new
   exchange types, session resumption will still include the normal
   IKE_AUTH exchange.


6.  Security Considerations

   A major goal of this protocol has been to maintain the level of
   security provided by IKEv2.  What follows is an analysis of this
   protocol.  The reader is referred to [RFC4306] and
   [I-D.ietf-ipsecme-ikev2bis] for the generic IKEv2 security
   considerations.

6.1.  Credential Security Assumptions

   This protocol makes no assumption on the strength of the shared
   credential.  Best common practices regarding minimal password length,
   use of multiple character classes etc.  SHOULD be followed.

6.2.  Vulnerability to Passive and Active Attacks

   The protocol is secure against both passive and active attackers.
   See Section 6.8 for a security proof.

   While not attacking the cryptography, an attacker can still perform a



Kuegler & Sheffer       Expires January 12, 2011               [Page 10]

Internet-Draft               IKEv2 with PACE                   July 2010


   standard password guessing attack.  To mitigate such attacks, an
   implementation MUST include standard protections, such as rate
   limiting the number of allowed password guessing attempts, possibly
   locking identities out after a certain number of failed attempts etc.
   Note that the protocol is symmetric and therefore this guidance
   applies to client-side implementations as well.

6.3.  Perfect Forward Secrecy

   TBD.

6.4.  Randomness

   The security of this protocol depends on the quality generation of
   random quantities, and see Sec. 5 of [RFC4306] for more details.
   Specifically, any deviation from randomness of the nonce s might
   compromise the password, when the nonce is encrypted with a stream
   cipher.  Therefore, it is strongly RECOMMENDED that when using a
   stream cipher, the initiator passes the raw random material through a
   strong prf to ensure the statistical qualities of the nonce.

6.5.  Identity Protection

   This protocol is identical to IKEv2 in the quality of identity
   protection it provides.  Both peers' identities are secure from
   passive attackers, and both peers' identities are exposed to active,
   man-in-the-middle attackers.

6.6.  Denial of Service

   We are not aware of any new denial-of-service attack vector enabled
   by this protocol.

6.7.  Choice of Encryption Algorithms

   Any transforms negotiated for IKEv2 may be used by this protocol.

6.8.  Security Model and Security Proof

   TODO: PACE is cryptographically proven secure in [PACEsec].  The
   application of PACE in IKEv2 however is however a slightly different
   setting that requires a modification of the proof.  A new proof will
   be provided once the details of the integration are fixed.

6.9.  Long-Term Credential Storage

   This protocol does not require peers to store the plaintext password.
   Instead, the value KPwd SHOULD be stored by both peers.



Kuegler & Sheffer       Expires January 12, 2011               [Page 11]

Internet-Draft               IKEv2 with PACE                   July 2010


   It has been suggested to generate a "long" shared secret after the
   initial authentication, such that the peers can use it later for
   standard preshared-secret authentication, in lieu of the short
   password.  We have not been able to identify sufficient security
   benefits with this approach that would justify the added complexity.


7.  IANA Considerations

   IANA is requested to allocate (has allocated) the following values:
   o  The PACE_SUPPORTED notification type (TBD) from the "IKEv2 Notify
      Message Types - Status Types" registry.
   o  A payload type (TBD) for the Encrypted Nonce (ENONCE) payload from
      the "IKEv2 Payload Types" registry.
   o  A payload type (TBD) for the Ephemeral Public Key (PKE) payload
      from the same registry.
   o  An authentication method (TBD) for Password Authenticated
      Connection Establishment (PACE) from the "IKEv2 Authentication
      Method" registry.
   o  An exchange type (TBD) for the IKE_PACE exchange, from the "IKEv2
      Exchange Types" registry.
   o  An exchange type (TBD) for the IKE_PACE_AUTH exchange, from the
      same registry.
   This document does not define any new registries.


8.  References

8.1.  Normative References

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

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, June 1999.

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






Kuegler & Sheffer       Expires January 12, 2011               [Page 12]

Internet-Draft               IKEv2 with PACE                   July 2010


8.2.  Informative References

   [I-D.harkins-ipsecme-pake-criteria]
              Harkins, D., "Password-Based Authentication in IKEv2:
              Selection Criteria and Considerations",
              draft-harkins-ipsecme-pake-criteria-00 (work in progress),
              April 2010.

   [I-D.ietf-ipsecme-eap-mutual]
              Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
              for EAP-Only Authentication in IKEv2",
              draft-ietf-ipsecme-eap-mutual-05 (work in progress),
              June 2010.

   [I-D.ietf-ipsecme-ikev2bis]
              Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol: IKEv2",
              draft-ietf-ipsecme-ikev2bis-11 (work in progress),
              May 2010.

   [PACEsec]  "Security Analysis of the PACE Key-Agreement Protocol",
              Information Security Conference (ISC) 2009, Lecture Notes
              in Computer Science, Volume 5735, pp. 33-48, Springer-
              Verlag.", 2009.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              January 2010.

   [TR03110]  "BSI TR-03110, Advanced Security Mechanisms for Machine
              Readable Travel Documents - Extended Access Control (EAC),
              Password Authenticated Connection Establishment (PACE),
              and Restricted Identification (RI), Version 2.03", 2010.

   [TR03111]  "BSI TR-03111, "Elliptic Curve Cryptography", Version
              1.11", 2009.


Appendix A.  Protocol Selection Criteria

   To support the selection of a password-based protocol for inclusion
   in IKEv2, a number of criteria are provided in
   [I-D.harkins-ipsecme-pake-criteria].  In the following sections,
   those criteria are applied to the PACE protocol.







Kuegler & Sheffer       Expires January 12, 2011               [Page 13]

Internet-Draft               IKEv2 with PACE                   July 2010


A.1.  Security Criteria

   SEC1:  PACE is a zero knowledge protocol.
   SEC2:  The protocol supports perfect forward secrecy and is resistant
          to replay attacks.
   SEC3:  The identity protection provided by IKEv2 remains unchanged.
   SEC4:  Any cryptographically secure Diffie-Hellman group can be used.
   SEC5:  The protocol is proven secure in the Bellare-Pointcheval-
          Rogaway model.
   SEC6:  Strong session keys are generated.
   SEC7:  A transform of the password can be used instead of the
          password itself.

A.2.  Intellectual Property Criteria

   IPR1:  The first draft of [TR03110] was published on May 21, 2007.
   IPR2:  BSI has developed PACE aiming to be free of patents.  BSI has
          not applied for a patent on PACE.
   IPR3:  The protocol itself is believed to be free of IPR.

A.3.  Miscellaneous Criteria

   MISC1:   One additional exchange is required.
   MISC2:   The protocol requires the following operations per entity:
            *  one key derivation from the password,
            *  one symmetric encryption or decryption,
            *  one multi-exponentiation for the mapping,
            *  one exponentiation for the key pair generation,
            *  one exponentiation for the shared secret calculation, and
            *  two symmetric authentications (generation and
               verification).
   MISC3:   The performance is independent of the type/size of password.
   MISC4:   Internationalization of character-based passwords is
            supported.
   MISC5:   The protocol uses the same group as negotiated for IKEv2.
   MISC6:   The protocol fits into the request/response nature of IKE.
   MISC7:   The password-based symmetric encryption must be additionally
            negotiated.
   MISC8:   Neither trusted third parties nor clock synchronization are
            required.
   MISC9:   Only general cryptographic primitives are required.
   MISC10:  Any secure variant of Diffie Hellman (e.g. standard or
            Elliptic Curve) can be used.
   MISC11:  The protocol can be implemented easily based on existing
            cryptographic primitives.






Kuegler & Sheffer       Expires January 12, 2011               [Page 14]

Internet-Draft               IKEv2 with PACE                   July 2010


Appendix B.  Change Log

   Note to RFC Editor: please remove this appendix before publication.

B.1.  -02

   Added security considerations.  Changed encryption of the nonce.
   Simplified the derivation of the AUTH payloads.

B.2.  draft-kuegler-ipsecme-pace-ikev2-01

   Formalized the protocol: added payload formats, error behavior etc.


Authors' Addresses

   Dennis Kuegler
   Bundesamt fuer Sicherheit in der Informationstechnik (BSI)
   Postfach 200363
   Bonn  53133
   Germany

   Email: dennis.kuegler@bsi.bund.de


   Yaron Sheffer
   Independent

   Email: yaronf.ietf@gmail.com






















Kuegler & Sheffer       Expires January 12, 2011               [Page 15]


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