RFC 5479
Requirements and Analysis of Media Security Management Protocols
RFC 5479: Requirements and Analysis of Media Security Management Protocols 🎀
okay so this is RFC 5479 and the title block is giving main character energy 💖 It's Informational, which means it's here to inform the Internet community 🫶 It was published in April 2009 by the Network Working Group. D. Wing, Ed. from Cisco is the editor, and S. Fries (Siemens AG), H. Tschofenig (Nokia Siemens Networks), and F. Audet (Nortel) co-wrote it with them. The title block doesn't list anything it obsoletes or updates, so no drama there ✨
Status of This Memo 📝
bestie, this memo is here to inform the Internet community. It is not specifying an Internet standard of any kind 🙈 Distribution of this memo is unlimited, so share it with whoever you want 💅
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they explain your rights and restrictions with respect to this document. Read the fine print, babe 🧚
Abstract 🌸
okay so the whole point of this doc is to lay out the requirements for a protocol that negotiates a security context for SIP-signaled Secure RTP (SRTP) media 🔐 Beyond the usual security needs, this negotiation protocol has to play nicely with SIP in certain ways, which is lowkey the tricky part 😭 A bunch of proposals have already been published, and a summary of them lives in the appendix of this document 📚
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4. Call Scenarios and Requirements Considerations . . . . . . . . 7
4.1. Clipping Media before Signaling Answer . . . . . . . . . . 7
4.2. Retargeting and Forking . . . . . . . . . . . . . . . . . 8
4.3. Recording . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Call Setup Performance . . . . . . . . . . . . . . . . . . 12
4.6. Transcoding . . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Upgrading to SRTP . . . . . . . . . . . . . . . . . . . . 13
4.8. Interworking with Other Signaling Protocols . . . . . . . 14
4.9. Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Management Protocol Requirements . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
5.3. Requirements outside of the Key Management Protocol . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview and Evaluation of Existing Keying
Mechanisms . . . . . . . . . . . . . . . . . . . . . 24
A.1. Signaling Path Keying Techniques . . . . . . . . . . . . . 25
A.1.1. MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
A.1.2. MIKEY-PSK . . . . . . . . . . . . . . . . . . . . . . 25
A.1.3. MIKEY-RSA . . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. MIKEY-RSA-R . . . . . . . . . . . . . . . . . . . . . 25
A.1.5. MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
A.1.6. MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC) . . . . . . . 26
A.1.8. SDP Security Descriptions with SIPS . . . . . . . . . 26
A.1.9. SDP Security Descriptions with S/MIME . . . . . . . . 27
A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
A.2. Media Path Keying Technique . . . . . . . . . . . . . . . 27
A.2.1. ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.3. Signaling and Media Path Keying Techniques . . . . . . . . 28
A.3.1. EKT . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . 28
A.3.3. MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
A.4. Evaluation Criteria - SIP . . . . . . . . . . . . . . . . 29
A.4.1. Secure Retargeting and Secure Forking . . . . . . . . 29
A.4.2. Clipping Media before SDP Answer . . . . . . . . . . . 31
A.4.3. SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 35
A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 35
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 39
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 42
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 421. Introduction ✨
okay so media security started way back when the Session Initiation Protocol (SIP) was still in its infancy 🍼 As SIP got deployed more and more, and new SIP extensions and related protocols showed up, people had to re-evaluate the need for end-to-end security 🔐 Re-checking earlier protocol work and design decisions is totally normal, and honestly it's kind of necessary so the protocols still meet what Internet users need 💅
This document sums up the media security requirements, which means the requirements for mechanisms that negotiate a security context, like cryptographic keys and parameters for SRTP 🦋
Here's the vibe of the rest of the doc 🗺️ Section 2 covers terminology, Section 3 walks through attack scenarios against the signaling path and the media path 😈, Section 4 gives an overview of possible call scenarios 📞, and Section 5 lists the requirements for media security 📋. The main part wraps up with the security considerations in Section 6 and the acknowledgements in Section 7 🫶 Appendix A lists and compares the available solution proposals 🧩. Appendix A.4 then compares the approaches for how well they suit the SIP signaling scenarios described in Appendix A, and Appendix A.5 compares their security aspects 🔥. Appendix B lists the non-goals for this document 🙅♀️
2. Terminology 💅
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are the BCP 14 key words in this document, and they're to be read as described in [RFC2119]. There's one important catch though 👀 Unless it says otherwise, these terms apply to the design of the media security key management protocol, not to its implementation or application ✨
Also, the terminology from SIP [RFC3261] about functions and components gets used all over this doc, so keep it in mind 🧚
Here's the extra vocab we're using:
- AOR (Address-of-Record): A SIP or SIPS URI that points to a domain with a location service. That service can map the URI to another URI where the user might be available 📍 The location service usually gets filled in through registrations. An AOR is often thought of as the "public address" of the user 💌
- SSRC: The 32-bit value that defines the synchronization source, used in RTP 🎵 These are generally unique, but collisions can happen 🙈
- two-time pad: Using the same key and the same keystream to encrypt different data 😱 For SRTP, a two-time pad happens if two senders use the same key and the same RTP SSRC value 💀
- Perfect Forward Secrecy (PFS): The property where disclosing the long-term secret keying material that's used to derive an agreed ephemeral key does not compromise the secrecy of agreed keys from earlier runs 🔒 Iconic behavior 👑
- active adversary: An active adversary can alter data communication to affect its operation (see also [RFC4949]) 😈
- passive adversary: A passive adversary can learn information from data communication, but can't alter that data communication (see also [RFC4949]) 👀
- signaling path: The route taken by SIP signaling messages sent between the calling and called user agents 📡 That can be direct signaling between the two user agents or, more commonly, it goes through the SIP proxy servers that were involved in call setup 🔁
- media path: The route taken by media packets that the endpoints exchange 🎶 In the simplest case the endpoints swap media directly, and the "media path" is defined by a quartet of IP addresses and TCP/UDP ports, along with an IP route 🛣️ In other cases this path can include RTP relays, mixers, transcoders, session border controllers, NATs, or media gateways 🌈
Last thing, bestie 🫶 Because this document is about media security requirements, the nomenclature R-XXX marks requirements, where XXX is the requirement which needs to be met 🎀
3. Attack Scenarios ✨
okay bestie, this section is where we talk about who's trying to snoop on the call 🕵️♀️ It relates to requirements R-ASSOC (specified in Section 5.1) R-PASS-MEDIA, R-PASS-SIG, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING (specified in Section 5.2).
This document sorts adversaries by their access and their capabilities 💅 An adversary might have access:
- only to the media path,
- only to the signaling path,
- to the media path and to the signaling path.
An attacker who can only be on the signaling path, and has no access to media (item 2), is not considered in this document 🙈
There are two kinds of adversaries: active and passive 🦋 An active adversary may need to be active with regard to the key exchange relevant information traveling along the media path or traveling along the signaling path.
Based on how well they hold up against the adversary capabilities above, we can group security mechanisms using the labels below. This list is generally ordered from easiest to compromise (at the top) to more difficult to compromise ✨
+---------------+---------+--------------------------------------+
| SIP signaling | media | abbreviation |
+---------------+---------+--------------------------------------+
| none | passive | no-signaling-passive-media |
| none | active | no-signaling-active-media |
| passive | passive | passive-signaling-passive-media |
| passive | active | passive-signaling-active-media |
| active | passive | active-signaling-passive-media |
| active | active | active-signaling-active-media |
| active | active | active-signaling-active-media-detect |
+---------------+---------+--------------------------------------+no-signaling-passive-media: Access only to the media path is sufficient to reveal the content of the media traffic.passive-signaling-passive-media: Passive attack on the signaling and passive attack on the media path is necessary to reveal the content of the media traffic.passive-signaling-active-media: Passive attack on the signaling and active attack on the media path is necessary to reveal the content of the media traffic.active-signaling-passive-media: Active attack on the signaling path and passive attack on the media path is necessary to reveal the content of the media traffic.no-signaling-active-media: Active attack on the media path is sufficient to reveal the content of the media traffic.active-signaling-active-media: Active attack on both the signaling path and the media path is necessary to reveal the content of the media traffic.active-signaling-active-media-detect: Active attack on both signaling and media path is necessary to reveal the content of the media traffic (as withactive-signaling-active-media), and the attack is detectable by protocol messages exchanged between the endpoints 🔥
For example, unencrypted RTP is vulnerable to no-signaling-passive-media 💀
As another example, SDP Security Descriptions [RFC4568], when protected by TLS (as it's commonly implemented and deployed), belong in the passive-signaling-passive-media category, since the adversary needs to learn the SDP Security Descriptions key by seeing the SIP signaling message at a SIP proxy (assuming that the adversary is in control of the SIP proxy). The media traffic can then be decrypted using that learned key 🔑
As another example, DTLS-SRTP (Datagram Transport Layer Security Extension for SRTP) falls into the active-signaling-active-media category when DTLS-SRTP is used with a public-key-based ciphersuite with self-signed certificates and without SIP Identity [RFC4474]. An adversary would have to modify the fingerprint that is sent along the signaling path and then modify the certificates carried in the DTLS handshake that travel along the media path 😭 If DTLS-SRTP is used with both SIP Identity [RFC4474] and SIP Connected Identity [RFC4916], the RFC-4474 signature protects both the offer and the answer, and such a system would then belong to the active-signaling-active-media-detect category (provided, of course, that the signaling path to the RFC-4474 authenticator and verifier is secured as per RFC 4474, and the RFC-4474 authenticator and verifier are behaving as per RFC 4474) 👑
The DTLS-SRTP discussion above shows how a single security protocol can land in different classes depending on the mode it's operated in 🌈 Other protocols can get a similar effect by adding functions outside of the on-the-wire key management protocol itself. Although it may be appropriate to deploy lower-classed mechanisms in some cases, the ultimate security requirement for a media security negotiation protocol is that it have a mode of operation available in which is detect-attack, which provides protection against the passive and active attacks and provides detection of such attacks. That is, there must be a way to use the protocol so that an active attack is required against both the signaling and media paths, and so that such attacks are detectable by the endpoints 🫶
4. Call Scenarios and Requirements Considerations ✨
The following subsections describe the call scenarios that pose the most challenge to the key management system for media data in cooperation with SIP signaling 🎀
Throughout the subsections, requirements are stated using the nomenclature R- to state an explicit requirement. All of the stated requirements are explained in detail in Section 5. They're listed according to their association to the key management protocol, to attack scenarios, and to requirements that can be met inside the key management protocol or outside of it 💖
4.1. Clipping Media before Signaling Answer 🧚
The discussion in this section relates to requirements R-AVOID-CLIPPING and R-ALLOW-RTP.
Per the Session Description Protocol (SDP) Offer/Answer Model [RFC3264]:
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information).
To meet this requirement with SRTP, the offerer needs to know the SRTP key for arriving media. If either endpoint receives encrypted media before it has access to the associated SRTP key, it can't play the media, and that causes clipping 😭
For key exchange mechanisms that send the answerer's key in SDP, a SIP provisional response [RFC3261], such as 183 (session progress), is useful. However, 183 messages aren't reliable unless both the calling and called endpoint support Provisional Response ACKnowledgement (PRACK) [RFC3262], use TCP across all SIP proxies, implement Security Preconditions [RFC5027], or both ends implement Interactive Connectivity Establishment [ICE] and the answerer implements the reliable provisional response mechanism described in ICE. Unfortunately, none of these techniques is widely deployed, and there's industry reluctance to require them to avoid the problems described in this section 🙃
Note that receiving an SDP answer isn't always enough to let media play for the offerer. Sometimes the offerer must send media to open up firewall holes or NAT bindings before media can be received (for details, see [MIDDLEBOX]). In this case, even a solution that makes the key available before the SDP answer arrives won't help 🚧
Preventing the arrival of early media (i.e., media that arrives at the SDP offerer before the SDP answer arrives) might obsolete the R-AVOID-CLIPPING requirement, but at the time of writing, early media exists in many normal call scenarios 🌸
4.2. Retargeting and Forking ✨
okay so this bit is about requirements R-FORK-RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE 🎀
In SIP, a request sent to one specific AOR but delivered to a different AOR is called a "retarget" 💅 A super common example is "call forwarding." In Figure 1, Alice sends an INVITE in step 1, and it gets sent to Bob in step 2. Bob responds with a redirect (SIP response code 3xx) pointing to Carol in step 3. Usually that redirect doesn't go back to Alice. It only goes to a proxy (the retargeting proxy), and that proxy sends the original INVITE to Carol in step 4 🦋
+-----+
|Alice|
+--+--+
|
| INVITE (1)
V
+----+----+
| proxy |
++-+-----++
| ^ |
INVITE (2) | | | INVITE (4)
& redirect (3) | | |
V | V
++-++ ++----+
|Bob| |Carol|
+---+ +-----+
Figure 1: RetargetingOkay, so retargeting can lead to situations where the User Agent Client (UAC) has no idea where its request is actually going 😭 At first that might not seem like a big deal. Think about the PSTN: when you call someone, you never really know if it's getting forwarded, who's going to pick up, and so on. BUT, when you're trying to use SIP mechanisms to authenticate the called party, this can make it really hard to tell apart an intermediary who's behaving legit from an attacker 💀 So from this angle, the main problems with retargeting are:
Not detectable by the caller: The originating user agent has no way of anticipating that this will happen, and no way of figuring out that it has happened until the call is already set up 🙈
Not preventable by the caller: There's no existing mechanism the originating user agent can use to guarantee that the call won't get retargeted 🥺
The mechanism SIP uses for identifying the calling party is SIP Identity [RFC4474]. But because of retargeting, SIP Identity can only identify the calling party (the one who started the SIP request) ✨ Some key exchange mechanisms came before SIP Identity and have their own identity mechanisms built in (like Multimedia Internet KEYing (MIKEY)). Those built-in ones also run into the SIP retargeting problem, though 😤 Connected Identity [RFC4916] does let you positively identify the called party, but the big issue is still there: the calling party can't tell whether a mismatched called party is legitimate (authorized retargeting) or illegitimate (unauthorized retargeting by an attacker above to modify SIP signaling) 👀
In SIP, 'forking' means a request gets delivered to multiple locations. This happens when a single AOR is registered more than once. For example, a user might have a desk phone, a PC client, and a mobile handset all registered to the same AOR 📱
+-----+
|Alice|
+--+--+
|
| INVITE
V
+-----+-----+
| proxy |
++---------++
| |
INVITE | | INVITE
V V
+--+--+ +--+--+
|Bob-1| |Bob-2|
+-----+ +-----+
Figure 2: ForkingWith forking, both Bob-1 and Bob-2 might send back SDP answers in SIP responses 💜 Alice will see those intermediate (18x) and final (200) responses. It's really useful for Alice to be able to link the SIP response to the incoming media stream. You can do that with ICE [ICE], and ICE is useful for making this link with RTP, but it's not desirable to require ICE just to get this association 🌸
Forking and retargeting are often used together 🎀 For example, a boss and secretary might have both phones ring (forking), and then it rolls over to voice mail if nobody picks up (retargeting) 📞
To keep the media traffic secure, only the endpoint that answers the call should know the SRTP keys for the session 🔐 Forked and retargeted calls only leak sensitive info to non-responders when the signaling messages carry sensitive information (like SRTP keys) that's accessible to parties who receive the offer but may not respond. That means the original recipients in a retargeted call, or the non-answering endpoints in a forked call 😬 For key exchange mechanisms that don't provide secure forking or secure retargeting, one workaround is to rekey immediately after forking or retargeting. BUT, because the originator may not know the call forked, this mechanism needs to rekey immediately after every session is established, which doubles the number of messages the network has to process 💀
It gets worse 😩 SIP has a unique feature: when forking is used, there is always only one final error response delivered to the sender of the request. The forking proxy is responsible for choosing which final response to pass along when forking results in multiple final error responses being received by the forking proxy. So if a request gets rejected, say with information that the keying information was rejected and including the far end's credentials, it's very possible the rejection never reaches the sender 🫠 This problem is called the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326], and it's hard to solve in SIP. Since we expect HERFP to stick around in SIP for the foreseeable future, a media security system should keep working even when HERFP behavior is happening 👑
4.3. Recording 🎙️
The discussion in this section relates to requirement R-RECORDING 💖
Some business environments, like stock brokerages, banks, and catalog call centers, need to record calls with customers. This is the familiar "this call is being recorded for quality purposes" you hear when you call these kinds of businesses 🙄 In these environments, media recording is usually done by an intermediate device (with RTP, this is typically a 'sniffer') 🕵️♀️
When you do this kind of call recording with SRTP, the end-to-end security is compromised. This is unavoidable, but it's necessary because the business needs the recording to operate 😤 It's desirable that the media security isn't unduly compromised by the media recording. The endpoint inside the organization needs to be told that there's an intermediate device, and it needs to cooperate with that device 🫶
This scenario doesn't place a requirement directly on the key management protocol. The requirement could be met directly by the key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an external out-of-band mechanism (e.g., [SRTP-KEY]) ✨
4.4. PSTN Gateway 🌈
The discussion in this section relates to requirement R-PSTN 🧚
It's desirable, even when one leg of a call is on the PSTN, that the IP leg of the call be protected with SRTP 🔥
The typical case of using media security is two entities having a Voice over IP (VoIP) conversation over IP-capable networks. BUT, there are cases where the other end of the communication isn't connected to an IP-capable network. In that setup, there needs to be some kind of gateway at the edge of the IP network that converts the VoIP conversation into a format the other network understands 🍓 An example is a PSTN gateway sitting at the edge of the IP and PSTN networks (like the architecture described in [RFC3372]) 💅
If media security (e.g., SRTP protection) is used in this kind of gateway setup, then media security and its related key management get terminated at the PSTN gateway. The other network (e.g., the PSTN) might have its own ways of protecting the communication, but from the media security point of view, the media security isn't really end-to-end between the communicating entities 😭
4.5. Call Setup Performance ⏱️
The discussion in this section relates to requirement R-REUSE 🦋
Some devices don't have enough processing power to do public key operations or Diffie-Hellman operations for every call, or they'd rather avoid doing those operations on every call 🥺 Being able to reuse previous public key or Diffie-Hellman operations can massively cut down call setup delay and processing requirements for these devices ✨
On certain devices, a Diffie-Hellman operation can take a second or two 🐢 Examples include handsets, IP Multimedia Services Identity Modules (ISIMs), and PSTN gateways. PSTN gateways typically use a Digital Signal Processor (DSP) that isn't yet busy with typical DSP work at the start of a call, so the DSP could do the calculation instead of the central host processor 🧠 BUT, not all PSTN gateways use DSPs (some only have central processors, or their DSPs can't do the necessary public key or Diffie-Hellman operation), and handsets don't have a separate, unused processor for these operations 😩
Two scenarios where R-REUSE is useful are calls between an endpoint and its voicemail server, or between an endpoint and its PSTN gateway 📞 In those cases, calls happen pretty often, so it can be useful for the voicemail server or PSTN gateway to skip public key operations for later calls 💜
Storing keys across sessions often interferes with perfect forward secrecy (R-PFS) 🔐
4.6. Transcoding 🎧
The discussion in this section relates to requirement R-TRANSCODER 💖
In some environments, network equipment has to transcode from one codec (e.g., a highly compressed codec that uses wireless bandwidth efficiently) to another codec (e.g., a standardized codec for a SIP peering interface) 🔄 With RTP, a transcoding function can be done by combining a SIP back-to-back user agent (B2BUA) that modifies the SDP with a processor that does the transcoding between codecs. BUT, with end-to-end secured SRTP, a transcoding function implemented that same way is a man-in-the-middle attack, and the key management system prevents its use 🚫
That said, a network-based transcoder can still be made to work with the cooperation and approval of the endpoint, and it can provide end-to-end transcoder and transcoder-to-end security 🫶
4.7. Upgrading to SRTP 🎀
okay so this bit is about the requirement R-ALLOW-RTP 🦋 Legit RTP media can get sent to an endpoint for announcements, colorful ringback tones (like music), ads, or normal call progress tones. The RTP can show up before the associated SDP answer, which is kinda wild, but it happens. For the full scenarios, check out [EARLY-MEDIA] 💅
Ngl, receiving that early RTP means the calling party is exposed to a risk of getting malicious RTP from an attacker 💀 Still, SRTP endpoints will need to receive and play out RTP media anyway, so they can work with the deployed systems that send RTP to calling parties 🫶
4.8. Interworking with Other Signaling Protocols 🌸
this one is tied to R-OTHER-SIGNALING ✨ In lots of environments, some devices get signaled with protocols that aren't SIP and don't share SIP's offer/answer model (for example [H.248.1]), or they don't use SDP at all (like H.323) 🙈 In other environments, both endpoints are SIP, but they use different key management systems. Like, one uses MIKEY-RSA and the other uses MIKEY-RSA-R. Chaotic, right? 😭
In these setups, SRTP is the goal, not plain RTP 💖 It's always possible to interwork these mismatched signaling or key management systems by decrypting and re-encrypting each SRTP packet on a device in the middle of the network (usually the same box doing the signaling interworking). It's possible but really not ideal 🙅♀️ It costs a lot and widens the attack area, because a device like that becomes a super valuable attack target 👑
At the time of writing, interworking is considered important. Interworking without decrypting and re-encrypting the SRTP is useful too, but it isn't deemed critical yet, since SRTP deployments are still relatively small 🧚
4.9. Certificates 💜
this section relates to R-CERTS 🌈 On the Internet and on some private networks, checking another peer's certificate usually runs through a trust anchor, which is basically a list of trusted Certificate Authorities. Getting those certificates can be hard or expensive for a peer 😩 And both parties in the call would need to trust the same trust anchor (a.k.a. the "certificate authority"). So the media plane key management protocol needs a way for end-users with no prior association to authenticate each other, without grabbing credentials from some third-party trust point 🔥 Quick note: this doesn't rule out setups where servers have certificates and vouch for the identities of end-users ✨
5. Requirements ✨
this section is split into a few parts: requirements for the key management protocol itself (Section 5.1), attack scenarios (Section 5.2), and requirements that can be met inside or outside the key management protocol (Section 5.3) 🦋
5.1. Key Management Protocol Requirements 💅
here's the forking and retargeting stuff from Section 4.2 🍓
R-FORK-RETARGET: The media security key management protocol MUST securely support forking and retargeting when all endpoints are willing to use SRTP, and it must do this without making the call setup fail. This means endpoints that didn't answer the call MUST NOT learn the SRTP keys (in either direction) that the answering endpoint is using. Iconic behavior, no notes 👑
R-DISTINCT: The media security key management protocol MUST be capable of creating distinct, independent cryptographic contexts for each endpoint in a forked session. Every fork gets its own lane 🛣️
R-HERFP: The media security key management protocol MUST function securely even when HERFP behavior is happening. That means the rejection of key information never reaches the sender 🙃
Performance considerations 🌟
R-REUSE: The media security key management protocol MAY support reusing a previously established security context.
Note: reusing the security context does not mean reusing RTP parameters, like the payload type or SSRC. Not the same thing, bestie 💀
Media considerations 🎶
R-AVOID-CLIPPING: The media security key management protocol SHOULD avoid clipping media before the SDP answer, without requiring Security Preconditions [RFC5027]. This comes from Section 4.1 ✨
R-RTP-CHECK: If SRTP key negotiation happens over the media path (meaning it uses the same UDP/TCP ports as the media packets), the key negotiation packets MUST NOT pass the RTP validity check defined in Appendix A.1 of [RFC3550]. That way, SRTP negotiation packets can be told apart from RTP packets 🔍
R-ASSOC: The media security key management protocol SHOULD include a mechanism for associating key management messages with both the signaling traffic that started the session and the protected media traffic. This is super useful, because it lets the SDP offerer skip CPU-heavy operations (like Diffie-Hellman or public key operations) with attackers who never saw the signaling messages 🛡️
Picture this: you're using a Diffie-Hellman keying technique with security preconditions, and the call forks to 20 endpoints. The call initiator would get 20 provisional responses, each with a signed Diffie-Hellman key pair. Computing 20 Diffie-Hellman secrets and validating 20 signatures can be a seriously hard task for some devices 😵 So when forking happens, you don't want to do a Diffie-Hellman operation with everyone. You only want to do it with the party that actually answers the call, and yeah, that might cost some media clipping. To pull this off, the signaling and media have to be associated, so the calling party knows which key management exchange to finish. The transport address in the SDP might do this job, but NATs can mess that association up 🙈
Note: because of RTP's design requirements, SRTP receivers are expected to authenticate any SRTP packets they receive. Authenticate everything, periodt 🔐
R-NEGOTIATE: The media security key management protocol MUST allow a SIP User Agent to negotiate media security parameters for each individual session. That negotiation MUST NOT cause a two-time pad (Section 9.1 of [RFC3711]). Never reuse the pad, babe 🙅♀️
R-PSTN: The media security key management protocol MUST support termination of media security in a PSTN gateway. This one's from Section 4.4 🌉
5.2. Security Requirements 🔒
this section lays out the overall security requirements, plus the specific ones that come from the attack scenarios (Section 3) 🩷
Overall security requirements 💜
R-PFS: The media security key management protocol MUST be able to support perfect forward secrecy ✨
R-COMPUTE: The media security key management protocol MUST support offering additional SRTP cipher suites without incurring significant computational expense 🧮
R-CERTS: The key management protocol MUST NOT require that end-users obtain credentials (certificates or private keys) from a third-party trust anchor. Remember the trust anchor drama from Section 4.9? This is the receipt 🧾
R-FIPS: The media security key management protocol SHOULD use algorithms that allow FIPS 140-2 [FIPS-140-2] certification, or similar country-specific certification (for example, [AISITSEC]) 🇺🇸
The United States Government can only buy and use crypto implementations that have been validated through the FIPS-140 [FIPS-140-2] process 🦅
The FIPS-140 standard applies to all Federal agencies that use cryptography-based security systems to protect sensitive information in computer and telecom systems, including voice systems. Private and commercial organizations can adopt and use this standard too 🏢
Some commercial orgs, like banks and defense contractors, require or prefer equipment that has the same validation. Very serious energy 🏦
R-DOS: The media security key management protocol MUST NOT introduce any new significant denial-of-service vulnerabilities. For example, the protocol should not ask the endpoint to do CPU-intensive operations unless the client can validate or authorize the request. Don't let the protocol be the reason someone's device melts 🔥
R-EXISTING: The media security key management protocol SHOULD allow endpoints to authenticate using pre-existing cryptographic credentials, like certificates or pre-shared keys 🗝️
R-AGILITY: The media security key management protocol MUST provide crypto-agility, meaning the ability to adapt to evolving cryptography and security requirements. That includes updating cryptographic algorithms without causing major disruption to deployed implementations. Future-proof queen 👸
R-DOWNGRADE: The media security key management protocol MUST protect cipher suite negotiation against downgrading attacks. No sneaky downgrades allowed 🚫
R-PASS-MEDIA: The media security key management protocol MUST have a mode that stops a passive adversary with access to the media path from getting the keying material used to protect SRTP media packets 👀
R-PASS-SIG: The media security key management protocol MUST have a mode in which it stops a passive adversary with access to the signaling path from getting the keying material used to protect SRTP media packets 👀
R-SIG-MEDIA: The media security key management protocol MUST have a mode in which it defends itself against an attacker who is solely on the media path, and against an attacker who is solely on the signaling path. An attack succeeds if the adversary can get the keying material needed to decrypt the SRTP-encrypted media traffic 🛡️
R-ID-BINDING: The media security key management protocol MUST enable the media security keys to be cryptographically bound to an identity of the endpoint 🪪
Note: this lets domains deploy SIP Identity [RFC4474]. It's giving identity glow-up ✨
R-ACT-ACT: The media security key management protocol MUST support a mode of operation that provides active-signaling-active-media-detect robustness. It MAY support modes of operation that provide lower levels of robustness, as described in Section 3 🧠
Note: if the protocol fails to meet R-ACT-ACT, it cannot provide secure end-to-end media. That's a big ol' no, bestie 💔
5.3. Requirements outside of the Key Management Protocol 🦋
okay bestie, this section is the "big picture" vibe check 💅 these requirements are for the whole VoIP security system, not just the key management protocol. And they can be met inside the key management protocol, or handled outside of it (like in SIP or in SDP) 🎀
R-BEST-SECURE: Even when some endpoints of a forked or retargeted call are incapable of using SRTP, a solution MUST be described that allows the establishment of SRTP associations with SRTP-capable endpoints and/or RTP associations with non-SRTP-capable endpoints. 🔥
R-OTHER-SIGNALING: A solution SHOULD be able to negotiate keys for SRTP sessions created via different call signaling protocols (e.g., between Jabber, SIP, H.323, Media Gateway Control Protocol (MGCP). 🌈
R-RECORDING: A solution SHOULD be described that supports recording of decrypted media. This requirement comes from Section 4.3. 🎙️
R-TRANSCODER: A solution SHOULD be described that supports intermediate nodes (e.g., transcoders), terminating or processing media, between the endpoints. 🧚
R-ALLOW-RTP: A solution SHOULD be described that allows RTP media to be received by the calling party until SRTP has been negotiated with the answerer, after which SRTP is preferred over RTP. ✨
6. Security Considerations 💀
ngl this one is serious 😭 this document is literally all about securing media traffic, so security is baked into every single part of it. it's the whole main character storyline 👑
7. Acknowledgements 🫶
the authors wanna shout out the active people in the RTPSEC BoF and on the RTPSEC mailing list for their contributions to the requirements part 💜 and a massive special thank you to Steffen Fries and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197] document, which is giving pure main character energy 🌸
the authors also thanked the following people for their review, suggestions, and comments: Flemming Andreasen, Richard Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic, Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter Schneider, Frank Shearar, Srinath Thiruvengadam, Dave Ward, Dan York, and Phil Zimmermann. they're all iconic 👑🎀
8. References 📚
8.1. Normative References 🔒
[FIPS-140-2]NIST, "Security Requirements for Cryptographic Modules", June 2005, <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[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.[RFC3262]Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, 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.
8.2. Informative References 🧸
[AISITSEC]Bundesamt fuer Sicherheit in der Informationstechnik [Federal Office of Information Security - Germany], "Anwendungshinweise und Interpretationen (AIS) zu ITSEC", January 2002, <http://www.bsi.de/zertifiz/zert/interpr/aisitsec.htm>.[DTLS-SRTP]McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, October 2008.[EARLY-MEDIA]Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", Work in Progress, October 2006.[EKT]McGrew, D., "Encrypted Key Transport for Secure RTP", Work in Progress, July 2007.[H.248.1]ITU, "Gateway control protocol", Recommendation H.248, June 2000, <http://www.itu.int/rec/T-REC-H.248/e>.[ICE]Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.[MIDDLEBOX]Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2008.[MIKEY-ECC]Milne, A., "ECC Algorithms for MIKEY", Work in Progress, June 2007.[MIKEYv2]Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, revisited", Work in Progress, March 2007.[MULTIPART]Wing, D. and C. Jennings, "Session Initiation Protocol (SIP) Offer/Answer with Multipart Alternative", Work in Progress, March 2006.[RFC3326]Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.[RFC3372]Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[RFC3830]Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.[RFC4474]Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.[RFC4492]Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.[RFC4568]Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 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.[RFC4916]Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.[RFC4949]Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.[RFC5027]Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007.[RFC5197]Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[SDP-CAP]Andreasen, F., "SDP Capability Negotiation", Work in Progress, July 2008.[SDP-DH]Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", Work in Progress, February 2006.[SIP-CERTS]Jennings, C. and J. Fischl, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, November 2008.[SIP-DTLS]Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol for Protection of Media Traffic Established with the Session Initiation Protocol", Work in Progress, July 2007.[SRTP-KEY]Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", Work in Progress, October 2008.[ZRTP]Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, February 2009.
Appendix A. Overview and Evaluation of Existing Keying Mechanisms ✨
okay so bestie, every SRTP key exchange mechanism fits into one of three buckets based on where the keys travel 🗺️
- signaling path 📞: all the keying is carried in the call signaling (SIP or SDP) path.
- media path 🎶: all the keying is carried in the SRTP/SRTCP media path, and no signaling at all goes in the call signaling path.
- signaling and media path 🧩: some of the keying is in the SRTP/SRTCP media path and some is in the call signaling (SIP or SDP) path.
Now the reason SRTP is so iconic 💅 Compared to other end-to-end encryption options, like IPsec, SRTP is bandwidth efficient AND it keeps the RTP header. Bandwidth efficiency is a big deal for VoIP in lots of situations where access bandwidth is limited or expensive, and keeping the RTP header matters for troubleshooting packet loss, delay, and jitter 🔍
Also, any SRTP keying mechanism is supposed to be efficient and not cause extra call setup delay 🙅♀️ The things that add call setup delay are network or database operations (like fetching certificates and sending extra SIP or media path messages), plus the computational overhead of establishing keys or validating certificates.
When you're deciding between keying in the signaling path, keying in the media path, or keying in both, you need to know that the media path is generally "faster" than the SIP signaling path ⚡ The SIP signaling path has computational elements that parse and route SIP messages. The media path usually doesn't have those, and even when computational elements like firewalls are involved, they add very little delay. That's why the media path can be useful for exchanging several messages to establish SRTP keys. The downside of keying over the media path is that interworking different key exchanges means the interworking function has to be in the media path, not just the signaling path. In practice, though, that involvement is probably unavoidable anyway 🤷♀️
A.1. Signaling Path Keying Techniques 📞
A.1.1. MIKEY-NULL
MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both directions. The key is sent unencrypted in SDP, which means the SDP must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-end (e.g., by using Secure/Multipurpose Internet Mail Extensions (S/MIME)) 🔐
MIKEY-NULL requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
A.1.2. MIKEY-PSK
MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints share one common key. MIKEY-PSK has the offerer encrypt the SRTP keys for both directions using this pre-shared key 🗝️
MIKEY-PSK requires one message from offerer to answerer (half a round trip), and does not add additional media path messages.
A.1.3. MIKEY-RSA
MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both directions using the intended answerer's public key, which is obtained from a mechanism outside of MIKEY 🔑
MIKEY-RSA requires one message from offerer to answerer (half a round trip), and does not add additional media path messages. MIKEY-RSA requires the offerer to obtain the intended answerer's certificate 📜
A.1.4. MIKEY-RSA-R
MIKEY-RSA-R [RFC4738] is basically the same as MIKEY-RSA, but it flips the roles of the offerer and the answerer when it comes to providing the keys 🔄 So the answerer encrypts the keys for both directions using the offerer's public key. Both the offerer and answerer validate each other's public keys using standard X.509 validation techniques. MIKEY-RSA-R also enables sending certificates in the MIKEY message 🎀
MIKEY-RSA-R requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-RSA-R requires the offerer to validate the answerer's certificate.
A.1.5. MIKEY-DHSIGN
In MIKEY-DHSIGN [RFC3830], the offerer and answerer derive the key from a Diffie-Hellman (DH) exchange 🌀 To stop an active man-in-the-middle, the DH exchange itself is signed using each endpoint's private key, and the associated public keys are validated using standard X.509 validation techniques 🕵️♀️
MIKEY-DHSIGN requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages. MIKEY-DHSIGN requires the offerer and answerer to validate each other's certificates. MIKEY-DHSIGN also enables sending the answerer's certificate in the MIKEY message 💌
A.1.6. MIKEY-DHHMAC
MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-Hellman exchange. It's basically a mix of MIKEY-PSK and MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate authentication 🧁
MIKEY-DHHMAC requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)
ECC Algorithms For MIKEY [MIKEY-ECC] describes how ECC can be used with MIKEY-RSA (using Elliptic Curve Digital Signature Algorithm (ECDSA) signature) and with MIKEY-DHSIGN (using a new DH-Group code). It also defines two new ECC-based algorithms, Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 🧚
With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV function exactly like MIKEY-RSA, and the new DH-Group code functions exactly like MIKEY-DHSIGN. So these ECC mechanisms are not discussed separately in this document 🙌
A.1.8. SDP Security Descriptions with SIPS
SDP Security Descriptions [RFC4568] have each side indicate the key they will use for transmitting SRTP media, and the keys are sent in the clear in SDP 👀 SDP Security Descriptions rely on hop-by-hop (TLS via "SIPS:") encryption to protect the keys exchanged in signaling 🔒
SDP Security Descriptions requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
A.1.9. SDP Security Descriptions with S/MIME
This keying mechanism is identical to Appendix A.1.8, except that rather than protecting the signaling with TLS, the entire SDP is encrypted with S/MIME 💫
A.1.10. SDP-DH (Expired)
SDP Diffie-Hellman [SDP-DH] exchanges Diffie-Hellman messages in the signaling path to establish session keys 🥀 To protect against active man-in-the-middle attacks, the Diffie-Hellman exchange needs to be protected with S/MIME, SIPS, or SIP Identity [RFC4474] and SIP Connected Identity [RFC4916] 🛡️
SDP-DH requires one message from offerer to answerer, and one message from answerer to offerer (full round trip), and does not add additional media path messages.
A.1.11. MIKEYv2 in SDP (Expired)
MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the time synchronization requirement 🕰️ It therefore now takes 2 round trips to complete. In the first round trip, the communicating parties learn each other's identities, agree on a MIKEY mode, crypto algorithm, and SRTP policy, and exchange nonces for replay protection. In the second round trip, they negotiate unicast and/or group SRTP context for SRTP and/or SRTCP 🔁
Furthermore, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3) 🎈
A.2. Media Path Keying Technique 🎶
A.2.1. ZRTP
ZRTP [ZRTP] does not exchange information in the signaling path. (Although it's possible for endpoints to exchange a hash of the ZRTP Hello message with a=zrtp-hash in the initial offer, if it's sent over an integrity-protected signaling channel. This provides some useful correlation between the signaling and media layers.) In ZRTP, the keys are exchanged entirely in the media path using a Diffie-Hellman exchange 🌸 The advantage here is that the signaling channel is used only for call setup, and the media channel is used to establish an encrypted channel, much like encryption devices on the PSTN 📟 ZRTP uses voice authentication of its Diffie-Hellman exchange by having each person read digits or words to the other person 🗣️ Subsequent sessions with the same ZRTP endpoint can be authenticated using the stored hash of the previously negotiated key, rather than voice authentication 💾
ZRTP uses four media path messages (Hello, Commit, DHPart1, and DHPart2) to establish the SRTP key, and three media path confirmation messages. These initial messages are all sent as non-RTP packets 📦
Note: when ZRTP probing is used, unencrypted RTP can be exchanged until the SRTP keys are established. ⚠️
A.3. Signaling and Media Path Keying Techniques 🧩
A.3.1. EKT
EKT [EKT] relies on another SRTP key exchange protocol, such as SDP Security Descriptions or MIKEY, for bootstrapping 🥾 In the initial phase, each member of a conference uses an SRTP key exchange protocol to establish a common key encryption key (KEK). Each member may use the KEK to securely transport its SRTP master key and current SRTP rollover counter (ROC), via RTCP, to the other participants in the session 👯
EKT requires the offerer to send some parameters (EKT_Cipher, KEK, and security parameter index (SPI)) via the bootstrapping protocol, such as SDP Security Descriptions or MIKEY. Each answerer sends an SRTCP message that contains the answerer's SRTP Master Key, rollover counter, and the SRTP sequence number. Rekeying is done by sending a new SRTCP message. For reliable transport, multiple RTCP messages need to be sent 🔄
A.3.2. DTLS-SRTP
DTLS-SRTP [DTLS-SRTP] exchanges public key fingerprints in SDP [SIP-DTLS] and then establishes a DTLS session over the media channel 🌊 The endpoints use the DTLS handshake to agree on crypto suites and establish SRTP session keys. SRTP packets are then exchanged between the endpoints 💜
DTLS-SRTP requires one message from offerer to answerer (half round trip), and one message from the answerer to offerer (full round trip) so the offerer can correlate the SDP answer with the answering endpoint. DTLS-SRTP uses four media path messages to establish the SRTP key.
This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as its cipher suite, which is the mandatory-to-implement cipher suite in TLS [RFC5246] 🎀
A.3.3. MIKEYv2 Inband (Expired)
As defined in Appendix A.1.11, MIKEYv2 also defines an in-band negotiation mode as an alternative to SDP (see Appendix A.3.3). The details are not sorted out in the document yet on what in-band actually means (i.e., UDP, RTP, RTCP, etc.) 🤔
A.4. Evaluation Criteria - SIP 🔍
This section considers how each keying mechanism interacts with SIP features 📞✨
A.4.1. Secure Retargeting and Secure Forking ✨
okay so retargeting and forking of signaling requests were covered back in Section 4.2, and this bit builds right on top of that 💅
this list compares how secure forking, answering association, two-time pads, and secure retargeting work for each keying mechanism 🦋
- MIKEY-NULL
- Secure Forking: No, all AORs see the offerer's and answerer's keys. The answer gets tied to the media by the SSRC in MIKEY. Plus, a two-time pad happens if two branches pick the same 32-bit SSRC and send SRTP packets 💀
- Secure Retargeting: No, all targets see the offerer's and answerer's keys. It also has the retargeting identity problem 🙈
- MIKEY-PSK
- Secure Forking: No, all AORs see the offerer's and answerer's keys. The answer gets tied to the media by the SSRC in MIKEY. Note that all AORs must share the same pre-shared key for forking to work at all with MIKEY-PSK. Also, a two-time pad happens if two branches pick the same 32-bit SSRC and send SRTP packets 😭
- Secure Retargeting: Not secure. For retargeting to work, the final target has to have the right PSK. Since that's likely when the call goes to another device belonging to the same user (forking), it's super unlikely other users will have that PSK and be able to actually answer the call 🙅♀️
- MIKEY-RSA
- Secure Forking: No, all AORs see the offerer's and answerer's keys. The answer gets tied to the media by the SSRC in MIKEY. Note that all AORs must share the same private key for forking to work at all with MIKEY-RSA. Also, a two-time pad happens if two branches pick the same 32-bit SSRC and send SRTP packets 😬
- Secure Retargeting: No.
- MIKEY-RSA-R
- Secure Forking: Yes, the answer gets tied to the media by the SSRC in MIKEY. 👑
- Secure Retargeting: Yes. 👑
- MIKEY-DHSIGN
- Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. The answer gets tied to the media by the SSRC in MIKEY. 🫶
- Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions. 🫶
- MIKEYv2 in SDP
- The behavior depends on which mode gets picked 🤷♀️
- MIKEY-DHHMAC
- Secure Forking: Yes, each forked endpoint negotiates unique keys with the offerer for both directions. The answer gets tied to the media by the SSRC in MIKEY. ✨
- Secure Retargeting: Yes, each target negotiates unique keys with the offerer for both directions. Note that for the keys to actually mean something, the PSK would have to be the same for all the potential intermediaries, which only happens inside a single domain 🌸
- SDP Security Descriptions with SIPS
- Secure Forking: No, each forked endpoint sees the offerer's key. The answer isn't tied to the media at all 😵
- Secure Retargeting: No, each target sees the offerer's key. 😵
- SDP Security Descriptions with S/MIME
- Secure Forking: No, each forked endpoint sees the offerer's key. The answer isn't tied to the media at all 😵
- Secure Retargeting: No, each target sees the offerer's key. It also has the retargeting identity problem 🙈
- SDP-DH
- Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. The answer isn't tied to the media at all 🧚
- Secure Retargeting: Yes, the final target calculates a unique SRTP key. 🧚
- ZRTP
- Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. With the "a=zrtp-hash" attribute, the media can be tied to an answer 🎀
- Secure Retargeting: Yes, the final target calculates a unique SRTP key. 🎀
- EKT
- Secure Forking: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions). The answer is tied to the media by the SPI in the EKT protocol. The answer is tied to the media by the SPI in the EKT protocol. 🍓
- Secure Retargeting: Inherited from the bootstrapping mechanism (the specific MIKEY mode or SDP Security Descriptions). 🍓
- DTLS-SRTP
- Secure Forking: Yes, each forked endpoint calculates a unique SRTP key. The answer is tied to the media by the certificate fingerprint in signaling and the certificate in the media path 🔐
- Secure Retargeting: Yes, the final target calculates a unique SRTP key. 🔐
- MIKEYv2 Inband
- The behavior depends on which mode gets picked 🤷♀️
A.4.2. Clipping Media before SDP Answer 🫧
clipping media before the signaling answer shows up is covered in Section 4.1, and this builds on that 💖
ngl the clipping problem gets even worse with forking. Say you're using a Diffie-Hellman keying technique with security preconditions and it forks to 20 endpoints. The call initiator would get 20 provisional responses, each with a signed Diffie-Hellman half key. Working out 20 DH secrets and checking 20 signatures can be a real struggle, depending on what the device can handle 😭
this list compares clipping before the SDP answer for each keying mechanism:
- MIKEY-NULL: Not clipped. The offerer provides the answerer's keys. ✨
- MIKEY-PSK: Not clipped. The offerer provides the answerer's keys. ✨
- MIKEY-RSA: Not clipped. The offerer provides the answerer's keys. ✨
- MIKEY-RSA-R: Clipped. The answer contains the answerer's encryption key. 🙃
- MIKEY-DHSIGN: Clipped. The answer contains the answerer's Diffie-Hellman response. 🙃
- MIKEY-DHHMAC: Clipped. The answer contains the answerer's Diffie-Hellman response. 🙃
- MIKEYv2 in SDP: The behavior depends on which mode gets picked 🤷♀️
- SDP Security Descriptions with SIPS: Clipped. The answer contains the answerer's encryption key. 🙃
- SDP Security Descriptions with S/MIME: Clipped. The answer contains the answerer's encryption key. 🙃
- SDP-DH: Clipped. The answer contains the answerer's Diffie-Hellman response. 🙃
- ZRTP: Not clipped, because the session starts out using RTP. While RTP is flowing, both ends negotiate SRTP keys in the media path and then switch over to SRTP 🦋
- EKT: Not clipped, as long as the first RTCP packet (the one with the answerer's key) doesn't get lost in transit. The answerer sends its encryption key in RTCP, and that arrives at the same time as, or before, the first SRTP packet encrypted with that key 🌈
Note: RTCP needs to work, in the answerer-to-offerer direction, before the offerer can decrypt SRTP media. 🚨
- DTLS-SRTP: No clipping after the DTLS-SRTP handshake is done. SRTP keys get exchanged in the media path. You need to wait for the SDP answer to make sure the DTLS-SRTP handshake happened with an authorized party 🔐
- If a middlebox messes with the media path, clipping can happen [MIDDLEBOX]. 👀
- MIKEYv2 Inband: Not clipped. Keys get exchanged in the media path without relying on the signaling path 💜
A.4.3. SSRC and ROC 🎀
okay the SSRC thing is a whole mood 🥹 In SRTP, a cryptographic context is defined by the SSRC, the destination network address, and the destination transport port number. In RTP, a flow is just the destination network address and destination transport port number. So the big question is: how do you communicate the SSRC so it can be used for the cryptographic context? 🤔
Two approaches have come up for this. The first one, used by all MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY exchange. The second one, used by SDP Security Descriptions, is "late binding": any new packet with a previously unseen SSRC (arriving at the same destination network address and destination transport port number) creates a new cryptographic context. Another approach, common among techniques with media-path SRTP key establishment, is to require a handshake over that media path before any SRTP packets get sent. MIKEY's approach changes RTP's SSRC collision detection behavior by requiring RTP to pre-establish the SSRC values for each session 🫶
there's also the rollover counter (ROC). SRTP adds it to record how many times the SRTP sequence number has rolled over. Since the sequence number is used for SRTP's default ciphers, it's really important that all endpoints know the ROC value. The ROC starts at 0 at the beginning of a session 🔢
Some keying mechanisms cause a two-time pad to happen if two endpoints of a forked call have an SSRC collision. 😬
Note: A proposal has been made to send the ROC value on every Nth SRTP packet [RFC4771]. This proposal has not yet been incorporated into this document. 📝
this list examines how SSRC and ROC get handled:
- MIKEY-NULL: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEY-PSK: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEY-RSA: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEY-RSA-R: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEY-DHSIGN: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEY-DHHMAC: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- MIKEYv2 in SDP: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
- SDP Security Descriptions with SIPS: Neither the SSRC nor the ROC gets signaled. SSRC "late binding" is used. 🧩
- SDP Security Descriptions with S/MIME: Neither the SSRC nor the ROC gets signaled. SSRC "late binding" is used. 🧩
- SDP-DH: Neither the SSRC nor the ROC gets signaled. SSRC "late binding" is used. 🧩
- ZRTP: Neither the SSRC nor the ROC gets signaled. SSRC "late binding" is used. 🧩
- EKT: The SSRC of the SRTCP packet containing an EKT update matches the SRTP master key and other parameters inside that packet. 🍓
- DTLS-SRTP: Neither the SSRC nor the ROC gets signaled. SSRC "late binding" is used. 🧩
- MIKEYv2 Inband: Each endpoint indicates a set of SSRCs and the ROC for the SRTP packets it transmits. ✨
A.5. Evaluation Criteria - Security 🔐
this section evaluates each keying mechanism based on its security properties. Let's get into it 💅
A.5.1. Distribution and Validation of Persistent Public Keys and Certificates 🔐
okay so using persistent public keys for confidentiality and authentication can bring in requirements for two types of systems, usually built with certificates: (1) a system to distribute those persistent public key certificates, and (2) a system for validating those persistent public keys. we call the first one a key distribution system and the second one an authentication infrastructure. a lot of the time, one monolithic public key infrastructure (PKI) handles both jobs 💅 but honestly, lots of other systems can do these roles too. for example, key distribution can be done by any public repository of keys. any setup where the two endpoints can reach trust anchors and intermediate CA certificates that can validate other endpoints' certificates counts, even a system of self-signed certificates 🌸 and that setup can support certificate validation in the schemes below.
with real-time communications, it's super important to avoid fetching or validating certificates in a way that delays call setup ⏰ so ideally, you fetch or validate certificates in a way that doesn't hold up the call. like, a certificate can be validated while the phone is ringing, or while ring-back tones are playing, or even while the called party picks up and says "hello" 📞 and the even better move? avoid fetching or validating persistent public keys at all ✨
SRTP key exchange mechanisms that need a particular authentication infrastructure to operate (whether for distribution or validation) only work once that infrastructure is deployed and available to both endpoints. which means no media security is achievable until such an infrastructure exists 🥺 for SIP, something like sip-certs [SIP-CERTS] might be used to obtain the certificate of a peer.
Note: Even if sip-certs [SIP-CERTS] were deployed, the retargeting problem (Appendix A.4.1) would still prevent successful deployment of keying techniques which require the offerer to obtain the actual target's public key. 🙈
okay now the list comparing what each keying mechanism brings in for public-key cryptography, both for public key distribution and for certificate validation 👑
MIKEY-NULL: public-key cryptography is not used. 🫶MIKEY-PSK: public-key cryptography is not used. instead, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.MIKEY-RSA: the offerer obtains the intended answerer's public key before starting the call, and that public key is used to encrypt the SRTP keys. there's no defined mechanism for the offerer to obtain the answerer's public key, although [SIP-CERTS] might be viable in the future 🤷♀️- the offer may also contain a certificate for the offerer, which would need an authentication infrastructure in order to be validated by the receiver.
MIKEY-RSA-R: the offer contains the offerer's certificate, and the answer contains the answerer's certificate. the answerer uses the public key in the certificate to encrypt the SRTP keys that will be used by the offerer and the answerer. an authentication infrastructure is necessary to validate the certificates 🎀MIKEY-DHSIGN: an authentication infrastructure is used to authenticate the public key that's included in the MIKEY message 💜MIKEY-DHHMAC: public-key cryptography is not used. instead, all endpoints must have some way to exchange per-endpoint or per-system pre-shared keys.MIKEYv2 in SDP: the behavior depends on which mode gets picked 🧚SDP Security Descriptions with SIPS: public-key cryptography is not used. 💀SDP Security Descriptions with S/MIME: using S/MIME means the endpoints have to be able to fetch and validate certificates for each other 😭 the offerer must obtain the intended target's certificate and encrypt the SDP offer with the public key in that certificate. the answerer must obtain the offerer's certificate and encrypt the SDP answer with the public key in the offerer's certificate.SDP-DH: public-key cryptography is not used. 🍓ZRTP: public-key cryptography is used (Diffie-Hellman), but it doesn't depend on persistent public keys, so certificates aren't fetched or validated. it's giving main character energy 🦋EKT: public-key cryptography is not used by itself, but it might be used by the EKT bootstrapping keying mechanism (such as certain MIKEY modes) 🌈DTLS-SRTP: the remote party's certificate is sent in the media path, and a fingerprint of that same certificate is sent in the signaling path 🔥MIKEYv2 Inband: the behavior depends on which mode gets picked ⭐
A.5.2. Perfect Forward Secrecy 🌙
okay so in the context of SRTP, Perfect Forward Secrecy (PFS) means that SRTP session keys which protected a previous session stay uncompromised even if the static keys belonging to the endpoints get compromised 😱 like, if someone recorded your encrypted session content and later got either party's private key, that content would still be safe from decryption if your key exchange mechanism had perfect forward secrecy. bestie, that's the dream 💖
here's how each key exchange mechanism provides PFS 🎀
MIKEY-NULL: not applicable, since MIKEY-NULL doesn't have a long-term secret. 🫠MIKEY-PSK: no PFS. 🥲MIKEY-RSA: no PFS. 🥲MIKEY-RSA-R: no PFS. 🥲MIKEY-DHSIGN: PFS is provided with the Diffie-Hellman exchange ✨MIKEY-DHHMAC: PFS is provided with the Diffie-Hellman exchange ✨MIKEYv2 in SDP: the behavior depends on which mode gets picked 🧚SDP Security Descriptions with SIPS: not applicable, since SDP Security Descriptions doesn't have a long-term secret 💅SDP Security Descriptions with S/MIME: not applicable, since SDP Security Descriptions doesn't have a long-term secret 💅SDP-DH: PFS is provided with the Diffie-Hellman exchange ✨ZRTP: PFS is provided with the Diffie-Hellman exchange ✨EKT: no PFS. 🥲DTLS-SRTP: PFS is provided if the negotiated cipher suite uses ephemeral keys, like Diffie-Hellman (DHE_RSA[RFC5246]) or Elliptic Curve Diffie-Hellman [RFC4492] 🌸MIKEYv2 Inband: the behavior depends on which mode gets picked 🧚
A.5.3. Best Effort Encryption 🫧
okay so with best effort encryption, SRTP gets used with endpoints that support SRTP, and plain RTP gets used otherwise 🦋
SIP needs backwards-compatible best effort encryption so SRTP can work with SIP retargeting and forking, especially when there's a mix of forked or retargeted devices, some that support SRTP and some that don't 🙃
Consider the case of Bob, with a phone that only does RTP and a voice mail system that supports SRTP and RTP. If Alice calls Bob with an SRTP offer, Bob's RTP-only phone will reject the media stream (with an emptym=line) because Bob's phone doesn't understand SRTP (RTP/SAVP). Alice's phone will see this rejected media stream and may terminate the entire call (BYE) and re-initiate the call as RTP-only, or Alice's phone may decide to continue with call setup with the SRTP-capable leg (the voice mail system). If Alice's phone decided to re-initiate the call as RTP-only, and Bob doesn't answer his phone, Alice will then leave voice mail using only RTP, rather than SRTP as expected. 📼💀
right now, a few techniques are commonly considered as candidates for opportunistic encryption 👀
multipart/alternative: [MULTIPART] describes how to form amultipart/alternativebody part in SIP. the big issues here are (1) that multipart MIME is incompatible with existing SIP proxies, firewalls, Session Border Controllers, and endpoints, and (2) when forking, the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326] causes problems if non-multipart-capable endpoints were involved in the forking 😤- session attribute: with this technique, the endpoints signal their desire to do SRTP by signaling RTP (
RTP/AVP) and using an attribute (a=) in the SDP. it's totally backwards compatible with non-SRT-aware endpoints, but it doesn't use theRTP/SAVPprotocol registered by SRTP [RFC3711] 🧃 - SDP Capability Negotiation: [SDP-CAP] provides a backwards-compatible mechanism to allow offering both SRTP and RTP in a single offer. this is the preferred technique 👑
- probing: with this technique, the endpoints first set up an RTP session using
RTP/AVP. then they send probe messages over the media path to figure out if the remote endpoint supports their keying technique. the downside is that an active attacker can interfere with probes, and until probing finishes (and SRTP is established), the media is in the clear 🚨
the preferred technique, SDP Capability Negotiation [SDP-CAP], can be used with all key exchange mechanisms 🫶 what makes ZRTP unique is that it can accomplish its best effort encryption by probing (sending ZRTP messages over the media path) or by session attribute (see "a=zrtp-hash" in [ZRTP]). current implementations of ZRTP use probing 🌈
A.5.4. Upgrading Algorithms ✨
okay so we need to be able to upgrade SRTP encryption and hash algorithms 🔄, and also the crypto functions used for the key exchange 🔑. ngl with SIP's offer/answer model this gets super expensive 💀. The offer has to include every combo of key exchange mechanisms (all MIKEY modes, SDP Security Descriptions), every SRTP cryptographic suite (AES-128, AES-256) and every SRTP cryptographic hash function (SHA-1, SHA-256) the offerer supports. So the offerer has to burn CPU just to build an offer with all of that info, and it becomes computationally prohibitive 😭.
Bestie, that's why it's so important to keep the offerer's CPU impact fixed 🫶. That way, offering a bunch of new SRTP encryption and hash functions costs zero extra. Iconic behavior 👑.
Here's the CPU breakdown for each key exchange technique 💅:
MIKEY-NULL: No significant computational expense.MIKEY-PSK: No significant computational expense.MIKEY-RSA: For each offered SRTP crypto suite, the offerer has to perform an RSA operation to encrypt the TGK (TEK Generation Key) 🔐.MIKEY-RSA-R: For each offered SRTP crypto suite, the offerer has to perform a public key operation to sign the MIKEY message ✍️.MIKEY-DHSIGN: For each offered SRTP crypto suite, the offerer has to perform a Diffie-Hellman operation, plus a public key operation to sign the Diffie-Hellman output 🧮.MIKEY-DHHMAC: For each offered SRTP crypto suite, the offerer has to perform a Diffie-Hellman operation 💜.MIKEYv2 in SDP: The behavior depends on which mode gets picked 🤷♀️.SDP Security Descriptions with SIPS: No significant computational expense.SDP Security Descriptions with S/MIME: S/MIME makes the offerer and the answerer encrypt the SDP with the other's public key, and decrypt the received SDP with their own private key 📨. Lots of crypto, bestie.SDP-DH: For each offered SRTP crypto suite, the offerer has to perform a Diffie-Hellman operation 🌸.ZRTP: The offerer has no additional computational expense at all, because the offer contains no ZRTP info or might containa=zrtp-hash🦋. Main character energy.EKT: The offerer's computational expense depends entirely on which EKT bootstrapping mechanism gets selected (one or more MIKEY modes or SDP Security Descriptions) 🧚.DTLS-SRTP: The offerer has no additional computational expense at all, since the offer only contains a fingerprint of the certificate that will be presented in the DTLS exchange 🍓.MIKEYv2 Inband: The behavior depends on which mode gets picked 🌈.
Appendix B. Out-of-Scope 🎀
okay this one's important 🚨. Compromising an endpoint that can see decrypted media (e.g., a SIP user agent, transcoder, or recorder) is out of scope for this document 🙈. That kind of compromise could come from privilege escalation, a virus or trojan horse install, or similar attacks. Not my problem in this spec, but still scary 💀.
B.1. Shared Key Conferencing 🎤
The RTPSEC mailing list consensus was to focus on unicast, point-to-point sessions 💖. So there are no requirements related to shared key conferencing. This section is only kept for informational purposes ✨.
Okay so for efficient scaling 📈, big audio and video conference bridges work best by encrypting the current speaker once and distributing that stream to the attendees 🎥. Usually the inactive participants get the same streams. They hear (or see) the active speaker(s), while the active speakers get distinct streams that don't include themselves 🙈. To keep these conferences confidential when listeners share a common key, all listeners must be rekeyed whenever a listener joins or leaves the conference 🔐.
An important use case for mixers/translators is a conference bridge 🌉:
+----+
A --- 1 --->| |
<-- 2 ----| M |
| I |
B --- 3 --->| X |
<-- 4 ----| E |
| R |
C --- 5 --->| |
<-- 6 ----| |
+----+
Figure 3: Centralized KeyingIn the figure above, 1, 3, and 5 are the RTP media contributions from Alice, Bob, and Carol 👭, and 2, 4, and 6 are the RTP flows back to those devices carrying the "mixed" media 🎶.
Several scenarios are possible 🦋:
- a. Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions.
- b. Multiple outbound sessions: 2, 4, and 6 are distinct RTP sessions.
- c. Single inbound session: 1, 3, and 5 are just different sources within the same RTP session.
- d. Single outbound session: 2, 4, and 6 are different flows of the same (multi-unicast) RTP session.
If there are multiple inbound AND multiple outbound sessions (scenarios a and b), then every keying mechanism acts as if the mixer were an endpoint, and it can set up a point-to-point secure session between the participant and the mixer 🤝. This is the simplest situation, but it's computationally wasteful 😩, since SRTP processing has to be done independently for each participant. Multiple inbound sessions (scenario a) don't waste computational resources 💅, though they do eat extra cryptographic context on the mixer for each participant. The big upside is data origin authentication ✅.
To support a single outbound session (scenario d) 📤, the mixer has to dictate its encryption key to the participants 🔑. Some keying mechanisms let the transmitter pick its own key, and others let the offerer decide the key for both the offerer and the answerer 🧠. Depending on how the call gets set up, the offerer might be a participant (like someone dialing into a conference bridge) or the mixer (like a conference bridge calling a participant) 📞. Offerless INVITEs may help some keying mechanisms reverse the offerer/answerer roles 🔄. The tricky part is knowing ahead of time whether the roles should be reversed for a particular call 🫠. The big advantage of a single outbound session is that the number of SRTP encryption operations stays constant even as participants increase 📊. The downside? Data origin authentication is lost 😱, which means any participant can spoof the sender, since everyone knows the sender's SRTP key 👻.
Authors' Addresses 💌
Dan Wing (editor)
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: dwing@cisco.comSteffen Fries
Siemens AG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: steffen.fries@siemens.comHannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo, 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.atFrancois Audet
Nortel
4655 Great America Parkway
Santa Clara, CA 95054
USA
EMail: audet@nortel.comThat's the whole doc, bestie! 🌈🎉 Thanks for hanging with me through all 9 parts 🫶💖
📦 where this page comes from
- ietf: rfc5479 2009-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms