RFC 5197
On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions
Okayyy bestie, come sit with me 🎀 This is RFC 5197 and it is a whole vibe. Part 1 of 8, so don't go anywhere yet 💅
The Title Block 📜
Network Working Group, RFC number 5197, published June 2008. Its category is Informational, which means it's an explainer and not a binding standard. The authors are S. Fries from Siemens and D. Ignjatic from Polycom. The title is On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions. The header doesn't list anything it obsoletes or updates, so there's no drama there 🌸
Status of This Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind, so think of it as a guide and not a rulebook 📖 Distribution of this memo is unlimited, so share it with everyone who wants it 💖
Abstract 🌈
Okay so MIKEY (Multimedia Internet Keying) is a key management protocol built for real-time apps. It was designed mainly to support the Secure Real-time Transport Protocol (SRTP) 🔐 MIKEY itself is standardized in RFC 3830, and it defines four key distribution methods. It was also built to be extensible, so new stuff keeps showing up, especially new key distribution methods but also payload upgrades 🚀
This document is an overview of the MIKEY base document and all the extensions to it, both the ones that are already defined and the ones still being worked on ✨ It's meant as an extra resource for developers and architects who want to understand the use cases, the motivations, and the pros and cons of each key distribution scheme 🦋 The use cases here are tied to specific SIP call scenarios that make key management extra tricky. The big ones are media before Session Description Protocol (SDP) answer, forking, and shared key conferencing 📞🔥
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. MIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Pre-Shared Key (PSK) Protected Distribution . . . . . . . 9
3.2. Public Key Encrypted Key Distribution . . . . . . . . . . 9
3.3. Diffie-Hellman Key Agreement Protected with Digital
Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Unprotected Key Distribution . . . . . . . . . . . . . . . 11
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared
Secrets . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. SAML-Assisted DH key Agreement . . . . . . . . . . . . . . 12
3.7. Asymmetric Key Distribution with In-Band Certificate
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Further MIKEY Extensions . . . . . . . . . . . . . . . . . . . 16
4.1. ECC Algorithms Support . . . . . . . . . . . . . . . . . . 16
4.1.1. Elliptic Curve Integrated Encryption Scheme
application in MIKEY . . . . . . . . . . . . . . . . . 17
4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme
Application in MIKEY . . . . . . . . . . . . . . . . . 17
4.2. New MIKEY Payload for Bootstrapping TESLA . . . . . . . . 17
4.3. MBMS Extensions to the Key ID Information Type . . . . . . 18
4.4. OMA BCAST MIKEY General Extension Payload Specification . 18
4.5. Supporting Integrity Transform Carrying the Rollover
Counter . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Selection and Interworking of MIKEY Modes . . . . . . . . . . 19
5.1. MIKEY and Early Media . . . . . . . . . . . . . . . . . . 21
5.2. MIKEY and Forking . . . . . . . . . . . . . . . . . . . . 22
5.3. MIKEY and Call Transfer/Redirect/Retarget . . . . . . . . 23
5.4. MIKEY and Shared Key Conferencing . . . . . . . . . . . . 23
5.5. MIKEY Mode Summary . . . . . . . . . . . . . . . . . . . . 24
6. Transport of MIKEY Messages . . . . . . . . . . . . . . . . . 24
7. MIKEY Alternatives for SRTP Security Parameter Negotiation . . 25
8. Summary of MIKEY-Related IANA Registrations . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 271. Introduction 🦋
Okay so key distribution is basically the process of getting cryptographic keys to the parties who need them 🔑 MIKEY [RFC3830] (the Multimedia Internet Keying) was defined with a focus on setting up security context for the Secure Real-time Transport Protocol [RFC3711]. Note that RFC 3830 is NOT limited to SRTP, though. It has a generic approach and allows extensions to the key distribution schemes, so it may also be used for security parameter negotiation for other protocols 🌷
For MIKEY, seven key distribution methods are described. Honestly this list is giving buffet energy 🍓
- Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK)
- Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA)
- Diffie-Hellman key agreement protected by digital signatures as defined in [RFC3830] (MIKEY-DHSIGN)
- Unprotected key distribution (MIKEY-NULL)
- Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined in [RFC4650] (MIKEY-DHHMAC)
- Security Assertion Markup Language (SAML) assisted Diffie-Hellman key agreement as defined (not available as a separate document, but discussions are reflected within this document (MIKEY-DHSAML))
- Asymmetric key distribution (based on asymmetric encryption) with in-band certificate provision as defined in [RFC4738] (MIKEY-RSA-R)
Note that the latter three modes are extensions to MIKEY, because there have been scenarios where none of the first four modes defined in [RFC3830] fits perfectly 🙈 There are also further extensions to MIKEY that cover algorithm enhancements and a new payload definition for protocols other than SRTP ✨
Algorithm extensions are defined in the following document:
- Elliptic Curve Cryptography (ECC) algorithms for MIKEY as defined in [MSEC-MIKEY]
Payload extensions are defined in the following documents:
- Bootstrapping TESLA, defining a new payload for the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol [RFC4082] as defined in [RFC4442]
- The Key ID information type for the general extension payload as defined in [RFC4563]
- Open Mobile Alliance (OMA) Broadcast (BCAST) MIKEY General Extension Payload Specification as defined in [RFC4909]
- Integrity Transform Carrying Roll-over Counter for SRTP as defined in [RFC4771]. Note that this is rather an extension to SRTP and requires MIKEY to carry a new parameter, but it's included here for completeness 🧚
This document gives an overview of RFC 3830 and how it relates to the different extensions, so you get a framework for using MIKEY 💜 It's meant as an extra resource for developers and architects who want more insight into use case scenarios, motivations, and the advantages and disadvantages of each key distribution scheme. The use cases here are inspired by specific SIP protocol workings that turned out to be problematic for a general key distribution mechanism. Those workings are described in detail in Wing, et al. [SIP-MEDIA], and they include the following:
- Early Media (i.e., media that arrives before the SDP answer)
- Forking
- Call Transfer/Redirect/Retarget
- Shared Key Conferencing
Okay that's the setup, bestie. Part 2 is where it gets spicy 🌈💅
2. Terminology and Definitions 🎀
Quick heads up: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc mean exactly what RFC 2119 [RFC2119] says they mean 💅
Next up, the definitions borrowed from [RFC3830] 💖
(Data) Security Protocol: the security protocol used to protect the
actual data traffic. Examples of security
protocols are IPsec and SRTP.
Data SA Data Security Association information for the security
protocol, including a TEK and a set of parameters/
policies.
CS Crypto Session, uni- or bidirectional data stream(s),
protected by a single instance of a security protocol.
CSB Crypto Session Bundle, collection of one or more
Crypto Sessions, which can have common TGKs (see
below) and security parameters.
CS ID Crypto Session ID, unique identifier for the CS within
a CSB.
CSB ID Crypto Session Bundle ID, unique identifier for the
CSB.
TGK TEK Generation Key, 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.
TEK Traffic-Encrypting Key, 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 [RFC4086]) string used
to protect against some off-line pre-computation
attacks on the underlying security protocol.
HDR the protocol header
PRF(k,x) a keyed pseudo-random function
E(k,m) encryption of m with the key k
RAND random value
T timestamp
CERTx the certificate of x
SIGNx the signature from x using the private key of x
PKx the public key of x
IDx the identity of x
[] an optional piece of information
{} zero or more occurrences
|| concatenation
| OR (selection operator)
^ exponentiation
XOR exclusive orNow for the bits that got added on top of [RFC3830] ✨
SSRC Synchronization Source Identifier
KEMAC MIKEY Key Data Transport Payload, containing a set of
encrypted sub-payloads and a Message Authentication
Code (MAC).
V MIKEY Verification Message
SP Security Parameter
Forking The ability of a SIP proxy to replicate an incoming
request to multiple outgoing requests in order to
efficiently find the called party for rendezvous. SIP
forking can be done in serial (depth-first search) or
in parallel (breadth-first search).
Redirect The ability of a SIP proxy to send a final response
that redirects the caller to send a request to an
alternate location.
Retarget The ability of a SIP proxy to re-write the Request-URI
thereby altering the destination of the request
without explicitly notifying the user agent client.3. MIKEY Overview 🦋
Okay, so this section gives you the overview of MIKEY 💜 MIKEY is all about setting up the cryptographic context needed to secure multimedia sessions in a heterogeneous environment. It's mainly meant for peer-to-peer setups, simple one-to-many setups, and small (interactive) groups. One of its big goals is to produce a data security association (SA) for the security protocol, including a Traffic-Encrypting Key (TEK) that's derived from a TEK Generation Key (TGK) and then used as input for the security protocol.
MIKEY can set up keys and parameters for more than one security protocol at the same time, or for several instances of the same security protocol. That's where the Crypto Session Bundle (CSB) comes in. A CSB is a collection of one or more Crypto Sessions that can share a common TGK and security parameters, but each one still gets its own distinct TEKs from MIKEY.
As defined in RFC 3830, MIKEY may take one roundtrip at most. It uses an Initiator message for the forward direction and a Responder message for the backward direction. Some MIKEY schemes can get the job done in a half roundtrip (for example, ones based on a pre-shared key), while others need a full roundtrip (for example, Diffie-Hellman-based schemes). The Initiator's message (I_MESSAGE) has one main job: it transports one or more TGKs (carried in the KEMAC field) and a set of security parameters (SPs) to the Responder, securely. The verification message from the Responder is optional for some schemes, so the Initiator indicates whether or not it needs one from the Responder 🌸
The next subsections focus on the key distribution methods, and talk through the advantages and disadvantages of each scheme.
Heads up on clocks! The MIKEY key distribution schemes rely on loosely synchronized clocks. If clock synchronization isn't available, the replay handling of MIKEY (cf. [RFC3830]) may not work. That's because MIKEY doesn't use a challenge-response mechanism for replay handling. Instead, it uses timestamps together with message caching. So the synchronization you need depends on how many messages can be cached on either side, and therefore MIKEY recommends adjusting the cache size depending on the clock skew in the deployment environment. RFC 3830 also recommends the ISO time synchronization protocol [ISO_sec_time]. If replay handling isn't available, an attacker may be able to replay an older message they eavesdropped earlier, which leads to different TGKs on both sides. Those TGKs get fed into the application using MIKEY (e.g., SRTP or TESLA), so both sides may end up relying on different keys and be unable to talk to each other 😭 The timestamps submitted in MIKEY have to match the NTP format described in [RFC1305]. In other cases, such as a SIP endpoint, clock synchronization by deriving time from a trusted outbound proxy may be appropriate.
The different MIKEY-related schemes get compared on these criteria:
- Mandatory for implementation: tells you whether RFC 3830 requires the implementation of this scheme.
- Scalability: describes how technically feasible it is to easily deploy a solution based on the scheme.
- Dependency on PKI: says whether support for a PKI is required to support this scheme. Note that PKI here refers to PKI services like key generation, distribution, and revocation.
- Provision of Perfect Forward Secrecy (PFS): describes whether PFS is supported. According to RFC 4949 [RFC4949], PFS is the property that compromising the long-term keying material does not compromise session keys that were previously derived from that long-term material.
- Key generation involvement: describes whether both participants or just one are actively involved in key generation. Involving both parties is considered here because it addresses a few points:
- If both sides contribute public entropy, each side can guarantee that keys are fresh, which helps avoid replay attacks.
- Involving both sides stops one side from generating weak (predictable) nonces, intentionally or unintentionally, which in turn can result in weak keys.
- Support of group keying: how feasible it is to use the MIKEY option for group keying too, e.g., in conferencing scenarios.
If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the SSRC to associate security policies with actual sessions. The SSRC identifies the synchronization source. Its value is chosen randomly, with the goal that no two synchronization sources within the same SRTP session end up with the same SSRC. The chance of multiple sources picking the same identifier is low, but all (S)RTP implementations must be prepared to detect and resolve collisions anyway. Still, in multimedia scenarios that support forking (see Section 5.2) or retargeting (see Section 5.3), collisions may happen and lead to so-called two-time pads, i.e., the same key gets used for media streams going to different destinations. This happens if two branches have the same TEK (based on the MIKEY key establishment) and pick the same 32-bit SSRC for their SRTP streams. The SRTP key derivation then produces the same session keys (since the input values are the same), and also derives the same initialization vector per packet, because the SSRCs are the same. Two-time pads can also happen for media streams going to the same destination. This is outlined in [RFC3711].
3.1. Pre-Shared Key (PSK) Protected Distribution 🔐
This option of the key management uses a pre-shared secret key to derive key material for integrity protection and encryption, which protects the actual exchange of key material. The pre-shared secret gets agreed upon before the session, e.g., by out-of-band means. The responder message is optional, and it may be used for mutual authentication (proof of possession of the pre-shared secret) or for error signaling.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], VThe upside here is that there's no dependency on a PKI (Public Key Infrastructure), the solution eats up low bandwidth and enables high performance, and all in all it's a simple, straightforward master key provisioning 💖 The downsides are that perfect forward secrecy is not provided, and key generation is only performed by the Initiator. On top of that, the approach doesn't scale to larger configurations, but it's acceptable in small-sized groups. Note that according to [RFC3830], this option is mandatory to implement.
3.2. Public Key Encrypted Key Distribution 🔐✨
okay bestie, so with the asymmetric option, the Initiator makes the key material (the TGKs) and sends it off wrapped up in a so-called envelope key 🎁. That envelope key is then locked with the receiver's public key 🔑. The envelope key, env-key, is just a random number, and it's used to derive the auth-key and the enc-key 💜. The envelope key can also be used as a pre-shared key to set up more crypto sessions later, which is lowkey iconic 🦋. The responder message is optional. It can be used for mutual authentication or for error signaling 🫶.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC, [CHASH],
PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], Vthe big perk here is that you can use self-signed certificates, and that means you can skip a full-blown PKI 🙌. but heads up, self-signed certs might not scale super well, and you'll probably need extra stuff for authentication, like comparing certificate fingerprints or something similar 🧐. the downsides are that you need a PKI for full scalability, only the Initiator does the key generation work, and there's no perfect forward secrecy 💀. also, the Responder's certificate has to be available on the sender's side ahead of time 📬. verifying certificates might not happen in real time either, which can be the case when a further component is checking revocation status 🙈. depending on the Initiator's role, this can also work for group-based communication, where a central server hands out the group key, protected with the public keys of the associated clients 👑. and according to [RFC3830], this option is mandatory to implement 🌸.
3.3. Diffie-Hellman Key Agreement Protected with Digital Signatures 💅
the Diffie-Hellman option lets the Initiator and Responder establish a shared secret where both of them chip in to it 🤝. the Diffie-Hellman key agreement gets authenticated (and integrity protected) with digital signatures, so it's giving trust 🔥.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, DHi, SIGNi --->
R_MESSAGE =
<--- HDR, T, [IDr|CERTr],
IDi, DHr, DHi, SIGNr[RFC3830] does mandate support for RSA as a specific asymmetric algorithm for signature generation ✨. on top of that, the algorithm used for signatures or public key encryption is defined by, and depends on, the certificate you're using. besides X.509v3 certificates, it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412] 🎀. other Diffie-Hellman groups can be used within MIKEY too! you do this by defining a new mapping sub-payload and the associated policy payload according to [RFC3830] 🧚. the perks are a fair, mutual key agreement (both parties provide to the key), perfect forward secrecy, and no need to fetch a certificate in advance like you do with the MIKEY-RSA method above 😭. it also gives you the option to use self-signed certificates so you can avoid a PKI deployment 🦋. just remember that depending on your security policy, self-signed certificates might not be suitable for every use case ⚠️.
ngl this one is not all sunshine. it scales mainly to point-to-point and depends on PKI for full scalability 💀. multiparty conferencing is not supported with just MIKEY-DHSIGN. however, the Diffie-Hellman secret that gets established can serve as a pre-shared key to bootstrap group-related security parameters 🌈. like the MIKEY-RSA mode, the verification of certificates may not necessarily happen in real time, which can be the case when a further component checks revocation status 🙈. and according to [RFC3830], this scheme is optional to implement 💜.
3.4. Unprotected Key Distribution 🙈
okay so [RFC3830] also has a mode that hands out a key without any protection, called MIKEY-NULL 😬. it's based on the symmetric key encryption option from Section 3.1, but it uses the NULL encryption and NULL authentication algorithms. you can compare it to the plain approach in SDP security descriptions [RFC4568] 🍓. MIKEY-NULL totally relies on the security of the underlying layer, for example, something like TLS 🔒. this option should be used with caution, because it does not protect the key management ⚠️.
since this method has zero cryptographic protection, it's obvious that perfect forward secrecy is not provided 💀. because it's based on the pre-shared secret mode, only the Initiator contributes to the key management 🫠. the method itself is highly scalable, but again, without proper protection from an underlying security layer, it is not advisable for use 🚫.
3.5. Diffie-Hellman Key Agreement Protected with Pre-Shared Secrets 🌸
this is an additional option, defined in [RFC4650] 💖. compared to the method in Section 3.3, here the Diffie-Hellman key agreement is authenticated (and integrity protected) using a pre-shared secret and a keyed hash function 🔐.
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],
IDr, {SP}, DHi, KEMAC --->
R_MESSAGE =
<--- HDR, T,[IDr], IDi,
DHr, DHi, KEMAC
TGK = g^(xi * yi) TGK = g^(xi * yi)for integrity protecting the Diffie-Hellman key agreement, [RFC4650] mandates the use of HMAC SHA-1 🧁. for Diffie-Hellman groups, [RFC3830] is referenced, so it is mandatory to support the Diffie-Hellman group "OAKLEY5" [RFC2412] 👑. other Diffie-Hellman groups can be used within MIKEY as well, by defining a new mapping sub-payload and the associated policy payload according to RFC 3830 ✨. this option has a bunch of perks too: a fair mutual key agreement, perfect forward secrecy, and no dependency on a PKI and PKI standards 🦋. it also has sound performance and reduced bandwidth requirements compared to MIKEY-DH-SIGN, and it gives you a simple, straightforward master key provisioning 🎀. the downside? establishing shared secrets and the lack of support for group keying 😭.
this mode is an efficient scheme in deployments where there's a central trusted server that's provisioned with shared secrets for many clients 🏢. examples include enterprise Private Branch Exchanges (PBXs), service provider proxies, etc. 📞. compared to the plain pre-shared key encryption-based mode from Section 3.1, this mode offers perfect forward secrecy as well as active involvement in the key generation from both parties involved 💜🔥.
3.6. SAML-Assisted DH key Agreement ✨
okay bestie, so there's been a loooong chat about this at IETF meetings and on the IETF MSEC mailing list 🫶 It's a SAML-assisted DH approach, and nobody has written it up as its own document. It's still worth talking about because it's aimed at the general requirements people have for key management approaches. Those requirements are:
- Mutual authentication of involved parties
- Both parties involved contribute to the session key generation
- Provide perfect forward secrecy
- Support distribution of group session keys
- Provide liveliness tests when involved parties do not have a reliable clock
- Support of limited parties involved
To hit all of these, the proposal uses a classic Diffie-Hellman key agreement for key establishment, plus a User Agent's (UA's) SIP server signed element 🔐 That element authenticates the Diffie-Hellman key and the ID using SAML (Security Assertion Markup Language [SAML_overview]). Basically, the server signs the client's public Diffie-Hellman credentials to make a SAML assertion (called CRED below), and that assertion can be reused for later sessions with other clients. It's giving reusable VIP pass 🎟️ The assertion needs to carry at least the ID, the public DH key, the expiry, and the signature from the server. This gives the clients mutual authentication and message integrity for the key management messages they swap.
Initiator Responder
I_MESSAGE =
HDR, T, RAND1, [CREDi],
IDr, {SP} --->
R_MESSAGE =
<--- HDR, T, [CREDr], IDi, DHr,
RAND2, (SP)
TGK = HMACx(RAND1|RAND2), where x = g^(xi * xr).The scheme also adds a second roundtrip 🔁 This one doesn't depend on synchronized clocks, and it gives liveliness checks. It works by swapping nonces that are protected with the session key. The second roundtrip can also be used to distribute group keys, or to use a weak DH key to get a stronger session key. The trigger for that second roundtrip is handled via SP, which is the security policy communicated through MIKEY.
Initiator Responder
I_MESSAGE =
HDR, SIGN(ENC(RAND3)) --->
R_MESSAGE =
<--- SIGN(ENC(RAND4))Note that if group keys are to be provided, RAND would be substituted by that group key.
With the second roundtrip, this approach also covers all the other key distribution methods when liveliness checks are needed, which is so cute 🌸 The catch is that these messages have to be woven into the signaling protocol's call flow. In a straightforward call, one roundtrip may be enough to set up a session, so this second roundtrip means extra messages have to go back and forth.
Looking at the criteria from the intro of this section, the wins are a fair, mutual key agreement (both parties contribute to the key) and perfect forward secrecy 💖 The second roundtrip lets you skip the dependency on synchronized clocks, and it allows group key distribution, which takes things from mostly point-to-point to multiparty conferencing. SAML-assisted DH can also cut the hidden latency cost of the credential validation that the signed DH scheme in Section 3.3 needs. If the UA got its SAML assertion from its domain's SIP server, it already trusts that server implicitly, so it can extend that trust to letting the server check the other party's SAML assertion. That kills the hidden validation latency and also the computational cost for the UA ⚡
Now the tea ☕ This proposal has one significant security risk, and it's a big one, so pay attention 😬 The UA's SIP server can cheat by creating an extra authentication object for the UA where the server holds the Diffie-Hellman private key. With that, the SIP server that issued the SAML assertion can successfully launch a Man-in-the-Middle (MITM) attack against two of its UAs. Two SIP servers can also collude, so either one can successfully launch a MITM attack against their UAs. A UA can block this attack if its Diffie-Hellman key is authenticated by a trustworthy third party and the whole object is signed by the SIP server. There's also the bandwidth and setup-time problem: this approach uses two roundtrips, which increases the bandwidth needed and the setup time, and that may be crucial in many scenarios. Finally, credential generation usually needs a separate component (server), so serverless call setup is not supported 🙅♀️
3.7. Asymmetric Key Distribution with In-Band Certificate Exchange 🎀
This is an additional option defined in [RFC4738] 📜 It describes asymmetric key distribution with optional in-band certificate exchange.
Initiator Responder
I_MESSAGE =
HDR, T, [IDi|CERTi], [IDr],
{SP}, [RAND], SIGNi --->
R_MESSAGE =
<--- HDR, [GenExt(CSB-ID)], T,
RAND, [IDr|CERTr], [SP],
KEMAC, SIGNrThis option has some perks compared to the asymmetric key distribution in Section 3.2 🦋 The sender and receiver don't need to know each other's certificate ahead of time, because the certificate can be sent in the MIKEY Initiator message. (If the receiver already knows the certificate in advance, RFC 3830's MIKEY-RSA mode may be used instead.) So the receiver can use the key material it got to encrypt the session parameters and send them back in the MIKEY responder message. Checking the certificate depends on the signing authority. If it's signed by a publicly accepted authority, validation is pretty straightforward, using the commonly known certificate authority's public key. Otherwise, extra steps may be necessary. The downside is that no perfect forward secrecy is provided 😢
This mode is meant to be an easy option for certificate provisioning when PKI is present and/or required. In SIP especially, session invitations can get retargeted or forked 🔀 MIKEY modes that make the Initiator target a single well-known Responder may be impractical here, because they can need multiple roundtrips to negotiate keys. By letting the Responder generate the secret material used for key derivation, this mode delivers keys efficiently ✨ Note that the Initiator can still contribute to the key material, since the key is derived from the CSB-ID and RAND payloads in unicast use cases. This mode is also useful for multicast scenarios where lots of clients contact a known server to download the key. The Responder's workload drops a lot in those scenarios compared to MIKEY in public key mode. That's because RSA encryption takes less effort than decryption with the private key (the public key is usually shorter than the private key, so encryption costs less performance than decryption). Examples of deployments where this mode can be used are enterprises with PKI, and service provider setups where the provider decides to provision certificates to its users, among others 🏢
4. Further MIKEY Extensions ✨
This section gives an overview of further MIKEY [RFC3830] extensions. They cover crypto algorithms and generic payload enhancements, plus enhancements that support negotiating security parameters for security protocols other than SRTP. These extensions have been defined in several additional documents 📚
4.1. ECC Algorithms Support 🌈
[MSEC-MIKEY] proposes extensions to the authentication, encryption, and digital signature methods described for use in MIKEY, using elliptic curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards.
The motivation for supporting ECC within MIKEY comes from these advantages:
- ECC modes are more and more added to security protocols.
- ECC support requires considerably smaller keys while keeping the same security level compared to other asymmetric techniques (like RSA). Elliptic curve algorithms can provide security consistent with Advanced Encryption Standard (AES) keys of 128, 192, and 256 bits without extensive growth in asymmetric key sizes 💅
- As stated in [MSEC-MIKEY], implementations have shown that elliptic curve algorithms can significantly improve performance and security-per-bit over other recommended algorithms.
These advantages make ECC especially interesting for embedded devices, which may have only limited performance and storage capabilities 🔋
[MSEC-MIKEY] proposes several ECC-based mechanisms to enhance the MIKEY key distribution schemes:
- Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDSA or ECGDSA
- Use of ECC methods extending the Diffie-Hellman key exchange: MIKEY-DHSIGN with ECDH
- Use of Elliptic Curve Integrated Encryption Scheme (MIKEY-ECIES)
- Use of Elliptic Curve Menezes-Qu-Vanstone Scheme(MIKEY-ECMQV)
The following subsections give more detail on the message exchanges for MIKEY-ECIES and MIKEY-ECMQV 🧚
4.1.1. Elliptic Curve Integrated Encryption Scheme application in MIKEY
The following figure shows the message exchange for the MIKEY-ECIES scheme:
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP}, KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V4.1.2. Elliptic Curve Menezes-Qu-Vanstone Scheme Application in MIKEY
The following figure shows the message exchange for the MIKEY-ECMQV scheme:
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], {SP},
ECCPTi, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V4.2. New MIKEY Payload for Bootstrapping TESLA 🦋
okay bestie, so TESLA [RFC4082] is a protocol for source authentication in multicast scenarios, and it's SO efficient 💖 It has low communication and computation overhead, it scales to huge numbers of receivers, and it tolerates packet loss, which is iconic. It's based on loose time synchronization between the sender and the receivers, and source authentication comes from MAC chaining (Message Authentication Code, for the record 🤓). The use of TESLA within SRTP was published in [RFC4383] to target multicast authentication where SRTP is protecting the multimedia data. That solution assumes the TESLA parameters are handed over by out-of-band mechanisms, so you have to get them somewhere else first ✨
[RFC4442] specifies payloads for MIKEY so it can bootstrap TESLA for source authentication of secure group communications using SRTP 🫶 TESLA can be bootstrapped with one of the MIKEY key management approaches we already covered, by sending the MIKEY message via unicast, multicast, or broadcast. This gives you the parameter payload extensions needed to use TESLA in SRTP. And if that parameter set also works for other TESLA use cases, you can use it there too, no cap 🌸
4.3. MBMS Extensions to the Key ID Information Type 🎀
this extension defines a new Type (the Key ID Information Type) for the General Extension Payload 💅 It's used in things like the Multimedia Broadcast/Multicast Service (MBMS), which is specified in the 3rd Generation Partnership Project (3GPP). MBMS needs MIKEY to convey the keys and related security parameters that secure the multimedia being multicast or broadcast, so MIKEY is literally load-bearing here 😭
okay so one of MBMS's security requirements is being able to do frequent key updates. The reason is that it's costly for subscribers to re-distribute decryption keys to non-subscribers. The cost of re-distributing keys over the unicast channel has to be higher than the cost of buying the keys, or the scheme doesn't work 💀 To handle this, MBMS uses a three-level key management setup. It distributes group keys to the clients and can re-key by pushing down a new group key. MBMS also needs to identify which types of keys are involved in a MIKEY message, and who they belong to 🔥
[RFC4563] specifies a new Type for the General Extension Payload in MIKEY, so you can identify the type and identity of the keys involved 🧚 And since MBMS uses MIKEY as both a registration protocol and a re-key protocol, this RFC adds the extra bits that let MIKEY work as both a unicast and a multicast re-key protocol in the MBMS setting. Main character energy ✨
4.4. OMA BCAST MIKEY General Extension Payload Specification 📻
the document [RFC4909] defines a new general extension payload type for the Open Mobile Alliance (OMA) Browser and Content Broadcast (BCAST) group 🌈 OMA BCAST's service and content protection spec uses short-term key message and long-term key message payloads, which in certain broadcast distribution systems get carried inside MIKEY. The general extension payload lets MIKEY be extended without defining a brand new payload every time 🙌 It can be used in any MIKEY message, and it's part of the authenticated or signed data part. Just note that it only includes a parameter description, not any key information 👑
4.5. Supporting Integrity Transform Carrying the Rollover Counter 🍓
the document [RFC4771] defines a new integrity transform for SRTP [RFC3711] that gives you the option to also send the Roll Over Counter (ROC) inside dedicated SRTP packets 😭 This was made for the 3GPP multicast/broadcast service. Here's the tea: the parties can agree on a starting ROC, but sometimes the receiver still can't sync its ROC with the sender's, even when it's signaled out of band. This extension gives the receiver a way to re-synchronize to the sender's ROC, and that's giving resilience 🫶
To signal the new integrity transform, certain MIKEY payloads need new definitions. That covers the integrity transform itself and a new integrity transform parameter. The document also adds an extra parameter so you can use different integrity transforms for SRTP and SRTCP 🔥
5. Selection and Interworking of MIKEY Modes 💜
okay so MIKEY and its extensions give you a whole buffet of modes 🍰 But an implementation is allowed to simplify its behavior, and it can do that by running a single mode when it's in the Initiator's role 💅 If PKI is available and/or required, an implementation could, for example, start every session in RSA-R mode, and then it's trivial for it to act as a Responder in public key mode. If envelope keys are cached, it can also do re-keying in shared key mode. Whether caching envelope keys is allowed is outside the scope of MIKEY and MIKEY extensions. It's a configuration thing for the components involved, and that local configuration is also outside MIKEY's scope 🙈
In general, the modes where the Initiator generates the keying material are useful when the two peers already know about each other before the MIKEY communication happens 🫶 If a peer doesn't want to operate in public key mode, it may reject the Initiator's certificate. The same goes for peers that only operate in one of the DH modes ✨
Forward MIKEY modes, where the Initiator provides the key material (like public key or shared key mode when used in SIP/SDP), can cause complications in some call scenarios. Forking is the big one, where key derivation material gets distributed to multiple parties 😭 As mentioned earlier, this can be impractical, because some of the destinations might not have the resources to validate the message, and that may make the Initiator drop the session invitation 💀 Even when every party has all the prerequisites to interpret the MIKEY message, there's a possible problem with multiple Responders starting media sessions using the same key. The SSRCs will be different most of the time, but they're only 32 bits long, so there's a high probability of a two-time pad problem 🔥 This comes up because of scenarios like forking (see also Section 5.2) or retargeting (see also Section 5.3). A two-time pad happens if two branches have the same TEK (based on the MIKEY key establishment) and choose the same 32-bit SSRC for their SRTP streams and transmit SRTP packets. As suggested earlier, forward modes are most useful when the two peers are aware of each other before communication starts, like in key renewal scenarios where costly public key operations can be avoided by using the envelope key 🌸
The following list shows how the different MIKEY modes may be used or combined, depending on which key material is available at the Initiator's side ✨
- If the Initiator has a PSK with the Responder, it uses the PSK mode.
- If the Initiator has a PSK with the Responder, but needs PFS or knows that the Responder has a policy that both parties should provide entropy to the key, then it uses the DH-HMAC mode.
- If the Initiator has the RSA key of the Responder, it uses the RSA mode to establish the TGK. Note that the TGK may be used as PSK together with Option 1 for further key management operations.
- If the Initiator does not expect the Responder to have its certificate, it may use RSA-R. Using RSA-R, it can provide the Initiator's certificate information in-band to the receiver. Moreover, the Initiator may also provide a random number that the receiver can use for key generation. Thus, both parties can be involved in the key management. But as the inclusion of the random number cannot be forced by the Initiator, true PFS cannot be provided. Note that in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
- The Initiator uses DH-SIGN when PFS is required by its policy and it knows that the Responder has a policy that both parties should provide entropy. Note that also in this mode, after establishing the TGK, it may be used as PSK with other MIKEY modes.
- If no PSK or certificate is available at the Initiator's side (and likewise at the Responder's side) but lower-level security (like TLS or IPsec) is in place, the user may use the unprotected mode of MIKEY. It has to considered that using the unprotected mode enables intermediate nodes like proxies to actually get the exchanged master key in plain. This may not be intended, especially in cases where the intermediate node is not trusted 🚨
Besides the available key material, choosing between the different MIKEY modes depends strongly on the use case 💅 This section will walk through dedicated scenarios to discuss how feasible the different modes are in each one. A comparison of the different modes of operation, covering the influences and requirements on the deploying infrastructure as well as the cryptographic strength, can be found in [SIP-MEDIA]. The following list covers the most prominent call scenarios, which are a matter of further discussion 🦋
- Early Media
- Forking
- Call Transfer/Redirect/Retarget
- Shared Key Conferencing
5.1. MIKEY and Early Media 📞
okay so "early media" is actually two different scenarios, bestie 🎀 The first one is when media data shows up before the SDP signaling answer has arrived. This can happen because the signaling path and the media path have different latency. People call this "media before signaling answer." The second one is when the callee sends media before the final SIP 200 OK message goes out. This usually happens in call center setups, like a waiting loop in the queue or custom ring tones 🎶
In early media situations, SRTP data can show up before the answer to the SIP signaling comes in. The two MIKEY modes that only need one message to be transported (Section 3.1 and Section 3.2) work nicely here, because both the sender and the receiver already have every parameter they need before they start sending or receiving encrypted data 💖 The other modes are a different story. The ones using Diffie-Hellman key agreement (Section 3.3, Section 3.5, and Section 3.6) or the enhanced asymmetric variant (Section 3.7) have a problem: the Initiator has to wait for the response before it can decrypt the incoming SRTP media 😭 Even when early media isn't used at all, meaning no media is sent before the SDP answer, a similar problem can still happen. SIP/SDP signaling has to hop through several proxies on its way back, so media can arrive before the SDP answer does. The delay is expected to be a lot shorter than in the early media case though ✨
It's worth noting that security descriptions [RFC4568] have basically the same problem, since the initiating end needs the SDP answer before it can start decrypting SRTP media 🙈
To deal with the early media problem, there are more approaches for describing security preconditions [RFC5027]. Basically, certain preconditions need to be met before voice data can be encrypted. One example is a scenario where a provisional response carrying the required MIKEY parameter gets sent before encrypted media is processed 🦋
5.2. MIKEY and Forking 🍴
In SIP forking scenarios, a SIP proxy server sends an INVITE request to more than one location. That also means the MIKEY payload, which is part of the SDP, gets sent to several different locations at once 😳 MIKEY modes that support signatures can be used in forking scenarios (Section 3.3 and Section 3.7), because the receiver can validate the signature. The symmetric key encryption modes and the asymmetric key encryption modes both have limitations here (Section 3.1 and Section 3.2). The reason is that with symmetric encryption, the recipient needs to already have the symmetric key before it can handle the MIKEY data. With asymmetric MIKEY modes, if the sender knows about the forking, it may not know in advance which location the INVITE gets forked to. That means it may not have the right receiver certificate to encrypt the MIKEY envelope key with 🥺 The sender can include several MIKEY containers in the same INVITE message to cope with forking. But that requires knowing all the forking targets ahead of time, and also having their certificates. It's out of the scope of MIKEY to specify behavior in a case like this. MIKEY Diffie-Hellman modes and MIKEY-RSA_R (Section 3.7) don't have this problem 💅 In scenarios where the sender isn't aware of forking, only the intended receiver can decrypt the MIKEY container 🔐
Things get even messier when forking is combined with early media 💀 If MIKEY modes that need a full roundtrip are used, like the signed Diffie-Hellman, multiple responses can overload the end device. Picture forking to 30 destinations (a group pickup, for example), with MIKEY running the signed Diffie-Hellman mode together with security preconditions. Every target would answer with a provisional response. That means 30 signature validations and 30 Diffie-Hellman calculations on the sender's side, which can lead to a prolonged media setup delay 🐢
On top of that, depending on the MIKEY mode chosen, a two-time pad can happen, based on the negotiated key material and the SSRC. For the non Diffie-Hellman modes other than RSA-R, a two-time pad can happen when multiple receivers pick the same SSRC 😱
5.3. MIKEY and Call Transfer/Redirect/Retarget 📲
In a SIP environment, the MIKEY exchange is tied to the SDP offer/answer. No matter which implementation model is used for call transfer, the same properties and limitations of MIKEY modes apply as in a normal call setup scenario ✨
Some SIP scenarios support redirect. In a redirect scenario, the call initiator gets a response saying that the called party has, for instance, temporarily moved and can be reached somewhere else. The caller can then set up the call with that new destination. Depending on the MIKEY mode originally chosen, though, the caller might not be able to use that same mode with the new destination 🙃 To be more precise, MIKEY-PSK and MIKEY-DHHMAC need a pre-shared secret in advance. MIKEY-RSA needs to know the target's certificate. So these modes can affect whether the caller is able to start a session at all 🥲
Retargeting is another thing SIP can support. Unlike redirect, the call initiator doesn't get any response about the different target. Instead, the SIP proxy sends the request to a different target after it gets a redirect response from the originally called target. This will most likely cause problems with MIKEY modes that need a pre-shared key (MIKEY-PSK, MIKEY-DHHMAC), or where the caller used asymmetric key encryption (MIKEY-RSA). The reason is that the key management was originally aimed at a different destination 🚫
5.4. MIKEY and Shared Key Conferencing 🎙️
First things first, not every MIKEY mode supports shared key conferencing. The Diffie-Hellman modes mostly can't be used straightforwardly for conferencing, because that mechanism results in a pairwise shared secret key 🙅♀️ All the other modes can be used in conferencing scenarios as long as they respect the Initiator and Responder roles. In other words, the half roundtrip modes have to be started by the conferencing unit so it can distribute the conferencing key. The remaining full roundtrip mode, MIKEY RSA-R, is started by the client, while the conferencing unit provides the conferencing key based on the certificate it received 👑
An example conferencing architecture is defined in the IETF's XCON WG. The scope of that working group covers a mechanism for membership and authorization control, a mechanism to manipulate and describe media "mixing" or "topology" for multiple media types (audio, video, text), a mechanism for notifying people about conference-related events and changes (for example, a floor change), and a basic floor control protocol. A document describing possible use case scenarios is available in [RFC4597] 🌸
5.5. MIKEY Mode Summary 📊
The following two tables sum up the discussion from the previous subsections. The first table matches the scenarios discussed in this section to the different MIKEY modes 🧚
MIKEY Early Secure Retarget Redirect Shared
mode Media Forking Key Conf
---------------------------------------------------------------------
PSK (3.1) Yes Yes*
RSA (3.2) Yes Yes*
DH-SIGN (3.3) Yes* Yes Yes
Unprotected (3.4) Yes
DH-HMAC (3.5)
RSA-R (3.7) Yes Yes Yes Yes
* In centralized conferencing, the media mixer needs to send the
MIKEY Initiator message.The following table maps the MIKEY modes to key management-related properties 🔑
MIKEY Manual Needs PFS Key Generation
mode Keys PKI Involvement
--------------------------------------------------------------
PSK (3.1) Yes No No Initiator
RSA (3.2) No Yes No Initiator
DH-SIGN (3.3) No Yes Yes Both
Unprotected (3.4) No No No Initiator
DH-HMAC (3.5) Yes No Yes Both
RSA-R (3.7) No Yes No Both*
* Assumed the Initiator provides the (optional) RAND value6. Transport of MIKEY Messages 🚚
MIKEY defines message formats for transporting key information and security policies between communicating entities 💌 It doesn't define how these messages get embedded into the signaling protocol being used. That's covered in separate documents, depending on which signaling protocol is in play. Still, MIKEY can also be transported over plain UDP or TCP to port 2269 🫶
Several IETF-defined protocols use the Session Description Protocol (SDP, [RFC4566]) to carry session parameters. Examples are the Session Initiation Protocol (SIP, [RFC3261] or the Gateway Control Protocol (GCP, [RFC5125]). Transporting MIKEY messages as part of SDP is described in [RFC4567]. Here, the complete MIKEY message is base64 encoded and sent as part of the SDP portion of the signaling protocol message. Note that since several key distribution messages can be carried inside one SDP container, [RFC4567] also includes integrity protection covering all the supplied key distribution attempts. So bidding-down attacks will be recognized 🕵️♀️ For RTSP, [RFC4567] defines header extensions that allow MIKEY messages to be transported. In that case, the initial messages use SDP, while the rest of the key management happens through those header extensions 🎬
MIKEY is also used in ITU-T protocols like H.323, which sets up communication sessions much like SIP does. H.323 has a security framework defined in H.235. Within that framework, H.235.7 [H.235.7] describes how MIKEY and SRTP are used in the context of H.323 🌈 The difference from SIP is that H.323 uses ASN.1 (Abstract Syntax Notation), so there's no need to base64 encode the MIKEY container. In H.323, the MIKEY container is binary encoded 🤓
7. MIKEY Alternatives for SRTP Security Parameter Negotiation ✨
Okay bestie, MIKEY isn't the only way to sort out security parameter establishment 💅. Some limitations showed up in certain scenarios, like the early media and forking situations we covered in Section 5, so other people built their own options. Here's the tea on each one 🍓
- sdescription 📝: [RFC4568] describes a key management scheme that uses SDP for transport and completely relies on the security of the underlying protocol. For transport, it defines an SDP attribute that sends all the necessary SRTP parameters in the clear. For security, it references TLS and S/MIME. Unlike MIKEY, the SRTP parameters for the Initiator-to-Responder direction are actually sent in the message going from the Initiator to the Responder, not the other way around. This may cause problems in early media scenarios 🙈
- sdescription with early media support 🎀: [WING-MMUSIC] upgrades the scheme above so it can also work in early media scenarios when security preconditions are not used ✨
- Encrypted Key Transport for Secure RTP 🔐: [MCGREW-SRTP] is an extension to SRTP that securely transports SRTP master keys, Rollover Counters, and other information inside SRTCP. It helps SRTP work for decentralized conferences with minimal control, and it can handle situations caused by SIP forking and early media. It may also be used together with MIKEY 🫶
- Diffie-Hellman support in SDP 🦋: [BAUGHER] defines a new SDP attribute for exchanging Diffie-Hellman public keys. It's a session-level attribute for describing DH keys, and there's a new media-level parameter for describing public keying material used to generate SRTP keys 💜
- DTLS-SRTP 🌈: [AVT-DTLS] describes SRTP extensions for DTLS. It's a method of using DTLS key management for SRTP through a new extension that says SRTP is to be used for data protection, and that also sets up the SRTP keys 🧚
- ZRTP ⭐: [ZIMMERMANN] defines ZRTP as RTP header extensions for a Diffie-Hellman exchange that agrees on a session key and the parameters for setting up SRTP sessions. ZRTP is completely self-contained in RTP, so it doesn't need support in the signaling protocol and doesn't assume a PKI 👑
There's been a long discussion in the IETF about which key management approach is the preferred one, since different scenarios and requirements keep coming up and people are still sorting out their options 😭 At IETF 68, three options were on the table: MIKEY in an updated version (called MIKEYv2), ZRTP, and DTLS-SRTP. The potential key management protocol for the standards track for media security was voted in favor of DTLS-SRTP 🔥 So, for more info on DTLS-SRTP, go check out [AVT-DTLS]. One more thing: MIKEY has already been deployed for setting up SRTP security contexts, and it's also targeted for use in MBMS applications 💖
8. Summary of MIKEY-Related IANA Registrations 🧾
For MIKEY and its extensions, IANA registrations have been made. Instead of copying them here (which could lead to inconsistencies, obviously 🙄), this document just links you to the right registration. The IANA registrations for MIKEY payloads are at http://www.iana.org/assignments/mikey-payloads. They cover the MIKEY base registrations as well as the payload registrations made by MIKEY extensions 🌸
The IANA registrations for MIKEY port numbers are at http://www.iana.org/assignments/port-numbers (search for MIKEY) 🦋
9. Security Considerations 🚨
Okay, this part is serious, so listen up 👀 This document does not define extensions to existing protocols. Instead, it gives an overview of the set of MIKEY modes and available extensions, and it explains where the different modes fit, so network architects can make a decision about which MIKEY scheme or extension to use for a specific target scenario 💅 Choosing between the schemes described here strongly influences the security of the target system, because the schemes offer different levels of security and also need different infrastructure support. Choose wisely, bestie 😭
Since this document is based on the MIKEY base specification and the different specifications for the extensions, the reader is referred to those original documents for the specific security considerations 🫶
10. Acknowledgments 💜
The authors would like to thank Lakshminath Dondeti for his document reviews and for his guidance. Iconic of him 👑
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
and K. Norrman, "MIKEY: Multimedia Internet KEYing",
RFC 3830, August 2004.11.2. Informative References
[AVT-DTLS] McGrew, D. and E. Rescorla, "Datagram Transport
Layer Security (DTLS) Extension to Establish Keys
for Secure Real-time Transport Protocol (SRTP)",
Work in Progress, February 2008.
[BAUGHER] Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges
for Multimedia Sessions", Work in Progress,
February 2006.
[H.235.7] ""ITU-T Recommendation H.235.7: Usage of the MIKEY
Key Management Protocol for the Secure Real Time
Transport Protocol (SRTP) within H.235"", 2005.
[ISO_sec_time] ""ISO/IEC 18014 Information technology - Security
techniques - Time-stamping services, Part 1-
3.http://www.oasis-open.org/committees/
documents.php?wg_abbrev=security"", 2002.
[MCGREW-SRTP] McGrew, D., "Encrypted Key Transport for Secure
RTP", Work in Progress, March 2007.
[MSEC-MIKEY] Milne, A., "ECC Algorithms for MIKEY", Work in
Progress, June 2007.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305,
March 1992.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
and K. Norrman, "The Secure Real-time Transport
Protocol (SRTP)", RFC 3711, March 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source
Authentication Transform Introduction", RFC 4082,
June 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed
Efficient Stream Loss-Tolerant Authentication
(TESLA) in the Secure Real-time Transport Protocol
(SRTP)", RFC 4383, February 2006.
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed
Efficient Stream Loss-Tolerant Authentication (TESLA)",
RFC 4442, March 2006.
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The
Key ID Information Type for the General Extension
Payload in Multimedia Internet KEYing (MIKEY)",
RFC 4563, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K.,
and E. Carrara, "Key Management Extensions for
Session Description Protocol (SDP) and Real Time
Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for
Media Streams", RFC 4568, July 2006.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
RFC 4597, August 2006.
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for
Multimedia Internet KEYing (MIKEY)", RFC 4650,
September 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin,
"MIKEY-RSA-R: An Additional Mode of Key Distribution
in Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006.
[RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman,
"Integrity Transform Carrying Roll-Over Counter for
the Secure Real-time Transport Protocol (SRTP)",
RFC 4771, January 2007.
[RFC4909] Dondeti, L., Castleford, D., and F. Hartung,
"Multimedia Internet KEYing (MIKEY) General
Extension Payload for Open Mobile Alliance BCAST
LTKM/STKM Transport", RFC 4909, June 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5027] Andreasen, F. and D. Wing, "Security Preconditions
for Session Description Protocol (SDP) Media
Streams", RFC 5027, October 2007.
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to
Historic", RFC 5125, February 2008.
[SAML_overview] Huges, J. and E. Maler, "Security Assertion Markup
Language (SAML) 2.0 Technical Overview, Working
Draft", 2005.
[SIP-MEDIA] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security
Management Protocols", Work in Progress, June 2008.
[WING-MMUSIC] Raymond, R. and D. Wing, "Security Descriptions
Extension for Early Media", Work in Progress,
October 2005.
[ZIMMERMANN] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP:
Media Path Key Agreement for Secure RTP", Work in
Progress, June 2008.Authors' Addresses 🖋️
Steffen Fries
Siemens Corporate Technology
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: steffen.fries@siemens.com
Dragan Ignjatic
Polycom
3605 Gilmore Way
Burnaby, BC V5G 4X5
Canada
EMail: dignjatic@polycom.comFull Copyright Statement 💖
okay so, the IETF Trust owns the copyright here, and it's the year 2008 💅 this document is subject to the rights, licenses and restrictions in BCP 78. except where BCP 78 says otherwise, the authors keep all their rights 🎀
this document and everything in it is provided "AS IS" 🫶 and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. that includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 😭 not gonna lie, that's a lot of legal energy, but it's the vibe 💀
Intellectual Property ✨
the IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this doc are valid or how far they reach, and it doesn't say whether a license for them is available 🦋 it also doesn't claim it went hunting for those rights itself. if you want the rules on rights for RFC documents, check BCP 78 and BCP 79 📚
if you want copies of IPR disclosures sent to the IETF Secretariat, or the assurances of licenses that come with them, or the results of anyone trying to get a general license or permission for implementers or users of this spec, you can find them in the IETF online IPR repository at http://www.ietf.org/ipr 🌸
and the IETF is totally inviting you 🧚 if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, bring it to their attention. send it to ietf-ipr@ietf.org 💜
📦 where this page comes from
- ietf: rfc5197 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms