Skip to main content

I-PAKE: Identity-Based Password Authenticated Key Exchange
draft-kwon-yoon-kim-ipake-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Hyojin Yoon , Sang Youb Kim
Last updated 2013-03-12 (Latest revision 2012-11-04)
RFC stream Independent Submission
Formats
Stream ISE state Response to Review Needed
Revised I-D Needed
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state I-D Exists::Revised I-D Needed
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kwon-yoon-kim-ipake-00
Internet Engineering Task Force                T.Kwon, Sejong University
INTERNET-DRAFT                                      H. Yoon, Samsung SDS
Intended Status: Standards Track                     S. Kim, Samsung SDS
Expires: May 6, 2013                                    November 2, 2012

      I-PAKE: Identity-Based Password Authenticated Key Exchange  
                   draft-kwon-yoon-kim-ipake-00

Abstract

   Although password authentication is the most widespread user
   authentication method today, cryptographic protocols for mutual
   authentication and key agreement, i.e., password authenticated key
   exchange (PAKE), in particular authenticated key exchange (AKE) based
   on a password only, are not actively used in the real world. This
   document introduces a quite novel form of PAKE protocols that employ
   a particular concept of ID-based encryption (IBE). The resulting
   cryptographic protocol is the ID-based password authenticated key
   exchange (I-PAKE) protocol which is a secure and efficient PAKE
   protocol in both soft- and hard-augmented models. I-PAKE achieves the
   security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also
   achieves the great efficiency by allowing the whole pre-computation
   of the ephemeral Diffie-Hellman public keys by both server and
   client.

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
 

                          Expires May 6, 2013                   [Page 1]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

Copyright and License Notice

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

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
     2.1 Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2 Abbreviations  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3 Underlying Group . . . . . . . . . . . . . . . . . . . . . .  6
     2.4 Notations  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3 Identity-Based Password Authenticated Key Exchange . . . . . . .  9
     3.1 Initialization . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.1 System Initialization  . . . . . . . . . . . . . . . . .  9
       3.1.2 Registration . . . . . . . . . . . . . . . . . . . . . .  9
     3.2 Protocol Execution . . . . . . . . . . . . . . . . . . . . .  9
   4  Security Considerations . . . . . . . . . . . . . . . . . . . . 13
     4.1 General - Completeness . . . . . . . . . . . . . . . . . . . 13
       4.1.1 Mutual Authentication  . . . . . . . . . . . . . . . . . 13
       4.1.2 Key Agreement  . . . . . . . . . . . . . . . . . . . . . 13
     4.2 I-PAKE - AKE Security  . . . . . . . . . . . . . . . . . . . 13
       4.2.1 Passive Attacks  . . . . . . . . . . . . . . . . . . . . 13
       4.2.2 Active Attacks . . . . . . . . . . . . . . . . . . . . . 14
       4.2.3 Forward Secrecy  . . . . . . . . . . . . . . . . . . . . 15
       4.2.4 Known Session Key  . . . . . . . . . . . . . . . . . . . 15
       4.2.5 Key Control  . . . . . . . . . . . . . . . . . . . . . . 16
     4.3 I-PAKE - Dictionary Attack . . . . . . . . . . . . . . . . . 16
       4.3.1 On-line Dictionary Attack  . . . . . . . . . . . . . . . 16
       4.3.2 Off-line Dictionary Attack . . . . . . . . . . . . . . . 17
     4.4 I-PAKE - Server Compromise . . . . . . . . . . . . . . . . . 17
       4.4.1 Soft-Augmented Model . . . . . . . . . . . . . . . . . . 17
       4.4.2 Hard-Augmented Model . . . . . . . . . . . . . . . . . . 18
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
 

                          Expires May 6, 2013                   [Page 2]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1  Normative References  . . . . . . . . . . . . . . . . . . . 18
     6.2  Informative References  . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

 

                          Expires May 6, 2013                   [Page 3]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

1  Introduction

   The most widespread user authentication method today is obviously
   password-based authentication; a user memorizes a textual and/or
   numerical password and makes its direct entry for authentication. 

   There have been various attempts to enhance security of password-
   based authentication. Password authenticated key exchange (PAKE) is a
   cryptographic protocol to achieve both mutual authentication and
   secure key agreement based on a password only, i.e., without
   requiring a public key certificate [IEEE P1363.2]. That is, PAKE is
   an authenticated key exchange (AKE) protocol based on the user-
   memorable low-entropy password, so that both authenticated entities
   can only agree on a fresh session key. Augmented PAKE protocols allow
   a server to store a one-way function of password instead of the plain
   text, so as to mitigate the server compromise [RFC2945].

   PAKE protocols, however, have not been deployed actively despite of
   their merits. Instead, for example, Web applications employ the
   SSL/TLS suite for secure transport of password information at the
   cost of manipulating and relying on server's public key certificates
   with regard to long-term security. This is in part due to that the
   password transport over SSL/TLS is easier for migration of existing
   password-based systems on the Web and also that PAKE protocols
   require a large amount of computation for security enhancement, e.g.,
   for encrypting ephemeral Diffie-Hellman public keys under the low-
   entropy password. There still remains a security concern as for the
   augmented PAKE protocols. The protocols which said to resist a server
   compromise are prone to off-line guessing attacks if the server is
   really compromised. The password information stored in the server's
   storage for verification purposes can be exploited by adversaries to
   derive real passwords. Consequently, users are still in great
   danger.

   This document raises the fundamental questions as above to the
   existing form of PAKE protocols and attempts to provide a novel
   design to resolve these problems. We depart from the previous way of
   encrypting the ephemeral Diffie-Hellman public keys under the low-
   entropy password. Instead we map <ID, password> to <salt, verifier>
   for authentication. To the protocol, the former pair is the user
   input derived from the user's memory, while the latter is the server
   input fetched from the server's storage. We also introduce the hard-
   augmented model which enhances the previous, soft-augmented model for
   sever compromise security, based on the hardware security module
   (HSM). For the purposes, a particular concept of identity-based
   encryption (IBE) is employed. At the cost of pre-computation of the
   salt alphabet as for the ID alphabet, we can reduce the amount of
   computation in real time, i.e., at registration and authentication.
 

                          Expires May 6, 2013                   [Page 4]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

   The resulting cryptographic protocol is the Identity-based password
   authenticated key exchange (I-PAKE) protocol which is a secure and
   efficient PAKE protocol in both soft- and hard-augmented models. I-
   PAKE achieves the security goals of AKE, PAKE, and hard-augmented
   PAKE. I-PAKE also achieves the great efficiency by allowing the whole
   pre-computation of the ephemeral Diffie-Hellman public keys by both
   server and client.

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

2.  Requirements Notation

2.1 Definitions

   Identity Based Encryption (IBE): Identity-based encryption (IBE) is a
   public-key encryption technology that allows a public key to be
   calculated from an identity and a set of public mathematical
   parameters and that allows for the corresponding private key to be
   calculated from an identity, a set of public mathematical parameters,
   and a domain-wide secret value [RFC5408]. The IBE framework is
   defined in [RFC5091], [RFC5408], and [RFC5409].

   Password Authenticated Key Exchange (PAKE): Password authenticated
   key exchange (PAKE) is a cryptographic protocol to achieve both
   mutual authentication and key agreement securely based on a password
   only, i.e., without requiring a public key certificate. That is, PAKE
   is a form of authenticated key exchange (AKE) which is in particular
   based on the password for authentication. The PAKE framework is
   defined in [IEEE P1363.2], [ISO/IEC 11770-4], and [RFC2945].

2.2 Abbreviations

   TDL               Trapdoor Discrete Logarithm

   IBE               Identity Based Encryption

   I-PAKE            Identity-Based Password Authenticated Key Exchange

   AKE               Authenticated Key Exchange

 

                          Expires May 6, 2013                   [Page 5]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

   PKG               Private Key Generator

   HSM               Hardware Security Module

   MAC               Message Authentication Code

   SSL/TLS           Secure Socket Layer/Transport Layer Security

   CDH               Computational Diffie-Hellman

2.3 Underlying Group

   The I-PAKE protocol can be implemented over the following group.

   Let N =p*q where p and q are sufficiently large B-smooth prime such
   that p = 3 (mod 4), q = 3 (mod 4), gcd(p - 1, q - 1) = 2. Let G be a
   multiplicative cyclic subgroup of Z_N^* with a generator g = g_m^2
   where g_m is a generator of a maximal cyclic subgroup of Z_N^* of
   order phi(N)/2. The order of g is phi(N)/4.

2.4 Notations

   a||b
      A concatenation of a and b.

   A
      The alphabet of ID. An alphanumeric set is commonly used.

   T
      The alphabet of private salt. A set of discrete logarithms of the
      A's elements in G. This set is maintained privately by the
      server's  HSM_s.

   P
      The alphabet of password. An alphanumeric set with special
      characters is commonly used.

   User
      A human user who actually remembers a pair of ID and password for
      authentication.

   ID
      User's identity which is represented ID = ID_1||ID_2|| ... ||
      ID_alpha where the ID_i is an element of Set A for all i in {1,2,
      ..., alpha}.

   Client or C
 

                          Expires May 6, 2013                   [Page 6]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

      A protocol entity providing a user interface to User for ID and
      password entry, and a system interface to a remote server for
      running the protocol. Client represents User in the protocol.

   Server or S
      A protocol entity providing a system interface to Client for
      running the protocol, and storing a 3-tuple of ID, salt, and
      password-verifier for authentication.

   HSM_t and HSM_v
      Private hardware attached to Server. HSM_t stores Set T and is
      used for deriving private salt given ID. HSM_v is only used in the
      hard-augmented model for computing a password-verifier.

   h
      A known random hash function which takes an arbitrary finite bit
      string and assigns it to an element of Z_N^*, where Z_N^* is a set
      of positive integers modulo N which are not zero divisors. In
      practice, a cryptographically secure one-way hash function is
      used.

   H
      It is defined as H(ID) = (h(ID))^2 for an ID. By definition, H
      takes an ID and assigns it to an elements of G. That is H(ID) = I
      is in G. In fact, ID = ID_1||ID_2|| ... || ID_alpha, H(ID) is
      calculated as H(ID_1) * H(ID_2) * ... * H(ID_alpha). 

   h_i (i = 0, 1, 2, 3, 4, 5, 6)
      Known random hash functions. In practice, a cryptographically
      secure one-way hash function is used with distinct indices i. Each
      h_i takes an arbitrary finite bit string and assigns it to a
      finite string. The bit size of output of each h_i can be different
      from each other.

   t_ID
      The secret key of the client whose identity is ID. t_ID is a
      discrete logarithm of I = H(ID) based on g. That is, t_ID = log_g
      H(ID) = log_g H(ID_1) * H(ID_2) * ... * H(ID_alpha) = log_g
      H(ID_1) + log_g H(ID_2) + ... + log_g H(ID_alpha) = t_ID_1 +
      t_ID_2 + ... + t_ID_alpha.

   pw and PW
      "pw" is the password maintained by Client. Importantly, pw can be
      a plaintext of password, exactly remembered by User, or a one-way
      hash function of it, depending on the protocol and Server
      implementation. "PW" is the password maintained by Server.
      Importantly, PW can be equal to pw, exactly maintained by Client,
      or a one-way hash function of it, or a MAC of it, depending on the
 

                          Expires May 6, 2013                   [Page 7]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

      protocol and Server implementation.

   V_PW
      A password-verifier maintained by Server, such that V_PW =
      h(ID,t_ID,PW). This value is derived from PW by hashing in the
      soft-augmented model or MAC in the hard-augmented model. That is
      PW = h'(pw) or PW = MAC_hk(pw), where h' is a cryptographically
      secure one-way hash function, MAC_hk is a message authentication
      code that takes an element in P and assigns it to a finite bit
      string where hk is a secret key of HSM_v.

   X and Y
      Ephemeral Diffie-Hellman public keys. X=g^x mod N and Y=g^y mod N,
      respectively, for randomly chosen x and y in Z_N^*.

   E_K(pw)
      Encryption of pw under the ephemeral high-entropy key K. The
      encryption function E is a secure symmetric key encryption
      function, for example, AES.

   C_1 and C_2
      Confirmation messages in the protocol.

 

                          Expires May 6, 2013                   [Page 8]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

3 Identity-Based Password Authenticated Key Exchange

   I-PAKE is a two-party protocol where Client and Server authenticate
   each other and generate a session key together, based on a human-
   memorable password and ID information. For the purpose, the client
   and the server exchange messages involving ephemeral keying
   information and agree on a fresh session key.

3.1 Initialization

   The initialization SHOULD be finished before the I-PAKE protocol
   execution.

3.1.1 System Initialization

   Server MAY negotiate with PKG or play the role of PKG by itself, so
   as to generate system parameters including underlying group
   parameters, ID and salt alphabets, and required functions.

   Server MUST keep the salt alphabet, T, secure, e.g., in HSM_t, after
   the initialization.

   In the hard-augmented model, Server MUST initialize HSM_v as well.

3.1.2 Registration

   User SHOULD select ID and a memorable password, and register them to
   Server through a secure channel. The secure channel at registration
   is out of scope in this document.

   Client MAY receive the User's input and set the password as pw, so as
   to submit ID and pw to Server.

   Server MUST fetch the discrete logarithms of H(ID_i) from T for ID,
   and set their sum as User's salt, t_ID. Server MAY set the received
   pw as PW, so as to compute a password-verifier.

   In the hard-augmented model, Server MUST negotiate with HSM_v for
   obtaining PW such that PW = MAC_hk(pw). In the soft-augmented model,
   Server MAY set PW as a function of pw.

   Server SHOULD store ID, t_ID, and V_PW in its storage after computing
   the password-verifier such that V_PW = h(ID,t_ID,PW)

   User MAY update the memorable password with a new one, and register
   it to Server again.

3.2 Protocol Execution
 

                          Expires May 6, 2013                   [Page 9]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

   User MUST input ID and password at the user interface provided by
   Client. The protocol SHOULD be executed between Server and Client.

      +------------+                 +-------------+
      |            |                 |             |
      |   Client   |     MESSAGE_1   |   Server    |
      |            |  -------------> |             |
      |            |     MESSAGE_2   |             |
      |            |  <------------  |             |
      |            |     MESSAGE_3   |             |
      |            |  -------------> |             |     +-------+
      |            |     MESSAGE_4   |             | --- | HSM_v |
      |            |  <------------- |             |     +-------+
      |            |                 |             |
      +------------+                 +-------------+

      Client  ----> Server 

        Client SHALL choose a random x from Z_N^* and computes its
        ephemeral Diffie-Hellman public key X = g^x mod N. It is an
        OPTION that this computation MAY be done as pre-computation.

          MESSAGE_1 = ID, X

      Server  ----> Client 

        If the received value X is 1, 0, or -1, then Server MUST
        terminate this protocol execution. Upon receiving MESSAGE_1,
        Server SHALL select a random y from Z_N^* and compute Y=g^y mod
        N. It is an OPTION that this computation MAY be done as pre-
        computation.

          MESSAGE_2 = Y

      Client  ----> Server 

        If the received value Y is 1, 0, or -1, then Client MUST
        terminate this protocol execution. Upon receiving MESSAGE_2,
        Client SHALL perform the following: 

        o Action 1: Calculate I = H(ID).

        o Action 2: Calculate e = h_0(ID,C,S,X,Y,I).

        o Action 3: Calculate Z = (YI^e)^x mod N.
 

                          Expires May 6, 2013                  [Page 10]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        o Action 4: Calculate the secret key K = h_1(ID,C,S,X,Y,I,Z).

        o Action 5: Calculate the session key sk = h_2(ID,C,S,X,Y,I,Z).

        o Action 6: Encrypt the password pw using the secret key K,
        E_K(pw).

        o Action 7: Calculate C_1 = h_3(ID,C,S,X,Y,I,sk).

          MESSAGE_3 = E_K(pw), C_1

      Server  ----> Client 

        Upon receiving MESSAGE_3, Server SHALL perform the following:

        o Action 1: Calculate I = H(ID).

        o Action 2: Calculate e = h_0(ID,C,S,X,Y,I).

        o Action 3: Calculate Z' = X^(y+t_ID*e) mod N.

        o Action 4: Calculate the secret key K' = h_1(ID,C,S,X, Y, I,
        Z').

        o Action 5: Calculate the session key sk' = h_2(ID,C,S,X, Y, I,
        Z').

        o Action 6: Decrypt the received E_K(pw) using the secret key
        K'.

        o Action 7: Calculate the password verifier V_PW =
        h(ID,t_ID,PW), where PW is MAC_hk(pw) in the hard-augmented
        model or h(pw) in the soft-augmented model.

        If the calculated V_PW is not equal to the saved V_PW then
        Server MUST terminate this protocol execution. Otherwise, Server
        SHALL perform the following:

        o Action 8: Calculate C_1' = h_3(ID,C,S,X,Y,I,sk).

        If the received C_1 in MESSAGE_3 is not equal to C_1' then
        Server MUST terminate this protocol execution. Otherwise, Server
        shall perform the following:

        o Action 9: Calculate C_2 = h_4(ID,C,S,X,Y,I,sk').

 

                          Expires May 6, 2013                  [Page 11]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

          MESSAGE_4 = C_2

        Since (YI^e)^x = (g^y * (g^sID)^e)^x = g^xy * g^((s_ID)ex) = X^y
        * X^(s_ID * e) = X^(y + s_ID*e), K = K' and sk = sk'. That is,
        Server calculates the same secret key with Client and can
        decrypt the MESSAGE_3 and obtain the same password pw. Server
        can confirm that Client is now operated by authenticated User
        and agree on the session key sk to be shared with Client.

      Client 

        Upon receiving MESSAGE_4, Client SHALL perform the following:

        o Action 1: Calculate C_2' = h_4(ID,C,S,X,Y,I,sk').

        If the received C_2 does not equal to C_2' then Client MUST
        terminate this protocol execution. Otherwise, Client can confirm
        that Server is authenticated and agree on the session key sk to
        be shared with Server.

 

                          Expires May 6, 2013                  [Page 12]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

4  Security Considerations

4.1 General - Completeness

        The I-PAKE protocol is a cryptographic protocol that achieves
        mutual authentication and key agreement, based on a human-
        memorable password and ID information, between two entities.

4.1.1 Mutual Authentication

        A user is authenticated by a server through a pair of ID and
        memorable password pw in the I-PAKE protocol. For the purpose, a
        client of the user should submit the encryption of pw under a
        correct fresh encryption key K, along with the user's ID, in the
        protocol. Note that pw can be a secure one-way hash function of
        real memorable password.

        The server is authenticated by the client through the private
        salt, that is, the user's ID information based on IBE, in the I-
        PAKE protocol. For the purpose, the server must show the
        confirmation that the same session key has been derived based on
        the private salt.

4.1.2 Key Agreement

        A client and a server both exchange ephemeral Diffie-Hellman
        public keys, X and Y, and agree on the same key incorporating
        the correct Diffie-Hellman key based on them.

4.2 I-PAKE - AKE Security

        The I-PAKE protocol is an AKE protocol based on a memorable
        password and ID information. Thus, it fulfills the requirements
        of AKE security.

4.2.1 Passive Attacks

        We say that an AKE protocol is secure against passive attacks if
        an adversary who merely observes honest entities carrying out
        the protocol, fails to derive a session key, which was
        authenticated and agreed by the honest entities.

        IPAKE is a secure AKE protocol because the messages, (U, X), (S,
        Y), C1, and C2, eavesdropped by a passive attacker, do not
        reveal the corresponding session key, sk, due to the CDH problem
        and the secure one-way hash function.

 

                          Expires May 6, 2013                  [Page 13]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        More specifically, sk and K are secure one-way hash functions of
        protocol messages involving the seed key, zk, denoted as
        follows.

        zk=Z*Z'^e mod N 

        Note that Z is a Diffie-Hellman key of X and Y, i.e., Z=g^(xy)
        mod N; Z' can be seen as another form of the Diffie-Hellman key
        of X and I, i.e., Z=g^(xt) mod N; and e is a secure one-way hash
        function of protocol messages involving X, Y, and I, i.e.,
        e=h0(U,S,X,Y,I).

        The confirmation messages, C1 and C2, are secure one-way hash
        functions of protocol messages involving sk.

        The I-PAKE protocol is secure against the passive attacks.

4.2.2 Active Attacks

        We say that an AKE protocol is secure against active attacks if
        an adversary who controls the protocol messages, e.g., by
        injection, interception, replay, and/or modification, fails to
        subvert the communications of the honest entities.

        o Impersonation of client: In order to impersonate a client of a
        target user, an adversary should obtain the encryption of pw
        under a fresh encryption key K and its confirmation message C1.
        (1) Although the adversary can inject a new message X to the
        protocol and derive K from x and Y, the probability of
        constructing the correct encryption of pw is bounded by the
        password space. (2) Although the adversary can replay the old
        message X' generated previously by the honest client, the new
        encryption key K must be different from the old encryption key
        K' due to the server's new ephemeral key Y that is different
        from the old ephemeral key Y'. In both cases, the adversary
        cannot construct the correct encryption of pw and its
        confirmation message C1, and thus fails to impersonate the
        client.

        o Impersonation of server: In order to impersonate a server, an
        adversary should obtain a correct encryption key K and its
        confirmation message C2. (1) Although the adversary can inject a
        new message Y to the protocol, the probability of computing K is
        bounded by the salt space. (2) Although the adversary can replay
        the old message Y' generated previously by the honest server,
        the new decryption key K must be different from the old
        encryption key K' due to the client's new ephemeral key X that
        is also distinct from the old ephemeral key X'. (3) Although the
 

                          Expires May 6, 2013                  [Page 14]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        adversary can modify a new message Y, e.g., Y=g^y*I^(1/e') mod
        N, for the purpose of canceling out I and so the slat s when
        computing a fresh key K from X, Y, and the secure one-way hash
        function e, the probability of obtaining e' such that e'=e must
        be bounded by the collision resistance of the hash function. In
        all cases, the adversary cannot obtain a correct encryption key
        K and its confirmation message C2, and thus fails to impersonate
        the server.

        o Man-in-the-middle attack: In order to reside as a middle man
        in the protocol, an adversary should enforce a fresh encryption
        key K, encryption of pw, and confirmation messages C1 and C2,
        according to her own key X' and Y', respectively. Although the
        adversary can intercept X and Y, and inject her own key X' and
        Y' to replace them, respectively, into the protocol, the
        probability of computing K against a client is bounded by the
        salt space while that of constructing the encryption of pw
        against the server is bounded by the password space. The
        adversary fails to reside as a middle man in the protocol.

        The I-PAKE protocol is secure against the active attacks.

4.2.3 Forward Secrecy

        We say AKE provides forward secrecy when the secrecy of previous
        session keys is not affected even if long-term secrets, such as
        passwords and private salt in the I-PAKE protocol, of one or
        more entities are compromised.

        If the password is compromised, an adversary should inspect the
        protocol messages of the previous sessions that incorporate the
        password but only is the encryption of pw from a conventional
        block cipher system. Due to the security assumption of the block
        cipher, the ephemeral encryption key K is not derivable. Even if
        K is also compromised, the previous session key is not derivable
        due to the security assumption of one-way hash function.

        If the private salt is compromised, the adversary should inspect
        the protocol messages of the previous sessions that incorporate
        the salt but only is the ID information. Due to the hardness
        assumption of the Diffie-Hellman problem, the previous session
        key is not derivable from X and Y.

        The I-PAKE protocol provides the forward secrecy.

4.2.4 Known Session Key

        We say AKE is secure against known session key attacks if the
 

                          Expires May 6, 2013                  [Page 15]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        protocol achieves its goal even if an adversary learned some
        previous session keys.

        If the previous session key sk is compromised, an adversary
        should inspect the protocol messages of the previous and/or
        future sessions but only is the confirmation message. Due to the
        hardness assumption of the Diffie-Hellman problem and the
        security assumption of one-way hash function, the old session
        keys neither reveal the password and salt information nor
        enforce forged key agreement.

        The I-PAKE protocol is secure against the known session key
        attacks.

4.2.5 Key Control

        We say AKE is secure against key control attacks if neither
        entity is able to force the session key to be a function of a
        pre-selected value, such as either X or Y.

        Due to the the hardness assumption of the Diffie-Hellman
        problem, neither entity can enforce the key agreement on a pre-
        selected value.

        The I-PAKE protocol is secure against the key control attacks.

4.3 I-PAKE - Dictionary Attack

        The I-PAKE protocol is a PAKE protocol that incorporates IBE.
        Thus, it fulfills the requirements of PAKE security against
        dictionary attacks.

4.3.1 On-line Dictionary Attack

        We say PAKE is secure against on-line dictionary attacks if an
        active adversary in the client side is only able to test a
        single guess from a password dictionary per on-line attempt
        while a server is able to count the number of failed attempts
        consistently, and also in the server side cannot test any guess
        from the password dictionary per on-line attempt. Note that the
        second requirement is very important in practical settings.

        In order to test a guessed password on-line in the client side,
        the adversary should send the honest server the encryption of
        guessed password and its confirmation C1 after exchanging X and
        Y. The adversary can verify the guess according to the response
        of the server, while the server can also verify it and count its
        failure due to the decryption result. If the failure count gets
 

                          Expires May 6, 2013                  [Page 16]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        to the limit, the server can lock the corresponding account.

        In order to test a guessed password on-line in the server side,
        the adversary should decrypt out the password which was
        encrypted by the honest client after exchanging X and Y. The
        adversary cannot verify the guess because the corresponding
        decryption key K is not derivable.

        The I-PAKE protocol is secure against the on-line dictionary
        attacks.

4.3.2 Off-line Dictionary Attack

        We say PAKE is secure against off-line dictionary attacks if an
        active adversary is only able to remove at most a single guess
        from a password dictionary per session, and a passive adversary
        cannot remove any guess from the dictionary.

        As described in the on-line dictionary attack, the active
        adversary can only remove a single guess from the dictionary in
        the client side, and no guess in the server side per session.

        As described in the passive attack, the passive adversary cannot
        derive a decryption key K, and thus cannot remove any guess from
        the dictionary per session.

        The I-PAKE protocol is secure against the off-line dictionary
        attacks.

4.4 I-PAKE - Server Compromise

        The I-PAKE protocol is an augmented PAKE protocol that fulfills
        the requirements of PAKE security against server compromise, not
        only in the previous (soft-) augmented model but also in the new
        hard-augmented model.

4.4.1 Soft-Augmented Model

        We say PAKE is secure against the server compromise in the soft-
        augmented model if an adversary who obtained a password
        verification directory stored by the server cannot impersonate
        the client of the target user directly, i.e., without launching
        the off-line dictionary attack. Note that the off-line
        dictionary attack is possible for the server compromise in the
        soft-augmented model.

        Since the server stores only ID, salt, and verifier in the
        password verification directory, the adversary who obtained the
 

                          Expires May 6, 2013                  [Page 17]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

        directory cannot construct the encryption of password.

        The I-PAKE protocol is secure against the server compromise in
        the soft-augmented model.

4.4.2 Hard-Augmented Model

        We say PAKE is secure against the server compromise in the hard-
        augmented model if an adversary who obtained a password
        verification directory stored by the server cannot impersonate
        the client of the target user and launch the off-line dictionary
        attack. The basic assumption is that the HSM module is never
        compromised.

        Since the server stores only ID, salt, and verifier in the
        password verification directory, the adversary who obtained the
        directory cannot construct the encryption of password.

        Since the verifier is the MAC of password information under the
        MAC key which is only stored in the HSM module, the adversary
        who obtained the directory cannot launch the off-line dictionary
        attack.

        The I-PAKE protocol is secure against the server compromise in
        the hard-augmented model.

5  IANA Considerations

        This document includes no request to IANA.

6  References

6.1  Normative References

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

   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
              RFC 2945, September 2000.

6.2  Informative References

   [RFC5408]  Appenzeller, G., Martin, L., and M. Schertler, "Identity-
              Based Encryption Architecture and Supporting Data
              Structures", RFC 5408, January 2009.
 

                          Expires May 6, 2013                  [Page 18]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

   [RFC5409]  Martin, L. and M. Schertler, "Using the Boneh-Franklin and
              Boneh-Boyen Identity-Based Encryption Algorithms with the
              Cryptographic Message Syntax (CMS)", RFC 5409, January
              2009.

   [RFC5091]  Boyen, X. and L. Martin, "Identity-Based Cryptography
              Standard (IBCS) #1: Supersingular Curve Implementations of
              the BF and BB1 Cryptosystems", RFC 5091, December 2007.

   [IEEE P1363.2]  
              IEEE P1363.2, "Password-Based Public-Key Cryptography",
              Submissions to IEEE P1363.2, <http://grouper.ieee.org/
              groups/1363/passwdPK/submissions.html>.

   [ISO/IEC 11770-4]  
              ISO/IEC JTC 1/SC 27 11770-4, "Information technology -
              Security techniques - Key management - Part 4: Mechanisms
              based on weak secrets", May 2006, <http://
              www.iso.org/iso/iso_catalogue/catalogue_tc/
              catalogue_detail.htm?csnumber=39723>.

Authors' Addresses

              Taekyoung Kwon
              Sejong University
              98 Kunja-dong, Kwangjin-gu
              Seoul 143-747, Korea

              EMail: tkwon@sejong.edu

              Hyojin Yoon
              Samsung SDS
              5th Fl., Medison Bldg.,
              Daechi-dong, Gangnam-gu,
              Seoul 135-280, Korea

              EMail: hj1230.yoon@samsung.com

              Sangyoub Kim
              Samsung SDS
              4th Fl., Medison Bldg.,
              Daechi-dong, Gangnam-gu,
              Seoul 135-280, Korea
 

                          Expires May 6, 2013                  [Page 19]
INTERNET DRAFT                   I-PAKE                 November 2, 2012

              EMail: sy9.kim@samsung.com

                          Expires May 6, 2013                  [Page 20]