RFC 4567

Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)

📅 published July 2006, from ietf

RFC 4567: Key Management Extensions for SDP and RTSP 🎀

RFC number: 4567
Title: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)
Authors: J. Arkko, F. Lindholm, M. Naslund, K. Norrman (all Ericsson), and E. Carrara (Royal Institute of Technology)
Stream and category: Network Working Group, Standards Track
Date: July 2006
Obsoletes / Updates: the header doesn't list anything it obsoletes or updates

okay bestie this is part 1 of 7, so more is coming 💅

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 🌸

Abstract 🦋

okay so this doc defines general extensions for SDP and RTSP that carry messages from a key management protocol, so the media gets secured. 🔐 It's presented as a framework, which means one or more key management protocols can plug into it. Its use only makes sense when it's paired with a proper key management protocol, so it's not a solo act 💜

It also gives general guidelines for using the framework together with SIP and RTSP. And it defines how it works with the Multimedia Internet KEYing (MIKEY) key management protocol too 🧚

Table of Contents 📚

   1. Introduction ....................................................3
      1.1. Notational Conventions .....................................4
   2. Applicability ...................................................4
   3. Extensions to SDP and RTSP ......................................5
      3.1. SDP Extensions .............................................5
      3.2. RTSP Extensions ............................................6
   4. Usage with SDP, SIP, RTSP, and SAP ..............................7
      4.1. Use of SDP .................................................8
           4.1.1. General Processing ..................................8
           4.1.2. Use of SDP with Offer/Answer and SIP ...............10
           4.1.3. Use of SDP with SAP ................................13
           4.1.4. Bidding-Down Attack Prevention .....................13
      4.2. RTSP Usage ................................................14
   5. Example Scenarios ..............................................17
      5.1. Example 1 (SIP/SDP) .......................................17
      5.2. Example 2 (SDP) ...........................................18
      5.3. Example 3 (RTSP) ..........................................18
      5.4. Example 4 (RTSP) ..........................................20
   6. Adding Further Key Management Protocols ........................21
   7. Integration of MIKEY ...........................................22
      7.1. MIKEY Interface ...........................................22
   8. Security Considerations ........................................23
   9. IANA Considerations ............................................25
      9.1. SDP Attribute Registration ................................25
      9.2. RTSP Registration .........................................26
      9.3. Protocol Identifier Registration ..........................26
   10. Acknowledgements ..............................................27
   11. References ....................................................27
      11.1. Normative References .....................................27
      11.2. Informative References ...................................28

1. Introduction 💖

okay so there's been recent work on a security profile to protect real-time apps running over RTP [SRTP]. But a security protocol needs a key management solution too, to swap keys and security parameters, and to manage and refresh those keys, etc. 🔑

A key management protocol runs before the security protocol does its thing. Its main job is to set up a security association for the security protocol in a secure and reliable way. That includes one or more cryptographic keys plus the rest of the parameters the security protocol needs, like which cipher and authentication algorithms to use. It's kind of giving SIP [SIP] and RTSP [RTSP] vibes, because it negotiates the info needed to set up the session. 🫶

The next sections are all about a new SDP attribute and a new RTSP header extension for key management, and how they fit into SIP and RTSP. The full framework is completed by one or more key management protocols that use these extensions 🦋

Here are some of the reasons to bundle key management into session establishment:

Codec info describes how to encode and decode the audio (or video) stream. Key management data is the same kind of thing, but it describes how to encrypt and decrypt the data. 🎀
You can negotiate security for the whole multimedia session all at once. ✨
Since you know about the media at session setup, it's super easy to tie the key management to the multimedia sessions. 💅
This can be more efficient than setting up security later, because that might force extra roundtrips, and possibly a separate setup for each stream. That means more delay before the media session actually gets going. 😭
You can negotiate keying material end-to-end without applying end-to-end protection to the SDP. Instead, hop-by-hop security mechanisms can be used, which is handy if intermediate proxies need to access the SDP. 🧚

Right now SDP [SDPnew] has one field for transporting keys, the "k=" field. But that's not enough for a key management protocol, since there are way more parameters that need to get carried, and the "k=" field isn't extensible. So the approach is to extend the SDP description with a bunch of attributes that carry the key management offer/answer and also tie it to the media sessions. SIP uses the offer/answer model [OAM], so extending SDP is enough there. RTSP [RTSP] doesn't use the offer/answer model with SDP, though, so a new RTSP header is introduced to carry key management data. 🌈

[SDES] also extends SDP to carry security parameters for the media streams. But the mechanism in [SDES] needs the SDP to be protected end-to-end by some security protocol such as S/MIME, in order to get end-to-end protection. The solution here only focuses on end-to-end protection of the key management parameters, so it doesn't need any external end-to-end protection means. It's important to note, and we'll say it again, that only the key management parameters are protected. 🚨

This document also defines how to use the framework together with the key management protocol Multimedia Internet KEYing (MIKEY) [MIKEY]. 💜

1.1. Notational Conventions 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Applicability 🍓

[SDES] offers similar cryptographic key distribution capabilities, and it's meant for use when the keying material is protected along with the signaling.

This specification is different. It expects endpoints to have preconfigured keys or common security infrastructure. It provides its own security, and it's independent of whatever protection the signaling has (if any). So it can be used in environments where signaling protection isn't turned on, or used hop-by-hop (aka scenarios where the SDP isn't protected end-to-end). Regardless of the signaling protection applied, this specification ensures end-to-end security establishment for the media. 🔥

3. Extensions to SDP and RTSP 🌸

This section describes common attributes that can be included in SDP or RTSP when an integrated key management protocol is used. The attribute values follow the general SDP and RTSP guidelines (see [SDPnew] and [RTSP]).

For both SDP and RTSP, the general method is to add the key management protocol by introducing new attributes: one identifier that names the specific key management protocol, and one data field where that protocol's data goes. The key management protocol data holds the info needed to set up the security protocol, like keys and cryptographic parameters. All parameters and keys are protected by the key management protocol. 🔐

The key management data SHALL be base64 [RFC3548] encoded and SHALL comply with the base64 grammar defined in [SDPnew]. The key management protocol identifier, KMPID, is defined below in Augmented Backus-Naur Form (ABNF) [RFC4234].

   KMPID =  1*(ALPHA / DIGIT)

Values for the identifier, KMPID, are registered and defined according to Section 9. Note that the KMPID is case sensitive, and it is RECOMMENDED that registered values are lowercase letters. ✨

3.1. SDP Extensions 🦋

This section gives an ABNF grammar (as used in [SDPnew]) for the key management extensions to SDP.

The new definitions are compliant with the definition of an attribute field, which looks like this:

   attribute    = (att-field ":" att-value) / att-field

The ABNF for the key management extensions (conforming to the att-field and att-value) goes like this:

      key-mgmt-attribute = key-mgmt-att-field ":" key-mgmt-att-value

      key-mgmt-att-field = "key-mgmt"
      key-mgmt-att-value = 0*1SP prtcl-id SP keymgmt-data

      prtcl-id     = KMPID
                     ; e.g., "mikey"

      keymgmt-data = base64
      SP           = %x20

Here, KMPID is as defined in Section 3 of this memo, and base64 is as defined in SDP [SDPnew]. Prtcl-id refers to the set of values defined for KMPID in Section 9. 💖

The attribute MAY be used at session level, media level, or at both levels. An attribute defined at media level overrides an attribute defined at session level. In other words, if the media-level attribute is present, the session level attribute MUST be ignored for this media. 🙈

Section 4.1 goes into detail about how the attributes are used and how the SDP is handled in different usage scenarios. The choice of level depends on the particular key management protocol, for example. Some protocols might not be able to derive enough key material for all the sessions, and a different protection for each session might be needed. Those protocols can only get that by specifying it at the media level. Other protocols, like MIKEY, can do more: it can express multiple security policies and derive multiple keys, so it can use the session level instead. 👑

3.2. RTSP Extensions ✨

okay so to support the key management attributes, we define this brand new RTSP header 💅

KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec)

key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %x22 URI %x22 ";"]

where KMPID is as defined in Section 3 of this memo, "base64" is as defined in [SDPnew], and URI is as defined in Section 3 of [RFC3986] 🦋

The uri parameter tells you which context the key management data is for, and the RTSP URI SHALL match a (session or media) URI that's already in the session description 🎀 If the RTSP aggregated control URI is included, that means the key management message is at session level (and the RTSP media control URI means it's at media level, same vibe) 🌸 If there's no uri parameter in a key-mgmt-spec, the spec applies to whatever context the RTSP request URI points to ✨

The KeyMgmt header MAY be used in the messages and directions in this table 💖

Method            | Direction  |  Requirement
---------------------------------------------
DESCRIBE response |   S->C     |  RECOMMENDED
SETUP             |   C->S     |  REQUIRED
SETUP Response    |   S->C     |  REQUIRED (error)

Note: Section 4.2 explains in detail how the RTSP extensions get used 🧚

We also define one new RTSP status code to report errors from any failure during key management processing (Section 4.2) 😭

Status-Code  =  "463" ; Key management failure

A 463 response MAY contain a KeyMgmt header with a key management protocol message that tells you more about what went wrong 🙈

4. Usage with SDP, SIP, RTSP, and SAP 🌈

this section is the rulebook for how and when to include the key management attribute when SIP and/or RTSP are used together with SDP 📋

when a key management protocol gets integrated with SIP/SDP and RTSP, these are the general requirements it has to meet:

At the current time, it MUST be possible to execute the key management protocol in at most one request-response message exchange. Future relaxation of this requirement is possible, but it would add a lot of complexity for implementations that support multi-roundtrip mechanisms 💀
It MUST be possible for the SIP/SDP and RTSP application, using the key management API, to receive key management data and find out whether or not a message was accepted 🔥

the content of the key management messages depends on whichever key management protocol is being used. That said, the content might be expected to look roughly like this: the key management Initiator (for example, the offerer) puts the key management data in a first message, which contains the media description it should apply to 👑 This data generally includes the security parameters (including key material) needed to secure the communication, plus the authentication information needed to make sure the message is authentic 🫶

on the Responder's side, the key management protocol checks that the key management message is valid, along with whether the offered parameters are available. Then it provides the key management data to be included in the answer 💜 This answer may typically authenticate the Responder to the Initiator, and it also says whether the initial offer was accepted or not ✨ Some protocols might require the Responder to include a selection of the security parameters it's willing to support 🌸 Again, what the actual content of these responses looks like depends on the particular key management protocol 💅

Section 7 describes a realization of the MIKEY protocol using these mechanisms 🦋 Procedures for mapping new key management protocols onto this framework are described in Section 6 🎀

4.1. Use of SDP

this section describes the processing rules for the different applications that use SDP for key management 🌷

4.1.1. General Processing

the processing when SDP is used is slightly different depending on how SDP is transported, and on whether it uses an offer/answer or an announcement 🧁 The processing can be split into four steps:

How to create the initial offer.
How to handle a received offer.
How to create an answer.
How to handle a received answer.

It's worth noting that the last two steps may not always apply, because there are cases where an answer cannot or will not be sent back 🙃

the general processing for creating an initial offer SHALL follow these actions:

The identifier of the key management protocol used MUST be placed in the prtcl-id field of SDP. IANA maintains a table of legal protocol identifiers (see Section 9) 📚
The keymgmt-data field MUST be created like this: the key management protocol MUST be used to create the key management message. This message SHALL be base64 encoded [RFC3548] by the SDP application and then encapsulated in the keymgmt-data attribute. Note though that what the encapsulated message means depends on the key management protocol being used 🫧

the general processing for handling a received offer SHALL follow these actions:

The key management protocol is identified according to the prtcl-id field. IANA maintains a table of legal protocol identifiers (Section 9) 🔍
The key management data from the keymgmt-data field MUST be extracted, base64 decoded to rebuild the original message, and then passed to the key management protocol for processing. Depending on the key management protocol, some extra parameters might also be requested by the specific API, such as the source/destination network address/port(s) for the specified media (though this is implementation specific and depends on the actual API) 🌈 Any extra parameters a key management protocol might need (other than the ones defined here) MUST be documented, describing their use, as well as how that key management protocol interacts with SDP and RTSP 📝
If errors occur, or the key management offer is rejected, the session SHALL be aborted. Which error messages are possible depends on the specific session establishment protocol 🚫

At this stage, the key management will have either accepted or rejected the offered parameters. This MAY cause a response message to be generated, depending on the key management protocol and the application scenario 💭

If an answer is going to be generated, the following general actions SHALL be performed:

The identifier of the key management protocol used MUST be placed in the prtcl-id field. 🏷️
The keymgmt-data field MUST be created like this. The key management protocol MUST be used to create the key management message. This message SHALL be base64 encoded [RFC3548] by the SDP application and then encapsulated in the keymgmt-data attribute. The meaning of the encapsulated message depends on the key management protocol being used 🎀

the general processing for handling a received answer SHALL follow these actions:

The key management protocol is identified according to the prtcl-id field. 🔎
The key management data from the keymgmt-data field MUST be extracted, base64 decoded to rebuild the original message, and then passed to the key management protocol for processing. 🧩
If the key management offer is rejected and the intent is to re-negotiate it, it MUST be done through another Offer/Answer exchange. It is RECOMMENDED to NOT abort the session in that case, and to re-negotiate using another Offer/Answer exchange instead 🔄 For example, in [SIP], the "security precondition" defined in [SPREC] solves the problem for session initiation. The procedures in [SPREC] are outside the scope of this document. In an established session, an additional Offer/Answer exchange using a re-INVITE or UPDATE, as appropriate, MAY be used 🦋
If errors occur, or the key management offer is rejected and there's no intent to re-negotiate it, the session SHALL be aborted. If possible, an error message indicating the failure SHOULD be sent back 🥺

Otherwise, if all the steps succeed, the normal setup proceeds 🥳

4.1.2. Use of SDP with Offer/Answer and SIP

Okay bestie, this part is only for apps using SDP with the offer/answer model [OAM] (aka SIP, and yes that's the main character 💅). It adds extra rules on top of the general stuff from Section 4.1.1 ✨

When an initial offer gets created, this offer/answer-specific procedure SHALL be applied:

Before creating the key management data field, the list of protocol identifiers MUST be provided by the SDP application to (each) key management protocol, as defined in Section 4.1.4 (to defeat bidding-down attacks) 🛡️

For a received SDP offer that has the key management attributes, this procedure SHALL be applied:

Before, or in conjunction with, passing the key management data to the key management protocol, the SDP application gives the key management protocol the complete list of protocol identifiers from the offer message (as defined in Section 4.1.4) 🫶

When an answer gets created, this offer/answer-specific procedure SHALL be applied:

If the key management rejects the offer and the intent is to re-negotiate it, the Answer SHOULD include the cause of failure in an included message from the key management protocol. The renegotiation MUST be done through another Offer/Answer exchange (e.g., using [SPREC]). In an established session, it can also be done through a re-INVITE or UPDATE as appropriate 🔁
If the key management rejects the offer and the session needs to be aborted, the answerer SHOULD return a 488 Not Acceptable Here message, optionally also including one or more Warning headers (a 306 Attribute not understood when one of the parameters is not supported, and a 399 Miscellaneous warning with arbitrary information to be presented to a human user or logged; see Section 20.43 in [SIP]). Further details about the cause of failure MAY be described in an included message from the key management protocol. The session is then aborted, and it's up to local policy or the end user to decide how to continue 💀

Quick note bestie: the key management attribute for the same key management protocol MAY be present both at session level and at media level 👀. So the process SHALL be repeated for each such key management attribute detected. If key management processing of any such attribute doesn't succeed (e.g., authentication failure, parameters not supported, etc.), on either session or media level, the entire session setup SHALL be aborted, including those parts of the session that already finished their part of the key management. Not a vibe 😭

If more than one key management protocol is supported, multiple instances of the key management attribute MAY be included in the initial offer when using the offer/answer model. Each one transports a different key management protocol, which shows the supported alternatives 🌈

If the offerer includes more than one key management protocol attribute at session level (the same goes for media level), these SHOULD be listed in order of preference, with the first one being the preferred 👑. The answerer picks the key management protocol it wants to use and only processes that one, on either session or media level, or on both, depending on where it's located. If the answerer doesn't support any of the offerer's suggested key management protocols, it tells the offerer so a new Offer/Answer can be triggered. Otherwise, it may return a 488 Not Acceptable Here error message, and then the sender MUST abort the current setup procedure 🙅‍♀️

Note that putting multiple key management offers in one message has a downside: the message gets bigger and the computational workload for the offerer goes up drastically 📈. Unless the guidelines of Section 4.1.4 are followed, multiple lines may open up bidding-down attacks. Also, the multiple-offer option was added to optimize signaling overhead for when the Initiator knows some key (e.g., a public key) that the Responder has, but isn't sure which protocol the Responder supports. It is not meant to negotiate options within one and the same protocol 🧚

The offerer MUST include the key management data within an offer that contains the media description it applies to 🎀

Re-keying MUST be handled as a new offer, with the new proposed parameters. The answerer treats this as a new offer where key management is the thing that changed. The re-keying exchange MUST be finalized before the security protocol can change the keys. The same key management protocol used in the original offer SHALL also be used in the new offer carrying re-keying. If the new offer carrying re-keying fails (e.g., the authentication verification fails), the answerer SHOULD send a 488 Not Acceptable Here message, including one or more Warning headers (at least a 306). The offerer MUST then abort the session. Yikes, big drama 😭

Note that in multicast scenarios, unlike unicast, there is only a single view of the stream [OAM], so there MUST be a uniform agreement of the security parameters 🦋

After the offer is issued, the offerer SHOULD be prepared to receive media, since the media may arrive before the answer. But this brings issues, because the offerer doesn't know yet the answerer's choice in terms of, e.g., algorithms, or maybe the key is already known. This can cause delay, or clipping can occur. If that's unacceptable, the offerer SHOULD use mechanisms outside the scope of this document, e.g., the security preconditions for SIP [SPREC] ✨

4.1.3. Use of SDP with SAP

There are cases where SDP gets used without the offer/answer model. Instead, it's a one-way SDP distribution (i.e., no back channel), like when it's used with SAP and HTTP 📻

The processing follows the first two steps of the general SDP processing (see Section 4.1.1). The difference from the offer/answer case is that only one key management protocol SHALL be offered, so no negotiation is possible 🙅‍♀️. That means the bidding-down attack isn't an issue, so the countermeasure isn't needed. The key management protocol used MUST support one-way messages 💜

4.1.4. Bidding-Down Attack Prevention

Supporting multiple key management protocols can, unless it's handled properly, introduce bidding-down attacks. Specifically, a man-in-the-middle could "peel off" cryptographically strong offers (deleting the key management lines from the message), leaving only weaker ones for the Responder to choose from 😤. To avoid this, the list of identifiers of the proposed key management protocols MUST be authenticated. The authentication MUST be done separately by each key management protocol.

So it MUST be specified (in the key management protocol specification itself or in a companion document) how the list of key management protocol identifiers can be processed so it gets authenticated from the offerer to the answerer by that specific key management protocol 🔐. Note that even if only one key management protocol is used, that protocol still MUST authenticate its own protocol identifier.

The list of protocol identifiers MUST then be given to each of the selected (offered) key management protocols by the application, with ; separated identifiers. All the offered protocol identifiers MUST be included, in the same order as they appear in the corresponding SDP description 🍓

The protocol list can formally be described as:

prtcl-list   =  KMPID *(";" KMPID)

where KMPID is as defined in Section 3.

For example, say the offered protocols are MIKEY and two yet-to-be-invented protocols, KEYP1 and KEYP2. The SDP looks like this:

v=0
o=alice 2891092738 2891092738 IN IP4 lost.example.com
s=Secret discussion
t=0 0
c=IN IP4 lost.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD...
a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD...
m=audio 39000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 42000 RTP/SAVP 31
a=rtpmap:31 H261/90000

The protocol list, "mikey;keyp1;keyp2", would be generated from that SDP description and used as input to each specified key management protocol (together with the data for that protocol). Each of the three protocols includes this protocol identifier list in its authentication coverage, according to its protocol specification 🧁

If more than one protocol is supported by the offerer, it is RECOMMENDED that all acceptable protocols are included in the first offer, rather than making single, subsequent alternative offers in response to error messages. See "Security Considerations" 🌸

End-to-end integrity protection of the key-mgmt attributes altogether, provided externally to the key management itself, also protects against this bidding-down attack. This is, for example, the case if SIP uses S/MIME [RFC3851] to end-to-end integrity protect the SDP description. However, since this end-to-end protection is not an assumption of the framework, the mechanisms defined in this section SHALL be applied 🦄

4.2. RTSP Usage 🎀

okay so RTSP doesn't do the offer/answer model like SIP does 🙈 which is kinda a problem, because (without changing RTSP itself) there's no way to send an answer back. so a brand new header got introduced to fix that (Section 3.2) ✨. this also assumes the key management is somehow bound to the media, so the server's response actually gets processed the way it should 💅

The server SHALL be the Initiator of the key management exchange for sessions in PLAY mode, i.e., transporting media from server to client 🎬. everything below describes PLAY mode. for any other mode, this specification doesn't define the behavior 🙅‍♀️

to get a session description, the client first reaches out to the server with a DESCRIBE message. the first key management message from the RTSP server rides along in the SDP inside the 200 OK response to that DESCRIBE 📩. heads up, only one key management protocol SHALL be used per session/media level 🔑. a server MAY let the SDP with its key management attribute(s) reach the client through other means than RTSP, but that's not specified here, so don't come for me on it 🫶

the uri parameter of the KeyMgmt header tells the key management protocol what context the carried message applies to 🧚. for key management messages on the SDP session level, the answer MUST contain the RTSP aggregated control URL to show that. for key management messages that start out on the SDP media level, the key management response in the KeyMgmt header MAY use the RTSP media-level URL 🍓. for RTSP sessions that aren't using aggregated control (so there's no session-level control URI defined at all), the key management protocol SHALL only be invoked on individual media streams 🎀. and in that case too, the key management response SHALL be on individual media streams, meaning one RTSP key management header per media 🌈

when the client responds to that initial key management message, it uses the new RTSP header (KeyMgmt) to send back an answer 💌. how that works depends on the usage context:

key management responses for the initial establishment of security parameters for an aggregated RTSP session SHALL be sent in the first SETUP of the session ✨. so if key management is declared for the whole session but gets set up in a non-aggregated way (one media per RTSP session), each SETUP MUST carry the same response for the session-level context 🙈. when setting up the second or any later media in an RTSP session, the same key management parameters that were established for the first media also apply to those setups 💜
key management responses for the initial establishment of security parameters for an individual media SHALL only be included in SETUP for the corresponding media stream 🦋

if a server gets a SETUP message where it expects a key management message but none is included, a "403 Forbidden" SHOULD be returned to the client 💀, and the current setup MUST be aborted 🛑

when the server creates an initial SDP message, the procedure SHALL be the same as described in Section 4.1.1 📝. the client's processing of that initial SDP message from the server SHALL follow the same procedures as Section 4.1.1, with one twist: if there's an error, the session is aborted and no error gets sent back 🫣

the client SHALL create the response using the key management header in RTSP, like this 🛠️:

the identifier of the key management protocol used (e.g., MIKEY) MUST be placed in the prot field of the header. the prot values are maintained by IANA (Section 9) 🌸
the keymgmt-data field MUST be created as follows: the key management protocol MUST be used to create the key management message. this message SHALL be base64 encoded by the RTSP application and then encapsulated in the data field of the header 🔐. what the encapsulated message means depends on the key management protocol being used 🧠
include the URL to indicate the context in the uri parameter, if necessary 🔗

the server SHALL process a received key management header in RTSP as follows 🖥️:

the key management protocol is identified according to the prot field 🏷️
the key management data from the data field MUST be extracted, base64 decoded to reconstruct the original message, and then passed to the key management protocol for processing 📦
if the key management protocol succeeds, processing can carry on according to the normal rules ✅
otherwise, if key management fails (e.g., due to an authentication failure or a parameter that isn't supported), an error is sent back as the SETUP response using RTSP error code 463 (see Section 3.2), and the session is aborted 😭. it's up to the key management protocol to specify (within the RTSP status code message or through key management messages) the details about what kind of error happened 🔍

re-keying within RTSP is for further study, since the media updating mechanisms within RTSP were unspecified when this document was written ⏳

5. Example Scenarios 🌸

the following examples use MIKEY [MIKEY] as the key management protocol to be integrated into SDP and RTSP 🧁

5.1. Example 1 (SIP/SDP)

okay so a SIP call is happening between Alice and Bob 📞. Alice sends an INVITE with this offer:

v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyONQ6gAAAAAGEEoo2pee4hp2
UaDX8ZE22YwKAAAPZG9uYWxkQGR1Y2suY29tAQAAAAAAAQAk0JKpgaVkDaawi9whVBtBt
0KZ14ymNuu62+Nv3ozPLygwK/GbAV9iemnGUIZ19fWQUOSrzKTAv9zV
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000

so Alice is proposing one audio stream and one video stream, both running over SRTP (that's the SAVP profile giving it away 🔐). she uses MIKEY to set up the security parameters for SRTP (Section 7) 🗝️. the MIKEY message carries the security parameters along with the key material it needs. MIKEY is exchanging the crypto suite for both streams, since it's placed at the session level 🫶. MIKEY also provides its own security, so when Bob processes Alice's MIKEY message, he'll also find the signaling of the security parameters used to secure the MIKEY exchange itself 🤯. Alice's authentication information is carried inside the MIKEY message too, to prove the message is authentic 🪪. the MIKEY message above is an example of the pre-shared method being used 🎀

when Bob gets the offer, he checks that the MIKEY message is valid. if the verification works, he accepts the offer and sends an answer back to Alice, complete with his authentication information and, if needed, some key material from his side 💖:

v=0
o=bob 2891092897 2891092897 IN IP4 foo.example.com
s=Cool stuff
e=bob@foo.example.com
t=0 0
c=IN IP4 foo.example.com
a=key-mgmt:mikey AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6gAAAAAJAAAQbWlja2
V5QG1vdXNlLmNvbQABn8HdGE5BMDXFIuGEga+62AgY5cc=
m=audio 49030 RTP/SAVP 98
a=rtpmap:98 AMR/8000
m=video 52230 RTP/SAVP 31
a=rtpmap:31 H261/90000

once Alice gets the answer, she verifies it's correct 🔍. if that succeeds, Alice and Bob now share the security parameters and the keys they need for secure RTP communication 🥳✨

5.2. Example 2 (SDP)

this one shows what Alice would have done if she only wanted to protect the audio stream 🎧. she'd put the MIKEY line at the media level for the audio stream only (and specify the SRTP profile there too, SAVP). the MIKEY messages mean the same thing as in the previous example, but they only apply to the audio stream 🎶

v=0
o=alice 2891092738 2891092738 IN IP4 w-land.example.com
s=Cool stuff
e=alice@w-land.example.com
t=0 0
c=IN IP4 w-land.example.com
m=audio 49000 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=video 52230 RTP/AVP 31
a=rtpmap:31 H261/90000

Bob then acts like in the previous example, including the MIKEY answer at the media level for the audio stream (just like Alice did) 🫡

the key management attribute could be specified at the session level, but the video part wouldn't be affected by it. a security profile isn't used there, since the RTP/AVP profile is signaled instead 🙅‍♀️

5.3. Example 3 (RTSP)

a client wants to set up a streaming session, so it asks the streaming server for a media description 🎥

DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp
From: user@example.com

the server sends back an OK message with an SDP description plus the MIKEY message. the MIKEY message has the security parameters the server is willing to offer the client, along with authentication information (to prove the message is authentic) and the key material. the SAVP profile also signals that SRTP is used to secure the media sessions 🔒

RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 478

v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy...
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=control:rtsp://movie.example.com/action/video

the client checks that the MIKEY message is valid, and if the verification works, it accepts the message 🙌. then it includes its key management data in the SETUP request going back to the server, plus its authentication information (to prove the message is authentic) and, if necessary, some key material 💜

SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action";
         data="AQEFgM0XflABAAAAAAAAAAAAAAYAyONQ6g..."

the server processes the request, including checking that the key management header is valid 🖥️

RTSP/1.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057;
                      server_port=5000-5001

so the key management line was specified at the session level, but the key management information only goes into the SETUP for the first stream 🎯. the uri tells the server that the context covers the whole aggregated session the key management applies to 🧚. the RTSP client then goes on to set up the second media (video) in aggregation with the audio 🎞️. because the two media run in aggregation and the key context was established in that first exchange, no more key management messages are needed 🌈💅

5.4. Example 4 (RTSP) 🎀

okay so this one is the MIKEY message showing up at the media level instead of the session level, and it changes the last example a bit 🦋

The 200 OK now carries two separate SDP attributes for MIKEY, one under each media line:

RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 561

v=0
o=actionmovie 2891092738 2891092738 IN IP4 movie.example.com
s=Action Movie
e=action@movie.example.com
t=0 0
c=IN IP4 movie.example.com
a=control:rtsp://movie.example.com/action
m=audio 0 RTP/SAVP 98
a=rtpmap:98 AMR/8000
a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/audio
m=video 0 RTP/SAVP 31
a=rtpmap:31 H261/90000
a=key-mgmt:mikey AQAFgM0AdlABAAAAAAAAAAAAA...
a=control:rtsp://movie.example.com/action/video

Then the RTSP header goes into each SETUP separately, one for audio and one for video 💖

SETUP rtsp://movie.example.com/action/audio RTSP/1.0
CSeq: 313
Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/audio";
         data="AQEFgM0XflABAAAAAAAAAAAAA..."

and the video session does the same thing:

SETUP rtsp://movie.example.com/action/video RTSP/1.0
CSeq: 315
Transport: RTP/SAVP/UDP;unicast;client_port=3058-3059
keymgmt: prot=mikey; uri="rtsp://movie.example.com/action/video";
         data="AQEFgM0AdlABAAAAAAAAAAAAAA..."

Note: the uri parameter could be left out of the two SETUP messages in this example. ✨

6. Adding Further Key Management Protocols ✨

Okay, so this framework can't be used with every key management protocol 🙈 The key management protocol has to meet the requirements in Section 4. On top of that, a few things need to be defined:

The key management protocol identifier that gets used as the protocol identifier should be registered at IANA, according to Section 9.
The information the key management needs from SDP and RTSP, and the other way around, is described in Section 4. The exact API is implementation specific, but it MUST at least support the exchange of the specified information.
The key management protocol being added MUST be such that the processing in Section 4 (which describes its interactions with SDP and RTSP) can be applied. Section 4.1.4 is the one to watch here, since it requires each key management protocol to specify how the list of protocol identifiers is authenticated inside that key management protocol. The key management MUST always be given the protocol identifier(s) of the key management protocol(s) included in the offer, in the correct order as they appear.

Finally, it is obviously crucial to analyze any possible security implications that come with adding a new key management protocol to this framework 😭🔥

Right now, the MIKEY protocol [MIKEY] has the key management extensions that work with SIP and RTSP (see Section 7). Other protocols MAY use the described attribute and header, for example Kerberos [KERB], but that is subject to future standardization 🌈

7. Integration of MIKEY 🦋

[MIKEY] describes a key management protocol for real-time applications, covering both peer-to-peer communication and group communication 💜 MIKEY carries the security parameters needed to set up the security protocol (for example SRTP) that protects the media stream. It can be integrated with SDP and RTSP by following the rules and guidelines in this document.

MIKEY satisfies the requirements in Section 4. The MIKEY message is formed as defined in [MIKEY], then passed from MIKEY to the SDP application, which base64 encodes it and wraps it in the keymgmt-data attribute. The examples in Section 5 use MIKEY, and they briefly explain what the exchange means too ✨

The key management protocol identifier (KMPID) that gets used as the protocol identifier SHALL be "mikey", and it is registered at IANA. See Section 9 for details 🎀

The information the key management needs from SDP and RTSP, and the other way around, follows Section 4. To avoid bidding-down attacks, the directives in Section 4.1.4 are followed. The list of protocol identifiers is authenticated within MIKEY by putting the list in a General Extension Payload (of type "SDP IDs", [MIKEY]). That payload then automatically gets integrity protected and signed. The receiver SHALL then match the list in the General Extension Payload against the list included in SDP. If they differ, or if integrity/signature verification fails, the receiver SHOULD (according to policy) reject the offer 🙅‍♀️

The server needs to know the identity of the client before it can create and send a MIKEY message. To tell the server the client's (MIKEY) identity in the DESCRIBE, it is RECOMMENDED to include the From header field in RTSP. Other ways to establish the identity could be using the IP address, or getting the identity from RTSP authentication if that's being used 💅

7.1. MIKEY Interface 🌸

Okay this subsection covers some things implementers SHOULD consider. If the MIKEY implementation is separate from the SDP/SIP/RTSP, then an application programming interface (API) is needed between MIKEY and those protocols with certain functionality. (Exactly what it looks like depends on the implementation.)

Here's what needs to be considered:

The possibility for MIKEY to receive information about the sessions that were negotiated. This is partly implementation dependent. It is RECOMMENDED that, for SRTP streams, the number of SRTP streams is included (along with their direction). It is also RECOMMENDED to provide the destination addresses and ports to MIKEY. When referring to streams described in SDP, MIKEY SHALL allocate two consecutive numbers for the related Crypto Session indexes, since each stream can be bi-directional. For example, if the SDP contains two m lines (in whatever direction the streams go) and MIKEY is at the session level, then MIKEY allocates, for instance, the Crypto Sessions Identifiers (CS IDs; see [MIKEY]) '1' and '2' for the first m line, and '3' and '4' for the second m line 🧚
The possibility for MIKEY to receive incoming MIKEY messages and return a status code from or to the SIP/RTSP application.
The possibility for the SIP or RTSP applications to receive information from MIKEY. This would typically include receiving the Crypto Session Bundle Identifier (CSB ID; see [MIKEY], so the active MIKEY session can be identified later), along with the SSRCs and the rollover counter (ROC; see [SRTP]) for SRTP usage. It is also RECOMMENDED that extra information about errors can be received 💀
The possibility for the SIP or RTSP application to receive outgoing MIKEY messages.
The possibility to tear down a MIKEY CSB. For example, if the SIP session is closed, the CSB SHOULD also be closed 🫶

8. Security Considerations 🔐✨

okay bestie, the whole point of this framework is to hand over the security parameters for end-to-end protection of the media session 🔐. It's also good practice to secure the session setup itself (SDP, SIP, RTSP, SAP) 💅. Sometimes though, the setup can only be protected hop-by-hop and not end-to-end 😬. SIP is a good example: intermediate proxies need to see part of the SIP message, and sometimes the SDP description too (see [E2M]), even though end-to-end confidentiality can hide bodies from middlemen 🙈. General security stuff for the setup lives in [SDPnew], [SIP], and [RTSP]. This framework is super useful when the setup isn't protected end-to-end but the media streams still need to be, so the keys and other security params aren't revealed to or messed with by intermediaries 🫶.

Security also depends on how strong the key management protocol is 💪. If we assume the key management schemes are secure, the SDP can be passed along unencrypted without messing up key management, and the media streams stay secure even if some attackers know what's in the SDP 🦋. Further security considerations are found for each key management protocol (for MIKEY, check [MIKEY]) 🌸. BUT if the SDP messages aren't integrity protected between the parties, an active attacker can change attributes without anyone noticing 😭. The key management protocol might indirectly rely on some session info from SDP (like address information), so an attack on SDP can have indirect consequences for key management 💀. Even if key management doesn't rely on SDP parameters and isn't affected by changes to them, denial-of-service (DoS) attacks aimed at SDP can still cause undesired interruptions in the setup 🙅‍♀️. See also the attacks described at the end of this section 👀.

Here's the tea 🍵: in this framework, the only integrity-protected attribute of the media stream is the set of key management protocols. That means an attacker could (1) swap key management offers across SDP messages, or (2) inject a previous key management offer into a new SDP message 😱. Assuming all the involved key management protocols are secure, the second attack gets caught by the replay protection mechanisms of the key management protocol(s) 🛡️. Assuming further that, following normal best current practice, each key management offer is made with independent (pseudo)random choices (for session keys and other parameters), the first attack will either get caught in the Responder's (now incorrect) verification reply message (if one is used) or just be a pure DoS attack, leaving the Initiator and Responder using different keys 💔.

It is RECOMMENDED for the identity at the SPD level to be the one authenticated at the key management protocol level 🪪. Privacy aspects might need to be considered here too, but those are out of scope for this framework 🙈.

Using multiple key management protocols in the same offer might open up a bidding-down attack, as specified in Section 4.1.4 📉. To exclude that possibility, the authentication of the protocol identifier list is used 🔒. Be aware though: the security level of the authenticated protocol identifier will be as high (or low) as the "weakest" protocol 😬. So the offer MUST NOT contain any security protocols (or configurations thereof) weaker than permitted by local security policy 🚫.

Now for the declined offers drama 🎭. It's impossible to ensure the authenticity of a declined offer, because even if it comes from the true respondent, the answerer declining usually means they don't support the protocol(s) offered, so they can't really be expected to authenticate the response either 🤷‍♀️. That means if the Initiator isn't sure which protocol(s) the Responder supports, we RECOMMEND that the Initiator offers all acceptable protocols in a single offer 🍓. If not, a "man-in-the-middle" (MITM) could mess with the outcome of the eventually agreed-upon protocol by faking unauthenticated error messages until the Initiator offers a protocol "to the liking" of the MITM 😤. It's not really a security problem, more of a mild form of denial of service, and following the recommendation above avoids it ✨. Also, the declined offer could be the result of an attacker sitting on the path and removing all the key management offers 🕵️‍♀️. The bidding-down attack prevention described above wouldn't work in that case, since the answerer receives no key management attribute 😩. Here, too, it's impossible to ensure the authenticity of a declined offer, and the reason this time is the "peeling-off" attack 🍌. It's up to local policy to decide what happens when the response declines any security (so there's no way to authenticate it) 📋. For example, if local policy requires a secure communication and can't accept an unsecured one, then the session setup SHALL be aborted 🛑.

9. IANA Considerations 🗂️

9.1. SDP Attribute Registration

The IANA has created a new subregistry for the purpose of key management protocol integration with SDP 🎀.

   SDP Attribute Field ("att-field"):

     Name:               key-mgmt-att-field
     Long form:          key management protocol attribute field
     Type of name:       att-field
     Type of attribute:  Media and session level
     Purpose:            See RFC 4567, Section 3.
     Reference:          RFC 4567, Section 3.1
     Values:             See RFC 4567, Sections 3.1 and 9.3.

9.2. RTSP Registration

The IANA has created a new subregistry for the purpose of key management protocol integration with RTSP 🌈. Following the guidelines of [RTSP], the registration is defined as follows 📝:

   Header name:      keymgmt
   Header syntax:    see RFC 4567, Section 3.2
   Intended usage:   see RFC 4567, Section 3.2
   Proxy treatment:  Proxies SHALL NOT add, change, or delete the
                      header.  The proxy does not need to read this
                      header.
   Purpose:          see RFC 4567, Section 3

The RTSP Status-Code "463" (RFC 4567), with the default string "Key management failure", needs to be registered 🚨.

9.3. Protocol Identifier Registration

This document defines one new name space, the "SDP/RTSP key management protocol identifier" 🧚, associated with the protocol identifier, KMPID, defined in Section 3, to be used with the above registered attributes in SDP and RTSP 💜.

The IANA has created a new subregistry for the KMPID parameter, with the following registration created initially: "mikey" 🦋.

   Value name:     mikey
   Long name:      Multimedia Internet KEYing
   Purpose:        Usage of MIKEY with the key-mgmt-att-field
                    attribute and the keymgmt RTSP header
   Reference:      Section 7 in RFC 3830

Note that this registration means the protocol identifier, KMPID, name space will be shared between SDP and RTSP 🤝.

Further values may be registered according to the "Specification Required" policy as defined in [RFC2434] 📚. Each new registration needs to indicate the parameter name and register it with IANA. The parameter name is case sensitive, and it is RECOMMENDED that the name be in lowercase letters 🔡. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter and the requested details of interaction between the key management protocol and SDP, as specified in RFC 4567 🫶.

New values MUST be registered with IANA 📬. Registrations SHALL include the following information 💅:

Contact: the contact name and email address
Value name: the name of the value being registered (which MUST comply with the KMPID as defined in Section 3)
Long Name: long-form name in English
Purpose: short explanation of the purpose of the registered name.
Reference: a reference to the specification (e.g., RFC number) providing the usage guidelines in accordance to Section 6 (and also complying to the specified requirements).

10. Acknowledgements 💖

The authors would like to thank Francois Audet, Rolf Blom, Johan Bilien, Magnus Brolin, Erik Eliasson, Martin Euchner, Steffen Fries, Joerg Ott, Jon Peterson, and Jon-Olov Vatn 🙌. A special thanks to Colin Perkins and Magnus Westerlund, who contributed in many sections 👑.

11. References 📖

11.1. Normative References

[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.

[OAM] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.

[SDPnew] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

11.2. Informative References

[E2M] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)", RFC 4189, October 2005.

[KERB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[SDES] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.

[SPREC] Andreasen, F., Baugher, M., and Wing, D., "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005.

[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

Authors' Addresses 💌

okay bestie, here are the girls (and guys) behind the doc, with their contact deets 🫶

Jari Arkko 🦋
- Ericsson
- 02420 Jorvas
- Finland
- Phone: +358 40 5079256
- EMail: jari.arkko@ericsson.com
Elisabetta Carrara 🌸
- Royal Institute of Technology
- Stockholm
- Sweden
- EMail: carrara@kth.se
Fredrik Lindholm 🎀
- Ericsson
- SE-16480 Stockholm
- Sweden
- Phone: +46 8 58531705
- EMail: fredrik.lindholm@ericsson.com
Mats Naslund 💜
- Ericsson Research
- SE-16480 Stockholm
- Sweden
- Phone: +46 8 58533739
- EMail: mats.naslund@ericsson.com
Karl Norrman 🧚
- Ericsson Research
- SE-16480 Stockholm
- Sweden
- Phone: +46 8 4044502
- EMail: karl.norrman@ericsson.com

Full Copyright Statement 📜

This doc is still under the rights, licenses and restrictions in BCP 78. Except for what that says, the authors keep all their rights 🔒

Now the legal bit, and it's giving serious energy 😭 The doc and everything in it is handed over "AS IS", with no promises. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any promise that using the info won't infringe anyone's rights, and any implied warranties of merchantability or fitness for a particular purpose. Nobody is promising it'll be perfect, periodt 💀

Intellectual Property 🔐

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or how far they reach. It also doesn't say whether a license for those rights is available. It hasn't tried to find any of these rights either, so don't assume it did 🙈 If you want the rules on rights for RFC docs, check BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat are on the IETF online IPR repository at http://www.ietf.org/ipr. You'll also find any licensing assurances there, plus results from anyone trying to get a general license or permission for implementers or users to use these proprietary rights.

The IETF also invites anyone to flag any copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard. Send that info to ietf-ipr@ietf.org 🫶

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you're literally the MVP ✨👑

📦 where this page comes from

ietf: rfc4567 2006-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms