IBAKE: Identity-Based Authenticated Key Agreement
draft-cakulev-ibake-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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 April 22, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

Cryptographic protocols based on public key methods are based on certificates and large scale public key infrastructure (PKI) to support certificate management. The emerging field of Identity Based Encryption protocols allows to simplify the infrastructure requirements via a Key Generation Function (KGF) while providing the same flexibility. However one significant limitation of Identity Based Encryption methods is that the KGF can end up being a de-facto key escrow server with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. Here, Identity Based Authenticated Key Exchange (IBAKE) Protocol is specified which does not suffer from the key escrow problem and in addition provides mutual authentication and a perfect forward and backwards secrecy.

Table of Contents

1.  Introduction
2.  Requirements notation
    2.1.  Definitions
    2.2.  Abbreviations
    2.3.  Conventions
3.  Identity Based Authenticated Key Agreement
    3.1.  Overview
    3.2.  IBAKE Message Exchange
    3.3.  Discussion
4.  Security Considerations
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

1.  Introduction

Authenticated Key Agreements are cryptographic protocols where two or more participants, authenticate each other and agree on a key for future communication. These protocols could be symmetric key or asymmetric public key protocols. Symmetric key protocols require an out-of-band security mechanism to bootstrap a secret key. On the other hand, public key protocols require certificates and large scale public key infrastructure. Clearly public key methods are more flexible, however the requirement for certificates and a large scale public key infrastructure have proved to be challenging. In particular, efficient methods to support large scale certificate revocation and management have proved to be elusive.

Recently, Identity Based Encryption (IBE) protocols have been proposed as a viable alternative to public key methods by simplifying the PKI requirements and replacing them with a simple Key Generation Function (KGF) to generate private keys. However, one significant limitation of Identity Based Encryption methods is that the KGF can end up being a de-facto key escrow server with undesirable consequences. Another limitation is a lack of mutual authentication between communicating parties. Here an Identity Based Authenticated Key Agreement Protocol is specified which does not suffer from the key escrow problem and Provides mutual authentication. Moreover the protocol also provides forward and backwards secrecy of session keys.

2.  Requirements notation

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 the corresponding private key to be calculated from the public key. The public key can then be used by an Initiator to encrypt messages which the recipient can decrypt using the corresponding private key. IBE framework is defined in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.), [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.) and [RFC5409] (Martin, L. and M. Schertler, “Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS),” January 2009.).

2.2.  Abbreviations

EC

Elliptic Curve

IBE

Identity Based Encryption

I

Initiator

IBAKE

Identity Based Authenticated Key Exchange

IDi

Initiator's Identity

IDr

Responder's Identity

KGF

Key Generation Function

K_PR

Private Key

K_PUB

Public Key

PKI

Public Key Infrastructure

R

Responder

2.3.  Conventions

• E is an elliptic curve over a finite field F
• P is a point on E of large prime order
• e: E x E -> G is a bi-linear map on E. G is the group of n-th roots of unity where n is a function of the number of points on E over F. Typical example of a bi-linear map is the Weil pairing [BF] (Boneh, D. and M. Franklin, “Identity-Based Encryption from the Weil Pairing,” 2003.).
• s is a non-zero positive integer. s is a secret stored in a Key Generation Function (KGF). This is a system-wide secret and not revealed outside the KGF.
• Ppub = sP is the public key of the system that is known to all participants. sP denotes a point in E, and denotes the point P added to itself s times where addition refers to the group operation one E.
• H1 is a known hash function that takes a string and assigns it to a point on the elliptic curve, i.e., H1(A) = QA on E, where A is usually based on the identity.
• dA = sQA is the private key computed by the KGF, corresponding to the public identity A, and delivered only to A
• H2 is a known hash function that takes an element of G and assigns it to a string
• E(k, A) denotes that A is IBE-encrypted with the key k
• s||t denotes concatenation of the strings s and t
• K_PUBx denotes Public Key of x

3.  Identity Based Authenticated Key Agreement

3.1.  Overview

IBAKE consists of a three-way exchange between an Initiator and a Responder. In the figure below, a conceptual signaling diagram of IBAKE is depicted.

            +---+                             +---+
            | I |                             | R |
            +---+                             +---+

                           MESSAGE_1
              ---------------------------------->
                           MESSAGE_2
              <----------------------------------
                           MESSAGE_3
              ---------------------------------->

The Initiator (I) and Responder (R) are attempting to mutually authenticate each other and agree on a key using IBAKE. This specification assumes that the Initiator and the Responder trust a third party, the Key Generation Function (KGF). Rather than a single KGF, several different KGFs may be involved, e.g. one for the Initiator and one for the Responder. The Initiator and the Responder do not share any credentials, however they know or can obtain each other's public parameters. This specification also assumes that the Initiator and Responder obtained their respective Private Keys from their respective KGFs prior to IBAKE message exchange. The procedures needed to obtain the privet keys and public parameters are outside of scope of this specification. The details of these procedures can be found in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.).

The Initiator and the Responder choose random x and y, respectively. In the first step, the Initiator computes xP (i.e., P added to itself x times as a point on E, using the addition law on E), encrypts xP, IDi and IDr using Responder’s public key (e.g., K_PUBr=H1(IDr||date)) and includes this encrypted information in a MESSAGE_1 message sent to the Responder. In this step encryption refers to identity based encryption described in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.).

The Responder, upon receiving the message, IBE-decrypts it using its private key (e.g. private key for that date), and obtains xP. The Responder next computes yP and IBE-encrypts Initiator's identity (IDi), its own identity (IDr), xP, and yP using Initiator's Public Key (e.g., K_PUBi=H1(IDi||date)). The initiator includes this encrypted information in MESSAGE_2 message sent to the Initiator.

The Initiator upon receiving and IBE-decrypting MESSAGE_2 obtains yP. Subsequently, the Initiator sends MESSAGE_3 message to the Responder, including IBE-encrypted IDi, IDr and yP. At this point both the Initiator and the Responder are able to compute the same session key as xyP.

3.2.  IBAKE Message Exchange

Initially, the Initiator selects a random x and computes xP; The Responder selects a random y and computes yP. Then:

Initiator    ---->      Responder

   MESSAGE_1 = E(K_PUBr, IDi || IDr || xP)

Upon receiving MESSAGE_1 message, the Responder SHALL perform the following:

• Decrypt the message as specified in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.)
• Obtain xP
• Encrypt the Initiator's identity (IDi), its own identity (IDr), xP and yP using Initiator's Public Key (K_PUBi).

Responder   ---->  Initiator

   MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP)

Upon receiving MESSAGE_2 message, the Initiator SHALL perform the following:

• Decrypt the message as specified in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.)
• Verify that the received xP is the same as sent in MESSAGE_1
• Obtain yP
• Encrypt its own identity (IDi), the Responder's identity (IDr) and yP using Responder's Public Key (K_PUBi).

Initiator    ---->      Responder

   MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)

Upon receiving MESSAGE_3 message, the Responder SHALL perform the following:

• Decrypt the message as specified in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.) and [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.).
• Verify that the received yP is the same as sent in MESSAGE_2

If any of the above verifications fails, the protocol halts; otherwise, following this exchange both the Initiator and the Responder have authenticated each other and are able to compute xyP as the session key

3.3.  Discussion

Properties of the protocol are as follows:

• Immunity from key escrow: Observe that all the steps in the protocol exchange are encrypted using IBE. So clearly the KGF can decrypt all the exchanges. However, the KGF cannot compute the session key. This is because of the hardness of the elliptic curve Diffie-Hellman problem. In other words, given xP and yP it is computationally hard to compute xyP.
• Mutually Authenticated Key Agreement: Observe that all the steps in the protocol exchange are encrypted using IBE. In particular only the Responder can decrypt the contents of the MESSAGE_1 and MESSAGE_3 sent by the Initiator, and similarly only the Initiator can decrypt the contents of the MESSAGE_2 sent by the Responder. Moreover, upon receiving MESSAGE_2, the Initiator can verify the Responder’s authenticity since xP could have been sent in MESSAGE_2 only after decryption of the contents of MESSAGE_1 by the Responder. Similarly, upon receiving MESSAGE_3, the Responder can verify the Initiator’s authenticity since yP could have been sent back in MESSAGE_3 only after correctly decrypting the contents of MESSAGE_2 and this is possible only by the Initiator. Finally both the Initiator and the Responder can agree on the same session key. In other words, the protocol is a mutually authenticated key agreement protocol based on IBE. The hardness of the key agreement protocol relies on the hardness of the Elliptic curve Diffie-Hellman problem. So clearly in any practical implementation care should be devoted to the choice of elliptic curve.
• Perfect forward and backwards secrecy: Since x and y are random, xyP is always fresh and unrelated to any past or future sessions between the Initiator and the Responder.
• No passwords: Clearly the IBAKE protocol does not require any offline exchange of passwords or secret keys between the Initiator and the Responder. In fact the method is applicable to any two parties communicating for the first time through any communication network. The only requirement is to ensure that both the Initiator and the Responder are aware of each other's public keys and public parameters of KGF which generated the corresponding private keys.
• KGF availability: KGFs are not contacted during IBAKE protocol exchange, which dramatically reduces availability requirements on KGF.

4.  Security Considerations

This draft is based on the basic Identity Based Encryption protocol, as specified in [BF] (Boneh, D. and M. Franklin, “Identity-Based Encryption from the Weil Pairing,” 2003.), [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.)), [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.) and [RFC5409] (Martin, L. and M. Schertler, “Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS),” January 2009.), and as such inherits some properties of that protocol. For instance, by concatenating the "date" with the identity (to derive the public key), the need for any key revocation mechanisms is virtually eliminated. Moreover, by allowing the participants to acquire multiple private keys (e.g., for duration of contract) the availability requirements on the KGF are also reduced without any reduction in security. The granularity associated with the "date" is a matter of security policy, and as such a decision made by the KGF administrator. However, the granularity applicable to any given participant should be publicly available and known to other participants. For example, this information can be made available in the same venue which provides "public information" of KGF server (i.e., P, sP) needed to execute IB encryption.

Some additional security considerations are outlined below:

• Attacks on the cryptographic algorithms used in Identity Based Encryption are outside the scope of this document. It is assumed that any administrator will pay attention to the desired strengths of the relevant cryptographic algorithms based on an up to date understanding of the strength of these algorithms from published literature as well as known attacks.
• It is assumed that the KGFs are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment.
• However, any malicious insider could potentially launch passive attacks (by decryption of one or more message exchanges offline). While it is in the best interest of administrators to prevent such issue, it is hard to eliminate this problem. Hence, it is assumed that such problems will persist, and hence the session key agreement protocols are designed to protect participants from passive adversaries.
• Communication between participants and their respective KGFs is expected to be secure, and as such outside the scope of this document. In any implementation of the protocols described in this document, administrators of any KGF have to ensure that communication with participants is secure and not compromised.
• Concatenating the "date" to the identity ensures that the corresponding private key is applicable only to that date. This serves to limit the damages related to a leakage or compromise of private keys to just that date. This in particular, eliminates the revocation mechanisms that are typical to various certificate based public key protocols.
• The basic IBAKE protocol from a cryptographic perspective is secure based on the following considerations.
  • In every step Identity Based Encryption (IBE) is used, with the recipient's public key. This guarantees that only the intended recipient of the message can decrypt the message [BF] (Boneh, D. and M. Franklin, “Identity-Based Encryption from the Weil Pairing,” 2003.).
  • Next, the use of identities within the encrypted payload is intended to eliminate some basic reflection attacks. For instance, suppose we did not use identities as part of the encrypted payload, in the first step of the IBAKE protocol (i.e., MESSAGE_1 of Figure 1 (Example IBAKE Message Exchange) in Section 3.1 (Overview)).
    • Assume an adversary who has access to the conversation between initiator and responder and can actively snoop into packets and drop/modify them before routing them to the destination.
    • For instance, assume that the IP source address and destination address can be modified by the adversary.
    • After the first message is sent by the initiator (to the responder), the adversary can take over and trap the packet.
    • Next the adversary can modify the IP source address to include adversary's IP address, before routing it onto the responder.
    • The responder will assume the request for an IBAKE session came from the adversary, and will execute step 2 of the IBAKE protocol (i.e., MESSAGE_2 of Figure 1 (Example IBAKE Message Exchange) in Section 3.1 (Overview)) but encrypt it using the adversary's public key.
    • The above message can be decrypted by the adversary (and only by the adversary). In particular, since the second message includes the challenge sent by the initiator to the responder, the adversary will now learn the challenge sent by the initiator.
    • Following this, the adversary can carry on a conversation with the initiator "pretending" to be the responder.
    • This attack will be eliminated if identities are used as part of the encrypted payload.
  • In summary, at the end of the exchange both initiator and responder can mutually authenticate each other and agree on a session key.
  • Recall that Identity Based Encryption guarantees that only the recipient of the message can decrypt the message using the private key. The caveat being, the KGF which generated the private key of recipient of message can decrypt the message as well. However, the KGF cannot learn the public key "xyP" given "xP" and "yP" based on the hardness of the Elliptic Curve Diffie-Hellman problem. This property of resistance to passive key escrow from the KGF, is not applicable to the basic IBE protocols proposed in [RFC5091] (Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2007.)), [RFC5408] (Appenzeller, G., Martin, L., and M. Schertler, “Identity-Based Encryption Architecture and Supporting Data Structures,” January 2009.) and [RFC5409] (Martin, L. and M. Schertler, “Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS),” January 2009.).
  • Observe that the protocol works even if the initiator and responder belong to two different KGFs. In particular, the parameters used for encryption to the responder and parameters used for encryption to the initiator can be completely different and independent of each other. Moreover, the Elliptic Curve used to generate the session key "xyP" can be completely different and chosen during the key exchange. If such flexibility is desired, then it would be required to add optional extra data to the protocol to exchange the algebraic primitives used in deriving the session key.
  • In addition to mutual authentication, and resistance to passive escrow, the Diffie-Hellman property of the session key exchange guarantees perfect secrecy of keys. In others, accidental leakage of one session key does not compromise past or future session keys between the same initiator and responder.

5.  IANA Considerations

At this time there are no IANA considerations.

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses