One document matched: draft-cakulev-ibake-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3830 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml'>
<!ENTITY rfc3711 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
<!ENTITY rfc4738 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4738.xml'>
<!ENTITY rfc4650 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4650.xml'>
<!ENTITY rfc4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY rfc4563 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml'>
<!ENTITY rfc5091 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5091.xml'>
<!ENTITY rfc5408 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5408.xml'>
<!ENTITY rfc5409 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5409.xml'>
<!ENTITY I-D.ietf-msec-mikey-ecc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-msec-mikey-ecc-03">
]>
<!-- <rfc category="info" ipr="full3978" category="std" docName="draft-cakulev-ibake-00.txt"> -->
<rfc ipr="pre5378Trust200902" category="std" docName="draft-cakulev-ibake-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='IBAKE'>
IBAKE: Identity-Based Authenticated Key Agreement
</title>
<author initials='V.' surname='Cakulev' fullname='Violeta Cakulev'>
<organization>Alcatel Lucent</organization>
<address>
<postal>
<street>600 Mountain Ave.</street>
<street>3D-517</street>
<city>Murray Hill</city> <region>NJ</region> <code>07974</code>
<country>US</country>
</postal>
<phone>+1 908 582 3207</phone>
<email>cakulev@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Ganapathy S. Sundaram" initials="G." surname="Sundaram">
<organization>Alcatel Lucent</organization>
<address>
<postal>
<street>600 Mountain Ave.</street>
<street>3D-517</street>
<city>Murray Hill</city> <region>NJ</region> <code>07974</code>
<country>US</country>
</postal>
<phone>+1 908 582 3209</phone>
<email>ganeshs@alcatel-lucent.com</email>
</address>
</author>
<date/>
<abstract><t>
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.
</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.</t>
<t>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.</t>
</section>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
<section title="Definitions">
<t>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 <xref target="RFC5091"/>,
<xref target="RFC5408"/> and <xref target="RFC5409"/>.</t>
</section>
<section title="Abbreviations">
<t><list hangIndent="12" style="hanging">
<t hangText="EC"> Elliptic Curve</t>
<t hangText="IBE"> Identity Based Encryption</t>
<t hangText="I"> Initiator</t>
<t hangText="IBAKE"> Identity Based Authenticated Key
Exchange</t>
<t hangText="IDi"> Initiator's Identity </t>
<t hangText="IDr"> Responder's Identity </t>
<t hangText="KGF"> Key Generation Function</t>
<t hangText="K_PR"> Private Key</t>
<t hangText="K_PUB"> Public Key</t>
<t hangText="PKI"> Public Key Infrastructure</t>
<t hangText="R"> Responder</t>
</list></t>
</section>
<section title="Conventions">
<t>
<list style='symbols'>
<t>E is an elliptic curve over a finite field F</t>
<t>P is a point on E of large prime order</t>
<t>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 <xref target="BF"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>dA = sQA is the private key computed by the KGF, corresponding to the public identity A, and delivered
only to A</t>
<t>H2 is a known hash function that takes an element of G and
assigns it to a string</t>
<t>E(k, A) denotes that A is IBE-encrypted with the key k</t>
<t>s||t denotes concatenation of the strings s and t</t>
<t>K_PUBx denotes Public Key of x</t>
</list>
</t>
</section>
</section>
<section title="Identity Based Authenticated Key Agreement">
<section title="Overview" anchor="overview">
<t>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.</t>
<t>
<figure title="Example IBAKE Message Exchange" anchor="example">
<artwork><![CDATA[
+---+ +---+
| I | | R |
+---+ +---+
MESSAGE_1
---------------------------------->
MESSAGE_2
<----------------------------------
MESSAGE_3
---------------------------------->
]]></artwork>
</figure>
</t>
<t>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
<xref target="RFC5091"/> and <xref target="RFC5408"/>.</t>
<t> 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 <xref target="RFC5091"/> and
<xref target="RFC5408"/>.</t>
<t>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.</t>
<t> 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.</t>
</section>
<section title="IBAKE Message Exchange">
<t>Initially, the Initiator selects a random x and computes xP;
The Responder selects a random y and computes yP. Then:</t>
<t>
<figure>
<artwork><![CDATA[
Initiator ----> Responder
MESSAGE_1 = E(K_PUBr, IDi || IDr || xP)
]]></artwork>
</figure>
</t>
<t>Upon receiving MESSAGE_1 message, the Responder SHALL
perform the following:</t>
<t>
<list style='symbols'>
<t>Decrypt the message as specified in
<xref target="RFC5091"/> and <xref target="RFC5408"/></t>
<t>Obtain xP</t>
<t>Encrypt the Initiator's identity (IDi), its own identity
(IDr), xP and yP using Initiator's Public Key (K_PUBi).</t>
</list>
</t>
<t>
<figure>
<artwork><![CDATA[
Responder ----> Initiator
MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP)
]]></artwork>
</figure>
</t>
<t>Upon receiving MESSAGE_2 message, the Initiator SHALL
perform the following:</t>
<t>
<list style='symbols'>
<t>Decrypt the message as specified in
<xref target="RFC5091"/> and <xref target="RFC5408"/></t>
<t>Verify that the received xP is the same as sent in
MESSAGE_1</t>
<t>Obtain yP</t>
<t>Encrypt its own identity (IDi), the Responder's identity
(IDr) and yP using Responder's Public Key (K_PUBi).</t>
</list>
</t>
<t>
<figure>
<artwork><![CDATA[
Initiator ----> Responder
MESSAGE_3 = E(K_PUBr, IDi || IDr || yP)
]]></artwork>
</figure>
</t>
<t>Upon receiving MESSAGE_3 message, the Responder SHALL
perform the following:</t>
<t>
<list style='symbols'>
<t>Decrypt the message as specified in
<xref target="RFC5091"/> and <xref target="RFC5408"/>.</t>
<t>Verify that the received yP is the same as sent in
MESSAGE_2</t>
</list>
</t>
<t>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</t>
</section>
<section title="Discussion">
<t>Properties of the protocol are as follows:</t>
<t>
<list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>KGF availability: KGFs are not contacted during IBAKE
protocol exchange, which dramatically reduces availability
requirements on KGF.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>This draft is based on the basic Identity Based Encryption
protocol, as specified in <xref target="BF"/>,
<xref target="RFC5091"/>),
<xref target="RFC5408"/> and <xref target="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.</t>
<t>Some additional security considerations are outlined below:
<list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The basic IBAKE protocol from a cryptographic perspective is
secure based on the following considerations.
<list style='symbols'>
<t>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
<xref target="BF"/>.</t>
<t>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 <xref target="example"/> in
<xref target="overview"/>).
<list style='symbols'>
<t>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.</t>
<t>For instance, assume that the IP source address and
destination address can be modified by the adversary.</t>
<t>After the first message is sent by the initiator (to the
responder), the adversary can take over and trap the
packet.</t>
<t>Next the adversary can modify the IP source address to
include adversary's IP address, before routing it onto
the responder.</t>
<t>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 <xref target="example"/> in
<xref target="overview"/>) but
encrypt it using the adversary's public key.</t>
<t>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.</t>
<t>Following this, the adversary can carry on a conversation
with the initiator "pretending" to be the responder.</t>
<t>This attack will be eliminated if identities are used as
part of the encrypted payload.</t>
</list>
</t>
<t>In summary, at the end of the exchange both initiator and responder can
mutually authenticate each other and agree on a session key.</t>
<t>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
<xref target="RFC5091"/>),
<xref target="RFC5408"/> and <xref target="RFC5409"/>.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>At this time there are no IANA considerations.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
</references>
<references title='Informative References'>
&rfc5091; &rfc5408; &rfc5409;
<reference anchor="BF">
<front>
<title>Identity-Based Encryption from the Weil Pairing</title>
<author initials='D.' surname='Boneh' fullname='Dan Boneh'>
<organization></organization>
</author>
<author initials='M.' surname='Franklin' fullname='Matthew K. Franklin'>
<organization></organization>
</author>
<date year="2003"></date>
</front>
<seriesInfo name='in SIAM J. of Computing, Vol. 32, No.' value='3' />
<seriesInfo name='pp.' value='586-615' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:04:37 |