Network Working Group V. Cakulev
Internet-Draft G. Sundaram
Intended status: Informational Alcatel Lucent
Expires: March 18, 2011 September 14, 2010
IBAKE: Identity-Based Authenticated Key Agreement
draft-cakulev-ibake-02.txt
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.
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 March 18, 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
Cakulev & Sundaram Expires March 18, 2011 [Page 1]
Internet-Draft IBAKE September 2010
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.
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.
Cakulev & Sundaram Expires March 18, 2011 [Page 2]
Internet-Draft IBAKE September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Identity Based Authenticated Key Agreement . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. IBAKE Message Exchange . . . . . . . . . . . . . . . . . . 8
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. IBAKE Protocol . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Cakulev & Sundaram Expires March 18, 2011 [Page 3]
Internet-Draft IBAKE September 2010
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.
Cakulev & Sundaram Expires March 18, 2011 [Page 4]
Internet-Draft IBAKE September 2010
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].
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], [RFC5408] and [RFC5409].
2.2. Abbreviations
EC Elliptic Curve
IBE Identity Based Encryption
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
2.3. Conventions
o E is an elliptic curve over a finite field F
o P is a point on E of large prime order
o 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].
Cakulev & Sundaram Expires March 18, 2011 [Page 5]
Internet-Draft IBAKE September 2010
o 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.
o 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.
o 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.
o dA = sQA is the private key computed by the KGF, corresponding to
the public identity A, and delivered only to A
o H2 is a known hash function that takes an element of G and assigns
it to a string
o E(k, A) denotes that A is IBE-encrypted with the key k
o s||t denotes concatenation of the strings s and t
o K_PUBx denotes Public Key of x
Cakulev & Sundaram Expires March 18, 2011 [Page 6]
Internet-Draft IBAKE September 2010
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
---------------------------------->
Figure 1: Example IBAKE Message Exchange
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 private keys and public parameters
are outside of scope of this specification. The details of these
procedures can be found in [RFC5091] and [RFC5408].
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] and [RFC5408].
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
Cakulev & Sundaram Expires March 18, 2011 [Page 7]
Internet-Draft IBAKE September 2010
(IDi), its own identity (IDr), xP, and yP using Initiator's Public
Key (e.g., K_PUBi=H1(IDi||date)). The Responder 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:
o Decrypt the message as specified in [RFC5091] and [RFC5408]
o Obtain xP
o 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:
o Decrypt the message as specified in [RFC5091] and [RFC5408]
o Verify that the received xP is the same as sent in MESSAGE_1
o Obtain yP
o Encrypt its own identity (IDi), the Responder's identity (IDr) and
yP using Responder's Public Key (K_PUBi).
Cakulev & Sundaram Expires March 18, 2011 [Page 8]
Internet-Draft IBAKE September 2010
Initiator ----> Responder
MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)
Upon receiving MESSAGE_3 message, the Responder SHALL perform the
following:
o Decrypt the message as specified in [RFC5091] and [RFC5408].
o 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:
o 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.
o 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.
Cakulev & Sundaram Expires March 18, 2011 [Page 9]
Internet-Draft IBAKE September 2010
o 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.
o 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.
o KGF availability: KGFs are not contacted during IBAKE protocol
exchange, which dramatically reduces availability requirements on
KGF.
Cakulev & Sundaram Expires March 18, 2011 [Page 10]
Internet-Draft IBAKE September 2010
4. Security Considerations
This draft is based on the basic Identity Based Encryption protocol,
as specified in [BF], [RFC5091]), [RFC5408] and [RFC5409], 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.
4.1. General
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.
In addition, it is assumed that the communication between
participants and their respective KGFs is secure. Therefore, 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.
Finally, 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
Cakulev & Sundaram Expires March 18, 2011 [Page 11]
Internet-Draft IBAKE September 2010
public key protocols.
4.2. IBAKE Protocol
For the basic IBAKE protocol from a cryptographic perspective
following security considerations apply.
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].
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 in
Section 3.1). Furthermore, 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 in
Section 3.1) 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]),
[RFC5408] and [RFC5409].
Observe that the protocol works even if the initiator and responder
Cakulev & Sundaram Expires March 18, 2011 [Page 12]
Internet-Draft IBAKE September 2010
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.
Cakulev & Sundaram Expires March 18, 2011 [Page 13]
Internet-Draft IBAKE September 2010
5. IANA Considerations
At this time there are no IANA considerations.
Cakulev & Sundaram Expires March 18, 2011 [Page 14]
Internet-Draft IBAKE September 2010
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.
6.2. Informative References
[BF] Boneh, D. and M. Franklin, "Identity-Based Encryption from
the Weil Pairing", in SIAM J. of Computing, Vol. 32,
No. 3, pp. 586-615, 2003.
[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.
[RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity-
Based Encryption Architecture and Supporting Data
Structures", RFC 5408, January 2009.
[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.
Cakulev & Sundaram Expires March 18, 2011 [Page 15]
Internet-Draft IBAKE September 2010
Authors' Addresses
Violeta Cakulev
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3207
Email: violeta.cakulev@alcatel-lucent.com
Ganapathy S. Sundaram
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3209
Email: ganesh.sundaram@alcatel-lucent.com
Cakulev & Sundaram Expires March 18, 2011 [Page 16]