RFC 3830
MIKEY: Multimedia Internet KEYing
Part 1 of 13 💖 more parts coming, bestie!
MIKEY: Multimedia Internet KEYing 🎀
- RFC number and title: RFC 3830, "MIKEY: Multimedia Internet KEYing"
- Authors: J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman (all from Ericsson Research)
- Category: Standards Track ✨
- Date: August 2004
- Stream: Network Working Group
- Obsoletes / Updates: the header doesn't list either, so this one doesn't obsolete or update anything 🌸
Status of This Memo 📜
Okay so this doc is an Internet standards track protocol for the whole Internet community 🌈 It's also asking people to talk about it and send ideas for making it better. If you want to know where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" list, which is STD 1 💅 And the best part: anyone can share this memo, no restrictions 🦋
Copyright Notice 🔖
Copyright (C) The Internet Society (2004).
Abstract 🌸
So this doc is all about a key management scheme for real-time apps, whether that's two people talking one-on-one or a whole group call 📞 It goes deep on how it supports the Secure Real-time Transport Protocol, aka SRTP 🎧
Security protocols for real-time multimedia have been popping up everywhere lately, and that's exactly why we need a key management solution to back them up 🔐 Iconic demand, honestly 👑
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 661. Introduction ✨
Okay so there's been work going on to define a security protocol that protects real-time apps running over RTP, which is [SRTP] 🎀 But here's the thing: a security protocol needs a key management solution so it can swap keys and the related security parameters 🔑 And the key management scheme has to be genuinely good, because it needs to serve streaming and real-time apps, like unicast and multicast, especially across heterogeneous (mix of wired and wireless) networks 🦋 That's a lot of pressure, ngl 💀
This document describes a key management solution built for multimedia scenarios, like SIP [SIP] calls and RTSP [RTSP] sessions 📞 The whole focus is on how to set up key management for secure multimedia sessions so the requirements still get met in a heterogeneous environment 💜
1.1. Existing Solutions 🧩
The IETF has been working on key management schemes for a while. For example, IKE [IKE] is a widely accepted unicast scheme for IPsec 🔐 Meanwhile, the MSEC WG is developing other schemes for group communication [GDOI, GSAKMP] 👑 Still, for reasons we'll get into below, there's a need for a scheme with lower latency, one that suits demanding cases like real-time data over heterogeneous networks and small interactive groups ⚡
An option in some cases might be to use [SDP], since SDP defines one field for transporting keys, the "k=" field 🌸 The catch is that this field can't be used for more general key management purposes, because it can't be extended from its current definition 🙈
1.2. Notational Conventions 📝
Here's how the key words work in this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are all to be read as described in BCP 14, RFC 2119 [RFC2119] 🫶
1.3. Definitions ✨
(Data) Security Protocol 🔐: the security protocol that protects the actual data traffic. Examples are IPsec and SRTP.
Data Security Association (Data SA) 💌: information for the security protocol, including a TEK and a set of parameters/policies.
Crypto Session (CS) 🎀: uni- or bi-directional data stream(s), protected by a single instance of a security protocol. For example, when SRTP is used, the Crypto Session will often contain two streams, an RTP stream and the corresponding RTCP, which are both protected by a single SRTP Cryptographic Context, i.e., they share key data and the bulk of security parameters in the SRTP Cryptographic Context (default behavior in [SRTP]). In the case of IPsec, a Crypto Session would represent an instantiation of an IPsec SA. A Crypto Session can be viewed as a Data SA (as defined in [GKMARCH]) and could therefore be mapped to other security protocols if necessary.
Crypto Session Bundle (CSB) 🧺: collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters.
Crypto Session ID 🪪: unique identifier for the CS within a CSB.
Crypto Session Bundle ID (CSB ID) 🆔: unique identifier for the CSB.
TEK Generation Key (TGK) 🗝️: a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-encrypting Keys can then be generated without needing further communication.
Traffic-Encrypting Key (TEK) 🔑: the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK.
TGK re-keying 🔄: the process of re-negotiating/updating the TGK (and consequently future TEK(s)).
Initiator 🙋: the initiator of the key management protocol, not necessarily the initiator of the communication.
Responder 🙌: the responder in the key management protocol.
Salting key 🧂: a random or pseudo-random (see [RAND, HAC]) string used to protect against some off-line pre-computation attacks on the underlying security protocol.
Here's the notation cheat sheet, copied exactly so nothing gets lost 📝:
PRF(k,x): a keyed pseudo-random function (see [HAC]).
E(k,m): encryption of m with the key k.
PKx: the public key of x
[] an optional piece of information
{} denotes zero or more occurrences
|| concatenation
| OR (selection operator)
^ exponentiation
XOR exclusive orBit and byte ordering 👀: throughout the document bits and bytes are indexed, as usual, from left to right, with the leftmost bits/bytes being the most significant.
1.4. Abbreviations 📚
Here's the abbreviations table, kept in a code block so it stays perfectly intact 💅:
AES Advanced Encryption Standard
CM Counter Mode (as defined in [SRTP])
CS Crypto Session
CSB Crypto Session Bundle
DH Diffie-Hellman
DoS Denial of Service
MAC Message Authentication Code
MIKEY Multimedia Internet KEYing
PK Public-Key
PSK Pre-Shared key
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SRTP Secure RTP
TEK Traffic-encrypting key
TGK TEK Generation Key1.5. Outline 🗺️
okay so Section 2 is the vibe check 💖: it covers the basic scenarios and design goals MIKEY is built for. It also gives a quick overview of the whole solution and how it connects to the group key management architecture [GKMARCH].
The basic key transport/exchange mechanisms get explained in detail in Section 3. The key derivation and other general key management procedures are in Section 4.
Section 5 describes the expected behavior of the involved parties. This also includes message creation and parsing 🧩.
All definitions of the payloads in MIKEY are in Section 6.
Section 7 deals with transport considerations, while Section 8 focuses on how MIKEY is used in group scenarios 👯.
The Security Considerations section (Section 9) gives a deeper explanation of important security-related topics. Lowkey the most important part 🚨.
2. Basic Overview 🌸
2.1. Scenarios 🎬
MIKEY is mainly intended for peer-to-peer, simple one-to-many, and small-size (interactive) groups 🫶. One of the main multimedia scenarios considered when designing MIKEY was the conversational multimedia scenario, where users may interact and communicate in real time. In these scenarios it can be expected that peers set up multimedia sessions between each other, where a multimedia session may consist of one or more secured multimedia streams (e.g., SRTP streams).
Here's the visual, which is honestly iconic 🦋 (Figure 2.1 is copied exactly):
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-to-many, many-to-many without a centralized server (also denoted as small interactive group), and many-to-many with a centralized server.
We identify in the following some typical scenarios which involve the multimedia applications we are dealing with (see also Figure 2.1) 🔍.
a) peer-to-peer (unicast) 📞: e.g., a SIP-based [SIP] call between two parties, where it may be desirable that the security is either set up by mutual agreement or that each party sets up the security for its own outgoing streams.
b) simple one-to-many (multicast) 📢: e.g., real-time presentations, where the sender is in charge of setting up the security.
c) many-to-many, without a centralized control unit 🤝: e.g., for small-size interactive groups where each party may set up the security for its own outgoing media. Two basic models may be used here. In the first model, the Initiator of the group acts as the group server (and is the only one authorized to include new members). In the second model, authorization information to include new members can be delegated to other participants.
d) many-to-many, with a centralized control unit 🏛️: e.g., for larger groups with some kind of Group Controller that sets up the security.
The key management solutions may be different in the above scenarios. When designing MIKEY, the main focus has been on cases a, b, and c. For scenario c, only the first model is covered by this document.
2.2. Design Goals 🎯
The key management protocol is designed to have the following characteristics 💅:
- End-to-end security 🔒: Only the participants involved in the communication have access to the generated key(s).
- Simplicity 🧸.
- Efficiency ⚡: Designed to have:
- low bandwidth consumption,
- low computational workload,
- small code size, and
- minimal number of roundtrips.
- Tunneling 🚇: Possibility to "tunnel"/integrate MIKEY in session establishment protocols (e.g., SDP and RTSP).
- Independence from any specific security functionality of the underlying transport 🦸: this one's a whole mood.
2.3. System Overview 🧠
One objective of MIKEY is to produce a Data SA for the security protocol, including a traffic-encrypting key (TEK), which is derived from a TEK Generation Key (TGK), and used as input for the security protocol.
MIKEY supports the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time. The concept of Crypto Session Bundle (CSB) is used to denote a collection of one or more Crypto Sessions that can have a common TGK and security parameters, but which obtain distinct TEKs from MIKEY 🧺.
The procedure of setting up a CSB and creating a TEK (and Data SA) is done in accordance with Figure 2.2 🪄:
- A set of security parameters and TGK(s) are agreed upon for the Crypto Session Bundle (this is done by one of the three alternative key transport/exchange mechanisms, see Section 3).
- The TGK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session.
- The TEK, together with the security protocol parameters, represents the Data SA, which is used as the input to the security protocol.
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+Figure 2.2: Overview of MIKEY key management procedure.
The security protocol can then either use the TEK directly or, if supported, derive further session keys from the TEK (e.g., see SRTP [SRTP]). It is however up to the security protocol to define how the TEK is used 🎀.
MIKEY can be used to update TEKs and the Crypto Sessions in a current Crypto Session Bundle (see Section 4.5) 🔁. This is done by executing the transport/exchange phase once again to obtain a new TGK (and consequently derive new TEKs), or to update some other specific CS parameters.
2.4. Relation to GKMARCH 🧩
The Group key management architecture (GKMARCH) [GKMARCH] describes a general architecture for group key management protocols. MIKEY is a part of this architecture, and can be used as a so-called Registration protocol 📋. The main entities involved in the architecture are the group controller/key server (GCKS), the receiver(s), and the sender(s).
In MIKEY, the sender could act as GCKS and push keys down to the receiver(s) 🚀.
Note that, for example, in a SIP-initiated call, the sender may also be a receiver. As MIKEY addresses small interactive groups, a member may dynamically change between being a sender and receiver (or being both simultaneously) 🔄✨.
3. Basic Key Transport and Exchange Methods ✨
okay bestie, this section is all about the three basic ways to get a TGK to your people 💅 It covers a pre-shared key, public-key encryption, and Diffie-Hellman (DH) key exchange. We're assuming unicast communication here just to keep things simple 🎀 On top of the TGK, a random "nonce", written RAND, gets transported too. All three methods use the TGK and RAND to derive TEKs (see Section 4.1.3), and a timestamp is sent along to avoid replay attacks (see Section 5.4). It's giving organized 🔥
The pre-shared key method and the public-key method are both basically key transport, where the actual TGK gets pushed (securely) to the recipient or recipients 🚀 The Diffie-Hellman method is different, because the actual TGK is derived from the DH values the peers swap with each other 🦋
The pre-shared case is, by far, the most efficient way to handle key transport, since it only uses symmetric cryptography 🍓 It also means only a small amount of data has to be exchanged. The catch? Scalability 😭 It's not always doable to share individual keys with a huge group of peers. So this case mostly covers things like server-to-client, plus cases where the public-key modes were already used, which gives you a "cache" of a symmetric key (see below and Section 3.2) ✨
Public-key cryptography can create a scalable system 🌈 The downside is that it's more resource-consuming than the pre-shared key approach. Another downside: in most cases you need a PKI (Public Key Infrastructure) to handle distributing the public keys. You can use public keys as pre-shared keys though (for example, with self-signed certificates) 💖 Also, as mentioned above, this method can establish a "cached" symmetric key that's later used to set up subsequent TGKs via the pre-shared key method, so the next request is way more efficient 🧚
DH key agreement has a higher resource consumption than the previous ones (both computationally and in bandwidth), and it needs certificates like the public-key case does 💀 But it gives you perfect forward secrecy (PFS) and flexibility, since it can be implemented in several different finite groups 👑
Heads up on DH: with this method, the two parties generate a unique, unpredictable random key. So you can't use DH to establish a group TEK, because everyone in the group would end up with different TEKs 🙈 DH isn't meant for that scenario. It's a great alternative for the special peer-to-peer case 🫶
The following general notation is used:
HDR: the general MIKEY header, which includes MIKEY CSB related data (e.g., CSB ID) and information mapping to the specific security protocol used. See Section 6.1 for payload definition.T: the timestamp, used mainly to prevent replay attacks. See Section 6.6 for payload definition and Section 5.4 for other timestamp related information.IDx: the identity of entity x (IDi=Initiator,IDr=Responder). See Section 6.7 for payload definition.RAND: random/pseudo-random byte-string, which is always included in the first message from the Initiator. RAND is used as a freshness value for the key generation. It is not included in update messages of a CSB. See Section 6.11 for payload definition. For randomness recommendations for security, see [RAND].SP: the security policies for the data security protocol. See Section 6.10 for payload definition.
3.1. Pre-shared key ✨
In this method, the pre-shared secret key, s, is used to derive key material for both the encryption (encr_key) and the integrity protection (auth_key) of the MIKEY messages, as described in Section 4.1.4. The encryption and authentication transforms are described in Section 4.2 🔐
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], VThe main objective of the Initiator's message (I_MESSAGE) is to securely transport one or more TGKs (carried into KEMAC) and a set of security parameters (SPs) to the Responder 💌 The verification message from the Responder is optional, so the Initiator indicates in the HDR whether it wants a verification message back from the Responder or not.
The KEMAC payload is this:
KEMAC = E(encr_key, {TGK}) || MACKEMAC contains a set of encrypted sub-payloads and a MAC 🎀 Each sub-payload includes a TGK randomly and independently chosen by the Initiator (plus other related parameters, e.g., the key lifetime). The MAC is a Message Authentication Code covering the entire MIKEY message, using the authentication key, auth_key. See Section 6.2 for payload definition and Section 5.2 for an exact definition of the MAC calculation.
The main objective of the verification message from the Responder is to obtain mutual authentication 🤝 The verification message, V, is a MAC computed over the Responder's entire message, the timestamp (the same one included in the Initiator's message), and the two parties' identities, using the authentication key. See also Section 5.2 for the exact definition of the Verification MAC calculation and Section 6.9 for payload definition.
The ID fields SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (otherwise it can't look up the pre-shared key). For example, this could be the case if the ID is extracted from SIP.
It is MANDATORY to implement this method. 🏆
3.2. Public-key encryption ✨
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], [IDr], {SP},
KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], VSame as before, the main objective of the Initiator's message is to securely transport one or more TGKs and a set of security parameters to the Responder 💖 This is done with an envelope approach, where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key gets sent to the Responder encrypted with the Responder's public key 🦋
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key). It's encrypted using the Responder's public key (PKr). If the Responder has several public keys, the Initiator can indicate which key was used in the CHASH payload (see Section 6.8) 🔑
The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMAC = E(encr_key, IDi || {TGK}) || MACThe first payload (IDi) in KEMAC is the identity of the Initiator (not a certificate, but generally the same ID as the one specified in the certificate) 🪪 Each of the following payloads (TGK) includes a TGK randomly and independently chosen by the Initiator (and possibly other related parameters, e.g., the key lifetime). The encrypted part is then followed by a MAC, which is calculated over the KEMAC payload. The encr_key and the auth_key are derived from the envelope key, env_key, as specified in Section 4.1.4. See also Section 6.2 for payload definition.
The SIGNi is a signature covering the entire MIKEY message, using the Initiator's signature key (see also Section 5.2 for the exact definition) ✍️
The main objective of the verification message from the Responder is to obtain mutual authentication 🤝 As the verification message V from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder. V is calculated in the same way as in the pre-shared key mode (see also Section 5.2 for the exact definition). See Section 6.9 for payload definition.
Note that there will be one encrypted IDi and possibly also one unencrypted IDi 👀 The encrypted one is used together with the MAC as a countermeasure for certain man-in-the-middle attacks, while the unencrypted one is always useful for the Responder to immediately identify the Initiator. The encrypted IDi MUST always be verified to be equal with the expected IDi. No skipping this, bestie 🚨
It's possible to cache the envelope key, so that it can be used as a pre-shared key. It is not recommended for this key to be cached indefinitely (however, it is up to the local policy to decide this) 🕰️ This can be super convenient during the lifetime of a CSB, if a new crypto session needs to be added (or an expired one removed). Then the pre-shared key can be used instead of the public keys (see also Section 4.5). If the Initiator indicates that the envelope key should be cached, the key is at least to be cached during the lifetime of the entire CSB.
The cleartext ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID, or can obtain the certificate in some other manner. For example, this could be the case if the ID is extracted from SIP.
For certificate handling, authorization, and policies, see Section 4.3 📜
It is MANDATORY to implement this method. 💅
3.3. Diffie-Hellman key exchange ✨
okay so this is the Diffie-Hellman bit 🫶 you pick a fixed, agreed-upon cyclic group (G,*), and g is its generator 🧚 the parameter choices are in Section 4.2.7, and the other transforms get explained in Section 4.2 💅
this method makes a DH-key that becomes the TGK 🔑 but it can't make group keys, only single peer-to-peer keys 💖 and implementing it is OPTIONAL 🌸
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],[IDr]
{SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNrthe Initiator's message is basically about sending its DH value (DHi), which is g^(xi), to the Responder in a secure way 🦋 xi MUST be randomly or pseudo-randomly chosen and kept secret, and the message also carries some security protocol parameters 🎀
SIGNi is a signature over the Initiator's MIKEY message, I_MESSAGE, made with the Initiator's signature key 🔏 (check Section 5.2 for the exact definition) ✨
the Responder's message does the same job from the other side: it securely hands over its DH value (DHr), which is g^(xr), and xr MUST be randomly or pseudo-randomly chosen and kept secret 🌈 the timestamp in the answer is the very same one that was in the Initiator's message ⭐
SIGNr is a signature over the Responder's MIKEY message, R_MESSAGE, made with the Responder's signature key (again, Section 5.2 has the exact details) 💜
the DH group parameters (like the group G and the generator g) get picked by the Initiator and then signaled to the Responder 🧚 both sides then work out the TGK, which is g^(xi*xr), from the DH values they swapped 🔥
The best part: the Initiator doesn't need any of the Responder's certificates ahead of time 🙈 it's enough that the Responder puts its signing certificate in the response 💅
the ID fields and certificate SHOULD be included 💖 but they MAY be left out when the peer can already be expected to know the other party's ID (or can grab the certificate some other way) ✨ for example, that could happen when the ID is pulled out of SIP 🎀
for certificate handling, authorization, and policies, check out Section 4.3 🦋
4. Selected Key Management Functions 👑
okay so MIKEY handles symmetric keys in two main ways 🫶 first, after a key transport or key exchange of TGK(s) (plus other parameters) using any of the three methods above, MIKEY keeps a mapping between Data SA identifiers and Data SAs 🗺️ the identifiers depend on the security protocol in question (see Section 4.4) 💅 so when the security protocol asks for a Data SA using one of those identifiers, it gets an up-to-date Data SA 🔥 the correct keying material, TEK(s), might need deriving too ✨ and that derivation (along with any other keying material) comes from a TGK, as described in Section 4.1.3 🌸
second, MIKEY needs two key management procedures for its own internal use 🧚
- in the pre-shared case, it derives encryption and authentication key material from one single pre-shared key 💜
- in the public key case, it derives similar key material from the transported envelope key 🦋
these two key derivation methods are specified in section 4.1.4 💖
all of the key derivation stuff above runs on a pseudo-random function, which we define next 🌈
4.1. Key Calculation ✨
in this part we define a general method (a pseudo-random function) for deriving one or more keys from a "master" key 🔑 it gets used to derive:
- TEKs, from a TGK and the RAND value 🎀
- encryption, authentication, or salting keys, from a pre-shared or envelope key and the RAND value 🫶
4.1.1. Assumptions 🌸
we assume these parameters are in place 💅
csb_id : Crypto Session Bundle ID (32-bits unsigned integer)
cs_id : the Crypto Session ID (8-bits unsigned integer)
RAND : (at least) 128-bit (pseudo-)random bit-string sent by the
Initiator in the initial exchange.the key derivation method takes these input parameters 🧚
inkey : the input key to the derivation function
inkey_len : the length in bits of the input key
label : a specific label, dependent on the type of the key to be
derived, the RAND, and the session IDs
outkey_len: desired length in bits of the output key.and it gives back this output 💜
outkey: the output key of desired length.4.1.2. Default PRF Description ✨
so HMAC is the SHA-1 based message authentication function (see [HMAC] [SHA-1]) 🔐 following the same approach as [TLS], we define the P-function like this 🦋
P (s, label, m) = HMAC (s, A_1 || label) ||
HMAC (s, A_2 || label) || ...
HMAC (s, A_m || label)where
A_0 = label,
A_i = HMAC (s, A_(i-1))
s is a key (defined below)
m is a positive integer (also defined below).the label's value depends on whatever case the PRF is being invoked in, and the values for the default PRF are given below 🌈 heads up though: other PRFs that get added to MIKEY later MAY specify different input parameters 💖
now the PRF itself, called PRF(inkey,label), is built on the P-function above and computes the output key, outkey 🎀
- let n = inkey_len / 256, rounded up to the nearest integer if it isn't one already 🧮
- split the inkey into n blocks,
inkey = s_1 || ... || s_n, where all s_i, except possibly s_n, are 256 bits each 🔪 - let m = outkey_len / 160, rounded up to the nearest integer if it isn't one already 🫶
(the numbers "256" and "160" are half the input block-size and the full output hash size of SHA-1, which is used in the P-function 🤓)
then the output key, outkey, is the outkey_len most significant bits of 👑
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
XOR P(s_n, label, m).4.1.3. Generating keys from TGK 🔑
here we describe how keying material gets derived from a TGK 🧚 this assumes the Data SA identifier has already been mapped to the correct TGK, following Section 4.4 ✨
the key derivation method SHALL be executed using the PRF above with these input parameters 💅
inkey: TGKinkey_len: bit length of TGKlabel: constant || cs_id || csb_id || RANDoutkey_len: bit length of the output key
the constant part of the label depends on what kind of key is being generated 🌸 the constant 0x2AD01C64 is used to generate a TEK from the TGK 💖 if the security protocol itself doesn't support key derivation for authentication and encryption from the TEK, then separate authentication and encryption keys MAY be created directly for the security protocol 🎀 you just swap 0x2AD01C64 for 0x1B5C7973 (authentication) and 0x15798CEF (encryption) respectively, and set outkey_len to the desired key length(s) in each case 🦋
a salt key can also be derived from the TGK, using the constant 0x39A2C14B 🌈 the Key data sub-payload (Section 6.13) can carry a salt too 🫶 the security protocol that needs the salt key SHALL use the salt key carried in the Key data sub-payload (in the pre-shared and public-key cases) when one is present 🔥 if none is sent, the salt key can be derived with the key derivation function described above ✨
here's the quick summary table of the constants used to make keys from a TGK 💜
constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting keyTable 4.1.3: Constant values for the derivation of keys from TGK.
the fun fact: these 32-bit constants come from the decimal digits of e (2.7182...) 🤯 each constant is made of nine decimal digits (for example, the first nine decimal digits, 718281828, are 0x2AD01C64) 🧮 the nine-digit strings weren't picked at random either, they're consecutive "chunks" of the decimal digits of e 🌟
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared key 🦋
this derivation makes the symmetric encryption key (plus a salting key) used to encrypt the TGK in the pre-shared key and public key methods 💖 it also derives the symmetric key for the message authentication code in those messages, and in the matching verification messages 🎀 that's why we need it: you get different keys for encryption and MAC, and in the pre-shared case it gives fresh key material for each new CSB 🌈 the parameters for the default PRF are here 🫶
inkey : the envelope key or the pre-shared key
inkey_len : the bit length of inkey
label : constant || 0xFF || csb_id || RAND
outkey_len : desired bit length of the output key.the constant part of the label depends on which key is being generated from the envelope or pre-shared key, as summarized below ✨
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt keyTable 4.1.4: Constant values for the derivation of keys from an envelope/pre-shared key.
4.2. Pre-defined Transforms and Timestamp Formats 🎀
this section names the default transforms for MIKEY 💅 it is mandatory to implement and support the following transforms in each respective case 🔥 new transforms can be added in the future (see Section 4.2.9 for the guidelines) 🌸
4.2.1. Hash functions 🔐
in MIKEY, it is MANDATORY to implement SHA-1 as the default hash function 💜
4.2.2. Pseudo-random number generator and PRF 🧚
a cryptographically secure random or pseudo-random number generator MUST be used for generating the keying material and nonces, e.g., [BMGL] 🔐 which one you use is up to the implementation, since the choice won't affect interoperability 🫶
for key derivations, it is MANDATORY to implement the PRF specified in Section 4.1 💖 other PRFs MAY be added by writing standard-track RFCs that specify the PRF constructions and their exact use within MIKEY 🦋
4.2.3. Key data transport encryption 🎀
Okay bestie, the default one that every implementation has to be able to do is AES in counter mode, as defined in [SRTP] 🔐. It uses a 128-bit key derived as in Section 4.1.4, with SRTP_PREFIX_LENGTH set to zero, and this initialization vector:
IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,where S is a 112-bit salting key (also derived as in Section 4.1.4), and T is the 64-bit timestamp sent by the Initiator 🕰️.
Note: this restricts the maximum size that can be encrypted to 2^23 bits, which is still enough for all practical purposes [SRTP] 💅
The NULL encryption algorithm (aka no encryption at all 🙈) can be used, but implementing it is OPTIONAL. Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason it's here is for specific SIP scenarios where SDP is protected end-to-end. For that case, MIKEY MAY be used with the pre-shared key method, the NULL encryption, and the NULL authentication algorithm (see Section 4.2.4), while relying on the security of SIP. Use this option with caution! 😭
The AES key wrap function [AESKW] is included as an OPTIONAL implementation method 🎁. If the key wrap function is used in the public key method, the NULL MAC is RECOMMENDED to be used, because the key wrap itself will provide integrity of the encrypted content. Quick plot twist though: the NULL MAC SHOULD NOT be used in the pre-shared key case, since the MAC in that case covers the entire message. The 128-bit key and a 64-bit salt, S, are derived in accordance to Section 4.1.4, and the key wrap IV is then set to S ✨
4.2.4. MAC and Verification Message function 🦋
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 as the MANDATORY implementation method, see [HMAC] 🔑. Authentication keys are derived according to Section 4.1.4. Note that the authentication key size SHOULD be equal to the size of the hash function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC] 💜
The NULL authentication algorithm (i.e., no MAC) can be used together with the NULL encryption algorithm, but implementation is OPTIONAL 🫶. Note that this MUST NOT be used unless the underlying protocols can guarantee security. Again the main reason is specific SIP scenarios where SDP is protected end-to-end. For this scenario, MIKEY MAY be used with the pre-shared key method and the NULL encryption and authentication algorithm, while relying on the security of SIP. Use this option with caution!
4.2.5. Envelope Key encryption 🌸
The public key encryption algorithm applied is defined by, and dependent on, the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS] 🍓
4.2.6. Digital Signatures ✍️
The signature algorithm applied is defined by, and dependent on, the certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it is RECOMMENDED to also support RSA PSS [PSS] 💅
4.2.7. Diffie-Hellman Groups 👑
The Diffie-Hellman key exchange, when supported, uses OAKLEY 5 [OAKLEY] as a mandatory implementation. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are OPTIONAL implementations) 🧚
See Section 4.2.9 for the guidelines on specifying a new DH Group to be used within MIKEY.
4.2.8. Timestamps ⏰
The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in seconds relative to 0h on 1 January 1900. An implementation MUST be aware of (and take into account) the fact that the counter will overflow approximately every 136th year 🙈 It is RECOMMENDED that the time always be specified in UTC 🌈
4.2.9. Adding new parameters to MIKEY 🧩
Okay so there are two different parameter sets that can be added to MIKEY. The first is a set of MIKEY transforms (needed for the exchange itself), and the second is the Data SAs ✨
New transforms and parameters (including new policies) SHALL be added by registering with IANA (according to [RFC2434], see also Section 10) a new number for the concerned payload, and also, if necessary, documenting how the new transform or parameter is used. Sometimes it might be enough to point to an already specified document for the usage, e.g., when adding a new, already standardized, hash function 📚
In the case of adding a new DH group, the group MUST be specified in a companion standards-track RFC (it is RECOMMENDED that the specified group use the same format as used in [OAKLEY]). A number can then be assigned by IANA for such a group to be used in MIKEY 💖
When adding support for a new data security protocol, the following MUST be specified:
- A map sub-payload (see Section 6.1). This is used to be able to map a crypto session to the right instance of the data security protocol, and possibly also to provide individual parameters for each data security protocol.
- A policy payload, i.e., specification of parameters and supported values.
- General guidelines of usage.
4.3. Certificates, Policies and Authorization 🎀
4.3.1. Certificate handling 📜
Certificate handling may involve a number of additional tasks not shown here, and effect the inclusion of certain parts of the message (c.f. [X.509]). However, the following observations can be made:
- The Initiator typically has to find the certificate of the Responder in order to send the first message. If the Initiator does not already have the Responder's certificate, this may involve one or more roundtrips to a central directory agent 🏃♀️
- It will be possible for the Initiator to omit its own certificate and rely on the Responder getting this certificate using other means. However, we only recommend doing this when it is reasonable to expect that the Responder has cached the certificate from a previous connection. Otherwise accessing the certificate would mean additional roundtrips for the Responder as well 🙃
- Verification of the certificates using Certificate Revocation Lists (CRLs) [X.509] or protocols such as OCSP [OCSP] may be necessary. All parties in a MIKEY exchange should have a local policy which dictates whether such checks are made, how they are made, and how often they are made. Note that performing the checks may imply additional messaging 🔍
4.3.2. Authorization 👀
In general, there are two different models for making authorization decisions for both the Initiator and the Responder, in the context of the applications targeted by MIKEY:
- Specific peer-to-peer configuration. The user has configured the application to trust a specific peer.
When pre-shared secrets are used, this is pretty much the only available scheme. Typically, the configuration or entering of the pre-shared secret is taken to mean that authorization is implied 🤝
In some cases, one could also use this with public keys, e.g., if two peers exchange keys offline and configure them to be used for the purpose of running MIKEY.
- Trusted root. The user accepts all peers that prove to have a certificate issued by a specific CA. The granularity of authorization decisions is not very precise in this method 🌷
In order to make this method possible, all participants in the MIKEY protocol need to configure one or more trusted roots. The participants also need to be capable of performing certificate chain validation, and possibly transfer more than a single certificate in the MIKEY messages (see also Section 6.7).
In practice, a combination of both mentioned methods might be advantageous. Also, the possibility for a user to explicitly exclude a specific peer (or sub-tree) in a trust chain might be needed 🚫
These authorization policies address the MIKEY scenarios a-c of Section 2.1, where the Initiator acts as the group owner and is also the only one that can invite others. This implies that for each Responder, the distributed keys MUST NOT be re-distributed to other parties 🔒
In a many-to-many situation, where the group control functions are distributed (and/or where it is possible to delegate the group control function to others), a means of distributing authorization information about who may be added to the group MUST exist. However, it is out of scope of this document to specify how this should be done 🧠
For any broader communication situation, an external authorization infrastructure may be used (following the assumptions of [GKMARCH]) 🌍
4.3.3. Data Policies 📋
Included in the message exchange, policies (i.e., security parameters) for the Data security protocol are transmitted. The policies are defined in a separate payload and are specific to the security protocol (see also Section 6.10). Together with the keys, the validity period of these can also be specified. For example, this can be done with an SPI (or SRTP MKI) or with an Interval (e.g., a sequence number interval for SRTP), depending on the security protocol 🎟️
New parameters can be added to a policy by documenting how they should be interpreted by MIKEY and by also registering new values in the appropriate name space in IANA. If a completely new policy is needed, see Section 4.2.9 for guidelines 💫
4.4. Retrieving the Data SA 🔎
The retrieval of a Data SA will depend on the security protocol, as different security protocols will have different characteristics. When adding support for a security protocol to MIKEY, some interface of how the security protocol retrieves the Data SA from MIKEY MUST be specified (together with policies that can be negotiated) 🧃
For SRTP, the SSRC (see [SRTP]) is one of the parameters used to retrieve the Data SA, while the MKI may be used to indicate the TGK/TEK used for the Data SA. However, the SSRC is not sufficient. For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY implementation support a lookup using destination network address and port together with SSRC. Note that MIKEY does not send network addresses or ports. One reason for this is that they may not be known in advance. Also, if a NAT exists in-between, problems may arise 😬 When SIP or RTSP is used, the local view of the destination address and port can be obtained from either SIP or RTSP. MIKEY can then use these addresses as the index for the Data SA lookup 🦋
4.5. TGK re-keying and CSB updating ✨
okay so MIKEY lets you update the CSB 💅 (think: sending a fresh TGK/TEK, or adding a brand new Crypto Session to it). You do this by running MIKEY again, like right before a TEK expires or when a new Crypto Session shows up. Quick reality check though: MIKEY does NOT do re-keying in the GKMARCH sense. It just updates keys with normal unicast messages 🦋
When MIKEY runs again to update the CSB, you don't have to resend the certificates and other info from the first exchange. Anything static or optionally included can just get left out (see Figure 4.1) 🧚
The new exchange MUST use the same CSB ID as the initial one, but it MUST use a new timestamp ⏰ A new RAND MUST NOT be included in the message exchange, because the RAND only does anything in the Initial exchange 🙅♀️ If you want, new Crypto Sessions can be added in the update message. An update message doesn't need new keying material (like a new TGK) though! In that case the crypto session just keeps using the keying material it already has, while the new info gets updated 🌸
As explained in Section 3.2, the envelope key can be "cached" as a pre-shared key (the Initiator says so in the first message it sends) 💜 If it's cached, the update message is a pre-shared key message using that cached envelope key as the pre-shared key. It MUST NOT be a public key message. If the public key message is used but the envelope key isn't cached, the Initiator MUST provide a new encrypted envelope key that can be used in the verification message. The Initiator doesn't need to provide any other keys, which is lowkey so nice 🥹
Figure 4.1 shows the update messages that can be sent, optional bits included. The big difference from the original message is that including TGKs (or DH values in the DH method) is optional 🍓 See Section 3 for more on the specific methods.
By definition, a CSB can hold several CSs, and this is where it gets tricky 😭 If an SPI (or something similar, like MKI in [SRTP]) isn't used, it can be hard to keep the TGK re-keying in sync. So it is RECOMMENDED that an SPI or MKI be used whenever more than one CS is present 🔐
Initiator Responder
Pre-shared key method:
I_MESSAGE =
HDR, T, [IDi], [IDr], {SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
Public key method:
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[KEMAC], [CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
DH method:
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr], {SP},
[DHi], SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNrFigure 4.1: Update messages.
Note that for the DH method, if the Initiator includes the DHi payload, then the Responder MUST include DHr and DHi. If the Initiator does not include DHi, the Responder MUST NOT include DHr or DHi 🫶
5. Behavior and message handling 🎀
Each message that the Initiator or the Responder sends is built from a set of payloads. This section explains how messages get created and when they can be used 💖
5.1. General 🌈
5.1.1. Capability Discovery
The Initiator tells the other side which security policy it wants to use (in terms of security protocol algorithms) 🔥 If the Responder doesn't support it for some reason, the Responder can send back an error message saying it doesn't support those parameters, and include its own capabilities (that's the negotiation part) so the Initiator can pick a common set of parameters 👑 This is done by including one or more security policy payloads in the error message sent in response (see Section 5.1.2.). You can give multiple attributes in sequence in the response, which cuts down on roundtrips as much as possible. Basically, in most cases where the policy is accepted the first time, one roundtrip is enough ✨ If the Responder doesn't accept the offer, the Initiator must go out with a new MIKEY message.
If the Responder isn't willing or able to provide security, or the parties just can't agree, it's up to each party's policies to decide what happens, like accepting or rejecting an insecure communication 🙈
Note that this protocol isn't meant to have a huge variety of options, since a denied offer should rarely happen 💅
In the one-to-many and many-to-many scenarios using multicast communication, the big issue is that there MUST be a common security policy for all the receivers. That limits how much negotiation is possible 🦋
5.1.2. Error Handling
Because of the key management protocol, all errors SHOULD be reported to the peer(s) with an error message. So the Initiator SHOULD always be ready to receive one from the Responder 🫣
If the Responder doesn't support the set of parameters the Initiator suggested, the error message SHOULD include the supported parameters (see also Section 5.1.1).
The error message is formed like this:
HDR, T, {ERR}, {SP}, [V|SIGNr]Note that if the failure is due to not being able to authenticate the peer, the error message is OPTIONAL and doesn't need to be authenticated. It's up to local policy to decide how to handle this kind of message 🧐 However, if a signed error message gets returned in response to a failed authentication, that can be used for DoS purposes (against the Responder) 😬 Similarly, an unauthenticated error message could be sent to the Initiator to trick it into tearing down the CSB. It is highly RECOMMENDED that local policy takes this into consideration 🚨 So in case of an authentication failure, one recommendation is to not authenticate such an error message, and when you receive an unauthenticated one, only treat it as a hint about what may have gone wrong 🍵
5.2. Creating a message 🧁
To create a MIKEY message, you first make a Common Header payload. After that comes a set of information payloads (like the DH-value payload, Signature payload, or Security Policy payload), depending on the message type. The defined payloads and the exact encoding of each one are described in Section 6 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5.1. MIKEY payload message example. Note that the payloads are byte aligned and not 32-bit aligned. 📐
The process of generating a MIKEY message has these steps:
- Create an initial MIKEY message starting with the Common Header payload 🪄
- Concatenate the necessary payloads of the MIKEY message (see the exchange definitions for payloads that may be included, and the recommended order) 🧩
- As a last step (for messages that must be authenticated, this also includes the verification message), create and concatenate the MAC/signature payload without the MAC/signature field filled in. If a Next payload field is included in this payload, it is set to Last payload 🏁
- Calculate the MAC/signature over the entire MIKEY message, except the MAC/Signature field, and add the MAC/signature in that field. In the case of the verification message, the Identity_i || Identity_r || Timestamp MUST directly follow the MIKEY message in the Verification MAC calculation. The added identities and timestamp are identical to those carried in the ID and T payloads 🔏
In the public key case, the Key data transport payload is generated by concatenating the IDi with the TGKs. This is then encrypted and placed in the data field. The MAC is calculated over the entire Key data transport payload except the MAC field. Before calculating the MAC, the Next payload field is set to zero 🫧
Note that all messages from the Initiator MUST use a unique timestamp. The Responder doesn't create a new timestamp; it uses the one the Initiator used 💜
5.3. Parsing a message 🔍
In general, parsing a MIKEY message means extracting payload by payload and checking that no errors occur. The exact procedure is implementation specific. However, for the Responder, it is RECOMMENDED that the following procedure be followed 🕵️♀️
- Extract the Timestamp and check that it's within the allowable clock skew (if it isn't, discard the message). Also check the replay cache (Section 5.4) so the message isn't replayed (see Section 5.4). If the message is replayed, discard it 🙅
- Extract the ID and authentication algorithm (if they're not included, assume the default) 🪪
- Verify the MAC/signature ✅
- If the authentication isn't successful, an Auth failure Error message MAY be sent to the Initiator. The message is then discarded from further processing. See also Section 5.1.2 for how to treat errors 💔
- If the authentication is successful, the message is processed and also added to the replay cache. Processing is implementation specific. Note also that only successfully authenticated messages are stored in the replay cache 🥇
- If any unsupported parameters or errors occur during processing, these MAY be reported to the Initiator by sending an error message, and then the processing is aborted. The error message can also include payloads that describe the supported parameters 🙋♀️
- If the processing was successful, and the Initiator asked for it, a verification/response message MAY be created and sent to the Initiator 🎉
5.4. Replay handling and timestamp usage ⏰
okay bestie, MIKEY does NOT use challenge-response for replay handling 🙈 it uses timestamps instead, which means the clocks have to be synchronized 🕰️ how synced they need to be depends on how many messages you can cache (fyi the replay cache only holds messages that were successfully authenticated 🔐). if the cache were unlimited, terminals wouldn't need synced clocks at all, since it could hold every previous message ♾️ but if the cache size is limited, the clocks need some level of sync. basically it's a tradeoff between cache size and how synced your clocks have to be ⚖️
timestamp usage prevents replay attacks under these assumptions 💅
- each host has a clock that's at least "loosely synchronized" with the clocks of the other hosts.
- if the clocks get synced over the network, a secure network clock synchronization protocol SHOULD be used, e.g., [ISO3].
- each Responder uses a replay cache to remember the successfully authenticated messages presented within an allowable clock skew (which is set by the local policy).
- replayed and outdated messages, like ones found in the replay cache or ones with an outdated timestamp, get discarded and not processed 🗑️
- if the host loses track of the incoming requests (e.g., due to overload), it rejects all incoming requests until the clock skew interval has passed 😤
in a client-server scenario, servers may run into a high workload, especially if a replay cache is necessary 😩 however, servers acting as MIKEY Initiators won't need to manage any significant replay cache, since they'll refuse all incoming messages that aren't a response to a message the server previously sent. iconic behavior honestly ✨
in general, a client may not expect a very high load of incoming messages, so it can allow the degree of looseness to be on the order of several minutes to hours ⏳ if a (D)DoS attack gets launched and the replay cache grows too large, MIKEY MAY dynamically decrease the looseness so the replay cache stays manageable. but note that these (D)DoS attacks can only be performed by peers that can authenticate themselves, so the attack is very easy to trace and mitigate 🕵️♀️ not me being impressed by that 💅
the maximum number of messages a client will need to cache may vary depending on the capacity of the client itself and the network. the number of expected messages should be taken into account 🧮
for example, say we can spend at most 6kB on a replay cache 🗂️ and we need to store 30 bytes for each incoming authenticated message (the hash of the message is 20 bytes). that means we can cache approximately 204 messages. if the expected number of messages per minute can be estimated, the clock skew can easily be calculated. in a SIP scenario where the client is expected, in the most extreme case, to receive 10 calls per minute, the clock skew needed is approximately 20 minutes 📞 in a not so extreme setting, where you could expect an incoming call every 5th minute, that works out to a clock skew on the order of 16.5 hours (approx 1000 minutes) 😴
now consider a very extreme case, where the maximum number of incoming messages is assumed to be on the order of 120 messages per minute, and the requirement is that the clock skew is on the order of 10 minutes. that would need a 48kB replay cache 💀
so yes, the required clock skew depends largely on the setting MIKEY is used in 🌸 one recommendation is to fix a size for the replay cache and let the clock skew be large (the initial clock skew can be set depending on the application it's used in). as the replay cache grows, the clock skew gets decreased depending on the percentage of the used replay cache. this is handled locally, so it won't require interaction with the peer (even though it may indirectly effect the peer) 🦋 exactly how to implement that functionality is out of the scope of this document and considered implementation specific, so that's on the implementers, bestie 🫶
in case of a DoS attack, the client will most likely be able to handle the replay cache. a more likely (and serious) DoS attack is a CPU DoS attack, where the attacker sends messages to the peer, which then needs to spend resources verifying the MACs/signatures of the incoming messages 🔥 this one is the real villain arc, ngl 😭
6. Payload Encoding ✨
this section breaks down all the payloads in detail 💖 all encoding uses network byte order, always 🧠 when defining supported types (like which hash functions are supported), the mandatory-to-implement types are marked (as Mandatory), along with the default types (default also implies mandatory implementation). support for the other types is implicitly assumed to be optional 🌈
heads up that support for SRTP [SRTP] as a security protocol is defined here. this helps you understand what the different payloads and fields are for 🎀 other security protocols MAY be specified for use within MIKEY, see Section 10 🦋
in the following, the sign ~ indicates a variable length field 💜
6.1. Common Header payload (HDR) 👑
the Common Header payload MUST always be present as the first payload in each message 😤 it includes a general description of the exchange message, so it's giving main character energy 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- version (8 bits): the version number of MIKEY.
version = 0x01refers to MIKEY as defined in this document 🧾 - data type (8 bits): describes the type of message (e.g., public-key transport message, verification message, error message) 📨
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error messageTable 6.1.a
- next payload (8 bits): identifies the payload that is added after this payload 🔗
Next payload | Value | Section
------------------------------
Last payload | 0 | -
KEMAC | 1 | 6.2
PKE | 2 | 6.3
DH | 3 | 6.4
SIGN | 4 | 6.5
T | 5 | 6.6
ID | 6 | 6.7
CERT | 7 | 6.7
CHASH | 8 | 6.8
V | 9 | 6.9
SP | 10 | 6.10
RAND | 11 | 6.11
ERR | 12 | 6.12
Key data | 20 | 6.13
General Ext. | 21 | 6.15Table 6.1.b
some payloads can't directly follow the header (like "Last payload" or "Signature"). still, the Next payload field is generic for all payloads, so each payload gets a value allocated. the Next payload field is set to zero (Last payload) if the current payload is the last one 🥺
- V (1 bit): flag to indicate whether a verification message is expected or not (this only has meaning when it's set by the Initiator) 🚩 the V flag SHALL be ignored by the receiver in the DH method (as the response is MANDATORY) 🙅♀️
V = 0 ==> no response expected
V = 1 ==> response expected- PRF func (7 bits): indicates the PRF function that has been, or will be, used for key derivation 🔑
PRF func | Value | Comments
--------------------------------------------------------
MIKEY-1 | 0 | Mandatory (see Section 4.1.2)Table 6.1.c
- CSB ID (32 bits): identifies the CSB 🆔 it is RECOMMENDED that the CSB ID be chosen at random by the Initiator. this ID MUST be unique between each Initiator-Responder pair, i.e., not globally unique 🌍 an Initiator MUST check for collisions when choosing the ID (if the Initiator already has one or more established CSBs with the Responder) 🙈 the Responder uses the same CSB ID in the response 🫶
- #CS (8 bits): indicates the number of Crypto Sessions that will be handled within the CBS 🧮 even though it's possible to use 255 CSs, it's not likely that a CSB will include this many CSs 💀 the integer 0 is interpreted as no CS included, which may be the case in an initial setup message 🌱
- CS ID map type (8 bits): specifies the method of uniquely mapping Crypto Sessions to the security protocol sessions 🗺️
CS ID map type | Value
-----------------------
SRTP-ID | 0Table 6.1.d
- CS ID map info (16 bits): identifies the crypto session(s) for which the SA should be created 🎯 the currently defined map type is the SRTP-ID (defined in Section 6.1.1) 💖
6.1.1. SRTP ID
okay so this is the SRTP ID payload 🎀 here's the picture:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+Policy_no_i(8 bits): the security policy applied for the stream withSSRC_i. The same security policy may apply for all CSs. 🔐SSRC_i(32 bits): specifies the SSRC that MUST be used for the i-th SRTP stream. Note that it is the sender of the streams that chooses the SSRC. Therefore, it is possible that the Initiator of MIKEY cannot fill in all fields. In this case, SSRCs that are not chosen by the Initiator are set to zero and the Responder fills in these fields in the response message. Note that SRTP specifies requirements on the uniqueness of the SSRCs (to avoid two-time pad problems if the same TEK is used for more than one stream) [SRTP]. 💅ROC_i(32 bits): current rollover counter used in SRTP. If the SRTP session has not started, this field is set to 0. This field is used to enable a member to join and synchronize with an already started stream. ✨
NOTE: The stream using SSRC_i will also have Crypto Session ID equal to no i (NOT to the SSRC). 🦋
6.2. Key data transport payload (KEMAC)
okay the Key data transport payload is where the encrypted Key data sub-payloads live 🧚 (see Section 6.13 for the definition of the Key data sub-payload). It may contain one or more Key data payloads, each including, for example, a TGK. The last Key data payload has its Next payload field set to Last payload. For an update message (see also Section 4.5), it is allowed to skip the Key data sub-payloads (which will result in the Encr data len being equal to 0).
Note that the MAC coverage depends on the method used, i.e., pre-shared vs public key, see below. 👀
If the transport method used is the pre-shared key method, this Key data transport payload is the last payload in the message (note that the Next payload field is set to Last payload). The MAC is then calculated over the entire MIKEY message following the directives in Section 5.2.
If the transport method used is the public-key method, the Initiator's identity is added in the encrypted data. This is done by adding the ID payload as the first payload, which is then followed by the Key data sub-payloads. Note that for an update message, the ID is still sent encrypted to the Responder (this is to avoid certain re-direction attacks) even though no Key data sub-payload is added after. 🚨
In the public-key case, the coverage of the MAC field is over the Key data transport payload only, instead of the complete MIKEY message, as in the pre-shared case. The MAC is therefore calculated over the Key data transport payload, except for the MAC field and where the Next payload field has been set to zero (see also Section 5.2). 🌸
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 alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): identifies the payload that is added after this payload. See Section 6.1 for defined values. ➡️Encr alg(8 bits): the encryption algorithm used to encrypt theEncr datafield.
Encr alg | Value | Comment
-------------------------------------------
NULL | 0 | Very restricted usage, see Section 4.2.3!
AES-CM-128 | 1 | Mandatory; AES-CM using a 128-bit key, see
Section 4.2.3)
AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
Section 4.2.3
Table 6.2.aEncr data len(16 bits): length ofEncr data(in bytes). 📏Encr data(variable length): the encrypted key sub-payloads (see Section 6.13). 🔒MAC alg(8 bits): specifies the authentication algorithm used. 🧾
MAC alg | Value | Comments | Length (bits)
----------------------------------------------------------
NULL | 0 | restricted usage | 0
| | Section 4.2.4 |
HMAC-SHA-1-160 | 1 | Mandatory, | 160
| | Section 4.2.4 |
Table 6.2.bMAC(variable length): the message authentication code of the entire message. 💜
6.3. Envelope data payload (PKE)
okay so the Envelope data payload carries the encrypted envelope key that protects the data in the Key data transport payload during public-key transport 💌 The encryption algorithm used is implicit from the certificate/public key used.
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 ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. ➡️C(2 bits): envelope key cache indicator (Section 3.2). 🗂️
Cache type | Value | Comments
--------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB.
Table 6.3Data len(14 bits): the length of the data field (in bytes). 📐Data(variable length): the encrypted envelope key. 🗝️
6.4. DH data payload (DH)
okay the DH data payload carries the DH-value and tells you which DH-group got used 🌈 Notice that in this sub-section, "MANDATORY" is conditioned upon DH being supported.
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 ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. ➡️DH-Group(8 bits): identifies the DH group used. 🔢
DH-Group | Value | Comment | DH Value length (bits)
--------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
Table 6.4DH-value(variable length): the public DH-value (the length is implicit from the group used). 🫶KV(4 bits): indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI in SRTP) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). See Section 6.13 for pre-defined values. 📅KV data(variable length): This includes either the SPI/MKI or an interval (see Section 6.14). If KV is NULL, this field is not included. 🧩
6.5. Signature payload (SIGN)
okay the Signature payload carries the signature and its related data ✍️ The signature payload is always the last payload in the PK transport and DH exchange messages. The signature algorithm used is implicit from the certificate/public key used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+S type(4 bits): indicates the signature algorithm applied by the signer. 🖊️
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
[PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
Table 6.5Signature len(12 bits): the length of the signature field (in bytes). 📏Signature(variable length): the signature (its formatting and padding depend on the type of signature). 🎟️
6.6. Timestamp payload (T)
okay the timestamp payload carries the timestamp info ⏰
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 ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next payload(8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. ➡️TS type(8 bits): specifies the timestamp type used. 🕰️
TS type | Value | Comments | length of TS value
-------------------------------------|-------------------
NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional | 32-bits
Table 6.6Note: COUNTER SHALL be padded (with leading zeros) to a 64-bit value when used as input for the default PRF. ⚠️
TS-value(variable length): the timestamp value of the specified TS type. 💖
6.7. ID payload (ID) / Certificate Payload (CERT) 🎀
okay bestie, these two are NOT the same payload 💅 they have different payload identifiers, so they're basically strangers 🙈 but they share the same structure, so they get one section together ✨
The ID payload carries a uniquely defined identifier 🦋
The certificate payload has an indicator of the certificate it's giving, plus the certificate data 🔥 and if there's a whole certificate chain, each certificate should go in its own separate CERT 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 ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
If the payload is an ID payload, the following values apply for the ID type field:
- ID Type (8 bits): specifies the identifier type used.
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
Table 6.7.aIf the payload is a Certificate payload, the following values apply for the Cert type field:
- Cert Type (8 bits): specifies the certificate type used.
Cert Type | Value | Comments
----------------------------------------------
X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only)
Table 6.7.b- ID/Cert len (16 bits): the length of the ID or Certificate field (in bytes).
- ID/Certificate (variable length): The ID or Certificate data. The X.509 [X.509] certificates are included as a bytes string using DER encoding as specified in X.509.
6.8. Cert hash payload (CHASH) 🍓
The Cert hash payload contains the hash of the certificate used 🧚
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 ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
- Hash func (8 bits): indicates the hash function that is used (see also Section 4.2.1).
Hash func | Value | Comment | hash length (bits)
-------------------------------------------------
SHA-1 | 0 | Mandatory | 160
MD5 | 1 | | 128
Table 6.8- Hash (variable length): the hash data. The hash length is implicit from the hash function used.
6.9. Ver msg payload (V) 🌈
The Ver msg payload contains the calculated verification message in the pre-shared key and the public-key transport methods 🔐 note that the MAC is calculated over the entire MIKEY message, as well as the IDs and Timestamp (see also Section 5.2) 👑
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 ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
- Auth alg (8 bits): specifies the MAC algorithm used for the verification message. See Section 6.2 for defined values.
- Ver data (variable length): the verification message data. The length is implicit from the authentication algorithm used.
6.10. Security Policy payload (SP) 🦋
The Security Policy payload defines a set of policies that apply to a specific security protocol 💅
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 ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
- Policy no (8 bits): each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a crypto session to a specific policy (see also Section 6.1.1).
- Prot type (8 bits): defines the security protocol.
Prot type | Value |
---------------------------
SRTP | 0 |
Table 6.10- Policy param length (16 bits): defines the total length of the policy parameters for the specific security protocol.
- Policy param (variable length): defines the policy for the specific security protocol.
The Policy param part is built up by a set of Type/Length/Value fields 🧩 for each security protocol, a set of possible types/values that can be negotiated is defined ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type (8 bits): specifies the type of the parameter.
- Length (8 bits): specifies the length of the Value field (in bytes).
- Value (variable length): specifies the value of the parameter.
6.10.1. SRTP policy 🎀
This policy specifies the parameters for SRTP and SRTCP 💖 the types/values that can be negotiated are defined by the following table:
Type | Meaning | Possible values
----------------------------------------------------
0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes
Table 6.10.1.aNote that if a Type/Value is not set, the default is used (according to SRTP's own criteria) 👀 note also that, if "Session Encr. key length" is set, this should also be seen as the Master key length (otherwise, the SRTP default Master key length is used) 🔑
For the Encryption algorithm, a one byte length is enough. The currently defined possible Values are:
SRTP encr alg | Value
---------------------
NULL | 0
AES-CM | 1
AES-F8 | 2
Table 6.10.1.bwhere AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP] 🌸
For the Authentication algorithm, a one byte length is enough. The currently defined possible Values are:
SRTP auth alg | Value
---------------------
NULL | 0
HMAC-SHA-1 | 1
Table 6.10.1.cFor the SRTP pseudo-random function, a one byte length is also enough. The currently defined possible Values are:
SRTP PRF | Value
---------------------
AES-CM | 0
Table 6.10.1.dIf FEC is used at the same time SRTP is used, MIKEY can negotiate the order in which these should be applied at the sender side 🔥
FEC order | Value | Comments
--------------------------------
FEC-SRTP | 0 | First FEC, then SRTP
Table 6.10.1.e6.11. RAND payload (RAND) 🌙
The RAND payload consists of a (pseudo-)random bit-string 🎲 The RAND MUST be independently generated per CSB (note that if the CSB has several members, the Initiator MUST use the same RAND for all the members) ⭐ for randomness recommendations for security, see [RAND] 🫶
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 ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
- RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at least 16.
- RAND (variable length): a (pseudo-)randomly chosen bit-string.
6.12. Error payload (ERR) 🚨
The Error payload is used to specify the error(s) that may have occurred 😭
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 ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values.
- Error no (8 bits): indicates the type of error that was encountered.
Error no | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Table 6.126.13. Key data sub-payload 🔑
The Key data payload is where the actual key material lives, like TGKs 🗝️. Key data payloads are never sent in clear, bestie 🙅♀️. They only show up as an encrypted part of the Key data transport payload (KEMAC) 🔒. Also, one Key data transport payload can hold multiple Key data sub-payloads, so the whole squad can ride together 💅
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): tells you which payload gets added right after this one 🔗. See Section 6.1 for the values.
- Type (4 bits): says what kind of key is in the payload 🎀
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3Table 6.13.a
Okay, so a TEK can be used instead of the TGK ✨ When it's sent directly, a TEK generally can't be shared between more than one Crypto Session (unless the Security protocol allows it, e.g., [SRTP]). The recommended time to send a TEK instead of a TGK is when pre-encrypted material already exists, so the TEK has to be known in advance 🧠
- KV (4 bits): indicates the type of key validity period specified 📅. This may be done with an SPI (or MKI in the case of [SRTP]), or by giving an interval where the key is valid (for SRTP in that case, that's the index range where the key is valid 🦋).
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g., a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time
| | (e.g., an SRTP TEK)Table 6.13.b
Note that when NULL is specified, any SPI or Interval is valid 🌈. For an Interval, that means the key is valid from the first observed sequence number until the key gets replaced (or the security protocol is shut down).
- Key data len (16 bits): the length of the Key data field, in bytes 📏. Note that the total length of all the Key data payloads inside one Key data transport payload (KEMAC) MUST be such that the KEMAC payload does not exceed a length of 2^16 bytes (total length of KEMAC, see Section 6.2). Non-negotiable, no cap 🚫
- Key data (variable length): the TGK or TEK data 🔑
- Salt len (16 bits): the salt key length in bytes 🧂. This field is only included if the salt is specified in the Type field.
- Salt data (variable length): the salt key data 🧂. This field is only included if the salt is specified in the Type field. (For SRTP, this is the so-called master salt.)
- KV data (variable length): this includes either the SPI or an interval (see Section 6.14). If KV is NULL, this field is not included.
6.14. Key validity data ⏳
The Key validity data isn't a standalone payload 🙅♀️. It's part of either the Key data payload (see Section 6.13) or the DH payload (see Section 6.4). It gives a guideline for when the key should be used 💭 There are two KV types defined (see Section 6.13): SPI/MKI (SPI), or a lifetime range (interval).
SPI/MKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- SPI Length (8 bits): the length of the SPI (or MKI) in bytes 📐
- SPI (variable length): the SPI (or MKI) value 🎫
Interval
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- VF Length (8 bits): length of the Valid From field in bytes 📏
- Valid From (variable length): a sequence number, index, timestamp, or other start value that the security protocol uses to identify where key usage starts 🚦
- VT Length (8 bits): length of the Valid To field in bytes 📏
- Valid To (variable length): a sequence number, index, timestamp, or other expiration value that the security protocol can use to identify when key usage expires 🛑
Note that for SRTP usage, the key validity period for a TGK/TEK should be specified either with an interval, where the VF/VT Length is equal to 6 bytes (i.e., the size of the index), or with an MKI 🌸 It is RECOMMENDED that if more than one SRTP stream is sharing the same keys and key update/re-keying is desired, this is handled using MKI rather than the From-To method. Main character energy for MKI 👑
6.15. General Extension Payload 🧩
The General extensions payload exists so MIKEY can be extended without having to define a brand-new payload every single time 🙌 It can show up in any MIKEY message, and it's part of the authenticated/signed data part 🔏
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 ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next payload (8 bits): identifies the payload that is added after this payload 🔗
- Type (8 bits): identifies the type of general payload 🏷️
Type | Value | Comments
---------------------------------------
Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])Table 6.15
- Length (16 bits): the length in bytes of the Data field 📏
- Data (variable length): the general payload data 💾
7. Transport protocols 🚚
MIKEY MAY be integrated within session establishment protocols 💌 Right now, integration of MIKEY within SIP/SDP and RTSP is defined in [KMASDP]. MIKEY MAY use other transports too, but then how MIKEY is carried over that transport protocol has to be defined first 📦
8. Groups 👯
Everything we've covered so far isn't limited to one-on-one peer-to-peer chats (except for the DH method) 💬 It can also distribute group keys for small interactive groups and simple one-to-many scenarios 📣 Section 2.1. describes the scenarios MIKEY is focused on. This section explains how MIKEY is used in a group scenario (though see also Section 4.3 for issues related to authorization 🛡️).
8.1. Simple one-to-many 📡
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++Figure 8.1. Simple one-to-many scenario.
In the simple one-to-many scenario, a server is streaming to a small group of clients 🎬 RTSP or SIP is used for registration and the key management setup. The streaming server acts as the Initiator of MIKEY. In this scenario, the pre-shared key or public key transport mechanism is the right fit for sending the same TGK to all the clients, which results in common TEKs for the group 🫶
Note, if the same TGK/TEK(s) should be used by all the group members, the streaming server MUST specify the same CSB_ID and CS_ID(s) for the session to all the group members 🚨
As the communication may be performed using multicast, the members need a common security policy if they want to be part of the group 🤝 That limits how much negotiation is possible.
Furthermore, the Initiator should carefully consider whether to request the verification message in reply from each receiver 🧐 That can put a real load on the Initiator as the group size grows.
8.2. Small-size interactive group 🫂
For small-size interactive groups, you can expect each client to be in charge of setting up security for its outgoing streams 💁♀️ In these scenarios, the pre-shared key or the public-key transport method is used.
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++Figure 8.2. Small-size group without a centralized controller.
One scenario could be a client setting up a three-way call using SIP 📞 Because the group is small, unicast SRTP is used between the clients. Each client sets up the security for its outgoing stream(s) to the others 💖
Same as the simple one-to-many case: if the same TGK/TEK(s) is used for all the group members, the streaming client specifies the same CSB_ID and CS_ID(s) for its outgoing sessions ✨
9. Security Considerations 🔐
9.1. General ✨
okay bestie, so key management protocols that run on timestamps or counters and do a one-roundtrip key transport have already been standardized before, like ISO [ISO1, ISO2]. the general security of these kinds of protocols is all over articles and literature, c.f. [HAC, AKE, LOA] 📚
no chain is stronger than its weakest link 💅 so if you want a certain level of protection, then the cryptographic functions protecting the keys during transport/exchange MUST offer security that's at least that level 🔥
for example, if you want security against attacks with a complexity of 2^96, then you should pick a secure symmetric cipher that supports at least 96 bit keys (128 bits may be a practical choice) for the actual media protection 🎀 and then a key transport mechanism with equivalent protection, like MIKEY's pre-shared key transport with 128 bit TGK, or RSA with 1024 bit keys (which according to [LV] matches the desired 96 bit level, with some margin) 🦋
in summary, the key size for the key-exchange mechanism MUST be weighed against the size of the exchanged TGK so that it at least offers the level you need 🌸 for efficiency reasons, you SHOULD also avoid security overkill, like using a public key transport whose public keys give a security level that's orders of magnitude higher than the length of the transported TGK 🙈 we refer to [LV] for concrete key size recommendations 📖
also, if the TGKs aren't random (or pseudo-random), a brute force search may get easier, which lowers the effective key size again 💀 so care MUST be taken when designing the (pseudo-) random generators for TGK generation, see [FIPS][RAND] 🫶
for picking the hash function, SHA-1 with 160-bit output is the default one 🍓 in general, hash sizes should be twice the "security level", which means SHA-1-256, [SHA256], should be used for the default 128-bit level ✨ however, because of the real-time aspects in the scenarios we're covering, hash sizes slightly below 256 are acceptable, since the normal "existential" collision probabilities would be of secondary importance 🌈
in a Crypto Session Bundle, the Crypto Sessions can share the same TGK, as discussed earlier 👑 to satisfy the criterion when the TGK is shared, the encryption of each individual Crypto Session is performed "independently" 💜 in MIKEY, this is done by having unique Crypto Session identifiers (see also Section 4.1) and a TEK derivation method that gives cryptographically independent TEKs to distinct Crypto Sessions (within the Crypto Session Bundle), regardless of the security protocol used 🧚
specifically, the key derivations, as specified in Section 4.1, are implemented by a pseudo-random function 🦋 the one used here is a simplified version of the one used in TLS [TLS]. only one single hash function is used here, whereas TLS uses two different functions 🌸 this choice was motivated by the high confidence in the SHA-1 hash function, and by efficiency and simplicity of design (complexity does not imply security) 💅 and honestly, as shown in [DBJ], if one of the two hashes is severely broken, the TLS PRF is actually less secure than if a single hash had been used on the whole key, which is what MIKEY does 😭
in the pre-shared key and public-key schemes, the TGK is generated by a single party (Initiator) 🍓 this makes MIKEY somewhat more sensitive if the Initiator uses a bad random number generator 💀 it should also be noted that neither the pre-shared nor the public-key scheme provides perfect forward secrecy 🙈 if mutual contribution or perfect forward secrecy is desired, the Diffie-Hellman method is to be used 🔥 authentication (e.g., signatures) in the Diffie-Hellman method is required to prevent man-in-the-middle attacks 🛡️
forward/backward security: if the TGK is exposed, all generated TEKs are compromised 😭 however, under the assumption that the derivation function is a pseudo-random function, disclosure of an individual TEK does not compromise other (previous or later) TEKs derived from the same TGK 🫶 the Diffie-Hellman mode can be considered by cautious users, since it's the only one that supports so-called perfect forward secrecy (PFS) ✨ this is in contrast to a compromise of the pre-shared key (or the secret key of the public key mode), where future sessions and recorded sessions from the past are then also compromised 💀
the use of random nonces (RANDs) in the key derivation is of utmost importance to counter off-line pre-computation attacks 👑 note however that update messages re-use the old RAND 🙈 this means the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs and RAND are each n bits long, is about L = n*(k+1)/2 bits, compared to the theoretical maximum of n*k bits 📐 in other words, a 2^L work effort MAY enable an attacker to get all k n-bit keys, which is better than brute force (except when k = 1) 😳
while this might seem like a defect, first note that for a proper choice of n, the 2^L complexity of the attack is way out of reach 🌈 moreover, the fact that more than one key can be compromised in a single attack is inherent to the key exchange problem 🧠 consider, for instance, a user who uses a fixed 1024-bit RSA key to exchange keys and communicate during a one or two year lifetime of the public key 🦋 breaking this single RSA key will enable access to all exchanged keys, and consequently the entire communication of that user over the whole period 💔
all the pre-defined transforms in MIKEY use state-of-the-art algorithms that have undergone large amounts of public evaluation 🌟 one of the reasons for using the AES-CM from SRTP [SRTP] is to have the possibility of limiting the overall number of different encryption modes and algorithms, while offering a high level of security at the same time 💖
9.2. Key lifetime 🕰️
even if the lifetime of a TGK (or TEK) is not specified, it MUST be taken into account that the encryption transform in the underlying security protocol can in some way degenerate after a certain amount of encrypted data 😬 it's not possible to state universally applicable, general key lifetime bounds here, so each security protocol should define such a maximum amount and trigger a re-keying procedure before the "exhaustion" of the key 🔑 for example, according to SRTP [SRTP], the TEK, together with the corresponding TGK, MUST be changed at least every 2^48 SRTP packet 📦
still, the following can be said as a rule of thumb 🧮 if the security protocol uses an "ideal" b-bit block cipher (in CBC mode, counter mode, or a feedback mode, e.g., OFB, with full b-bit feedback), degenerate behavior in the crypto stream, possibly useful for an attacker, is (with constant probability) expected to occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs) 🌀 for security margin, re-keying MUST be triggered well in advance compared to the above bound 🚨 see [BDJR] for more details 📚
for use of a dedicated stream cipher, we refer to the analysis and documentation of said cipher in each specific case 🌊
9.3. Timestamps ⏰
the use of timestamps, instead of challenge-responses, requires the systems to have synchronized clocks 🕑 of course, if two clients are not synchronized, they'll have difficulties setting up the security 😩 the current timestamp-based solution was selected to allow a maximum of one roundtrip (i.e., two messages), but still provide reasonable replay protection 🎀 a (secure) challenge-response based version would require at least three messages 🙃 for a detailed description of the timestamp and replay handling in MIKEY, see Section 5.4 🧾
practical experience with Kerberos and other timestamp-based systems indicates that it's not always necessary to synchronize the terminals over the network 🌸 manual configuration could be a feasible alternative in many cases (especially in scenarios where the degree of looseness is high) ✨ however, the choice must be made carefully with respect to the usage scenario 💜
9.4. Identity Protection 🕵️♀️
user privacy is a complex matter that can be enforced to some extent by cryptographic mechanisms, but it also requires policy enforcement and various other functionalities 🫶 one particular facet of privacy is user identity protection 🦋 however, identity protection was not a main design goal for MIKEY 🙈 such a feature would add more complexity to the protocol, so it was not chosen to be included 🧩 as MIKEY is anyway proposed to be transported over, e.g., SIP, the identity may be exposed by this 😬 however, if the transporting protocol is secured and also provides identity protection, MIKEY might inherit the same feature 🌈 how this should be done is for future study 🔮
9.5. Denial of Service 🚫
this protocol is resistant to Denial of Service attacks in the sense that a Responder does not construct any state (at the key management protocol level) before it has authenticated the Initiator 🛡️ however, this protocol, like many others, is open to attacks that use spoofed IP addresses to create a large number of fake requests 😤 this may, for example, be solved by letting the protocol transporting MIKEY do an IP address validity test 🌐 the SIP protocol can provide this using the anonymous authentication challenge mechanism (specified in Section 22.1 of [SIP]) 💫
it is highly RECOMMENDED to include IDr in the Initiator's message 👑 if it's not included, its absence can be used for DoS purposes (the largest DoS impact being on the public key and DH methods), where a message intended for other entities is sent to the target 💀 in fact, the target may verify the signature correctly, because the Initiator's ID is correct and the message is actually signed by the claimed Initiator (e.g., by re-directing traffic from another session) 😳
however, in the public key method, the envelop key and the MAC will ensure that the message is not accepted (still, compared to a normal faked message, where the signature verification would detect the problem, one extra public key decryption is needed to detect the problem in this case) 🔐
in the DH method, a message would be accepted (without detecting the error), and a response (and state) would be created for the malicious request 😭
as also discussed in Section 5.4, the tradeoff between time synchronization and the size of the replay cache may be affected in case of, for example, a flooding DoS attack 🌊 however, if the recommendations of using a dynamic size of the replay cache are followed, it is believed that the client will in most cases be able to handle the replay cache ✨ of course, as the replay cache decreases in size, the required time synchronization is more restricted 🕰️ however, a bigger problem during such an attack would probably be processing the messages (e.g., verifying signatures/MACs) due to the computational workload this implies 🥵
9.6. Session Establishment 🔐
okay so, if the session establishment protocol is insecure, attackers can mess with it and that causes indirect problems for the secured media streams 😬 this only applies to groups though (it's not a MIKEY-specific thing) 🫶. the scary part is one group member redirecting a stream from one member to another. that's basically the same as someone impersonating a member, like by changing its IP address 👀. if that's a problem for you, it is RECOMMENDED that you apply a Data Origin Authentication (DOA) scheme (e.g., digital signatures) to the security protocol 💅.
redirecting streams can absolutely happen outside of a group too 🦋. but it's not the same vibe. in a group, impersonation can happen if DOA isn't used, which is way worse. outside a group, redirection just means the receiver can't get the data (or it arrives late) 🥲.
10. IANA Considerations 🧚
this document defines a bunch of new name spaces tied to the MIKEY payloads 🌈. this section lists the ones IANA is asked to manage. IANA should record the pre-defined values from the sections below for each name space, and manage any extra values added later 💜. unless it's explicitly said otherwise, values in the range 0-240 for each name space SHOULD be approved through IETF consensus, and values 241-255 are reserved for Private Use, per [RFC2434] ✨.
the Common header payload fields (from Section 6.1) that IANA manages are, with the table with the starting values in brackets:
- version
- data type (Table 6.1.a)
- Next payload (Table 6.1.b)
- PRF func (Table 6.1.c). this one is 0-127, where 0-111 should be approved by IETF consensus and 112-127 are reserved for Private Use 🫠
- CS ID map type (Table 6.1.d)
the Key data transport payload fields (from Section 6.2) IANA manages:
- Encr alg (Table 6.2.a)
- MAC alg (Table 6.2.b)
the Envelope data payload fields (from Section 6.3) IANA manages:
- C (Table 6.3)
the DH data payload field (from Section 6.4) IANA manages:
- DH-Group (Table 6.4)
the Signature payload field (from Section 6.5) IANA manages:
- S type (Table 6.5)
the Timestamp payload field (from Section 6.6) IANA manages:
- TS type (Table 6.6)
the ID payload and Certificate payload fields (from Section 6.7) IANA manages:
- ID type (Table 6.7.a)
- Cert type (Table 6.7.b)
the Cert hash payload field (from Section 6.8) IANA manages:
- Hash func (Table 6.8)
the Security policy payload field (from Section 6.10) IANA manages:
- Prot type (Table 6.10)
for each security protocol that uses MIKEY, a set of unique parameters MAY be registered 🎀.
from Section 6.10.1, IANA manages these:
- SRTP Type (Table 6.10.1.a)
- SRTP encr alg (Table 6.10.1.b)
- SRTP auth alg (Table 6.10.1.c)
- SRTP PRF (Table 6.10.1.d)
- FEC order (Table 6.10.1.e)
the Error payload field (from Section 6.12) IANA manages:
- Error no (Table 6.12)
the Key data payload fields (from Section 6.13) IANA manages:
- Type (Table 6.13.a). this one is 0-16, which should be approved by IETF consensus
- KV (Table 6.13.b). also 0-16, which should be approved by IETF consensus
the General Extensions payload field (from Section 6.15) IANA manages:
- Type (Table 6.15)
10.1. MIME Registration 📎
this section tells IANA to register the application/mikey MIME media type. the registration looks like this:
MIME media type name : application
MIME subtype name : mikey
Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo11. Acknowledgments 🙏
the authors want to thank Mark Baugher, Ran Canetti, Martin Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov Vatn, Erik Eliasson, and Gerhard Strangar for their valuable feedback 🌸✨.
12. References 📚
12.1. Normative References
[HMAC]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[NAI]Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.[OAKLEY]Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.[PSS]PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, June 14, 2002, www.rsalabs.com[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2434]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.[SHA-1]NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.[SRTP]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004.[URI]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.[X.509]Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.[AESKW]Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
12.2. Informative References
[AKE]Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and their use for Building Secure Channels", Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.[BDJR]Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes of Operation", in Proceedings of the 38th Symposium on Foundations of Computer Science, IEEE, 1997, pp. 394-403.[BMGL]Hastad, J. and M. Naslund: "Practical Construction and Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.[DBJ]Johnson, D.B., "Theoretical Security Concerns with TLS use of MD5", Contribution to ANSI X9F1 WG, 2001.[FIPS]"Security Requirements for Cryptographic Modules", Federal Information Processing Standard Publications (FIPS PUBS) 140-2, December 2002.[GKMARCH]Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Group Key Management Architecture", Work in Progress.[GDOI]Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.[GSAKMP]Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress.[HAC]Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC press, 1996.[IKE]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.[ISO1]ISO/IEC 9798-3: 1997, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques.[ISO2]ISO/IEC 11770-3: 1997, Information technology - Security techniques - Key management - Part 3: Mechanisms using digital signature techniques.[ISO3]ISO/IEC 18014 Information technology - Security techniques - Time-stamping services, Part 1-3.[KMASDP]Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for SDP and RTSP", Work in Progress.[LOA]Burrows, Abadi, and Needham, "A logic of authentication", ACM Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.[LV]Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm[NTP]Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.[OCSP]Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.[RAND]Eastlake, 3rd, D., Crocker, S., and J. Schiller, "Randomness Requirements for Security", RFC 1750, December 1994.[RTSP]Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.[SDP]Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.[SHA256]NIST, "Description of SHA-256, SHA-384, and SHA-512", http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf[SIP]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.[TLS]Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
Appendix A. MIKEY - SRTP Relation 🧩
MIKEY's terminology is different from SRTP's, because MIKEY needs to be more general and isn't tied to SRTP only 💫. so it can be hard to spot how the keys and parameters MIKEY makes line up with the ones SRTP uses. this appendix gives some hints 🦋.
MIKEY | SRTP
-------------------------------------------------
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master keythe Data SA is built from a TEK and the security policy that gets exchanged 🔑. SRTP may use an MKI to index the TEK or TGK (the TEK is then derived from the TGK that goes with the matching MKI), see below 💜.
A.1. MIKEY-SRTP Interactions ✨
okay so bestie, this part is literally the handshake between MIKEY and SRTP 🦋 we're gonna walk through how the two talk to each other. it's only the receiver side here (the sender side needs its own version, which is giving homework energy 💀)
- when an SRTP packet shows up and gets processed, the receiver grabs the triple
<SSRC, destination address, destination port>from it and uses that to find the right SRTP crypto context, aka the Data SA 🔑 (the lookup can happen in a couple ways: SRTP can explicitly ask MIKEY for it, or SRTP can read straight from a "database" that MIKEY keeps. the application usually picks whichever one it likes better 💅) - if an MKI is in the SRTP packet, it points to the correct key inside the SA 🎯. if SRTP's
<From, To>feature is being used instead, then theROC||SEQof the packet tells you which key to grab. - now it depends on whether the key MIKEY sent (the one you got in step 2) was a TEK or a TGK 👀 there are two cases here:
- if the key from step 2 is the TEK itself, SRTP just uses it directly as a master key. no drama 🌸
- if it's a TGK instead, MIKEY uses the CS_ID (that's internal to MIKEY, see Section 6.1.1) to work out the right TEK from the TGK, as described in Section 4.1. only then does SRTP get to use it 🧚
if multiple TGKs (or TEKs) get sent, it is RECOMMENDED that each TGK (or TEK) gets its own distinct MKI 🏷️ and it is RECOMMENDED that the <From, To> thing stays limited to very simple cases, like one stream only. don't get fancy with it, bestie 🙈
besides the actual master key, the rest of the info in the Data SA (like the transform identifiers) also gets passed from MIKEY over to SRTP. obviously 💖
Authors' Addresses 💌
omg the people behind this spec, let's gooo 🫶
Jari Arkko
Ericsson Research
02420 Jorvas
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.comElisabetta Carrara
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 50877040
EMail: elisabetta.carrara@ericsson.comFredrik Lindholm
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.comMats Naslund
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 58533739
EMail: mats.naslund@ericsson.comKarl Norrman
Ericsson Research
SE-16480 Stockholm
Sweden
Phone: +46 8 4044502
EMail: karl.norrman@ericsson.comFull Copyright Statement 🌈
the Internet Society owns the copyright here (2004, we're vintage 🕰️). this doc is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 📜
the doc and everything in it is handed over "AS IS" 🫠 the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all say no to warranties, express or implied. that includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose. it's giving disclaimer era 💅
Intellectual Property 🔐
the IETF doesn't take a side on whether any intellectual property rights (or other rights) claimed for the tech in this doc are valid or how far they reach. it also doesn't say whether licenses for those rights are available, and it hasn't independently checked for any such rights either 🧐 if you want the rules on rights for RFC documents, go read BCP 78 and BCP 79.
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be offered, and the results of anyone trying to get a general license or permission to use those proprietary rights for this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 📂
the IETF also invites anyone to tell them about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that to ietf-ipr@ietf.org 📬 speak up, bestie 📣
Acknowledgement 🫶
funding for the RFC Editor function is currently coming from the Internet Society 💜 thank you for keeping the lights on, we love a sponsor 🌟
📦 where this page comes from
- ietf: rfc3830 2004-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms