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

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

INTERNET-DRAFT                                                D. Kuegler
Intended Status: informational                                     (BSI)
Expires: November 4, 2010                                    May 3, 2010


       Password Authenticated Connection Establishment with IKEv2
                draft-kuegler-ipsecme-pace-ikev2-00.txt


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/1id-abstracts.html

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


Copyright and License 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
   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.






Kuegler                 Expires November 4, 2010                [Page 1]

INTERNET DRAFT                    PACE                       May 3, 2010


Abstract

   This document provides an adaptation of PACE (Password Authenticated
   Connection Establishment) to the setting of IKEv2 to allow for a
   password-based authentication mode.

Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
      1.1  Security Criteria . . . . . . . . . . . . . . . . . . . . . 3
      1.2  Intellectual Property Criteria  . . . . . . . . . . . . . . 4
      1.3  MISC Criteria . . . . . . . . . . . . . . . . . . . . . . . 4
      1.4  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3  Protocol Sequence  . . . . . . . . . . . . . . . . . . . . . . . 5
      3.1  The IKE_SA_INIT Exchange  . . . . . . . . . . . . . . . . . 6
      3.2  The IKE_PACE Exchange . . . . . . . . . . . . . . . . . . . 7
      3.3  The IKE_PACE_AUTH Exchange  . . . . . . . . . . . . . . . . 7
   4  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      4.1  Diffie Hellman  . . . . . . . . . . . . . . . . . . . . . . 8
      4.2  Elliptic Curve Diffie Hellman . . . . . . . . . . . . . . . 8
      4.3  Validation  . . . . . . . . . . . . . . . . . . . . . . . . 8
   5  Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
   6  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 9
   7  References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
      7.1  Normative References  . . . . . . . . . . . . . . . . . . . 9
      7.2  Informative References  . . . . . . . . . . . . . . . . . . 9
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10























Kuegler                 Expires November 4, 2010                [Page 2]

INTERNET DRAFT                    PACE                       May 3, 2010


1  Introduction

   This is a preliminary draft describing the possible integration of
   the password-based authentication protocol PACE [TR03110] in IKEv2.

   PACE establishes an 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.

   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
   mathematic 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, i.e. the mechanisms used to establish session keys as
   provided by IKEv2 are completely maintained.

   NOTE: Due to the adaptations of the original protocol [TR03110], the
   proof [PACEsec] requires some modifications, that will be provided
   once the details of the integration are fixed.


   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.

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




Kuegler                 Expires November 4, 2010                [Page 3]

INTERNET DRAFT                    PACE                       May 3, 2010


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

1.3  MISC Criteria

   MISC1:  One additional exchange is required.
   MISC2:  The protocol requires the following operations per entity:
           o  one key derivation from the password,
           o  one symmetric encryption or decryption,
           o  one multi-exponentiation for the mapping,
           o  one exponentiation for the key pair generation,
           o  one exponentiation for the shared secret calculation, and
           o  two symmetric authentications (generation & 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.

1.4  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:

      E()   Symmetric encryption
      D()   Symmetric decryption
      KA()  Key agreement
      Map() Mapping function
      Pwd   Shared Password



Kuegler                 Expires November 4, 2010                [Page 4]

INTERNET DRAFT                    PACE                       May 3, 2010


      KPwd  Symmetric key derived from a password Pwd
      G     Static group generator
      GE    Ephemeral group generator
      CIPH  Enciphered 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 are partially replacing IKE_AUTH.

      1. The initiator randomly and uniformly chooses a nonce, encrypts
         the nonce, and sends the ciphertext CIPH to the responder.

      2. The responder recovers the plaintext 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 = KA(SKEi, PKEi, GE) = KA(SKEr, PKEr, GE).

            During the Diffie-Hellman key agreement, each party SHOULD
            check that the two public keys PKEi and PKEr differ.

         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                 Expires November 4, 2010                [Page 5]

INTERNET DRAFT                    PACE                       May 3, 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, CIPH, PKEi} ->

                                 <- HDR, SK{IDr, PKEr}

     IKE_PACE_AUTH:

     HDR, SK{AUTH} ->

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


3.1  The IKE_SA_INIT Exchange

   Within this exchange the initiator and the responder negotiate the
   use of PACE by exchanging a PACE_SUPPORTED notifications.

   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 authentication algorithm.

   In addition, a new transform type is used to negotiate the password-
   based encryption of the nonce. This transform includes the cipher and
   it's mode of operation as well as the bit length of the nonce to be
   used.

   NOTE: The password-based encryption MUST NOT introduce any redundancy
   that allows for excluding possible plaintexts with a brute-force
   attack on the password.

   An example for a suitable password based encryption is a block cipher
   in ECB mode using key KPwd = prf+(Pwd, "PACE Password") which is
   derived from the shared password Pwd. In this case the size of the
   nonce SHALL be the block size of the cipher.





Kuegler                 Expires November 4, 2010                [Page 6]

INTERNET DRAFT                    PACE                       May 3, 2010


3.2  The IKE_PACE Exchange

   The initiator selects a nonce s as binary bit string. The nonce MUST
   be chosen randomly and uniformly, the length of the nonce SHALL be
   according to the negotiated value. The nonce is encrypted to CIPH =
   E(Pwd, s) using the negotiated password based-encryption using the
   password Pwd.

   NOTE: The is no other requirement on the generation of the nonce
   other than the fact that it MUST be random and uniformly
   distributed.

   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 CIPH containing the encrypted nonce
   and PKEi containing the ephemeral public key.

   The responder decrypts the received encrypted nonce s = D(Pwd, CIPH),
   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.


3.3  The IKE_PACE_AUTH Exchange

   The initiator and the responder calculate the shared secret
   PACESharedSecret, derive the authentication key, and calculate the
   authentication token AUTH.

   The initiator calculates:

   AUTH = prf(prf+(PACESharedSecret, "PACE Authentication i" | IDr |
          IDi), PKEr)

   The responder calculates:

   AUTH = prf(prf+(PACESharedSecret, "PACE Authentication r" | IDi |
          IDr), PKEi)

   The authentication token are then exchanged and verified by the other
   party.


4  Mapping

   The mapping is based on a second anonymous Diffe-Hellman key
   agreement protocol to create a shared secret which is used together



Kuegler                 Expires November 4, 2010                [Page 7]

INTERNET DRAFT                    PACE                       May 3, 2010


   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. This shared
   secret SHALL be reused.

   Let G, and GE be the generator of the group, and the calculated
   ephemeral generator, respectively.


4.1  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.
   Implementations that detect such a failure 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.
   Implementations that detect such a failure 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
   infinity.

   Any failure in the validation SHALL be interpreted as an attack.


5  Security Considerations



Kuegler                 Expires November 4, 2010                [Page 8]

INTERNET DRAFT                    PACE                       May 3, 2010


   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  IANA Considerations

   TBD: One notification (N(PACE_SUPPORTED)), one transform type
   (Password-based Encryption), two payloads (CIPH, PKEi/PKEr) and an
   Auth Method Identifier.


7  References

7.1  Normative References

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

   [RFC2361]   E. Rescorla, "Diffie-Hellman key agreement method",
               RFC 2631, 1999

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


7.2  Informative References

   [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

   [PACEsec]   J. Bender, M. Fishlin, D. Kuegler, "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. Full
               version available at http://eprint.iacr.org/2009/624






Kuegler                 Expires November 4, 2010                [Page 9]

INTERNET DRAFT                    PACE                       May 3, 2010


Author's Addresses


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

   EMail: dennis.kuegler@bsi.bund.de









































Kuegler                 Expires November 4, 2010               [Page 10]


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