RFC 6539

IBAKE: Identity-Based Authenticated Key Exchange

📅 published March 2012, from ietf

RFC 6539: IBAKE: Identity-Based Authenticated Key Exchange 🎀

Okay bestie, this is RFC 6539, and it's a hot take on how two people can prove who they are to each other without a giant certificate system. 💅

It's an Independent Submission and the category is Informational 🌸. The ISSN is 2070-1721, and it was published in March 2012. The authors are V. Cakulev, G. Sundaram, and I. Broustis, all from Alcatel Lucent 💜. There is no Obsoletes or Updates line in this one, so it doesn't replace or change any other RFC according to its own header.

Abstract ✨

Okay so, public-key crypto has always leaned on certificates and a PKI (Public Key Infrastructure) to manage everything 📜. Identity-Based Encryption (IBE) is the newer glow-up 🦋. It gets rid of a lot of that infrastructure using a Private-Key Generator (PKG), and you still get the same flexibility.

BUT, and this is a big but 😭, an IBE setup can end up with the PKG acting as a de facto key escrow server, and that has some really undesirable consequences. The other problem is that there's no mutual authentication between the two parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol 👑. IBAKE doesn't have the key escrow problem, it gives you mutual authentication, and it also gives you perfect forward and backward secrecy. Iconic 🙌.

Status of This Memo

Not gonna lie, this part is a bit of a formality, but it matters 💀. This document is not an Internet Standards Track specification. It's published for informational purposes only 📚.

It's a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that.

For the current status of this document, any errata, and how to give feedback, check out http://www.rfc-editor.org/info/rfc6539 🌈.

Independent Submissions Editor Note

This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol 🔥. Because it's pretty specialized, it only got limited review within the Internet Community 🙈. So if you're a reader, please carefully evaluate its value before you implement or deploy it. Seriously, be careful 🫶.

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), as they're in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document 💜.

Table of Contents

1. Introduction ....................................................2
2. Requirements Notation ...........................................3
   2.1. IBE: Definition ............................................3
   2.2. Abbreviations ..............................................3
   2.3. Conventions ................................................4
3. Identity-Based Authenticated Key Exchange .......................5
   3.1. Overview ...................................................5
   3.2. IBAKE Message Exchange .....................................6
   3.3. Discussion .................................................7
4. Security Considerations .........................................9
   4.1. General ....................................................9
   4.2. IBAKE Protocol ............................................10
5. References .....................................................12
   5.1. Normative References ......................................12
   5.2. Informative References ....................................12

1. Introduction

Okay so, authenticated key agreements are crypto protocols where two or more participants prove who they are to each other and agree on key material to secure whatever they talk about next 🔐. These can be symmetric-key or asymmetric public-key protocols.

Symmetric-key protocols need an out-of-band security mechanism to bootstrap a secret key 🗝️. Public-key protocols usually need certificates and a large-scale PKI. Public-key methods are clearly more flexible, but needing certificates and a large-scale PKI has been really challenging. Efficient ways to do large-scale certificate revocation and management have been elusive, honestly 😩.

Recently, Identity-Based Encryption (IBE) protocols showed up as a viable alternative to public-key methods 🦋. They swap the PKI out for a Private-Key Generator (PKG). BUT one major limitation of IBE is that the PKG can end up as a de facto key escrow entity (meaning an entity that has enough info to decrypt communicated data), and that comes with undesirable consequences. Another limitation is no mutual authentication between communicating parties.

This document specifies an Identity-Based Authenticated Key Encryption (IBAKE) protocol that doesn't have the key escrow problem and does provide mutual authentication ✨. The scheme here also lets you use time-bound public identities and their matching public and private keys. That means private keys automatically expire at the end of the time span written in the identity itself ⏳.

Because the public identities self-expire, you don't need the traditional real-time validity checks and revocation procedures that certificates need 🙌. For example, if the public identity is bound to one day, then at the end of that day, the public/private key pair given to this peer just won't be valid anymore. Just like with public-key certificate systems, though, if you need to revoke keys before their expiry time, you'll need to talk to a third party 📞.

Finally, the protocol also gives you forward and backward secrecy of session keys. In other words, a session key made with IBAKE is always fresh, and it's unrelated to any past or future sessions between the protocol participants 💅.

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. IBE: Definition

Identity-Based Encryption (IBE) is a public-key encryption tech that lets you compute a public key from an identity and a set of public parameters. You can then calculate the matching private key from that public key 🔑. An Initiator can use the public key to encrypt messages, and the recipient decrypts them with the corresponding private key. The IBE framework is defined in [RFC5091], [RFC5408], and [RFC5409] 📚.

2.2. Abbreviations

Here's the abbreviation cheat sheet 🍓:

EC          Elliptic Curve

IBE         Identity-Based Encryption

IBAKE       Identity-Based Authenticated Key Exchange

IDi         Initiator's Identity
IDr         Responder's Identity

K_PUB       Public Key

PKG         Private-Key Generator

PKI         Public Key Infrastructure

2.3. Conventions

Here's how the symbols work in this doc 🧚:

  • E is an elliptic curve over a finite field F.
  • P is a point on E of large prime order.
  • s is a non-zero positive integer. s is a secret stored in a PKG. It's a system-wide secret and it's never revealed outside the PKG 🤫.
  • sP is the public key of the system, and it's known to all participants. sP denotes a point on E, and it denotes the point P added to itself s times, where addition refers to the group operation on E 💖.
  • H1 is a known hash function that takes a string and assigns it to a point on the elliptic curve, so H1(A) = QA on E, where A is usually based on the identity 🌸.
  • 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 a public key of x.

3. Identity-Based Authenticated Key Exchange

3.1. Overview

IBAKE is a three-way exchange between an Initiator and a Responder 🦋. The figure below is a conceptual signaling diagram of IBAKE:

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

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

             Figure 1: Example IBAKE Message Exchange

The Initiator (I) and Responder (R) are trying to mutually authenticate each other and agree on a key using IBAKE 🤝. This spec assumes that the Initiator and the Responder trust a third party, the PKG 👑. The PKG doesn't have to be just one: different PKGs may be involved, for example one for the Initiator and one for the Responder.

The Initiator and the Responder don't share any credentials. BUT they do know, or can get, each other's public identity (key), as well as the public parameters of each other's PKG 🎀. This spec doesn't make any assumptions about when and how the private keys are obtained. That said, to finish the protocol (meaning, to decrypt the encrypted messages in the IBAKE exchange), the Initiator and the Responder need their respective private keys. The procedures for getting private keys and public parameters are outside the scope of this spec. You can find those details in [RFC5091] and [RFC5408] 📖.

The protocol here relies on elliptic curves. Section 3.3 talks about how to choose them 🌈. How the Initiator and the Responder agree on a specific elliptic curve is left to the application that uses the IBAKE protocol (see [EAP-IBAKE], for example) 💜.

The Initiator picks a random x. In the first step, the Initiator computes xP (that's P, as a point on E, added to itself x times using the addition law on E). Then it encrypts xP, the IDi, and the IDr using the Responder's public key (for example, K_PUBr=H1(IDr||date)). It puts this encrypted info in MESSAGE_1 and sends that to the Responder 📨. In this step, encryption means IBE as described in [RFC5091] and [RFC5408] ✨.

When the Responder gets the message, it IBE-decrypts it using its private key (for example, the private key for that date) and gets xP 🔓. The Responder then picks a random y and computes yP. Next, it IBE-encrypts the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (for example, K_PUBi=H1(IDi||date)). The Responder puts this encrypted info in MESSAGE_2 and sends it to the Initiator 💌.

When the Initiator receives and IBE-decrypts MESSAGE_2, it gets yP. After that, the Initiator sends MESSAGE_3 to the Responder. MESSAGE_3 includes the IBE-encrypted IDi, IDr, and yP 🫶. At this point, both the Initiator and the Responder can compute the same session key, which is xyP 🔥👑.

Heads up: that's the end of part 1. Parts 2 and 3 are still coming, so stay tuned, bestie 🧚💖

3.2. IBAKE Message Exchange ✨

Okay bestie, so first up, the Initiator picks a random x and works out xP 💖. The Initiator MUST use a fresh, random value for x on each run of the protocol, so no recycling 🙅‍♀️. Then it encrypts xP, the IDi, and the IDr with the Responder's public key (for example, K_PUBr=H1(IDr||date)) 🦋. It packs all of that into MESSAGE_1 and sends it off like this:

   Initiator   ---->   Responder

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

When the Responder gets MESSAGE_1, it SHALL do the following:

  • Decrypt the message as specified in [RFC5091] and [RFC5408].
  • Obtain xP.
  • Select a random y and compute yP. The Responder MUST use a fresh, random value for x on each run of the protocol. 🌸
  • Encrypt the Initiator's identity (IDi), its own identity (IDr), xP, and yP using the Initiator's public key (K_PUBi) 💜.

Responder's turn! It sends back MESSAGE_2:

   Responder   ---->   Initiator

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

Upon receiving MESSAGE_2, the Initiator SHALL perform the following:

  • Decrypt the message as specified in [RFC5091] and [RFC5408].
  • Verify that the received xP is the same as that sent in MESSAGE_1. 👀
  • Obtain yP.
  • Encrypt its own identity (IDi), the Responder's identity (IDr), and yP using the Responder's public key (K_PUBi).

And the Initiator sends MESSAGE_3 back:

   Initiator   ---->   Responder

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

Upon receiving MESSAGE_3, the Responder SHALL perform the following:

  • Decrypt the message as specified in [RFC5091] and [RFC5408].
  • Verify that the received yP is the same as that sent in MESSAGE_2.

If any of the above verifications fail, the protocol halts 🛑. Otherwise, after this exchange, both the Initiator and the Responder have authenticated each other and can compute xyP as the session key 🔑. At this point, both protocol participants MUST discard all intermediate cryptographic values, including x and y. Similarly, both parties MUST immediately discard these values whenever the protocol terminates as a result of a verification failure or timeout. No leftovers, periodt 🧹✨

3.3. Discussion 🌈

Okay, here are the main properties of the protocol, and they're honestly iconic 👑.

  • Immunity from key escrow: Every step in the exchange is encrypted using IBE. So, obviously, the PKG can decrypt all of the exchanges. 🙃 However, given the assumption that PKGs are trusted and well behaved (e.g., PKGs will not mount an active man-in-the-middle (MitM) attack), they 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: Again, every step is encrypted using IBE. Only the Responder and its corresponding PKG can decrypt the contents of MESSAGE_1 and MESSAGE_3 sent by the Initiator, and similarly only the Initiator and its corresponding PKG can decrypt the contents of MESSAGE_2 sent by the Responder. Given the same assumption as above (that PKGs are trusted and well behaved, e.g., a PKG will not impersonate a user to which it issued a private key), 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 correct decryption of the contents of MESSAGE_2 by the Initiator. Finally, both the Initiator and the Responder can agree on the same session key. In other words, IBAKE 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. Thus, in any practical implementation, care should be devoted to the choice of elliptic curve. 🦋
  • Perfect forward and backward 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: The IBAKE protocol does not require any offline exchange of passwords or secret keys between the Initiator and the Responder. It's giving "first contact, no problem" 🤝. 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 the public parameters of the PKG that generated the corresponding private keys.
  • PKG availability: PKGs need not be contacted during an IBAKE protocol exchange, which dramatically reduces the availability requirements on PKGs. 🙌
  • Choice of elliptic curves: This specification relies on elliptic curves for both IBE and Elliptic Curve Diffie-Hellman exchange. When choosing elliptic curves, it is beneficial to choose two different elliptic curves: a non-supersingular curve for the internal calculations of Elliptic Curve Diffie-Hellman values xP and yP, and a supersingular curve for the IBE encryption/decryption. For the calculations of Elliptic Curve Diffie-Hellman values, it is beneficial to use the curves recommended by NIST [FIPS-186]. These curves make the calculations simpler while keeping the security high. On the other hand, IBE systems are based on bilinear pairings. Therefore, the choice of an elliptic curve for IBE is restricted to a family of supersingular elliptic curves over finite fields of large prime characteristic. The appropriate elliptic curves for IBE are described in [RFC5091]. 📐
  • Implementation considerations: An implementation of IBAKE would consist of two primary modules: point addition operations over a NIST curve, and IBE operations over a supersingular curve. The implementation of both modules only needs to be aware of the following parameters: (a) the full description of the curves that are in use (fixed or negotiated), (b) the public parameters of the PKG used for the derivation of IBE private keys, and (c) the exact public identity of each IBAKE participant. Knowing these parameters is enough to perform Elliptic Curve Cryptography (ECC) operations in different terminals and produce the same results, independently of the implementation. 🧚

4. Security Considerations 🔥

This document is based on the basic IBE 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 PKG are also reduced without any reduction in security. The granularity associated with the date is a matter of security policy and is a decision made by the PKG 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 that provides "public information" on a PKG server (i.e., P, sP) needed to execute IBE.

4.1. General 💅

Attacks on the cryptographic algorithms used in IBE 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 to known attacks. 📚

It is assumed that the PKGs are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment. Nevertheless, if an active adversary can fool the parties into believing that it is a legitimate PKG, then it can mount a successful MitM attack. Therefore, care should be taken when choosing a PKG. In addition, 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 an 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. 😭🔐

It is also assumed that the communication between participants and their respective PKGs is secure. Therefore, in any implementation of the protocols described in this document, administrators of any PKG 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 damage 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. 🌸✨

4.2. IBAKE Protocol 🔐✨

Okay bestie, time for the security considerations for the basic IBAKE protocol 💅. From a cryptographic perspective, the following apply.

In every step, IBE is used with the recipient's public key. This is giving only the intended recipient of the message and its corresponding PKG can decrypt it [BF]. 🔥

Next, using identities within the encrypted payload is meant to shut down some basic reflection attacks 🙈. Picture this: suppose we did not use identities as part of the encrypted payload in the first step of the IBAKE protocol exchange (i.e., MESSAGE_1 of Figure 1 in Section 3.1). Now assume an adversary can see the conversation between the Initiator and the Responder, and can actively snoop packets and drop or modify them before routing them to the destination. For instance, assume 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. Then the adversary can modify the IP source address to include the adversary's IP address, before routing it on to the Responder. The Responder will assume that the request for an IBAKE session came from the adversary. So it executes step 2 of the IBAKE protocol exchange (i.e., MESSAGE_2 of Figure 1 in Section 3.1), but encrypts it using the adversary's public key. 💀

The adversary is the only one who can decrypt that message. And since the second message includes the challenge sent by the Initiator to the Responder, the adversary now learns the challenge sent by the Initiator. Next, the adversary can carry on a conversation with the Initiator, "pretending" to be the Responder. This attack is eliminated if identities are used as part of the encrypted payload. ✨

In summary, at the end of the exchange, both the Initiator and the Responder can mutually authenticate each other and agree on a session key. 🫶

Recall that IBE guarantees that only the recipient of the message can decrypt it using the private key. The caveat is that the PKG that generated the recipient's private key can decrypt the message as well. However, the PKG cannot learn the public key xyP given xP and yP, based on the hardness of the Elliptic Curve Diffie-Hellman problem. This resistance to passive key escrow from the PKG 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 belong to two different PKGs. The parameters used for encryption to the Responder and the 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 it can be chosen during the key exchange. If that 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. 🌈

Last but not least, 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 other words, accidental leakage of one session key does not compromise past or future session keys between the same Initiator and Responder. Iconic. 👑

5. References 📚

5.1. Normative References

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

5.2. Informative References

[BF]        Boneh, D. and M. Franklin, "Identity-Based Encryption
            from the Weil Pairing", in SIAM Journal on Computing,
            Vol. 32, No. 3, pp. 586-615, 2003.

[EAP-IBAKE] Cakulev, V. and I. Broustis, "An EAP Authentication
            Method Based on Identity-Based Authenticated Key
            Exchange", Work in Progress, February 2012.

[FIPS-186]  National Institute of Standards and Technology, "Digital
            Signature Standard (DSS)", FIPS Pub 186-3, June 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.

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

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


Ioannis Broustis
Alcatel Lucent
600 Mountain Ave.
3D-526
Murray Hill, NJ  07974
US

Phone: +1 908 582 3744
EMail: ioannis.broustis@alcatel-lucent.com
📦 where this page comes from