RFC 8871
A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)
RFC 8871: A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC) ✨
okay bestie, let's get into it 🎀 this one is the title block tea: it's an IETF Standards Track doc (category, so it's real, implementable, and people are supposed to actually build it 💅). It was written by P. Jones from Cisco, D. Benham, and C. Groves, who are listed as Independent 🦋. It came out in January 2021, and it doesn't obsolete or update any other RFCs, so it's a fresh start, no drama 🌸. The ISSN is 2070-1721 (the number that identifies the RFC series itself, iykyk 🤓).
The whole vibe of this doc is private media in PERC (Privacy-Enhanced RTP Conferencing). The big idea: in a switched conference, the middle-person boxes that forward your video and audio should NOT be able to peek at it 👀 🔐. That's the main character energy 👑.
Abstract
okay so the abstract is basically the TL;DR 💖. It describes a solution framework to keep media confidentiality and integrity intact from end to end, even though the Media Distributors aren't trusted with the end-to-end encryption keys 🫶. It's built on top of the RTP security stuff that already exists, so nobody has to reinvent the wheel ✨.
Status of This Memo
this section is the official paperwork energy 📋 but here's the gist: it's a standards track document 🎀, it reflects IETF consensus, it got public review, and the IESG approved it 💜. If you want the deets on standards, check out Section 2 of RFC 7841 🌈. Errata and feedback live at https://www.rfc-editor.org/info/rfc8871 🔗.
Copyright Notice
copyright is 2021, IETF Trust and the authors, all rights reserved 🦋. The doc is subject to BCP 78 and the IETF Trust's Legal Provisions (see https://trustee.ietf.org/license-info for the vibes). If you pull code out of this doc, it has to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and comes with no warranty 🫶.
Table of Contents
here's the whole roadmap 🗺️
1. Introduction
2. Conventions Used in This Document
3. PERC Entities and Trust Model
3.1. Untrusted Entities
3.1.1. Media Distributor
3.1.2. Call Processing
3.2. Trusted Entities
3.2.1. Endpoint
3.2.2. Key Distributor
4. Framework for PERC
4.1. E2E-Authenticated and HBH-Authenticated Encryption
4.2. E2E Key Confidentiality
4.3. E2E Keys and Endpoint Operations
4.4. HBH Keys and Per-Hop Operations
4.5. Key Exchange
4.5.1. Initial Key Exchange and Key Distributor
4.5.2. Key Exchange during a Conference
5. Authentication
5.1. Identity Assertions
5.2. Certificate Fingerprints in Session Signaling
5.3. Conference Identification
6. PERC Keys
6.1. Key Inventory and Management Considerations
6.2. DTLS-SRTP Exchange Yields HBH Keys
6.3. The Key Distributor Transmits the KEK (EKT Key)
6.4. Endpoints Fabricate an SRTP Master Key
6.5. Summary of Key Types and Entity Possession
7. Encrypted Media Packet Format
8. Security Considerations
8.1. Third-Party Attacks
8.2. Media Distributor Attacks
8.2.1. Denial of Service
8.2.2. Replay Attacks
8.2.3. Delayed Playout Attacks
8.2.4. Splicing Attacks
8.2.5. RTCP Attacks
8.3. Key Distributor Attacks
8.4. Endpoint Attacks
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🌸
okay so switched conferencing is hugely popular rn 💅 with a bunch of people sharing audio, video, text, and other media. The key difference is that the media from participants is NOT mixed, transcoded, translated, recomposed, or messed with by a Media Distributor, unlike an old-school media server or Multipoint Control Unit (MCU) 🙅♀️. The Media Distributors just forward each participant's flows to everyone else 🦋. They often only forward a subset of flows, based on voice activity detection or other criteria 🎧. Sometimes they tweak RTP headers [RFC3550] a little, but the actual media content (voice, video, etc.) stays untouched ✨.
Switched conferencing is also easy to deploy, since Media Distributors can run on general-purpose hardware, including virtualized setups in private and public clouds ☁️. Public cloud has been seen as less secure, since you don't physically control the hardware you're using 🙈. So this doc defines better security to lower the barrier to using those environments 🔐.
The framework makes media privacy happen by making it impossible for a Media Distributor to get the keys needed to decrypt or authenticate the actual media sent between participants 🔒. Media Distributors can still modify certain RTP headers, add, remove, encrypt, or decrypt RTP header extensions, and encrypt and decrypt RTP Control Protocol (RTCP) packets [RFC3550] 💜. It also stops replay attacks by authenticating each packet between a participant and the Media Distributor with a unique per-endpoint key, separate from the media encryption and authentication key 🧚.
Basically this framework gives extra privacy in RTP conferencing while reusing existing RTP security procedures, with minimal extras 🎀.
2. Conventions Used in This Document 🦋
okay here's the rulebook 📖. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but ONLY when they're in all capitals like this 🫶.
Here are the terms and abbreviations this framework uses 💅:
- End-to-End (E2E): communications from one endpoint, through one or more Media Distributors, to the endpoint on the other end 🌈.
- Hop-by-Hop (HBH): communications between an endpoint and a Media Distributor, or between Media Distributors 🦋.
- Trusted Endpoint (or simply endpoint): an RTP flow-terminating entity that has the E2E media encryption keys and terminates E2E encryption. This can be embedded user conferencing gear, browsers on computers, media gateways, MCUs, media recording devices, and more, as long as they're in the trusted domain for a deployment 🎧. In WebRTC [W3C.CR-webrtc], where a JavaScript app and a browser split the session control, the browser acts as the Trusted Endpoint for this framework (same as it's the endpoint for DTLS-SRTP [RFC5764] in one-to-one calls) 💖.
- Media Distributor (MD): an RTP middlebox that forwards endpoint media content (voice or video data) unaltered, either a subset or all of the flows at any time, and is NEVER allowed to access E2E encryption keys 🔐. It works like a Selective Forwarding Middlebox per the RTP topologies in [RFC7667], under the constraints of the PERC system. That includes, but isn't limited to, having no access to RTP media plaintext and having limits on which RTP header fields it can change 🙅♀️. The header fields a Media Distributor may modify are listed in Section 4 of the double cryptographic transform specification [RFC8723], and were picked with utility and the security considerations in this doc in mind ✨.
- Key Distributor: a logical function that hands out keying material and related info to Trusted Endpoints and Media Distributor(s), only what's appropriate for each 🗝️. It might live on the same box as another entity that's trusted with E2E keying material 🧚.
- Conference: two or more participants talking via Trusted Endpoints to swap RTP flows through one or more Media Distributors 🎀.
- Call Processing: all Trusted Endpoints join a conference through a call processing dialog, e.g., with the "focus" defined in "A Framework for Conferencing with the Session Initiation Protocol (SIP)" [RFC4353] 📞.
- Third Party: any entity that isn't an endpoint, Media Distributor, Key Distributor, or call processing entity as described here 👀.
3. PERC Entities and Trust Model 👑
Figure 1 shows the trust relationships, direct or indirect, between the entities in the next subsections 🗺️. These entities can be co-located or split into multiple physical devices 🦋.
heads up, though 🚨: some entities that count as untrusted in the simple, general deployment scenario this doc mostly uses might be trusted in other deployments. This doc doesn't rule those out, but it keeps the definitions and examples focused by only using the simplest, most general scenario 💅.
|
+----------+ | +-----------------+
| Endpoint | | | Call Processing |
+----------+ | +-----------------+
|
|
+----------------+ | +--------------------+
| Key Distributor| | | Media Distributor |
+----------------+ | +--------------------+
|
Trusted | Untrusted
Entities | Entities
|
Figure 1: Trusted and Untrusted Entities in PERC3.1. Untrusted Entities 🙈
the framework lets conferencing infrastructure live in domains like a cloud conferencing provider's facilities, where trustworthiness is below what you'd need to assume participants' media stays private ☁️. That infrastructure is still trusted to reliably connect participants into a conference 🤝, but it's NOT trusted with the keying material needed to decrypt any participant's media 🔐. Entities in these less-trustworthy domains are called untrusted entities from here on 🦋.
Important! 🚨 "untrusted" in this doc does NOT mean an entity isn't expected to work properly 💅. It only means the entity doesn't have access to the E2E media encryption keys 🗝️.
This is part 1 of 6. More parts are coming, so keep your eyes peeled 👀💖.
3.1.1. Media Distributor 🦋
okay so the Media Distributor is the forwarder of the conference 💅 It passes RTP flows between endpoints and does per-hop authentication on every single RTP packet 🔥 It might need to look at one or more RTP headers or header extensions, and it can add or change a certain subset of them. It also relays secured messages between the endpoints and the Key Distributor, and it grabs its per-hop key info from the Key Distributor 🫶 The actual media content has to stay undecryptable for a Media Distributor 🙈 It doesn't get the E2E media encryption keys, and the key exchange methods in this framework make sure it never gets them 🔐
Here's the thing though: being able to join a conference run by a Media Distributor means an endpoint is allowed to have the E2E media encryption keys. The Media Distributor can't actually check whether that's true 😭 So the Key Distributor handles it. It authenticates the endpoint (for example, using WebRTC identity assertions [RFC8827]) and decides whether that endpoint is allowed to receive E2E and HBH media encryption keys ✨
A Media Distributor has to do its forwarding job properly while also handling denial-of-service attacks (see Section 8). It needs to be at least as good at that as traditional conferencing (non-PERC) setups 💪
A Media Distributor, or the conferencing infrastructure around it, can also start or end various conference control messaging techniques. That stuff is outside the scope of this framework document, so we're not going there today 🧚
3.1.2. Call Processing 🌸
Call processing is untrusted in the simple, general deployment scenario 🙅 If some of the call processing lives in facilities outside the trusted domain, it really shouldn't be trusted with E2E key information.
Call processing can handle call signaling messages and sign them. It can also authenticate endpoints for call signaling and for joining a conference hosted by one or more Media Distributors 💖 Call processing can optionally keep call signaling messages private between itself, the endpoint, and other entities 🤫
3.2. Trusted Entities 👑
From the PERC model system's point of view, trusted entities (see Figure 1) can have the E2E media encryption keys for one or more conferences 🫶
3.2.1. Endpoint 💜
An endpoint is considered trusted and has access to E2E key information. Could an endpoint get compromised and start acting up? Sure, it's possible 😬 But how well an endpoint resists compromise is outside the scope of this document. Endpoints also handle denial-of-service attacks (see Section 8) coming from other entities, including other endpoints, at least as well as traditional conference (non-PERC) deployments do 🛡️
3.2.2. Key Distributor 🔑
The Key Distributor is in charge of giving key information to endpoints for both E2E and HBH security, and giving key information to Media Distributors for HBH security. It might live right alongside an endpoint or run on its own ✨
It has to work with call processing so the conference-to-endpoint mappings are right. That's covered in Section 5.3 🧠
The Key Distributor needs to be locked down and managed so an adversary can't exploit it. If it gets compromised in any way, the security of the whole conference is at risk 😱
The Key Distributor also needs to know which endpoints and which Media Distributors are allowed to be in the conference. How it gets that info is outside the scope of this document 🙃 Either way, Key Distributors MUST reject DTLS associations with any unauthorized endpoint or Media Distributor 🚫
4. Framework for PERC ✨
The point of this framework is to give you a way to keep media private inside a conferencing environment made up of one or more Media Distributors that only switch media and never terminate it 🎀 It doesn't try to hide the fact that a conference between endpoints is happening, though 👀
This framework reuses a few specified RTP security technologies: the Secure Real-time Transport Protocol (SRTP) [RFC3711], Encrypted Key Transport (EKT) [RFC8870], and DTLS-SRTP 🧁
4.1. E2E-Authenticated and HBH-Authenticated Encryption 🔐
This solution framework is all about the E2E privacy and integrity of the participant's media. It does that by limiting access to the E2E key used for authenticated E2E encryption to trusted entities only 💅 That said, the framework does give a Media Distributor access to RTP header fields and header extensions. It can also modify a certain subset of the header fields and add or change header extensions 🦋 Packets received by a Media Distributor or an endpoint are authenticated hop by hop ✨
To make all of this work, the framework defines two security contexts and two encryption keys 🌈 First there's an "inner" key, which is a distinct E2E key for each transmitted media flow, used for authenticated encryption of RTP media between endpoints. Then there's an "outer" key, which is a HBH key known only to a Media Distributor or the adjacent endpoint, used on the hop between an endpoint and a Media Distributor or peer endpoint. An endpoint gets one or more E2E keys from every other endpoint in the conference, matching the media flows those endpoints send. HBH keys are derived from the DTLS-SRTP association with the Key Distributor. Two communicating Media Distributors use DTLS-SRTP associations directly with each other to get the HBH keys they need. See Section 4.5 for more on key exchange 🔑
+-------------+ +-------------+
| ################################ | ||||
|---|---|---|---|---|
| Media | ------------------------ *-----> | Media | ||
| Distributor | <----------------------*- | ------ | Distributor | |
| X | #####################*# | # | ###### | Y |
+-------------+ | | | +-------------+ # ^ | # HBH Key (XY) -+ | | # ^ | # # | | # E2E Key (B) ---+ | # | | # # | | # E2E Key (A) -----+ # | | # # | | # # | | # # | | # # | | # # | | ---- HBH Key (AX) HBH Key (YB) ---- | | # # | | # # | | # # --------- E2E Key (A) E2E Key (A) --------- # # | ------- E2E Key (B) E2E Key (B) ------- | # # | | # # | | # # | v # # | v # +-------------+ +-------------+
| Endpoint A | Endpoint B |
+-------------+ +-------------+
Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets
The double transform [RFC8723] lets endpoints encrypt using both the E2E and HBH contexts, and it still keeps the same overall interface as other SRTP transforms 🪄 The Media Distributor just uses the normal single AES-GCM transform, keyed with the right HBH keys. For a rundown of the keys used in PERC, see Section 6.1. For a diagram of what encrypted RTP packets look like on the wire, see Section 7 📦
RTCP is only encrypted hop by hop -- not end to end 🙀 This framework doesn't add an extra step for RTCP-authenticated encryption. Instead, implementations use the existing procedures from [RFC3711], which use the same outer HBH cryptographic context picked in the double transform operation above. Because of that, endpoints MUST NOT send confidential information via RTCP 🚨
4.2. E2E Key Confidentiality 🤐
To keep E2E keys shared between endpoints confidential, endpoints use a common Key Encryption Key (KEK). Only the trusted entities in a conference know it 👀 The EKT specification [RFC8870] calls it the EKT Key, and it's used to encrypt the SRTP master key for E2E-authenticated encryption of media sent by a given endpoint 🧁 Each endpoint creates its own SRTP master key for E2E-authenticated encryption. It also keeps track of the E2E keys it receives via the Full EKT Tag for each distinct synchronization source (SSRC) in the conference, so it can decrypt received media properly 💜 An endpoint can change its E2E key at any time and advertise the new key to the conference, as specified in [RFC8870] 🦋
4.3. E2E Keys and Endpoint Operations 🎀
Every RTP media flow is identified by its SSRC. An endpoint might send more than one of those at a time, and it can change the mix of media flows it's sending during the lifetime of a conference 🌸
So an endpoint MUST maintain a list of SSRCs from received RTP flows, along with each SSRC's associated E2E key information 📋 An endpoint MUST discard old E2E keys no later than when it leaves the conference 🧹
If the packet is going to carry RTP header extensions, those extensions are only encrypted hop by hop per [RFC8723] 😬 That's why endpoints MUST NOT transmit confidential information via RTP header extensions 🙅♀️
4.4. HBH Keys and Per-Hop Operations ✨
Okay bestie, so the integrity thing is a big deal 🔐. It is REQUIRED that every packet gets authenticated hop by hop, both between an endpoint and a Media Distributor and between Media Distributors. The HBH authentication key comes from an SRTP master key that is shared only on that one hop. Every HBH key is unique to its hop, and no two hops ever share the same SRTP master key. Main character energy for security 💅
Endpoints do HBH authentication too, but they can also rebuild the original RTP header 🧩. That means they can authenticate RTP packets end to end, which is so clever. It also gives the Media Distributor some wiggle room to tweak certain RTP header values while it forwards packets 🦋. The values the Media Distributor is allowed to change are defined in [RFC8723]. RTCP can only be encrypted hop by hop, so the Media Distributor gets to (1) forward RTCP content unchanged, (2) send compound RTCP packets, (3) start RTCP packets to report statistics, or (4) pass along other info. Doing HBH authentication on all RTP and RTCP packets also helps with replay protection (see Section 8) 🙈. The replay protection mechanism from Section 3.3.2 of [RFC3711] is REQUIRED at each hop, no exceptions 🔥
If you need to encrypt one or more RTP header extensions hop by hop, the endpoint derives an encryption key from the HBH SRTP master key and uses it as per [RFC6904] 🎀. The Media Distributor still gets to see header extensions, like the one used to figure out the audio level [RFC6464] of conference participants 🎧. Heads up though: when RTP header extensions are encrypted, every hop has to decrypt and re-encrypt them 👀. For the actual procedures, check out Sections 5.1, 5.2, and 5.3 of [RFC8723] 💖
4.5. Key Exchange
Here's the quick tea on who gets which keys ☕:
- The HBH keys an endpoint uses to send and receive SRTP media come from a DTLS handshake with the Key Distributor, following normal DTLS-SRTP procedures 🌸
- The E2E key an endpoint uses to send SRTP media can either be set from the DTLS-SRTP association with the Key Distributor, or the endpoint can pick it itself ✨. Then it gets shared with other endpoints inside a Full EKT Tag, encrypted under an EKT Key the Key Distributor gave the client within the DTLS channel they negotiated 🔐. Note that an endpoint MAY create a different E2E key per media flow, where a media flow is identified by its SSRC value 🦋
- Each E2E key an endpoint uses to receive SRTP media gets set when it receives a Full EKT Tag from another endpoint 📩
- The HBH keys between two Media Distributors come from DTLS-SRTP procedures done directly between them 🧚
4.5.1. Initial Key Exchange and Key Distributor
The Media Distributor keeps a tunnel open with the Key Distributor (for example, using the tunnel protocol in [PERC-DTLS]) 🚇. That lets it help set up a secure DTLS association between each endpoint and the Key Distributor, as shown in Figure 3. That DTLS association is how each endpoint generates its E2E and HBH keys and receives the KEK 🗝️. Meanwhile, the Key Distributor securely hands the HBH key info over to the Media Distributor. The key info here may include the SRTP master key, the SRTP master salt, and the negotiated cryptographic transform 💜
+-----------+
KEK info | Key | HBH Key info to
to Endpoints |Distributor| Endpoints & Media Distributor
+-----------+
# ^ ^ #
# | | #--- Tunnel
# | | #
+-----------+ +-----------+ +-----------+
| Endpoint | DTLS | Media | DTLS | Endpoint |
| KEK |<------------|Distributor|------------>| KEK |
| HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key |
+-----------+ +-----------+ +-----------+
Figure 3: Exchanging Key Information between EntitiesBesides that secure tunnel between the Media Distributor and the Key Distributor, there are two more kinds of security associations in the key exchange 🎀. One is a DTLS-SRTP association between an endpoint and the Key Distributor, with packets passing through the Media Distributor. The other is a DTLS-SRTP association between peer Media Distributors 🫶.
Endpoints set up a DTLS-SRTP association over the RTP session with the Media Distributor and its media ports, so they can swap key info with the Key Distributor 🌈. The Media Distributor doesn't terminate the DTLS signaling. It just forwards DTLS packets from an endpoint to the Key Distributor (and back again) through the tunnel between them 🦋.
When an endpoint and the Key Distributor are setting up their DTLS association, the endpoint MUST act as the DTLS client, and the Key Distributor MUST act as the DTLS server 👑. The KEK goes from the Key Distributor to endpoints over that DTLS association, using the procedures in EKT [RFC8870] via the EKTKey message 🔑.
The Key Distributor MUST NOT establish DTLS-SRTP associations with endpoints without first authenticating the Media Distributor that is tunneling the DTLS-SRTP packets from the endpoint 🚫. Nobody gets past the bouncer without ID 🙅♀️
Note that when following DTLS-SRTP procedures for the cipher defined in [RFC8723], the endpoint generates both E2E and HBH encryption keys and salt values 🧂. Endpoints MUST either use the DTLS-SRTP-generated E2E key for transmission or generate a fresh E2E key 🔄. In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value the Key Distributor provides via the EKTKey message 🧂✨. Why? Because every endpoint in the conference uses the same SRTP master salt 🤝. The endpoint only sends the SRTP master key (not the salt) used for E2E encryption to other endpoints, inside RTP/RTCP packets per [RFC8870] 📦.
Media Distributors use DTLS-SRTP directly with a peer Media Distributor to set up the HBH key for sending RTP and RTCP packets to that peer 🛰️. The Key Distributor does not help set up HBH keys between Media Distributors 🙅♀️
4.5.2. Key Exchange during a Conference
Once the initial key info exchange with the Key Distributor is done, an endpoint can encrypt media end to end with an E2E key 🔐. It sends that E2E key to other endpoints encrypted with the KEK, and it can encrypt and authenticate RTP packets with a HBH key too 💖. This framework does not let the Media Distributor get access to the KEK information, so it can't get any endpoint's E2E key and then decrypt the media 🛡️. Iconic.
The KEK may need to change from time to time during a conference's life, like when someone new joins or leaves 🚪. Whether, when, or how often a conference gets rekeyed is outside the scope of this document 🙈. But this framework does allow for rekeying during a conference 🔁.
When a Key Distributor decides to rekey a conference, it sends a new EKTKey message containing the new EKT Key to each conference participant 📨. When an endpoint gets that new EKT Key, it MUST create a new SRTP master key and get ready to send that key inside a FullEKTField using the new EKT Key, as per Section 4.5 of [RFC8870] 🆕. To give everyone time to get the new keys, the sender should follow the recommendations in Section 4.6 of [RFC8870] ⏳. Once an endpoint receives a new EKT Key, it MUST be prepared to decrypt EKT Tags using the new key 🔓. The EKT Security Parameter Index (SPI) field is how you tell EKT Tags encrypted with the old key apart from ones encrypted with the new key 🏷️.
After rekeying, an endpoint SHOULD keep its prior SRTP master keys and EKT Keys for a while 🗄️. The reason is so it can still decrypt late-arriving or out-of-order packets, or packets other endpoints sent using the prior keys for a bit after rekeying started 📬. An endpoint MAY keep old keys until the conference ends 🎬.
Endpoints MAY follow the procedures in Section 5.2 of [RFC5764] to renegotiate HBH keys whenever they want 🔄. If new HBH keys get generated, they're also delivered to the Media Distributor using the procedures in [PERC-DTLS], which is one possible method 📤.
At any time, endpoints MAY change the E2E encryption key they're using 🎨. An endpoint MUST generate a new E2E encryption key whenever it receives a new EKT Key 🆕. After switching to a new key, that key gets shared with the other endpoints in the conference inside RTP/RTCP packets, per [RFC8870] 💌.
5. Authentication 🪪
It matters a lot that entities can check whether other entities are legit, especially the Key Distributor and endpoints 🕵️♀️. The details on this are outside the scope of this specification, but a few options get talked about in the sections below 👀. The critical requirements are that (1) an endpoint can verify it's connected to the correct Key Distributor for the conference, and (2) the Key Distributor can verify that the endpoint is the correct endpoint for the conference 🫶. Two possible approaches for this are identity assertions and certificate fingerprints 💅.
5.1. Identity Assertions
A WebRTC identity assertion [RFC8827] binds the identity of the endpoint's user to the fingerprint of the DTLS-SRTP certificate used for the call 🪞. That certificate is unique for a given call and conference. Because of that, the Key Distributor can make sure only authorized users join the conference 🚪✅. The Key Distributor can do the same thing in reverse: it creates a WebRTC identity assertion that binds the fingerprint of its unique certificate for this conference, so the endpoint can verify it's talking to the correct Key Distributor 🔐. This setup needs an Identity Provider (IdP) that both the endpoints and the Key Distributor trust 🆔✨
5.2. Certificate Fingerprints in Session Signaling ✨
okay so session signaling entities are generally treated as untrusted in PERC 🙅♀️ but bestie, there are some deployments where parts of the signaling can be trusted enough to swap an entity's certificate fingerprint in a way that can be authenticated 🔐 that's the vibe we're going for!
As a concrete example, SIP [RFC3261] and the Session Description Protocol (SDP) [RFC4566] can carry fingerprint info per [RFC5763] 📞 An endpoint's SIP User Agent sends an INVITE with SDP for the media session plus the endpoint's certificate fingerprint 💌 That fingerprint can be signed using the procedures in [RFC8224], so it can be passed along to other entities by the focus [RFC4353] 🧚 Other entities can check that the fingerprints match the certificates found in the DTLS-SRTP connections, which tells them who the far end of the DTLS-SRTP connection is and whether that's an authorized entity 🕵️♀️ iconic detective work.
Ultimately, if you're using session signaling, an endpoint's certificate fingerprint has to be securely mapped to a user and conveyed to the Key Distributor, so the Key Distributor can check that the user is authorized 👑 Same energy in reverse: the Key Distributor's certificate fingerprint can be conveyed to an endpoint in a way that can be authenticated as an authorized Key Distributor for this conference 🫶
5.3. Conference Identification 🎀
The Key Distributor needs to know which endpoints are being added to a given conference 🧐 So the Key Distributor and the Media Distributor both need endpoint-to-conference mappings, and those are enabled by exchanging a conference-specific unique identifier as described in [PERC-DTLS] 💜 How that unique identifier gets assigned is outside the scope of this document, so that's not our problem today 🙈
6. PERC Keys 🔑
This section describes the various keys employed by PERC. Let's gooo! 💅
6.1. Key Inventory and Management Considerations 🗝️
This section sums up the different keys used in the PERC framework, how they're generated, and what purpose each one serves 🌸
The keys are described in the order you'd typically acquire them 📋
The various keys used in PERC are shown in Table 1 below 👇
+===========+=============================================+
| Key | Description |
+===========+=============================================+
| HBH Key | SRTP master key used to encrypt media hop |
| | by hop. |
+-----------+---------------------------------------------+
| KEK | Key shared by all endpoints and used to |
| (EKT Key) | encrypt each endpoint's E2E SRTP master key |
| | so receiving endpoints can decrypt media. |
+-----------+---------------------------------------------+
| E2E Key | SRTP master key used to encrypt media end |
| | to end. |
+-----------+---------------------------------------------+
Table 1: Key InventoryWhile the number of key types is very small, it should be understood that the actual number of distinct keys can be large as the conference grows in size 📈 the key types are few, but the count can get wild 🤯
As an example, with 1,000 participants in a conference, there would be at least 1,000 distinct SRTP master keys, all of which share the same master salt 🫠 Each of those keys goes through the Key Derivation Function (KDF) as defined in [RFC3711] to produce the actual encryption and authentication keys 🧮
Complicating things is the fact that the KEK can change, and when it does, the endpoints generate new SRTP master keys associated with a new EKT SPI 🌀 Endpoints might hang onto old keys for a while so they can properly decrypt late-arriving or out-of-order packets, which means the number of keys held during that window might be substantially higher 😭 the drama is real
A more detailed explanation of each key follows 🦋
6.2. DTLS-SRTP Exchange Yields HBH Keys 🌈
The first set of keys acquired is for HBH encryption and decryption ✨ Per the double transform procedures [RFC8723], the endpoint does a DTLS-SRTP exchange with the Key Distributor and gets a key that is, in fact, "double" the size it needs 👯 The E2E part is the first half, so the endpoint throws that part away when generating its own key 🗑️ The second half of the keying material is for HBH operations, so that half (the least significant bits) gets assigned internally as the HBH key 💖
The Key Distributor tells the Media Distributor about the HBH key 📣 Specifically, the Key Distributor sends the least significant bits that correspond to the half of the keying material determined through DTLS-SRTP with the endpoint to the Media Distributor 💌 A salt value is generated along with the HBH key, and that salt is also longer than needed for HBH operations, so only the least significant bits of the required length (half of the generated salt material) are sent to the Media Distributor 🧂 One way to transmit this key and salt info is via the tunnel protocol defined in [PERC-DTLS] 🚇
No two endpoints have the same HBH key! So the Media Distributor MUST keep track of each distinct HBH key (and the corresponding salt) and use it only for the specified hop. Don't mix them up, bestie 🙅♀️
The HBH key is also used for HBH encryption of RTCP 🎶 RTCP is not E2E-encrypted in PERC, so keep that in mind 🙈
6.3. The Key Distributor Transmits the KEK (EKT Key) 🔐
The Key Distributor sends the KEK (the EKT Key per [RFC8870]) to the endpoint over the DTLS-SRTP association we already talked about 🫶 This key is known only to the Key Distributor and the endpoints 🤫 It's the single most important thing to protect, because knowing this key (and the SRTP master salt sent in the same message) lets an entity decrypt any media packet in the conference 😱 main villain energy if it leaks
Note that the Key Distributor can send any number of EKT Keys to endpoints 🔄 This info is used to rekey the entire conference. Each key is identified by an SPI value 🏷️ Endpoints MUST expect that a conference might be rekeyed when a new participant joins or when a participant leaves, so the confidentiality of the conversation is protected both before and after those events 🛡️ Rekey, rekey, slay ✨
The SRTP master salt to be used by the endpoint is transmitted along with the EKT Key 🧂 All endpoints in the conference use the same SRTP master salt that corresponds with a given EKT Key 🤝
The Full EKT Tag in media packets is encrypted using a cipher specified via the EKTKey message (for example, AES Key Wrap with a 128-bit key) 🎀 This cipher is different from the one used to protect media, and it's only used to encrypt the endpoint's SRTP master key (and other EKT Tag data as per [RFC8870]) 🧁 two ciphers, two jobs, no mixing!
The KEK is not given to the Media Distributor 🚫 the Media Distributor stays out of the KEK lane entirely
6.4. Endpoints Fabricate an SRTP Master Key 🧪
As stated earlier, the E2E key determined via DTLS-SRTP MAY be discarded in favor of a locally generated E2E SRTP master key 🔁 The DTLS-SRTP-derived SRTP master key can be used at first, but the endpoint might choose to change the SRTP master key periodically, and it MUST change the SRTP master key as a result of the EKT Key changing 🔄 non-negotiable, periodt 💅
A locally generated SRTP master key is used along with the master salt sent to the endpoint from the Key Distributor via the EKTKey message to encrypt media end to end 🔒
Since the Media Distributor isn't involved in E2E functions, it doesn't create this key, and it doesn't have access to any endpoint's E2E key 🙅♀️ Also, even the Key Distributor is unaware of the locally generated E2E keys used by each endpoint 🕶️ nobody sees your E2E key except the people you're sharing with
The endpoint transmits its E2E key to the other endpoints in the conference by periodically including it in SRTP packets in a Full EKT Tag 📦 When it's placed in the Full EKT Tag, it's encrypted using the EKT Key provided by the Key Distributor 🔐 The master salt is not transmitted this way, since all endpoints already get the same master salt via the EKTKey message from the Key Distributor 🧂 The recommended frequency with which an endpoint transmits its SRTP master key is specified in [RFC8870] 📅
6.5. Summary of Key Types and Entity Possession 📊
All endpoints have knowledge of the KEK 👯♀️
Every HBH key is distinct for a given endpoint, so Endpoint A and Endpoint B do not know each other's HBH key 🙅 Since HBH keys are derived from a DTLS-SRTP association, there is at most one HBH key per endpoint 🎯 (The only exception is where the DTLS-SRTP association might be rekeyed per Section 5.2 of [RFC5764] and a new key is created to replace the former key 🔄)
Each endpoint generates its own E2E key (SRTP master key), so there's a distinct E2E key per endpoint 🦄 That key gets sent (encrypted) via the Full EKT Tag to the other endpoints 📨 Endpoints that receive media from a given transmitting endpoint learn the transmitter's E2E key via the Full EKT Tag 🧠
Table 2 summarizes the various keys and which entity has possession of each one 👀
+=======================+============+======+======+============+
| Key/Entity | Endpoint A | MD X | MD Y | Endpoint B |
+=======================+============+======+======+============+
| KEK (EKT Key) | Yes | No | No | Yes |
+-----------------------+------------+------+------+------------+
| E2E Key (A and B) | Yes | No | No | Yes |
+-----------------------+------------+------+------+------------+
| HBH Key (A<=>MD X) | Yes | Yes | No | No |
+-----------------------+------------+------+------+------------+
| HBH Key (B<=>MD Y) | No | No | Yes | Yes |
+-----------------------+------------+------+------+------------+
| HBH Key (MD X<=>MD Y) | No | Yes | Yes | No |
+-----------------------+------------+------+------+------------+
Table 2: Key Types and Entity Possession7. Encrypted Media Packet Format 📦
Figure 4 shows the complete picture of what an encrypted media packet under this framework looks like on the wire 👀 The packet format in the figure is encrypted using the double cryptographic transform, with an EKT Tag appended to the end 🎁
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++
|V=2|P|X| CC |M| PT | sequence number | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| timestamp | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
| synchronization source (SSRC) identifier | IO
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO
| contributing source (CSRC) identifiers | IO
| .... | IO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
| RTP extension (OPTIONAL) ... | |O+>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O I | payload ... | IO
O I | +-------------------------------+ IO
O I | | RTP padding | RTP pad count | IO
O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O | | E2E authentication tag | |O
O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O
O | | OHB ... | |O
+>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+
| | | HBH authentication tag | ||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| | | EKT Tag ... | R ||
| | +-+-+-+-+-+-+-+-+-+ | ||
| | +- Neither encrypted nor authenticated; ||
| | appended after the double transform ||
| | is performed ||
| | ||
| +- E2E-Encrypted Portion E2E-Authenticated Portion ---+|
| |
+--- HBH-Encrypted Portion HBH-Authenticated Portion ----+
I = Inner (E2E) encryption/authentication
O = Outer (HBH) encryption/authenticationFigure 4: Encrypted Media Packet Format 🎀
8. Security Considerations 🔥
8.1. Third-Party Attacks
Okay bestie, third-party attacks are attacks from an adversary who isn't supposed to have keying material, or who is otherwise not an authorized participant in the conference. Not invited, not allowed 🙅♀️
On-path attacks get handled by HBH integrity protection and encryption 🔒. The integrity protection covers packet modification. Encryption makes selectively blocking packets harder, but not impossible 🥲.
Off-path attackers could try connecting to different PERC entities and send super specifically crafted packets to trick the receiver into forwarding or rendering bogus media packets 👀. Endpoints and Media Distributors fight back by doing HBH authentication and tossing any packet that fails 🗑️.
Another vibe: a third party pretending to be a Media Distributor 🎭, tricking endpoints into sending packets to the fake one instead of the real one. The senders might wrongly think their packets reached everyone when they didn't 😵. This is possible, but the result is just a simple denial of service with no leak of confidential information, since the fake Media Distributor doesn't have HBH or E2E encryption keys 🙌.
A third party could also cause a denial of service by flooding receivers with lots of bogus or replayed packets, which slowly degrades conference or device performance. Therefore, implementations might wish to devise mechanisms to guard against this, like rate-limiting or basic sanity checks (e.g., looking at packet length or expected sequence number ranges) before doing the more expensive decryption operations 💪.
Mutual DTLS authentication (as required by DTLS-SRTP) helps too 🛡️. It stops a false endpoint or false Media Distributor from successfully joining as a perceived valid media sender that could otherwise carry out an on-path attack. When mutual authentication fails, a receiving endpoint knows it can safely discard media packets from that endpoint without inspecting them 💅.
8.2. Media Distributor Attacks
A malicious or compromised Media Distributor can attack the session in a bunch of possible ways, as we're about to see 😈.
8.2.1. Denial of Service
The simplest version is discarding received packets that should be forwarded. This solution framework doesn't provide any mitigation for Media Distributors that fail to forward media packets 😤.
Another move is modifying received packets before forwarding them. With this framework, any change to the E2E-authenticated data means the receiving endpoint gets an integrity failure when it authenticates the packet 🚨.
The Media Distributor can also try resource consumption attacks on the receiving endpoint. One example: inserting random SSRC/CSRC values into any RTP packet along with a Full EKT Tag. That triggers the receiver to form a new cryptographic context, so the Media Distributor can try to drain the receiver's resources 🥵. E2E authentication would fail and the cryptographic context would be destroyed, but the key derivation operation would still burn some computational resources. Resource consumption attacks can't be mitigated entirely, though rate-limiting packets might help reduce the impact 🫠.
8.2.2. Replay Attacks
A replay attack is when an already-received packet from a previous point in the RTP stream gets replayed as a new packet. For example, it could let a Media Distributor send a sequence of packets that sound like a user saying "yes", even though the user actually said "no" 😬.
This is mitigated by the requirement to implement replay protection as described in Section 3.3.2 of [RFC3711]. E2E replay protection MUST be provided for the duration of the conference 🔐.
8.2.3. Delayed Playout Attacks
A delayed playout attack is when media gets received and held by a Media Distributor, then forwarded to endpoints later on 🕰️.
This attack is possible even if E2E replay protection is in place. The Media Distributor is allowed to select a subset of streams and not forward the rest to a receiver, like forwarding only the most active speakers, so the receiver has to accept gaps in the E2E packet sequence. The problem is that a Media Distributor can choose not to deliver a particular stream for a while 🙃.
It can purposely stop forwarding media flows, and it can also pick an arbitrary starting point to resume forwarding them, perhaps sending old packets instead of current ones 🫣. So what the media source sent can be substantially delayed at the receiver, who thinks the newly arriving packets are only delayed by transport delay, when they could actually be minutes or hours old ⏳.
This attack can't be eliminated entirely, but its effectiveness can be reduced by rekeying the conference periodically, since significantly delayed media encrypted with expired keys wouldn't be decrypted by endpoints 🔑.
8.2.4. Splicing Attacks
A splicing attack is when a Media Distributor receiving multiple media sources splices one media stream into another 🧵. If it could change the SSRC without the receiver having any way to verify the original source ID, it could first deliver stream A and then later forward stream B under the same SSRC that stream A was using. By including the SSRC in the integrity check for each packet (both HBH and E2E), PERC prevents splicing attacks ✨.
8.2.5. RTCP Attacks
PERC does not provide E2E protection of RTCP messages. That means a compromised Media Distributor can mess with any message sent via RTCP, including media statistics, picture requests, or loss indication 📉. It can also forge requests, like asking the endpoint to send a new picture 📸. Those requests can eat up a lot of bandwidth and seriously impair conference performance 🐢.
8.3. Key Distributor Attacks
As we said in Section 3.2.2, the Key Distributor needs to be secured, because exploiting the Key Server can let an adversary access the keying material for one or more conferences. With that access, the adversary could decrypt media sent from any endpoint in the conference 😱.
As a first line of defense, the Key Distributor authenticates every security association, both with endpoints and with Media Distributors 🪪. It knows which entities are authorized to have which keys, and inspecting certificates will substantially reduce the risk of handing keys to an adversary.
Both physical and network access to the Key Distributor should be severely restricted 🚧. This may be harder to pull off when the Key Distributor is embedded in, for example, an endpoint. Still, consider shielding it from unauthorized access, or from any access that isn't strictly necessary for supporting an ongoing conference.
Think about whether access to the keying material will be needed after the conference ends. If not, the Key Distributor's policy should be to destroy the keying material once the conference concludes, or when the keying material changes during the conference 🗑️. If the keying material is needed beyond the lifetime of the conference, give further thought to protecting it from future exposure. It might seem obvious, but it's worth saying out loud: if an adversary records the media packets sent during a conference and later gains unauthorized access to keying material left unsecured on the Key Distributor, even years later, they could decrypt the content of every packet transmitted during the conference 💀.
8.4. Endpoint Attacks 💅
Okay so a Trusted Endpoint is literally named that because conference confidentiality leans super hard on the security and integrity of the endpoint 🔐. If an adversary successfully exploits a vulnerability in an endpoint, they might be able to grab all of the keying material used in the conference 😭. With that keying material, an adversary could decrypt any of the media flows received from any other endpoint, either in real time or later on (assuming they saved copies of the media packets) 💀.
Also, if an adversary exploits an endpoint, they could inject media into the conference 🙈. For example, they could mess with the RTP or SRTP software to transmit whatever media they want. This could involve reusing the compromised endpoint's SSRC or, since all conference participants share the same KEK, using a brand new SSRC or the SSRC value of another endpoint 🎀. Only a single SRTP cipher suite defined provides source authentication properties that let an endpoint cryptographically assert that it sent a particular E2E-protected packet (that's Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383]), and its usage is presently not defined for PERC 🥲. The suite defined in PERC only lets an endpoint figure out that whoever sent a packet had received the KEK 🔑.
But attacks on the endpoint aren't limited to the PERC-specific software inside it 👀. An attacker could inject or record media by manipulating the software that sits between the PERC-enabled application and the hardware microphone of a video camera, for example 📷. Likewise, an attacker could potentially access confidential media by poking around memory, cache, disk storage, and so on, if the endpoint isn't secured 🚨.
9. IANA Considerations 🌸
This document has no IANA actions. 🥳
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013,
<https://www.rfc-editor.org/info/rfc6904>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
"Double Encryption Procedures for the Secure Real-Time
Transport Protocol (SRTP)", RFC 8723,
DOI 10.17487/RFC8723, April 2020,
<https://www.rfc-editor.org/info/rfc8723>.
[RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
Andreasen, "Encrypted Key Transport for DTLS and Secure
RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021,
<https://www.rfc-editor.org/info/rfc8870>.10.2. Informative References
[PERC-DTLS]
Jones, P. E., Ellenbogen, P. M., and N. H. Ohlmeier, "DTLS
Tunnel between a Media Distributor and Key Distributor to
Facilitate Key Exchange", Work in Progress, Internet-
Draft, draft-ietf-perc-dtls-tunnel-06, 16 October 2019,
<https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-
06>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006,
<https://www.rfc-editor.org/info/rfc4353>.
[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,
DOI 10.17487/RFC4383, February 2006,
<https://www.rfc-editor.org/info/rfc4383>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<https://www.rfc-editor.org/info/rfc6464>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/info/rfc8827>.
[W3C.CR-webrtc]
Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
Real-time Communication Between Browsers", W3C Proposed
Recommendation, <https://www.w3.org/TR/webrtc/>.Acknowledgments 🫶
The authors would like to thank Mo Zanaty, Christian Oien, and Richard Barnes for invaluable input on this document 💜. Also, a big shoutout to Nermeen Ismail for serving on the initial draft versions of this document as a coauthor 🌈. We would also like to acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for providing some of the text in the document, including much of the original text in the Security Considerations section (Section 8) ✨.
Authors' Addresses 🦋
Paul E. Jones
Cisco
7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709
United States of America
Phone: +1 919 476 2048
Email: paulej@packetizer.com
David Benham
Independent
California
United States of America
Email: dabenham@gmail.com
Christian Groves
Independent
Melbourne
Australia
Email: cngroves.std@gmail.com📦 where this page comes from
- ietf: rfc8871 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms