RFC 6267
MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) 🎀
okay bestie, this is RFC 6267 💖 It's an Informational doc (not a Standards Track one) from June 2011, written by V. Cakulev and G. Sundaram at Alcatel Lucent. The ISSN is 2070-1721. Its title block doesn't list any RFCs it obsoletes or updates, so it stands on its own. This is part 1 of 6 ✨
Abstract 🌸
so this doc describes a key management protocol variant for MIKEY (Multimedia Internet KEYing) 🦋 It relies on a trusted key management service. The variant uses the Identity-Based Authenticated Key Exchange (IBAKE) framework, which lets the participating clients do mutual authentication and derive a session key inside an asymmetric Identity-Based Encryption (IBE) framework. On top of mutual authentication, it gets rid of the key escrow problem that normal IBE has, and it gives you perfect forward and backward secrecy 😭🔥
Status of This Memo 💅
this one is not an Internet Standards Track spec. It's just published for informational purposes ✨
This doc is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🙈
For info on the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6267 🫶
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🥺 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Definitions and Notation . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 7
4. MIKEY-IBAKE Protocol Description . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Message Exchanges and Processing . . . . . . . . . . . . . 10
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange . . 10
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges . . . . . . . . 12
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Generating Keys from the Session Key . . . . . . . . . . . 17
5.2. Generating Keys for MIKEY Messages . . . . . . . . . . . . 17
5.3. CSB Update . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Generating MAC and Verification Message . . . . . . . . . 18
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Common Header Payload (HDR) . . . . . . . . . . . . . . . 19
6.1.1. IBAKE Payload . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Encrypted Secret Key (ESK) Payload . . . . . . . . . . 21
6.1.3. Key Data Sub-Payload . . . . . . . . . . . . . . . . . 21
6.1.4. EC Diffie-Hellman Sub-Payload . . . . . . . . . . . . 22
6.1.5. Secret Key Sub-Payload . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. General Security Considerations . . . . . . . . . . . . . 24
7.2. IBAKE Protocol Security Considerations . . . . . . . . . . 25
7.3. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4. Retargeting . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Deferred Delivery . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 291. Introduction ✨
okay so MIKEY [RFC3830] is the spec that describes a bunch of key distribution modes for multimedia scenarios 💜 They can use pre-shared keys, Public Keys, and optionally a Diffie-Hellman key exchange. Lots of MIKEY extensions exist too, like HMAC-Authenticated (Hashed Message Authentication Code) Diffie-Hellman [RFC4650] and MIKEY-RSA-R [RFC4738] 🦋
when a security system has to serve a huge number of users, a key management service is usually the move 🌟 With one in place, a user can ask for credentials for any other user whenever they need them. Some proposed solutions [RFC6043] use Key Management Services (KMSs) in the network that create, distribute, and manage keys in real time ⚡ But because they do so much, those KMSs have to be online, keep high availability, and be networked across operator boundaries. that's a lot, bestie 😭
this doc goes a different way 🧚 Here the KMSs are low-availability servers that talk to end-user clients periodically (e.g., once a month). The online transactions between end-user clients, for media plane security, are based on Identity-Based Encryption (IBE) [BF] 💅 These transactions let the clients mutually authenticate each other and derive a session key that no external entity knows about, KMSs included 🔥 So the protocol gives you keys unknown to any external entity, lets end-user clients mutually authenticate each other at the media plane layer, and provides perfect forward and backward secrecy. literally iconic 👑
because the KMS-to-client exchange only happens sparingly (e.g., once a month), the KMS doesn't need to be a high-availability server anymore 🎀 And different KMSs don't have to talk to each other, so no crossing operator boundaries either 🙌 Since IBE is used, the costly Public Key Infrastructure (PKI) and all its operational costs of certificate management and revocation are gone ✨
here's how it works: Public Keys get concatenated with a date field 🌸 That way the corresponding Private Keys change with the date. The big win is that losing a Private Key only damages that one date, and endpoints don't have to be time synchronized to make it work 🥹 How granular the date field is depends on security policy and deployment. For example, an operator might use one key per day, so the KMS could issue Private Keys for a whole subscription cycle at the start of that cycle 📅
so unlike PKI, where a certificate stays valid for a period and needs revocation procedures to limit that validity, this scheme uses time-bound public identities that automatically expire at the end of the time span written in the identity itself 💀 Since they self-expire, you don't need real-time validity checks or revocation. for example, if the public identity is bound to one day, then at the end of that day the Public/Private Key pair issued to that peer just won't be valid anymore 🫠 Still, just like Public-Key certificate systems, if you need to revoke keys before their designated expiry time, you'll need to talk to a third party 🍓
Also, various call scenarios are securely supported 🦋 That includes secure forking, retargeting, deferred delivery, and pre-encoded content 💖
MIKEY is widely used in the 3GPP community 🌈 This spec is mainly meant for 3GPP media security, but it may also be applicable in Internet applications ✨
2. Terminology 🧚
2.1. Requirements Language 💅
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.2. Definitions and Notation 🎀
IBE Encryption: okay so Identity-Based Encryption (IBE) is a Public-Key encryption technology. It lets a Public Key get calculated from an identity, and the matching Private Key get calculated from the Public Key 🔑 [RFC5091], [RFC5408], and [RFC5409] describe the algorithms you need to implement IBE 🌸
(Media) session: this is the communication session that the MIKEY-IBAKE provided key(s) are meant to secure 🦋
Here's the notation, verbatim 💜
E(k, x) Encryption of x with the key k
[x]P Point multiplication on an elliptic curve, i.e., adding
a point P to itself total of x times
K_PUBx Public Key of x
[x] x is optional
{x} Zero or more occurrences of x
(x) One or more occurrences of x
|| Concatenation
| OR (selection operator)2.3. Abbreviations 🍓
here's the whole abbreviations list, kept exactly as written 🧾
EC Elliptic Curve
ESK Encrypted Secret Key
HMAC Hashed Message Authentication Code
IBE Identity-Based Encryption
I Initiator
IBAKE Identity-Based Authenticated Key Exchange
IDRi Initiator's Identity
IDRr Responder's Identity
KMS Key Management Service
K_PR Private Key
K_PUB Public Key
K_SESSION Session Key
MAC Message Authentication Code
MIKEY Multimedia Internet KEYing
MKI Master Key Identifier
MPK MIKEY Protection Key
PKI Public Key Infrastructure
PRF Pseudorandom Function
R Responder
SK Secret Key
SIP Session Initiation Protocol
SPI Security Parameter Index
SRTP Secure Realtime Transport Protocol
TEK Traffic Encryption Key
TGK TEK Generation Key3. Use Case Scenarios 🌟
this section covers some of the use case scenarios MIKEY-IBAKE supports, on top of regular two-party communication 💖
that's the end of part 1 of 6, so stay tuned for the next drop 🫶✨
3.1. Forking 🍴
Okay so forking is when one request (like a SIP INVITE message) gets delivered to multiple endpoints at once. 📞 This happens when a single user is registered more than once. Picture it: someone has a desk phone, a PC client, and a mobile handset, all registered with the same public identity. Ring ring ring, all three go off! 💅
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Request
------------------------------------->
Figure 1: Forking3.2. Retargeting 🎯
Retargeting is when some functional element decides to redirect the session to a different destination. 🦋 It's giving "new destination, who dis?" 😭 This decision can be made for different reasons, by a bunch of different functional elements, at different points while the session is being set up.
There are two basic scenarios of session redirection, and they're giving different vibes. 💜 In scenario one, a functional element (e.g., Proxy) decides to redirect the session by passing the new destination information to the originator. Then the originator starts a brand new session to the redirected destination that the Proxy gave it. For the case of MIKEY-IBAKE, this means the originator will initiate a new session with the identity of the redirected destination. Figure 2 shows how it goes. ✨
+---+ +-------+ +---+ +---+
| A | | PROXY | | B | | C |
+---+ +-------+ +---+ +---+
Request
-------------------->
Request
-------------------->
Redirect
<--------------------
Redirect
<-------------------
Request
---------------------------------------------------------->
Figure 2: RetargetingIn the second scenario, a proxy decides to redirect the session without telling the originator. 🙈 This is a super common one, and it's specified in SIP [RFC3261]. Iconic behaviour, honestly. 👑
3.3. Deferred Delivery 📬
Deferred delivery is a type of service where the session content can't be delivered to the destination at the moment it's being sent (e.g., the destination user is not currently online). 💀 But the sender still expects the network to deliver the message as soon as the recipient becomes available. The classic example? Voicemail! 📼 Literally the whole vibe of "I'll get back to you" in networking form. 🌸
4. MIKEY-IBAKE Protocol Description 🔐
4.1. Overview 🧚
Okay, so most of the MIKEY modes we've defined before are a single (or half) roundtrip between two peers. 🌈 MIKEY-IBAKE is different: it consists of up to three roundtrips. ✨ In the first roundtrip, the users (Initiator and Responder) get their Private Key(s) (K_PR) from the KMS. This roundtrip can happen at anytime, and as explained earlier, it takes place, for example, once a month (or once per subscription cycle). 🗓️ The second and third roundtrips are between the Initiator and the Responder. Observe that the Key Management Service is only involved in the first roundtrip. 👀 Figure 3 shows a conceptual signaling diagram for the MIKEY-IBAKE mode.
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
REQUEST_KEY_INIT REQUEST_KEY_INIT
------------------> <----------------------
REQUEST_KEY_RESP REQUEST_KEY_RESP
<------------------ ---------------------->
I_MESSAGE_1
----------------------------------------------------------->
R_MESSAGE_1
<-----------------------------------------------------------
I_MESSAGE_2
----------------------------------------------------------->
R_MESSAGE_2
<-----------------------------------------------------------
Figure 3: Example Message ExchangeThe Initiator (I) wants to set up a secure media session with the Responder (R). 🎀 The Initiator and the Responder trust a third party, the Key Management Service (KMS), and they both have, or can set up, shared credentials with it. These pre-established trust relations are how a user (i.e., Initiator or Responder) gets Private Keys. 🗝️ Rather than one single KMS, several different KMSs may be involved, e.g., one for the Initiator and one for the Responder, like Figure 3 shows. The Initiator and the Responder don't share any credentials, but the Initiator does know the Responder's public identity. 🫶 The assumed trust model is illustrated in Figure 4.
+---+ +------+ +------+ +---+
| I | | KMS1 | | KMS2 | | R |
+---+ +------+ +------+ +---+
Pre-established Pre-established
trust relation trust relation
<-----------------> <--------------------->
Security association based on mutual authentication
performed during MIKEY-IBAKE exchange
<---------------------------------------------------------->
Figure 4: Trust ModelBelow, I'll walk you through how Private Keys get obtained using MIKEY messages. 🧁 There's also an alternative way to get Private Keys using HTTP, described in [RFC5408].
The Initiator gets Private Key(s) from the KMS by sending a REQUEST_KEY_INIT message. 📨 That message includes the Initiator's public identity(s) (if the Initiator has more than one public identity, it may request Private Keys for every identity registered), and it's protected via a MAC based on a pre-shared key or via a signature (similar to the MIKEY-PSK and MIKEY-RSA modes). 🔏 If the request is authorized, the KMS generates the requested keys, encodes them, and sends them back in a REQUEST_KEY_RESP message. This exchange happens periodically, and it doesn't need to happen every time an Initiator wants to set up a secure connection with a Responder. Big time saver! ⭐
The Initiator next picks a random x and computes [x]P, where P is a point on elliptic curve E that everyone knows. 🌊 The Initiator uses the Responder's public identity to generate the Responder's Public Key (e.g., K_PUBr=H1(IDRr||date)), where Hi is a hash function everyone knows, and the granularity in date is a matter of security policy and is publicly known. 🍓 Then the Initiator uses this generated Public Key to encrypt [x]P, IDRi and IDRr, and it puts that encrypted info into an I_MESSAGE_1 message, which gets sent to the Responder. The encryption is Identity-Based Encryption (IBE), as specified in [RFC5091] and [RFC5408]. 💫 Next, the Responder IBE-decrypts the message using its Private Key for that date, picks a random y, and computes [y]P. The Responder then uses the Initiator's identity from I_MESSAGE_1 to generate the Initiator's Public Key (e.g., K_PUBi=H1(IDRi||date)), IBE-encrypts (IDRi, IDRr, [x]P, [y]P) using K_PUBi, and includes that in an R_MESSAGE_1 message sent to the Initiator. 🦄 At this point, the Responder can generate the session key as [x][y]P. This session key is then used to generate TGK, as specified in Section 5.1.
When the Initiator receives and IBE-decrypts an R_MESSAGE_1 message, it verifies the [x]P it got back. 🧐 At this point the Initiator can generate the same session key, [x][y]P. Once that verification succeeds, the Initiator sends an I_MESSAGE_2 message to the Responder, including IBE-encrypted IDRi, IDRr and the [y]P it got earlier. ✅ The Responder then sends an R_MESSAGE_2 message back to the Initiator as verification. Bestie, we're basically done with the handshake! 🥳
The above is the most typical use case. In Section 3, we talk about some alternative use cases. 👑
MIKEY-IBAKE is based on [RFC3830], so the same terminology, processing, and considerations still apply unless otherwise stated. 📚 Payloads containing EC Diffie-Hellman values and keys exchanged in I_MESSAGE/R_MESSAGE are IBE-encrypted as specified in [RFC5091] and [RFC5408], while the keys exchanged in KEY_REQUES_INIT/ KEY_REQUEST_RESPONSE are encrypted as specified in [RFC3830]. Lowkey confusing, but here's the big takeaway: in all exchanges, encryption only applies to the payloads containing keys and EC Diffie-Hellman values, and not to the entire messages. 🔒
4.2. Message Exchanges and Processing 💌
4.2.1. REQUEST_KEY_INIT/REQUEST_KEY_RESP Message Exchange 🌷
This exchange is how a user (e.g., Initiator or Responder) requests Private Keys from a trusted Key Management Service that it has pre-shared credentials with. 🌟 A full roundtrip is required before a user gets its keys. Since this message has to make sure the KMS knows who the user is, it's protected via a MAC based on a pre-shared key or via a signature. The REQUEST_KEY_INIT message comes in two variants, matching the pre-shared key (PSK) and Public-Key encryption (PKE) methods of [RFC3830]. The response message, REQUEST_KEY_RESP, is the same for both variants, and it SHALL be protected by using the pre-shared/envelope key indicated in the REQUEST_KEY_INIT message. 🛡️
Initiator/Responder KMS
REQUEST_KEY_INIT_PSK = ---->
HDR, T, RAND, (IDRi/r),
IDRkms, [IDRpsk], [KEMAC], V <---- REQUEST_KEY_RESP =
HDR, T, [IDRi/r], [IDRkms],
KEMAC, V
REQUEST_KEY_INIT_PKE = ---->
HDR, T, RAND, (IDRi/r),
{CERTi/r}, IDRkms, <---- REQUEST_KEY_RESP =
[KEMAC], [CHASH], HDR, T, [IDRi/r], [IDRkms],
PKE, SIGNi/r KEMAC, V4.2.1.1. Components of the REQUEST_KEY_INIT Message 🍰
The main goal of the REQUEST_KEY_INIT message is for a user to request one or more Private Keys (K_PR) from the KMS. 🎯 The user may request a K_PR for each public identity it has, and for multiple dates too.
The REQUEST_KEY_INIT message MUST always include the Header (HDR), Timestamp (T), and RAND payloads. 📋 The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The user SHALL include it in the CSB ID field of the Header. The user SHALL set the #CS field to '0', since CS (Crypto Session(s)) SHALL NOT be handled. 🙅♀️ The CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
IDRi/r contains the identity of the user. Since the user may have multiple identities, multiple IDRi/r fields may appear in the message. 🪪
IDRkms SHALL be included. 💖
The KEMAC payload SHALL be used only when the user needs to use specific keys. Otherwise, this payload SHALL NOT be used. ✨
4.2.1.1.1. Components of the REQUEST_KEY_INIT_PSK Message
okay so the IDRpsk payload MAY be used to show which pre-shared key is being used 🔑✨ that's the bestie move for telling everyone which key we mean
the last payload SHALL be a Verification (V) payload, and its authentication key (auth_key) gets derived from the pre-shared key 🧁 (the key derivation details are in Section 4.1.4 of [RFC3830], go check it if you're curious 🤓)
4.2.1.1.2. Components of the REQUEST_KEY_INIT_PKE Message
the certificate (CERT) payload SHOULD be included 💌 and if there's a whole certificate chain to send, every single certificate in that chain MUST go in its own separate CERT payload 📜💅
the PKE payload holds the encrypted envelope key, written as PKE = E(PKkms, env_key) 🔐 it gets encrypted with the KMS's Public Key (PKkms) 💖 and if the KMS has several Public Keys, the user can say which one she used by putting it in the CHASH payload 🎀
SIGNi/r is a signature that covers the entire MIKEY message 🖋️ made with the Initiator's signature key, so it's giving full authenticity energy 🫶
4.2.1.2. Processing of the REQUEST_KEY_INIT Message
so here's the flow 💅 if the KMS can verify the integrity of the message and the message parses correctly, the KMS MUST check whether the Initiator is authorized 👀 if the Initiator is allowed to receive the requested Private Key(s), the KMS MUST send back a REQUEST_KEY_RESP message 💌
unexpected payloads in the REQUEST_KEY_INIT message SHOULD be ignored 🙈 and errors get handled the way [RFC3830] describes, periodt ✨
4.2.1.3. Components of the REQUEST_KEY_RESP Message
the version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be exactly the same as the matching fields in the REQUEST_KEY_INIT message 🎀 the KMS SHALL set the V flag to 0, and the user who gets it SHALL ignore it, since it doesn't mean anything in this context 🙃
the Timestamp type and value SHALL match the ones used in the REQUEST_KEY_INIT message ⏰✨
KEMAC = E(encr_key, (ID || K_PR))the KEMAC payload SHOULD use the NULL authentication algorithm 🫧 because the MAC already lives in the V payload 🧚 depending on which type of REQUEST_KEY_INIT message you got, either the pre-shared key or the envelope key SHALL be used to derive the encr_key 🔑
the last payload SHALL be a Verification (V) payload 💜 and once again, depending on the REQUEST_KEY_INIT type, either the pre-shared key or the envelope key SHALL be used to derive the auth_key 🍓
4.2.1.4. Processing of the REQUEST_KEY_RESP Message
if the Initiator or Responder can parse the received message correctly, the session info they got SHOULD be stored 📥✨ otherwise they SHOULD quietly discard the message and abort the protocol 🥀 no drama, just bye 💅
4.2.2. I_MESSAGE/R_MESSAGE Message Exchanges
this exchange is how the Initiator and Responder mutually authenticate each other 🤝 and it also swaps the EC Diffie-Hellman values that get used to generate TGK 🌈 it's modeled on the pre-shared key mode, except the EC Diffie-Hellman values and Secret Keys (SKs) ride inside IBAKE and ESK payloads instead of a KEMAC payload 🦋 two full roundtrips are required for this to successfully complete, and the messages are preferably included in the session setup signaling (e.g., SIP INVITE) 📞💖
Initiator Responder
I_MESSAGE_1 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_1 =
HDR, T, IDRi,
IDRr, IBAKE
I_MESSAGE_2 = ---->
HDR, T, RAND, IDRi, IDRr,
IBAKE, [ESK] <---- R_MESSAGE_2 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V4.2.2.1. Components of the I_MESSAGE_1 Message
the I_MESSAGE_1 message MUST always include the Header (HDR), Timestamp (T), and RAND payloads 🎀 the CSB ID (Crypto Session Bundle ID) SHALL be picked at random by the Initiator 🎲 and since the R_MESSAGE_1 message is mandatory, the Initiator uses the V flag to say a verification message is expected 🙌
the IDRi and IDRr payloads SHALL be included 🫶
the IBAKE payload holds the Initiator's Identity, the EC Diffie-Hellman values (ECCPTi), and the Responder's Identity, all encrypted with the Responder's Public Key (so encr_key = K_PUBr) 🔒 like this:
IBAKE = E(encr_key, IDRi || ECCPTi || IDRr)the ESK payload MAY be included, totally optional 🍰 if it's there, it has an identity and a Secret Key (SK) encrypted with the intended Responder's Public Key (encr_key = K_PUBr) 🗝️
ESK = E(encr_key, ID || SK)4.2.2.2. Processing of the I_MESSAGE_1 Message
parsing the I_MESSAGE_1 message SHALL be done as in [RFC3830] 📖 if it parses correctly, the Responder SHALL use the Private Key (K_PRr) that matches the received IDRr to decrypt the IBAKE payload 🔓 if the message has an ESK payload, the Responder SHALL decrypt the SK and use it to open the IBAKE payload 🧩 but if the Responder can't decrypt the IBAKE payload, it SHALL tell the Initiator by sending back only its own EC Diffie-Hellman value (ECCPTr) in the next message, which is R_MESSAGE_1 🫧
if the message can't be parsed correctly, the Responder SHOULD quietly discard it and abort the protocol 🥀
4.2.2.3. Components of the R_MESSAGE_1 Message
the version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL match the I_MESSAGE_1 message 🎀 the V flag SHALL be set to 1, since the I_MESSAGE_2 message is mandatory 💅
the Timestamp type and value SHALL match the ones in the I_MESSAGE_1 message ⏰
the IDRi and IDRr payloads SHALL be included 🫶 the IDRi payload SHALL be exactly as received in the I_MESSAGE_1 🎯 and in the IDRr payload, the Responder SHALL put in its own identity 🪞 this identity might be different from the one in the IDRr payload received in I_MESSAGE_1 👀 the IDRr payloads of I_MESSAGE_1 and R_MESSAGE_1 will be different in the case of forking, retargeting, and deferred delivery 🦋 (see Section 3 for the use case scenarios 💜)
the Responder's IBAKE payload holds the Initiator's EC Diffie-Hellman value (ECCPTi) from I_MESSAGE_1 (if it got decrypted successfully) 🔐 plus the Responder's own generated EC Diffie-Hellman value (ECCPTr), along with the matching Initiator and Responder identities 🎀 if the Responder can't decrypt the IBAKE payload from I_MESSAGE_1 (say the message landed in the intended Responder's mailbox 📬), the Responder SHALL include only its own EC Diffie-Hellman value (ECCPTr) 💌 the IBAKE payload in R_MESSAGE_1 is encrypted with the Initiator's Public Key (so encr_key = P_PUBi) like this:
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)4.2.2.4. Processing of the R_MESSAGE_1 Message
parsing R_MESSAGE_1 SHALL be done as in [RFC3830] 📖 if it parses correctly, the Initiator shall use the Private Key that matches the received IDRi to decrypt the IBAKE payload 🔑 if the ECCPTi sent in I_MESSAGE_1 isn't in the received IBAKE payload (like when the Responder is offline and the R_MESSAGE_1 came from its mailbox 📭), the Initiator SHALL send ECCPTi again in the next message, I_MESSAGE_2 🔁 and in this case, I_MESSAGE_2 SHALL also carry an ESK payload encrypted with the intended recipient's K_PUB 🎁
if the message can't be parsed correctly, the Initiator SHOULD quietly discard it and abort the protocol 💀
4.2.2.5. Components of the I_MESSAGE_2 Message
the I_MESSAGE_2 message MUST always include the Header (HDR), Timestamp (T), and RAND payloads 🎀 the version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL match the R_MESSAGE_2 message 🫶 and because the R_MESSAGE_2 message is mandatory, the Initiator uses the V flag to say a verification message is expected ✅
the IDRi and IDRr payloads SHALL be included 💖 the IDRr payload SHALL be the same as the IDRr payload received in R_MESSAGE_1 🪞
the Initiator's IBAKE payload SHALL contain the Initiator's EC Diffie-Hellman value (ECCPTi) if ECCPTi wasn't received in R_MESSAGE_1 🧁 otherwise, ECCPTi SHALL NOT be included 🙅♀️ the IBAKE payload in I_MESSAGE_2 SHALL contain the Initiator's and Responder's identities, plus the Responder's EC Diffie-Hellman value received in R_MESSAGE_1 ✨ and the IBAKE payload SHALL be encrypted with the Responder's Public Key (encr_key = K_PUBr) like this:
IBAKE = E(encr_key, IDRi || {ECCPTi} || IDRr || ECCPTr)the ESK payload can be included too, totally optional 🍓 but it SHALL be included if R_MESSAGE_1 didn't have the Initiator's EC Diffie-Hellman value (ECCPTi), like in the deferred delivery case 📬 when it's there, it holds an Initiator's identity and an Initiator-generated Secret Key (SK), encrypted with the intended recipient's Public Key (encr_key = K_PUB) 🗝️
ESK = E(encr_key, ID || SK)4.2.2.6. Processing of the I_MESSAGE_2 Message
parsing the I_MESSAGE_2 message SHALL be done as in [RFC3830] 📖 if it parses correctly, the Responder shall use the K_PRr that matches the received IDRr to decrypt the IBAKE payload 🔓 if an ESK comes in, the Responder SHALL store it for later 📦 (like when the Responder is a mailbox that forwards the key to the user once they're back online 💌)
if the message can't be parsed correctly, the Responder SHOULD quietly discard it and abort the protocol 🥀
4.2.2.7. Components of the R_MESSAGE_2 Message
the version, PRF func, CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL match the I_MESSAGE_2 message 🎀 the Responder SHALL set the V flag to 0, and the Initiator SHALL ignore it 🙃
the Timestamp type and value SHALL match the ones used in the I_MESSAGE_2 message ⏰
the IDRi and IDRr payloads SHOULD be included 🫶
if the Initiator's EC Diffie-Hellman value (ECCPTi) came in I_MESSAGE_2, the Responder SHALL also include the IBAKE payload 💅 when it's there, it holds the Initiator's EC Diffie-Hellman value (ECCPTi) and the Initiator's identity from I_MESSAGE_2, encrypted with the Initiator's Public Key (encr_key = K_PUBi) like this:
IBAKE = E(encr_key, IDRi || ECCPTi)the last payload SHALL be a Verification (V) payload 💜 where the authentication key (auth_key) is derived as specified in Section 5.2 🔑
4.2.2.8. Processing of the R_MESSAGE_2 Message
parsing R_MESSAGE_2 SHALL be done as in [RFC3830] 📖 if it parses correctly and it has the IBAKE payload, the Initiator SHALL use the K_PRi that matches the received IDRi to decrypt the IBAKE payload 🔓
if the message can't be parsed correctly, the Initiator SHOULD quietly discard it and abort the protocol 💀
5. Key Management ✨
the keys used in the REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange get derived from the pre-shared key or the envelope key, as specified in [RFC3830] 🗝️ and since crypto sessions aren't handled in this exchange, further keying material (i.e., TEKs) for this message exchange SHALL NOT be derived 🙅♀️💖
5.1. Generating Keys from the Session Key 🔑
okay so, like we said up top, the session key [x][y]P gets cooked up from the EC Diffie-Hellman values that the Initiator and Responder swap, where x and y are randomly picked by each of them 🎲. Then the session key, which is a point on an elliptic curve, gets turned into an octet string following [SEC1] 💅. That octet string, K_SESSION, is what makes MPK and TGK. Last step: the traffic encryption keys (like TEK) get generated from TGK, as [RFC3830] spells out 🧚.
The MPK and TGK come from K_SESSION like this ✨
inkey : K_SESSION
inkey_len : bit length of the MPK
label : constant || 0xFF || 0xFFFFFFFF || RAND
outkey_len : desired bit length of the output key (MPK or TGK)The constant depends on which derived key type you're making, so check the table below 💜
+-------------+------------+
| Derived Key | Constant |
+-------------+------------+
| MPK | 0x220E99A2 |
| TGK | 0x1F4D675B |
+-------------+------------+
Table 1: Constants for Key DerivationThe constants are taken from the decimal digits of e, as described in [RFC3830] 🤓
5.2. Generating Keys for MIKEY Messages 🎀
The keys for MIKEY messages are what protect the MIKEY messages passed between the Initiator and Responder (aka I_MESSAGE and R_MESSAGE). In the REQUEST_KEY_INIT/REQUEST_KEY_RESP exchange, the key derivation SHALL be done exactly as in [RFC3830] 🫶
MIKEY Protection Key (MPK) for the I_MESSAGE/R_MESSAGE exchange is generated as described in Section 5.1. This MPK is then used to derive keys that protect the R_MESSAGE_2 message 🔥
inkey : MPK
inkey_len : bit length of the MPK
label : constant || 0xFF || csb_id || RAND
outkey_len : desired bit length of the output keywhere the constants are as defined in [RFC3830] ✨
5.3. CSB Update 🔄
Similar to [RFC3830], MIKEY-IBAKE gives you ways to update the CSB (Crypto Session Bundle), e.g., shipping new EC Diffie-Hellman values or adding new crypto sessions. The CSB updating happens by running the I_MESSAGE_1/R_MESSAGE_1 exchange, and the CSB updating MAY be started by either the Initiator or the Responder 💖
Initiator Responder
I_MESSAGE_1 = ---->
HDR, T, [IDRi], [IDRr],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], V
Responder Initiator
I_MESSAGE_1 = ---->
HDR, T, [IDRr], [IDRi],
[IBAKE] <---- R_MESSAGE_1 =
HDR, T, [IDRi], [IDRr],
[IBAKE], VThe new message exchange MUST use the same CSB ID as the initial exchange, but it MUST use a new Timestamp 🕰️ Other payloads that were provided in the initial exchange SHOULD NOT be included. And new RANDs MUST NOT be included in the message exchange, because the RANDs only have effect in the initial exchange 🙈
An IBAKE payload with new EC Diffie-Hellman values SHOULD be included. If new EC Diffie-Hellman values are being exchanged during CSB updating, messages SHALL be protected with keys derived from those EC Diffie-Hellman values, exchanged as specified in Section 5.2 🔐 Otherwise, if new EC Diffie-Hellman values are not being exchanged during the CSB update exchange, messages SHALL be protected with the same keys that protected the I_MESSAGE/R_MESSAGE messages in the initial exchange 🌸
5.4. Generating MAC and Verification Message 🔐
The authentication tag in all MIKEY-IBAKE messages is generated as described in [RFC3830]. Like we said above, the MPK is used to derive the auth_key. The MAC/Signature in the V/SIGN payloads covers the entire MIKEY message, except the MAC/Signature field itself. And if there is an ESK payload in the message, it SHALL be omitted from the MAC/Signature calculation 👀
The identities (not whole payloads) of the involved parties MUST directly follow the MIKEY message in the Verification MAC/Signature calculation. Note that in the I_MESSAGE/R_MESSAGE exchange, IDRr in R_MESSAGE_1 MAY not be the same as the one appearing in I_MESSAGE_1 🦋
6. Payload Encoding 📦
This section does not describe all the payloads used in the new message types. It describes the new IBAKE and ESK payloads in detail, and the payloads that have been changed compared to [RFC3830] in less detail. For a detailed description of the MIKEY payloads (e.g., Timestamp (T) payload, RAND payload, etc.), see [RFC3830]. For the description of the IDR payload, as well as the definition of additional PRF functions and encryption algorithms not defined in [RFC3830], see [RFC6043] 🧠
6.1. Common Header Payload (HDR) 🎀
For the Common Header Payload, new values are added to the data type and the next payload namespaces ✨
- Data type (8 bits): describes the type of message.
+------------------+-------+------------------------------------+
| Data Type | Value | Comment |
+------------------+-------+------------------------------------+
| REQUEST_KEY_PSK | 19 | Request Private Keys message (PSK) |
| REQUEST_KEY_PKE | 20 | Request Private Keys message (PKE) |
| REQUEST_KEY_RESP | 21 | Response Private Keys message |
| I_MESSAGE_1 | 22 | First Initiator's message |
| R_MESSAGE_1 | 23 | First Responder's message |
| I_MESSAGE_2 | 24 | Second Initiator's message |
| R_MESSAGE_2 | 25 | Second Responder's message |
+------------------+-------+------------------------------------+
Table 2: Data Type (Additions)- Next payload (8 bits): identifies the payload that is added after this payload.
+--------------+-------+---------------+
| Next Payload | Value | Section |
+--------------+-------+---------------+
| IBAKE | 22 | Section 6.1.1 |
| ESK | 23 | Section 6.1.2 |
| SK | 24 | Section 6.1.5 |
| ECCPT | 25 | Section 6.1.4 |
+--------------+-------+---------------+
Table 3: Next Payload (Additions)- V (1 bits): flag to indicate whether or not a response message is expected (this only has meaning when it is set in an initiation message). If a response is required, the V flag SHALL always be set to 1 in the initiation messages, and the receiver of the initiation message (Responder or KMS) SHALL ignore it 🙌
- #CS (8 bits): indicates the number of crypto sessions that will be handled within the CSB. It SHALL be set to 0 in the Request Key exchange, as crypto sessions SHALL NOT be handled 🚫
- CS ID map type (8 bits): specifies the method of uniquely mapping crypto sessions to the security protocol sessions. In the Request Key exchange, the CS ID map type SHALL be the "Empty map" (defined in [RFC4563]), as crypto sessions SHALL NOT be handled 💀
6.1.1. IBAKE Payload 🧁
The IBAKE payload contains IBE encrypted (see [RFC5091] and [RFC5408] for details about IBE) Initiator and Responder's Identities and EC Diffie-Hellman Sub-Payloads (see Section 6.1.4 for the definition of EC Diffie-Hellman Sub-Payload). It may contain one or more EC Diffie-Hellman Sub-Payloads and their associated identities. The last EC Diffie-Hellman or Identity Sub-Payload has its Next payload field set to Last payload 💜
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload.
- Encr data len (16 bits): length of Encr data (in bytes).
- Encr data (variable length): the IBE encrypted EC Diffie-Hellman Sub-Payloads (see Section 6.1.4) and their associated Identity payloads.
6.1.2. Encrypted Secret Key (ESK) Payload 🗝️
The Encrypted Secret Key payload contains IBE encrypted (see [RFC5091] and [RFC5408] for details about IBE) Secret Key Sub-Payload and its associated identity (see Section 6.1.5 for the definition of the Secret Key Sub-Payload) 🤫
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Encr data len ! Encr data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload.
- Encr data len (16 bits): length of Encr data (in bytes).
- Encr data (variable length): the encrypted secret key Sub-Payloads (see Section 6.1.5).
6.1.3. Key Data Sub-Payload 🔑
For the key data Sub-Payload, a new type of key is defined. The Private Key (K_PR) is used to decrypt the content encrypted using the corresponding Public Key (K_PUB). KEMAC in the REQUEST_KEY_RESP SHALL contain one or more Private Keys. 🌈
- Type (4 bits): indicates the type of key included in the payload.
+------+-------+-------------+
| Type | Value | Comments |
+------+-------+-------------+
| K_PR | 7 | Private Key |
+------+-------+-------------+
Table 4: Key Data Type (Additions)6.1.4. EC Diffie-Hellman Sub-Payload 💖
okay so the EC Diffie-Hellman (ECCPT) Sub-Payload has its own format 🎀 and it's never sent in clear. It only ever shows up as an encrypted part of the IBAKE payload 🔒
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! ECC Curve ! ECC Point ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth alg ! TGK len ! Reserv! KV !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): tells you which payload gets added right after this one 🧚 See Section 6.1 of [RFC3830] for the values.ECC Curve(8 bits): identifies the ECC curve being used 🌈
+--------------------------------------+-------+
| ECC Curve | Value |
+--------------------------------------+-------+
| ECPRGF192Random / P-192 / secp192r1 | 1 |
| EC2NGF163Random / B-163 / sect163r2 | 2 |
| EC2NGF163Koblitz / K-163 / sect163k1 | 3 |
| EC2NGF163Random2 / none / sect163r1 | 4 |
| ECPRGF224Random / P-224 / secp224r1 | 5 |
| EC2NGF233Random / B-233 / sect233r1 | 6 |
| EC2NGF233Koblitz / K-233 / sect233k1 | 7 |
| ECPRGF256Random / P-256 / secp256r1 | 8 |
| EC2NGF283Random / B-283 / sect283r1 | 9 |
| EC2NGF283Koblitz / K-283 / sect283k1 | 10 |
| ECPRGF384Random / P-384 / secp384r1 | 11 |
| EC2NGF409Random / B-409 / sect409r1 | 12 |
| EC2NGF409Koblitz / K-409 / sect409k1 | 13 |
| ECPRGF521Random / P-521 / secp521r1 | 14 |
| EC2NGF571Random / B-571 / sect571r1 | 15 |
| EC2NGF571Koblitz / K-571 / sect571k1 | 16 |
+--------------------------------------+-------+
Table 5: Elliptic CurvesECC Point(variable length): the ECC point data, padded so it ends on a 32-bit boundary, encoded as an octet string 🦋Auth alg(8 bits): specifies the MAC algorithm used for the verification message. For MIKEY-IBAKE this field is ignored 🙈TGK len(16 bits): the length of the TGK, in bytes. For MIKEY-IBAKE this field is ignored 🙈KV(4 bits): indicates the type of key validity period specified. This can be done with an SPI (or an MKI in SRTP), or by giving an interval in which the key is valid. For SRTP, that interval is the index range where the key is valid. See Section 6.13 of [RFC3830] for the pre-defined values 📅KV data(variable length): this holds either the SPI/MKI or an interval (see Section 6.14 of [RFC3830]). IfKVis NULL, this field is not included 🫶
6.1.5. Secret Key Sub-Payload 🔑
the Secret Key payload is included as a Sub-Payload inside the Encrypted Secret Key payload. Just like the EC Diffie-Hellman Sub-Payload, it's never sent in clear, only as an encrypted part of the ESK payload 🔐
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): identifies the payload that gets added after this one 🧚Type(4 bits): indicates the type of the key included in the payload 🗝️
+------+-------+
| Type | Value |
+------+-------+
| SK | 1 |
+------+-------+
Table 6: Secret Key TypesKV(4 bits): indicates the type of key validity period specified. This can be done with an SPI (or an MKI in the case of [RFC3711]), or by giving an interval in which the key is valid. For SRTP, that interval is the index range where the key is valid.KVvalues are the same as in Section 6.13 of [RFC3830] 📅Key data len(16 bits): the length of theKey datafield, in bytes 📏Key data(variable length): the SK data 💜KV data(variable length): this holds either the SPI or an interval. IfKVis NULL, this field is not included 🫶
7. Security Considerations 🛡️
okay this is the serious part bestie 😭 Unless explicitly stated otherwise, the security properties of the MIKEY protocol described in [RFC3830] also apply to MIKEY-IBAKE. On top of that, MIKEY-IBAKE is built on the basic Identity-Based Encryption protocol from [RFC5091], [RFC5408], and [RFC5409], so it inherits some of that protocol's properties too. For example, by concatenating the "date" with the identity (to derive the Public Key), the need for key revocation mechanisms is basically gone 🍓 And by letting participants acquire multiple Private Keys (for example, for the duration of a contract), the availability requirements on the KMS also go down, with no loss in security 👑
7.1. General Security Considerations
the MIKEY-IBAKE protocol relies on Identity-Based Encryption. [RFC5091] describes attacks on the cryptographic algorithms used in Identity-Based Encryption. [RFC5091] also gives recommendations for security parameters for the IBE algorithms described there 🔍
It is assumed that the Key Management Services are secure, not compromised, trusted, and will not engage in launching active attacks, either on their own or in a collaborative environment. However, any malicious insider could potentially launch passive attacks (by decrypting one or more message exchanges offline). It's in the best interest of administrators to prevent this, but it's hard to eliminate the problem entirely 😬 So it's assumed that these problems will persist, which is exactly why the protocols are designed to protect participants from passive adversaries 🛡️
7.2. IBAKE Protocol Security Considerations
for the basic IBAKE protocol, from a cryptographic perspective, the 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 it [BF] ✨
Next, using identities inside the encrypted payload is meant to shut down basic reflection attacks. Imagine identities weren't part of the encrypted payload, in the first step of the IBAKE protocol (that's I_MESSAGE_1 of Figure 3 in Section 4.1). Now picture an adversary who can see the conversation between Initiator and Responder, can actively snoop on packets, and can drop or modify them before they reach their destination. Say the adversary can change the IP source and destination addresses. After the first message is sent by the Initiator to the Responder, the adversary takes over and traps the packet. Then the adversary changes the IP source address to its own IP address before routing it on to the Responder 😱 The Responder will think the request for an IBAKE session came from the adversary. It will run step 2 of the IBAKE protocol (that's R_MESSAGE_1 of Figure 3 in Section 4.1), but it will encrypt it with the adversary's Public Key. That means the adversary can decrypt the message, and only the adversary can. Since the second message includes the challenge the Initiator sent to the Responder, the adversary now learns that challenge. After that, the adversary can carry on a conversation with the Initiator while "pretending" to be the Responder 🙃 This attack is eliminated when identities are used as part of the encrypted payload. In short, by the end of the exchange, the Initiator and Responder can mutually authenticate each other and agree on a session key 🤝
Remember that Identity-Based Encryption guarantees that only the recipient can decrypt the message using the Private Key. The catch is that the KMS that generated the recipient's Private Key can decrypt the message too 👀 However, the KMS cannot work out the session key [x][y]P from [x]P and [y]P, because of the Elliptic Curve Diffie-Hellman problem. This resistance to passive key escrow from the KMS does not apply to the basic IBE protocols proposed in [RFC5091], [RFC5408], and [RFC5409] 🔐
Notice that the protocol still works even if the Initiator and Responder belong to two different Key Management Services. In particular, the parameters used for encrypting to the Responder and the parameters used for encrypting to the Initiator can be completely different and independent of each other. Also, the Elliptic Curve used to generate the session key [x][y]P can be completely different too. If that flexibility is wanted, it would be helpful to add optional extra data to the protocol so the algebraic primitives used to derive the session key can be exchanged 🧩
Besides mutual authentication and resistance to passive escrow, the Diffie-Hellman property of the session key exchange gives perfect secrecy of keys 🌸 In other words, accidentally leaking one session key doesn't compromise past or future session keys between the same Initiator and Responder 💖
7.3. Forking
In the Forking feature, there are multiple potential Responders. It's important to notice that there is one "common Responder" identity (with its corresponding Public and Private Keys), and each Responder also has a unique identity (with its own corresponding Public and Private Keys). In this framework, when one Responder answers the Initiator's invite, it uses its unique identity, and the protocol guarantees that no other Responder learns the session key 🦋
7.4. Retargeting
In the Retargeting feature, the forwarding server never learns the Private Key of the intended Responder, since that key is encrypted with the retargeted Responder's Public Key 📞 The Initiator also learns that the retargeted Responder answered the phone (and not the intended Responder), because the retargeted Responder includes its own identity in the message it sends to the Initiator. That lets the Initiator decide whether or not to carry on the conversation 🙋♀️ Finally, the session key can't be discovered by the intended Responder, because the random number chosen by the retargeted Responder isn't known to the intended Responder 🔒
7.5. Deferred Delivery 📬✨
okay so Deferred Delivery is giving secure voicemail energy 💌. The Initiator and the Responder's mailbox mutually authenticate each other, which means the mailbox can't just pretend to be the Responder and fish for stuff. That's how it stops server side "phishing" attacks 🎣🚫. And it works the other way too: the server (and eventually the Responder) gets to know who the Initiator is, so nobody's anonymous in this chat 🫶.
The key the Initiator uses to encrypt the message contents is completely separate from the session key between the Initiator and the server. Two keys, zero drama 🔑💅. And the message key is itself encrypted with the Responder's Public Key, so the mailbox server can hold the message without ever being able to read what's inside 🙈🔒. The server is basically carrying a sealed envelope it can't open, which is iconic behaviour from a server, honestly 💜.
8. IANA Considerations 🧚
This document defines several new values for the namespaces Data Type, Next Payload, and Key Data Type defined in [RFC3830]. The IANA assignments have been added to the MIKEY Payload registry, and the table containing the registered values is referenced in brackets next to each one:
- Data Type (see Table 2)
- Next Payload (see Table 3)
- Key Data Type (see Table 4)
The ECCPT payload defines an 8-bit ECC Curve field, and IANA has created and will maintain a brand new namespace for it in the MIKEY Payload registry 🌸. Assignments are an ECC curve paired with its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry look like this:
Value ECC curve
------- ------------------------------------
0 Reserved
1 ECPRGF192Random / P-192 / secp192r1
2 EC2NGF163Random / B-163 / sect163r2
3 EC2NGF163Koblitz / K-163 / sect163k1
4 EC2NGF163Random2 / none / sect163r1
5 ECPRGF224Random / P-224 / secp224r1
6 EC2NGF233Random / B-233 / sect233r1
7 EC2NGF233Koblitz / K-233 / sect233k1
8 ECPRGF256Random / P-256 / secp256r1
9 EC2NGF283Random / B-283 / sect283r1
10 EC2NGF283Koblitz / K-283 / sect283k1
11 ECPRGF384Random / P-384 / secp384r1
12 EC2NGF409Random / B-409 / sect409r1
13 EC2NGF409Koblitz / K-409 / sect409k1
14 ECPRGF521Random / P-521 / secp521r1
15 EC2NGF571Random / B-571 / sect571r1
16 EC2NGF571Koblitz / K-571 / sect571k1
17-239 Unassigned
240-254 Private Use
255 ReservedThe SK Sub-Payload defines a 4-bit Type field, and IANA has created and will maintain another new namespace for it in the MIKEY Payload registry 🎀. Assignments are a type of key paired with its associated value. Values in the range 2-15 SHOULD be approved by the process of Specification Required. The initial contents are:
Value Type
------- ---------------
0 Reserved
1 Secret Key (SK)
2-15 Unassigned9. References 📚
9.1. Normative 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.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.
- [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", September 2000.
9.2. Informative References
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
- [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 Sundaram
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3209
EMail: ganesh.sundaram@alcatel-lucent.comand that's the whole spec, bestie 🌈👑 you made it through all six parts!! no cap, the way this protocol is built is literally so thoughtful 😭💅
📦 where this page comes from
- ietf: rfc6267 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms