diff options
Diffstat (limited to 'doc/rfc/rfc6539.txt')
| -rw-r--r-- | doc/rfc/rfc6539.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6539.txt b/doc/rfc/rfc6539.txt new file mode 100644 index 0000000..520818b --- /dev/null +++ b/doc/rfc/rfc6539.txt @@ -0,0 +1,731 @@ + + + + + + +Independent Submission V. Cakulev +Request for Comments: 6539 G. Sundaram +Category: Informational I. Broustis +ISSN: 2070-1721 Alcatel Lucent + March 2012 + + + IBAKE: Identity-Based Authenticated Key Exchange + +Abstract + + Cryptographic protocols based on public-key methods have been + traditionally based on certificates and Public Key Infrastructure + (PKI) to support certificate management. The emerging field of + Identity-Based Encryption (IBE) protocols allows simplification of + infrastructure requirements via a Private-Key Generator (PKG) while + providing the same flexibility. However, one significant limitation + of IBE methods is that the PKG 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. This + document specifies the Identity-Based Authenticated Key Exchange + (IBAKE) protocol. IBAKE does not suffer from the key escrow problem + and in addition provides mutual authentication as well as perfect + forward and backward secrecy. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its 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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6539. + +Independent Submissions Editor Note + + This document specifies the Identity-Based Authenticated Key Exchange + (IBAKE) protocol. Due to its specialized nature, this document + experienced limited review within the Internet Community. Readers of + this RFC should carefully evaluate its value for implementation and + deployment. + + + +Cakulev, et al. Informational [Page 1] + +RFC 6539 IBAKE March 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +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 + + Authenticated key agreements are cryptographic protocols where two or + more participants authenticate each other and agree on key material + used for securing 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 traditionally + require certificates and a large-scale Public Key Infrastructure + (PKI). Clearly, public-key methods are more flexible; however, the + requirement for certificates and a large-scale PKI 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 replacing + the PKI with a Private-Key Generator (PKG). However, one significant + limitation of IBE methods is that the PKG can end up being a de facto + + + +Cakulev, et al. Informational [Page 2] + +RFC 6539 IBAKE March 2012 + + + key escrow entity (i.e., an entity that has sufficient information to + decrypt communicated data), with undesirable consequences. Another + limitation is a lack of mutual authentication between communicating + parties. This document specifies an Identity-Based Authenticated Key + Encryption (IBAKE) protocol that does not suffer from the key escrow + problem and that provides mutual authentication. In addition, the + scheme described in this document allows the use of time-bound public + identities and corresponding public and private keys, resulting in + automatic expiration of private keys at the end of a time span + indicated in the identity itself. With the self-expiration of the + public identities, the traditional real-time validity verification + and revocation procedures used with certificates are not required. + For example, if the public identity is bound to one day, then, at the + end of the day, the public/private key pair issued to this peer will + simply not be valid anymore. Nevertheless, just as with public-key- + based certificate systems, if there is a need to revoke keys before + the designated expiry time, communication with a third party will be + needed. Finally, the protocol also provides forward and backward + secrecy of session keys; i.e., a session key produced using IBAKE is + always fresh and 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 technology + that allows a public key to be calculated from an identity and a set + of public parameters, 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 that the recipient can decrypt using + the corresponding private key. The 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 + + + + +Cakulev, et al. Informational [Page 3] + +RFC 6539 IBAKE March 2012 + + + IDr Responder's Identity + + K_PUB Public Key + + PKG Private-Key Generator + + 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 s is a non-zero positive integer. s is a secret stored in a PKG. + This is a system-wide secret and not revealed outside the PKG. + + o sP is the public key of the system that is known to all + participants. sP denotes a point on E, and denotes the point P + added to itself s times where addition refers to the group + operation on 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 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 a public key of x. + + + + + + + + + + + + + + + + + + + + +Cakulev, et al. Informational [Page 4] + +RFC 6539 IBAKE March 2012 + + +3. Identity-Based Authenticated Key Exchange + +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 PKG. Rather than a single PKG, different PKGs 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 identity (key) + as well as the public parameters of each other's PKG. This + specification does not make any assumption on when and how the + private keys are obtained. However, to complete the protocol + described (i.e., to decrypt encrypted messages in the IBAKE protocol + exchange), the Initiator and the Responder need to have their + respective private keys. The procedures needed to obtain the private + keys and public parameters are outside the scope of this + specification. The details of these procedures can be found in + [RFC5091] and [RFC5408]. Finally, the protocol described in this + document relies on the use of elliptic curves. Section 3.3 discusses + the choice of elliptic curves. However, how the Initiator and the + Responder agree on a specific elliptic curve is left to the + application that is leveraging the IBAKE protocol (see [EAP-IBAKE], + for example). + + The Initiator chooses a random x. In the first step, the Initiator + computes xP (i.e., P, as a point on E, added to itself x times using + the addition law on E); encrypts xP, the IDi, and the IDr using the + Responder's public key (e.g., K_PUBr=H1(IDr||date)); and includes + + + + +Cakulev, et al. Informational [Page 5] + +RFC 6539 IBAKE March 2012 + + + this encrypted information in MESSAGE_1 sent to the Responder. In + this step, encryption refers to IBE as described in [RFC5091] and + [RFC5408]. + + The Responder, upon receiving the message, IBE-decrypts it using its + private key (e.g., a private key for that date), and obtains xP. The + Responder further chooses a random y and computes yP. The Responder + then IBE-encrypts the Initiator's identity (IDi), its own identity + (IDr), xP, and yP using the Initiator's public key (e.g., + K_PUBi=H1(IDi||date)). The Responder includes this encrypted + information in MESSAGE_2 sent to the Initiator. + + The Initiator, upon receiving and IBE-decrypting MESSAGE_2, obtains + yP. Subsequently, the Initiator sends MESSAGE_3, which includes the + IBE-encrypted IDi, IDr, and yP, to the Responder. 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 + Initiator MUST use a fresh, random value for x on each run of the + protocol. The Initiator then encrypts xP, the IDi, and the IDr using + the Responder's public key (e.g., K_PUBr=H1(IDr||date)). The + Initiator includes this encrypted information in MESSAGE_1 and sends + it to the Responder, as shown below. + + Initiator ----> Responder + + MESSAGE_1 = E(K_PUBr, IDi || IDr || xP) + + Upon receiving MESSAGE_1, the Responder SHALL perform the following: + + o Decrypt the message as specified in [RFC5091] and [RFC5408]. + + o Obtain xP. + + o Select a random y and compute yP. The Responder MUST use a fresh, + random value for x on each run of the protocol. + + o Encrypt the Initiator's identity (IDi), its own identity (IDr), + xP, and yP using the Initiator's public key (K_PUBi). + + Responder ----> Initiator + + MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP) + + + + + +Cakulev, et al. Informational [Page 6] + +RFC 6539 IBAKE March 2012 + + + Upon receiving MESSAGE_2, 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 that sent in MESSAGE_1. + + o Obtain yP. + + o Encrypt its own identity (IDi), the Responder's identity (IDr), + and yP using the Responder's public key (K_PUBi). + + Initiator ----> Responder + + MESSAGE_3 = E(K_PUBr, IDi || IDr || yP) + + Upon receiving MESSAGE_3, 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 that sent in MESSAGE_2. + + If any of the above verifications fail, 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. 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. + +3.3. Discussion + + Properties of the protocol are as follows: + + o Immunity from key escrow: Observe that all of the steps in the + protocol exchange are encrypted using IBE. So, clearly, 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. + + o Mutually authenticated key agreement: Observe that all of the + steps in the protocol exchange are encrypted using IBE. In + particular, 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 + + + +Cakulev, et al. Informational [Page 7] + +RFC 6539 IBAKE March 2012 + + + PKG can decrypt the contents of MESSAGE_2 sent by the Responder. + Again, given the assumption made 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. + + o 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. + + 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 the public parameters of the PKG that generated the + corresponding private keys. + + o PKG availability: Observe that PKGs need not be contacted during + an IBAKE protocol exchange, which dramatically reduces the + availability requirements on PKGs. + + o Choice of elliptic curves: This specification relies on the use of + elliptic curves for both IBE and Elliptic Curve Diffie-Hellman + exchange. When making a decision on the choice of 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 + + + + +Cakulev, et al. Informational [Page 8] + +RFC 6539 IBAKE March 2012 + + + 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]. + + o Implementation considerations: An implementation of IBAKE would + consist of two primary modules, i.e., 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. The knowledge of these + parameters is sufficient 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 as such + 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 + + + +Cakulev, et al. Informational [Page 9] + +RFC 6539 IBAKE March 2012 + + + 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 + + For the basic IBAKE protocol, from a cryptographic perspective, the + following security considerations apply. + + In every step, IBE is used, with the recipient's public key. This + guarantees that only the intended recipient of the message and its + corresponding PKG 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 exchange (i.e., MESSAGE_1 of Figure 1 in + Section 3.1). Furthermore, assume that an adversary has access to + the conversation between the Initiator and the Responder and can + actively snoop 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 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, and + will execute step 2 of the IBAKE protocol exchange (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 + + + +Cakulev, et al. Informational [Page 10] + +RFC 6539 IBAKE March 2012 + + + 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 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 the message using the private key, with the caveat that the + PKG that generated the private key of the recipient of the message + 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 property of 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. 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 can be 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 other words, accidental + leakage of one session key does not compromise past or future session + keys between the same Initiator and Responder. + + + + + + + + + + + + + + + + + + +Cakulev, et al. Informational [Page 11] + +RFC 6539 IBAKE March 2012 + + +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. + + + + + + + + + + + + + + + + + + +Cakulev, et al. Informational [Page 12] + +RFC 6539 IBAKE March 2012 + + +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 + + + + + + + + + + + + + + + + + + +Cakulev, et al. Informational [Page 13] + |