RFC 4568
Session Description Protocol (SDP) Security Descriptions for Media Streams
RFC 4568 💖 (Part 1 of 10)
Okay bestie, let's start with the basics 🎀. This is RFC 4568, Session Description Protocol (SDP) Security Descriptions for Media Streams. It came out in July 2006 from the Network Working Group, written by F. Andreasen, M. Baugher, and D. Wing at Cisco Systems. It's in the Standards Track category ✨. The title block doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any earlier RFC listed there 🫶.
Status of This Memo 📜
This is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 💬. If you want the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice ⚖️
Copyright (C) The Internet Society (2006).
Abstract 🦋
So the big idea is this: the doc defines an SDP cryptographic attribute for unicast media streams 💜. That attribute describes a cryptographic key and other parameters used to set up security for a unicast media stream, either in a single message or in a roundtrip exchange ⭐. It can be used with a bunch of SDP media transports, and this doc spells out how to use it for Secure Real-time Transport Protocol (SRTP) unicast media streams 🔥. The SDP crypto attribute also needs a data security protocol to secure the SDP message itself 🙈.
Table of Contents 🍓
1. Introduction ....................................................3
2. Notational Conventions ..........................................5
3. Applicability ...................................................5
4. SDP "Crypto" Attribute and Parameters ...........................5
4.1. Tag ........................................................6
4.2. Crypto-Suite ...............................................6
4.3. Key Parameters .............................................7
4.4. Session Parameters .........................................8
4.5. Example ....................................................8
5. General Use of the crypto Attribute .............................9
5.1. Use with Offer/Answer ......................................9
5.1.1. Generating the Initial Offer - Unicast Streams ......9
5.1.2. Generating the Initial Answer - Unicast Streams ....10
5.1.3. Processing of the Initial Answer - Unicast
Streams ............................................11
5.1.4. Modifying the Session ..............................11
5.2. Use Outside Offer/Answer ..................................11
5.3. General Backwards Compatibility Considerations ............12
6. SRTP Security Descriptions .....................................12
6.1. SRTP Key Parameter ........................................13
6.2. Crypto-Suites .............................................16
6.2.1. AES_CM_128_HMAC_SHA1_80 ............................16
6.2.2. AES_CM_128_HMAC_SHA1_32 ............................17
6.2.3. F8_128_HMAC_SHA1_80 ................................17
6.2.4. Adding New Crypto-Suite Definitions ................17
6.3. Session Parameters ........................................17
6.3.1. KDR=n ..............................................18
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP .............18
6.3.3. UNAUTHENTICATED_SRTP ...............................18
6.3.4. FEC_ORDER=order ....................................19
6.3.5. FEC_KEY=key-params .................................19
6.3.6. Window Size Hint (WSH) .............................19
6.3.7. Defining New SRTP Session Parameters ...............20
6.4. SRTP Crypto Context Initialization ........................20
6.4.1. Late Binding of One or More SSRCs to a
Crypto Context .....................................21
6.4.2. Sharing Cryptographic Contexts among
Sessions or SSRCs ..................................22
6.5. Removal of Crypto Contexts ................................23
7. SRTP-Specific Use of the Crypto Attribute ......................23
7.1. Use with Offer/Answer .....................................23
7.1.1. Generating the Initial Offer - Unicast Streams .....23
7.1.2. Generating the Initial Answer - Unicast Streams ....24
7.1.3. Processing of the Initial Answer - Unicast
Streams ............................................25
7.1.4. Modifying the Session ..............................25
7.1.5. Offer/Answer Example ...............................27
7.2. SRTP-Specific Use Outside Offer/Answer ....................28
7.3. Support for SIP Forking ...................................28
7.4. SRTP-Specific Backwards Compatibility Considerations ......29
7.5. Operation with KEYMGT= and k= lines .......................29
8. Security Considerations ........................................29
8.1. Authentication of Packets .................................30
8.2. Keystream Reuse ...........................................30
8.3. Signaling Authentication and Signaling Encryption .........31
9. Grammar ........................................................32
9.1. Generic "Crypto" Attribute Grammar ........................32
9.2. SRTP "Crypto" Attribute Grammar ...........................32
10. IANA Considerations ...........................................34
10.1. Registration of the "crypto" Attribute ...................34
10.2. New IANA Registries and Registration Procedures ..........34
10.2.1. Key Method Registry and Registration ..............34
10.2.2. Media Stream Transport Registry and Registration ..35
10.3. Initial Registrations ....................................35
10.3.1. Key Method ........................................35
10.3.2. SRTP Media Stream Transport .......................35
10.3.2.1. SRTP Crypto Suite Registry and
Registration .............................35
10.3.2.2. SRTP Session Parameter Registration ......36
11. Acknowledgements ..............................................36
12. Normative References ..........................................36
13. Informative References ........................................37
Appendix A - Rationale for Keying Material Directionality .........401. Introduction ✨
Okay, so the Session Description Protocol (SDP) [RFC4566] is what describes multimedia sessions 🎥. Those can be audio, video, whiteboard, fax, modem, and other media streams 🎶. Those streams often need security services like data origin authentication, integrity, and confidentiality 🔐. The Secure Real-time Transport Protocol (SRTP) [RFC3711] gives security to RTP media, and you turn it on by using a secure RTP transport like "RTP/SAVP" or "RTP/SAVPF" in an SDP media (m=) line 🦋. The tea though: SDP itself has no way to configure SRTP beyond default values 😭. So this doc introduces a new SDP attribute called "crypto" 💅. It's used to signal and negotiate cryptographic parameters for media streams in general, and for SRTP especially ✨. The crypto attribute here is limited to two-party unicast media streams where each source has its own unique cryptographic key 👯♀️. Support for multicast media streams or multipoint unicast streams is still for further study 🔮.
The crypto attribute is defined in a generic way so it can work with SRTP and any other secure transport that can set up cryptographic parameters in a single message or a single round-trip exchange, using the offer/answer model [RFC3264] 🧚. Extending it to transports other than SRTP is out of scope for this doc 🙅♀️. Every secure media transport needs its own spec for the crypto-attribute parameter 📝. Those definitions are usually pretty specific to that transport, and they must be specified in a Standards-Track RFC and registered with IANA following the procedures in Section 10 💼. This document only defines the security parameters and keying material for SRTP 🎀.
Here's why this matters: it would be self-defeating not to protect cryptographic keys and other parameters at least as well as the data they unlock 🙃. Data security protocols like SRTP depend on a separate key management system to securely set up encryption and/or authentication keys 🗝️. Key management protocols provide authenticated key establishment (AKE) procedures, which authenticate the identity of each endpoint and protect against man-in-the-middle, reflection/replay, connection hijacking, and some denial-of-service attacks [skeme] 🛡️. Along with the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK [kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime], or TLS [TLS] securely shares info describing both the key and the data-security session 🌸. AKE is needed because it's pointless to send a key over a medium where an attacker can snoop the key, mess with the key so it's useless, or change the security session's parameters to get into session-related info 👀.
SDP was not designed to provide AKE services, though, and the media security descriptions in this doc don't add AKE to SDP 🙈. This spec is not a replacement for a key management protocol, or for carrying key management messages in SDP [keymgt] 🚫. The SDP security descriptions defined here are only suitable for restricted cases, where IPsec, TLS, or some other encapsulating data-security protocol (e.g., SIP S/MIME) protects the SDP message 🔒. This doc adds security descriptions to those encrypted and/or authenticated SDP messages through the new SDP "crypto" attribute, which gives the cryptographic parameters of a media stream 💜.
The "crypto" attribute can be adapted to any media transport, but its exact definition is unique to each particular transport 🌈.
Here's the roadmap 🗺️: Section 2 has the notational conventions, and Section 3 covers applicability for the crypto attribute. Section 4 introduces the general SDP crypto attribute, and Section 5 defines how it's used with and without the offer/answer model. Section 6 defines the crypto attribute details needed for SRTP, and Section 7 defines SRTP-specific use of the attribute with and without offer/answer. Section 8 covers security considerations, and Section 9 gives an Augmented-BNF grammar for the general crypto attribute as well as the SRTP-specific use 🤓. IANA considerations are in Section 10 📋.
2. Notational Conventions 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔑. The terminology here follows [RFC2828], "Internet Security Glossary" 📖.
Quick math check 🧮: n^r is exponentiation, where n is multiplied by itself r times, and n and r are integers. 0..k is an integer range of all integers from 0 through k, inclusive 🔢.
The terms 'transport' and 'media transport' are used to mean 'transport protocol' as defined in RFC 4566 🎀.
Explanatory notes pop up in a few places throughout the document, and they're indented three spaces from the surrounding text 👀.
3. Applicability ✨
okay so RFC 4567 already does similar cryptographic key distribution 🔐, and it's the one you want when the signaling gets its own confidentiality and/or integrity protection, separate from the keying material 💅.
this spec is the opposite vibe 🦋. it carries the keying material inside the SDP message, so it's for when the keying material is protected right alongside the signaling. implementations MUST employ security mechanisms that provide confidentiality and integrity for the keying material 🫶. no skipping this, bestie 😭.
when this is used with SIP [RFC3261], the application SHOULD employ either the SIPS URI or S/MIME to protect the SDP message and the keying material inside it 🎀. using transport layer or IP layer security instead of the SIPS URI or S/MIME is NOT RECOMMENDED 🙈. the reason is literally that the protection of the SDP message and its keying material can't be ensured through all intermediate entities, like SIP proxies 💀.
4. SDP "Crypto" Attribute and Parameters 🎀
a new media-level SDP attribute called "crypto" describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line 🌸. the "crypto" attribute MUST only appear at the SDP media level, not at the session level 🙅♀️. the format looks like this (the formal ABNF grammar is in Section 9.1):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]the fields tag, crypto-suite, key-params, and session-params each get their own sub-section below 🧚. the values of each field are case-insensitive unless noted otherwise, but implementers are encouraged to use the actual case shown in this document and any extensions to it 🍓. fun fact: per normal SDP rules, the "crypto" attribute name itself is case-sensitive 🤓.
here's an example for the "RTP/SAVP" transport, aka the secure RTP extension to the Audio/Video Profile [RFC3711] 👑. the newlines are only there for formatting:
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32so the crypto-suite is AES_CM_128_HMAC_SHA1_80, the key-params is everything starting with "inline:", and session-params is omitted 💖.
4.1. Tag 🏷️
the tag is a decimal number that identifies a particular crypto attribute (see Section 9.1 for details). leading zeroes MUST NOT be used 🙅♀️. the tag MUST be unique among all crypto attributes for a given media line ✨. it's used with the offer/answer model to figure out which of several offered crypto attributes the answerer picked (see Section 5.1) 🫶.
in the offer/answer model, the tag is a negotiated parameter 🤝.
4.2. Crypto-Suite 🔐
the crypto-suite field is an identifier that describes the encryption and authentication algorithms (e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section 9.1 for details) 💜. the possible values are defined within the context of the transport. each transport gets its own namespace for crypto-suites 🌈.
for example, "AES_CM_128_HMAC_SHA1_80" defined within the "RTP/SAVP" transport applies to Secure RTP only 🙈. the string can be reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but that would need a separate definition 🦋.
in the offer/answer model, the crypto-suite is a negotiated parameter 🤝.
4.3. Key Parameters 🗝️
the key-params field gives one or more sets of keying material for the crypto-suite in question ✨. it's a method indicator, then a colon, then the actual keying info. the formal grammar (in Section 9.1) looks like this:
key-params = <key-method> ":" <key-info>keying material might come from different means than key-params, but that's out of scope 🙃. only one method is defined in this document, and it's "inline", which means the actual keying material lives in the key-info field itself 🎀. there's a single namespace for the key-method, so it's transport independent 💅. new key-methods (like using a URL) may be defined in a Standards-Track RFC in the future 🔮.
even though the key-method can be generic, the accompanying key-info definition is specific to both the key-method and the transport 😭. key-info encodes keying material for a crypto suite, which is what defines that keying material 🫶. new key methods MUST be registered with IANA following the procedures in Section 10.2.1 📋.
key-info is defined as a general octet string (see Section 9.1 for details). further transport and key-method specific syntax and semantics MUST be provided in a Standards-Track RFC for each combination of transport and key-method that uses it. the definitions for SRTP are in Section 6 🌸. these definitions live within the context of a particular transport (like "RTP/SAVP") and a specific key-method (like "inline") 🧁. IANA will register the list of supported key methods for each transport 📝.
when there are multiple keys in the key parameters, it MUST be possible to tell which key is being used for a given media packet just by looking at the media packet you received. trial-and-error between the possible keys MUST NOT be performed 🙅♀️. no guessing games, periodt 💀.
For SRTP, this could be achieved by use of Master Key Identifiers (MKI) [RFC3711]. Use of <"From, "To"> values are not supported in SRTP security descriptions for reasons explained in Section 6.1, below.
in the offer/answer model, the key parameter is a declarative parameter 📣.
4.4. Session Parameters 🧩
session parameters are specific to a given transport, and using them is OPTIONAL in the security descriptions framework. there they're just defined as general character strings 🍬. if session parameters are going to be used for a given transport, then transport-specific syntax and semantics MUST be provided in a Standards-Track RFC. the definitions for SRTP are in Section 6 ✨.
in the offer/answer model, session parameters may be either negotiated or declarative. the definition of each specific session parameter MUST indicate which one it is 🫶. negotiated parameters apply to data sent in both directions, whereas declarative parameters only apply to media sent by the entity that generated the SDP 🦋. so a declarative parameter in an offer applies to media sent by the offerer, and a declarative parameter in an answer applies to media sent by the answerer 💜.
4.5. Example 🌷
this example shows the crypto attribute for the "RTP/SAVP" media transport type (as defined in Section 5). the "a=crypto" line is actually one long line, but it's split across two lines here because of page formatting 📄.
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portraitthis SDP message describes three media streams 🎬, and two of them use the "RTP/SAVP" transport 🎧. each of those has a crypto attribute for "RTP/SAVP" 🔐. these secure-RTP specific descriptions are defined in Section 6 🧚.
5. General Use of the crypto Attribute 💅
in this section we go over the general use of the crypto attribute, outside of any transport or key-method specific rules 🌈.
5.1. Use with Offer/Answer 🤝
the general offer/answer rules for the crypto attribute are in addition to the rules in RFC 3264, which MUST be followed unless otherwise noted 📜. RFC 3264 covers both unicast and multicast streams. the sections below only describe two-party unicast streams, since support for multicast streams (and multipoint unicast streams) is for further study 🔮.
5.1.1. Generating the Initial Offer - Unicast Streams 🎁
when you're generating an initial offer for a unicast stream, there MUST be one or more crypto attributes present for each media stream where security is wanted. each crypto attribute for a given media stream MUST contain a unique tag 🏷️.
the ordering of multiple "a=crypto" lines matters: the most preferred crypto line goes first 👑. each crypto attribute describes the crypto-suite, key(s), and possibly session parameters offered for the media stream ✨. in general, a "more preferred" crypto-suite SHOULD be cryptographically stronger than a "less preferred" one 💪.
the crypto-suite always applies to media in the directions the media stream supports (e.g., send and receive) 🦋. the key(s), though, apply to data packets (like SRTP and SRTCP packets) that will be sent by the same party that generated the SDP. so each endpoint picks its own transmission keys and sends them, in SDP, to the other endpoint 🫶.
This is done for consistency. Also, in the case of SRTP, for example, secure RTCP will still be flowing in both the send and receive direction for a unidirectional stream. 🌸
the inline parameter carries the keying material an endpoint uses to encrypt the media streams it transmits. the recipient uses that same keying material to decrypt those streams 🔓.
the offer may include session parameters. there are no general offer rules for session parameters. instead, specific rules can be provided as part of the transport-specific definitions of any session parameters 🧩.
when issuing an offer, the offerer MUST be prepared to support media security in accordance with any of the crypto attributes included in the offer 💪. but there are two problems with this, bestie 😬. first, the offerer doesn't know which key the answerer will use for media sent to the offerer 🙈. second, the offerer may not be able to figure out which of the offered crypto attributes were accepted 🤷♀️. since media can arrive before the answer, delay or clipping can happen 📉. if that's unacceptable to the offerer, the offerer SHOULD use a mechanism outside the scope of this document to prevent the problem above 🛡️.
For example, in SIP [RFC3261], a "security" precondition as defined in [sprecon] could solve the above problem. ✨
5.1.2. Generating the Initial Answer - Unicast Streams ✨
okay so when the answerer gets the initial offer with one or more crypto attributes for a unicast media stream, they MUST either accept exactly one of the offered crypto attributes, or the offered stream MUST be rejected. no in-between! 🙅♀️
if the answerer wants to show it supports other crypto attributes too, it can list those using the SDP Simple Capability Declaration [RFC3407] extensions. 🎀
only valid crypto attributes can be accepted 🧐. valid means it doesn't break any of the general rules for security descriptions, and it doesn't break any specific rules for the transport and key-method in question. when picking one, the answerer SHOULD select the most preferred crypto attribute it can support, which is the first valid supported one in the list, based on its own capabilities and security policies. ⭐
if there are crypto attributes in the offer but none of them are valid, or none of the valid ones are supported, the offered media stream MUST be rejected. 💀
when an offered crypto attribute gets accepted, the crypto attribute in the answer MUST contain the following:
- the tag and crypto-suite from the accepted crypto attribute in the offer (the same crypto-suite MUST be used in the send and receive direction) 💜
- the key(s) the answerer will be using for media sent to the offerer. note that a key MUST be provided, irrespective of any direction attributes in the offer or answer 🔑
furthermore, any session parameters that are negotiated MUST be included in the answer 🫶. declarative session parameters provided by the offerer are NOT included in the answer, but the answerer may provide its own set of declarative session parameters. 🌸
once the answerer has accepted one of the offered crypto attributes, the answerer MAY begin sending media to the offerer in accordance with the selected crypto attribute. just note that the offerer may not be able to process those media packets correctly until the answer has been received 😭.
5.1.3. Processing of the Initial Answer - Unicast Streams 🦋
when the offerer receives the answer, the offerer MUST verify that one of the initially offered crypto suites and its accompanying tag were accepted and echoed in the answer. also, the answer MUST include one or more keys, which will be used for media sent from the answerer to the offerer 🔐.
if the offer contained any mandatory negotiated session parameters (see Section 6.3.7), the offerer MUST verify that said parameters are included in the answer and support them. if the answer contains any mandatory declarative session parameters, the offerer MUST be able to support those 🧠.
if any of the above fails, the negotiation MUST fail. no drama, just reset 💅.
5.1.4. Modifying the Session 🌈
once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8 🔄. this modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite. if media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges. the procedures are similar to those defined in Section 5.1.1, 5.1.2, and 5.1.3 of this document, subject to the considerations provided in RFC 3264, Section 8 🧚.
5.2. Use Outside Offer/Answer 🍓
the crypto attribute can also be used outside the context of offer/answer, where there is no negotiation of the crypto suite, cryptographic key, or session parameters. in this case, the sender determines the security parameters for the stream 🎯. since there is no negotiation mechanism, the sender MUST include exactly one crypto attribute, and the receiver MUST either accept it or SHOULD NOT receive the associated stream. the sender SHOULD select the security description that it deems most secure for its purposes 🔒.
5.3. General Backwards Compatibility Considerations 🕰️
in the offer/answer model, it's possible that the answerer supports a given secure transport (e.g., RTP/SAVP) and accepts the offered media stream, but does NOT support the crypto attribute defined in this document, so it ignores it 🙈. the offerer can recognize this situation by seeing an accepted media stream in the answer that does not include a crypto line. in that case, the security negotiation defined here MUST fail ❌.
similar issues exist when security descriptions are used outside the offer/answer model. but the source of a non-negotiated security description has no indication that the receiver has ignored the crypto attribute 👀.
6. SRTP Security Descriptions 👑
in this section, we provide definitions for security descriptions for SRTP media streams. in the next section, we define how to use SRTP security descriptions with and without the offer/answer model ✨.
SRTP security descriptions MUST only be used with the SRTP transport (e.g., RTP/SAVP or RTP/SAVPF). the following specifies security descriptions for the RTP/SAVP profile, defined in [RFC3711]. however, it is expected that other secure RTP profiles (e.g., RTP/SAVPF) can use the same descriptions, which are in accordance with the SRTP protocol specification [RFC3711] 💫.
there is no assurance that an endpoint is capable of configuring its SRTP service with a particular crypto attribute parameter, but SRTP guarantees minimal interoperability among SRTP endpoints through the default SRTP parameters [RFC3711]. more capable SRTP endpoints support a variety of parameter values beyond the SRTP defaults, and these values can be configured by the SRTP security descriptions defined here. an endpoint that does not support the crypto attribute will ignore it according to the SDP. such an endpoint will not correctly process the particular media stream 😬. by using the Offer/Answer model, the offerer and answerer can negotiate the crypto parameters to be used before commencement of the multimedia session (see Section 7.1) 🤝.
there are over twenty cryptographic parameters listed in the SRTP specification. many of these parameters have fixed values for particular cryptographic transforms. at the time of session establishment, however, there is usually no need to provide unique settings for many of the SRTP parameters, such as salt length and pseudo-random function (PRF). thus, it's possible to simplify the list of parameters by defining "cryptographic suites" that fix a set of SRTP parameter values for the security session 🧁. this approach is followed by the SRTP security descriptions, which use the general security description parameters as follows:
* crypto-suite: Identifies the encryption and authentication
transforms.
* key parameter: SRTP keying material and parameters
* session parameters: The following parameters are defined:
- KDR: The SRTP Key Derivation Rate is the rate at which a
pseudo-random function is applied to a master key.
- UNENCRYPTED_SRTP: SRTP messages are not encrypted.
- UNENCRYPTED_SRTCP: SRTCP messages are not encrypted.
- UNAUTHENTICATED_SRTP: SRTP messages are not authenticated.
- FEC_ORDER: Order of forward error correction (FEC)
relative to SRTP services.
- FEC_KEY: Master Key for FEC when the FEC stream is sent
to a separate address and/or port.
- WSH: Window Size Hint.
- Extensions: Extension parameters can be defined.please refer to the SRTP specification for a complete list of parameters and their descriptions [Section 8.2, srtp] 📚. regarding the UNENCRYPTED_SRTCP parameter, offerers and answerers of SDP security descriptions MUST NOT use the SRTCP E-bit to override UNENCRYPTED_SRTCP or the default, which is to encrypt all SRTCP messages (see Section 6.3.2) 🚫🔐. the key parameter, the crypto-suite, and the session parameters shown above are described in detail in the following subsections 🎀.
6.1. SRTP Key Parameter ✨
okay so for SRTP security descriptions, the only keying method we define is "inline" 🔑. Any other method (like URL) is for further study, so hold that thought 🌸
The "inline" key is the whole package 🎀 It holds the keying material (master key and salt) plus all the policy for that master key, like how long it can be used (lifetime) and whether it uses a master key identifier (MKI) to match an incoming SRTP packet to the right master key. Compliant implementations follow the policies tied to a master key and MUST NOT accept incoming packets that break the policy (for example, after the master key lifetime has expired) 💀
The key parameter holds one or more cryptographic master keys. Each one MUST be a unique cryptographically random [RFC1750] value compared with every other master key in the entire SDP message (so that includes the master keys for other streams too) 🦋 Each key follows this format (the formal definition is in Section 9.2):
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
key||salt concatenated master key and salt, base64 encoded
(see [RFC3548], Section 3)
lifetime master key lifetime (max number of SRTP or SRTCP
packets using this master key)
MKI:length MKI and length of the MKI field in SRTP packetsHere's an example for AES_CM_128_HMAC_SHA1_80 💖
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4The first field ("d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj") is the master key with the master salt stuck on the end 🧁 You concatenate the two first and then base64 encode them. How long the concatenated key and salt has to be depends on the crypto-suite the key is for. If the decoded length (after you undo the base64) doesn't match what the crypto-suite says, the crypto attribute is MUST be considered invalid 🚫 Each master key and salt MUST be a cryptographically random number, and MUST be unique across the entire SDP message 🔐 When you base64 decode the key and salt, the padding characters (one or two "=" at the very end of the base64-encoded data) get thrown away (see [RFC3548] for details). Base64 encoding assumes the input is a whole number of octets. If a crypto-suite needs a concatenated key and salt that isn't a whole number of octets, that crypto-suite MUST define a padding scheme so the base64 input ends up as a whole number of octets. For example, if the length were 250 bits, you'd need 6 padding bits, which could be defined as the last 6 bits of a 256 bit input 🌈
The second field is the OPTIONAL lifetime of the master key, measured as the maximum number of SRTP or SRTCP packets that can use that master key (so the number of SRTP packets and the number of SRTCP packets each have to be less than the lifetime) ⏳ The lifetime value MAY be written as a non-zero, positive decimal integer or as a power of 2 (check the grammar in Section 9.2 for the details), and leading zeroes MUST NOT be used. The "lifetime" value MUST NOT exceed the maximum packet lifetime for the crypto-suite. If the lifetime is too big or otherwise invalid, the entire crypto attribute MUST be considered invalid 😭 The default MAY be signaled implicitly by just leaving the lifetime out (note that the lifetime field never has a colon, but the third field always does). This is handy when the SRTP cryptographic key lifetime is the default value ✨ To avoid super long decimal numbers, the lifetime syntax lets you use the literal "2^", which means "two to the power of". The example above shows a lifetime of 2^20. The next example, for AES_CM_128_HMAC_SHA1_80, leaves the lifetime field at its default, which means SRTP's and SRTCP's default values get used (see [RFC3711]) 🍓
inline:YUJDZGVmZ2hpSktMbW9QUXJzVHVWd3l6MTIzNDU2|1066:4That example shows a 30-octet key and concatenated salt, base64 encoded. Expanded by the three-in-four encoding of base64, the 30-octet key/salt concatenation becomes 40 characters (octets) 🧚
The third field, which is also OPTIONAL, is the Master Key Identifier (MKI) and its byte length 🪪
"MKI" is the master key identifier tied to the SRTP master key. The MKI is defined here as a positive decimal integer that gets encoded as a big-endian integer in the actual SRTP packets, and leading zeroes MUST NOT be used in the integer representation. If the MKI is given, the length of the MKI MUST also be given, separated from the MKI by a colon (":"). The MKI length is the size of the MKI field in the SRTP packet, written in bytes as a decimal integer, and leading zeroes MUST NOT be used. If the MKI length is missing or its value is over 128 (bytes), the entire crypto attribute MUST be considered invalid 🙈 In the first example, the substring "1:4" gives the key an MKI of 1 that's 4 bytes long, and the second example gives the key a 4-byte MKI of 1066 💜 You can define one or more master keys with their MKI first, then update them later, or delete them and define new ones.
SRTP has a second way to set a master key's lifetime, using two values called "From" and "To", which are defined on the SRTP sequence number space [RFC3711]. This SRTP Security Descriptions spec does NOT support the <"From", "To"> feature, though, because the lifetime of an AES master key is 2^48 SRTP packets. That means there's no cryptographic reason to swap out a master key for practical point-to-point applications 🤷♀️ So there's no need to support two ways of signaling a key update. This spec picks the MKI over <"From", "To"> for the very few applications that need it, since the MKI feature is simpler (even though the MKI adds extra bytes to each packet, and <"From", "To"> doesn't) 🫶
Like I said above, the key parameter can hold one or more master keys. When it holds more than one master key, every master key in that key parameter MUST include an MKI value 👑
And when you're using the MKI, the MKI length MUST be the same for all keys in a given crypto attribute 💅
6.2. Crypto-Suites
The SRTP crypto-suites define the encryption and authentication transforms used for the SRTP media stream 🔥 The SRTP specification has defined three crypto-suites, which the next subsections describe in the context of SRTP security descriptions. Here's a quick overview of the crypto-suites and their parameters:
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Master salt length | 112 bits | 112 bits | 112 bits |
| SRTP lifetime | 2^48 packets| 2^48 packets | 2^48 packets |
| SRTCP lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | AES F8 Mode |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| SRTP auth. tag | 80 bits | 32 bits | 80 bits |
| SRTCP auth. tag | 80 bits | 80 bits | 80 bits |
| SRTP auth. key len. | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key len.| 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+6.2.1. AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_80 is the SRTP default: AES Counter Mode cipher plus HMAC-SHA1 message authentication with an 80-bit authentication tag 💖 The master-key length is 128 bits, with a default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first [Page 39, srtp].
SRTP allows 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first. However, it is RECOMMENDED that automated key management allow easy and efficient rekeying at intervals far smaller than 2^31 packets given today's media rates or even HDTV media rates.
The SRTP and SRTCP encryption key lengths are 128 bits. The SRTP and SRTCP authentication key lengths are 160 bits (see Security Considerations in Section 8) 🔐 The master salt is 112 bits long and the session salt is 112 bits long. The pseudo-random function (PRF) is the default SRTP one, which uses AES Counter Mode with a 128-bit key length ✨
The length of the base64-decoded key and salt for this crypto-suite MUST be 30 characters (i.e., 240 bits). Otherwise, the crypto attribute is considered invalid 🚫
6.2.2. AES_CM_128_HMAC_SHA1_32
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the authentication tag is 32 bits 🦋
The length of the base64-decoded key and salt for this crypto-suite MUST be 30 octets, i.e., 240 bits. Otherwise, the crypto attribute is considered invalid.
6.2.3. F8_128_HMAC_SHA1_80
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the cipher is F8 [RFC3711] 🌸
The length of the base64-decoded key and salt for this crypto-suite MUST be 30 octets, i.e., 240 bits. Otherwise, the crypto attribute is considered invalid.
6.2.4. Adding New Crypto-Suite Definitions
If new transforms get added to SRTP, new definitions for those transforms SHOULD be given for SRTP security descriptions and published in a Standards-Track RFC 🧚 Sections 6.2.1 through 6.2.3 show how to define crypto-suite values for particular cryptographic transforms. Any new crypto-suites MUST be registered with IANA following the procedures in Section 10 📋
6.3. Session Parameters
SRTP security descriptions define a set of "session" parameters, which OPTIONALLY may be used to override SRTP session defaults for the SRTP and SRTCP streams 🎀 These parameters configure an RTP session for SRTP services, giving session-specific info to set up the SRTP cryptographic context.
6.3.1. KDR=n
KDR specifies the Key Derivation Rate, as described in Section 4.3.1 of [RFC3711] 🔑
The value n MUST be a decimal integer in the set {1,2,...,24}, which denotes a power of 2 from 2^1 to 2^24, inclusive, and leading zeroes MUST NOT be used 🍓 The SRTP key derivation rate controls how often a new session key gets derived from the SRTP master key(s) [RFC3711] given in the declaration. When the key derivation rate isn't specified (i.e., the KDR parameter is omitted), a single initial key derivation is performed [RFC3711] ✨
In the offer/answer model, KDR is a declarative parameter 💅
6.3.2. UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 🔓
okay so SRTP and SRTCP payloads are encrypted by default 🔐 no cap. The UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters tweak that default for the crypto-suites they're used with:
UNENCRYPTED_SRTCPsignals that the SRTCP packet payloads are not encrypted.UNENCRYPTED_SRTPsignals that the SRTP packet payloads are not encrypted.
In the offer/answer model these get negotiated. If UNENCRYPTED_SRTCP is signaled for the session, then the SRTCP E bit MUST be clear (0) in all SRTCP messages. If the default is used, all SRTCP messages are encrypted, and the E bit MUST be set (1) on all SRTCP messages. 🔒
6.3.3. UNAUTHENTICATED_SRTP 🙈
SRTP and SRTCP payloads are authenticated by default ✅. The UNAUTHENTICATED_SRTP session parameter signals that SRTP messages are not authenticated. Use of UNAUTHENTICATED_SRTP is NOT RECOMMENDED (see Security Considerations) 🚩.
The SRTP specification requires use of message authentication for SRTCP, but not for SRTP [RFC3711].
In the offer/answer model, this parameter is negotiated. 🤝
6.3.4. FEC_ORDER=order 🧩
FEC_ORDER signals the use of forward error correction for the RTP packets [RFC2733]. The forward error correction values for "order" are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied before SRTP processing by the sender of the SRTP media and after SRTP processing by the receiver of the SRTP media, and FEC_SRTP is the default ✨. SRTP_FEC is the reverse processing.
In the offer/answer model, FEC_ORDER is a declarative parameter. 📝
6.3.5. FEC_KEY=key-params 🔑
FEC_KEY signals the use of separate master key(s) for a Forward Error Correction (FEC) stream. The master key(s) are specified with the exact same format as the SRTP Key Parameter defined in Section 6.1, and the semantic rules are the same. In particular, the master key(s) MUST be different from all other master key(s) in the SDP 🗝️. An FEC_KEY MUST be specified when the FEC stream is sent to a different IP-address and/or port than the media stream to which it applies (i.e., the "m=" line), e.g., as described in RFC 2733, Section 11.1 🌐.
When an FEC stream is sent to the same IP-address and port as the media stream to which it applies, an FEC_KEY MUST NOT be specified. If an FEC_KEY is specified in this latter case, the crypto attribute in question MUST be considered invalid 💀.
In the offer/answer model, FEC_KEY is a declarative parameter. 📝
6.3.6. Window Size Hint (WSH) 🪟
SRTP defines the SRTP-WINDOW-SIZE [RFC3711, Section 3.3.2] parameter to protect against replay attacks 🛡️. The minimum value is 64 [RFC3711]. However, this value may be considered too low for some applications (e.g., video) 🎥.
The Window Size Hint (WSH) session parameter provides a hint for how big this window should be to work satisfactorily (e.g., based on sender knowledge of the number of packets per second). However, there might be enough information given in SDP attributes like a=maxprate [maxprate] and the bandwidth modifiers to allow a receiver to derive the parameter satisfactorily 🧠. Consequently, this value is only considered a hint to the receiver of the SDP that MAY choose to ignore the value provided 💅. The value is a decimal integer, and leading zeroes MUST NOT be used 🔢.
In the offer/answer model, WSH is a declarative parameter. 📝
6.3.7. Defining New SRTP Session Parameters 🪄
New SRTP session parameters for the SRTP security descriptions can be defined in a Standards-Track RFC and registered with IANA according to the registration procedures defined in Section 10 📚.
New SRTP session parameters are by default mandatory. A newly defined SRTP session parameter that is prefixed with the dash character ("-"), however, is considered optional and MAY be ignored 🌸. If an SDP crypto attribute is received with an unknown session parameter that is not prefixed with a "-" character, that crypto attribute MUST be considered invalid 🚫.
6.4. SRTP Crypto Context Initialization 🧁
In addition to the various SRTP parameters defined above, there are three pieces of information that are critical to the operation of the default SRTP ciphers 🔥:
SSRC: Synchronization sourceROC: Roll-over counter for a given SSRCSEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints on these values 👀.
The first constraint is on the SSRC, which makes an SRTP keystream unique from other participants 🔑. As explained in SRTP, the keystream MUST NOT be reused on two or more different pieces of plaintext. Keystream reuse makes the ciphertext vulnerable to cryptanalysis 😱. One vulnerability is that known-plaintext fields in one stream can expose portions of the reused keystream, and this could further expose more plaintext in other streams. Since all current SRTP encryption transforms use keystreams, key sharing is a general problem [RFC3711]. SRTP mitigates this problem by including the SSRC of the sender in the keystream. But SRTP does not solve this problem in its entirety, because the Real-time Transport Protocol has SSRC collisions, which, although very rare [RFC3550], are quite possible 🥲. During a collision, two or more SSRCs that share a master key will have identical keystreams for overlapping portions of the RTP sequence number space. SRTP Security Descriptions avoid keystream reuse by making unique master keys REQUIRED for the sender and receiver of the security description. Thus, the first constraint is satisfied ✅.
Also note that there is a second problem with SSRC collisions: the SSRC is used to identify the crypto context and thereby the cipher, key, ROC, etc. to process incoming packets. In case of SSRC collisions, crypto context identification becomes ambiguous and correct packet processing may not occur. Furthermore, if an RTCP BYE packet is to be sent for a colliding SSRC, that packet may also have to be secured. In a (unicast) point-to-multipoint scenario, this can be problematic for the same reasons, i.e., it is not known which of the possible crypto contexts to use. Note that these problems are not unique to the SDP security descriptions; any use of SRTP needs to consider them. ⚠️
The second constraint is that the ROC MUST be zero at the time that each SSRC commences sending packets. Thus, there is no concept of a "late joiner" in SRTP security descriptions, which are constrained to be unicast and pairwise 🚪. The ROC and SEQ form a "packet index" in the default SRTP transforms, and the ROC is consistently set to zero at session commencement, according to this document.
The third constraint is that the initial value of SEQ SHOULD be chosen to be within the range of 0..2^15-1. This avoids an ambiguity when packets are lost at the start of the session 🌈. If it is at the start of a session, an SSRC source might randomly select a high sequence-number value and put the receiver in an ambiguous situation. If initial packets are lost in transit up to the point that the sequence number wraps (i.e., exceeds 2^16-1), then the receiver might not recognize that its ROC needs to be incremented 🙃. By restricting the initial SEQ to the range of 0..2^15-1, SRTP packet-index determination will find the correct ROC value, unless all the first 2^15 packets are lost (which seems, if not impossible, rather unlikely). See Section 3.3.1 of the SRTP specification regarding packet-index determination [RFC3711] 🧮.
6.4.1. Late Binding of One or More SSRCs to a Crypto Context 🎯
The packet index, therefore, depends on the SSRC, the SEQ of an incoming packet, and the ROC, which is an SRTP crypto context variable. Thus, SRTP has a big security dependency on SSRC uniqueness 💘.
Given the above constraints, unicast SRTP crypto contexts can be established without the need to negotiate SSRC values in the SRTP security descriptions. Instead, an approach called "late binding" is RECOMMENDED by this specification 💡. When a packet arrives, the SSRC that is contained in it can be bound to the crypto context at the time of session commencement (i.e., SRTP packet arrival) rather than at the time of session signaling (i.e., receipt of an SDP). With the arrival of the packet containing the SSRC, all the data items needed for the SRTP crypto context are held by the receiver. (Note that the ROC value by definition is zero. If non-zero values were to be supported, additional signaling would be required.) 📬
In other words, the crypto context for a secure RTP session using late binding is initially identified by the SDP as
<*, address, port>
where * is a wildcard SSRC, "address" is the local receive address from the c= line, and "port" is the local receive port from the m= line 🗺️. When the first packet arrives with ssrcX in its SSRC field, the crypto context
<ssrcX, address, port>
is instantiated, subject to the following constraints:
- Media packets are authenticated: authentication MUST succeed. Otherwise, the crypto context is not instantiated. 🔐
- Media packets are not authenticated: crypto context is automatically instantiated. 😬
Note that use of late binding when there is no authentication of the SRTP media packets is subject to numerous security attacks, and that consequently it is NOT RECOMMENDED (of course, this can be said for unauthenticated SRTP in general) 🚨.
Note that use of late binding without authentication will result in the creation of local state as a result of receiving a packet from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore, is NOT RECOMMENDED, because it invites easy denial-of-service attack. In contrast, late binding with authentication does not suffer from this weakness. 🥺
6.4.2. Sharing Cryptographic Contexts among Sessions or SSRCs 🫂
With the constraints and procedures described above, it is not necessary to explicitly signal the SSRC, ROC, and SEQ for a unicast RTP session. So there are no a=crypto parameters for signaling SSRC, ROC, or SEQ 🙌. Thus, multiple SSRCs from the same entity will share a=crypto parameters when late binding is used. Multiple SSRCs from the same entity arise due to either multiple sources (microphones, cameras, etc.) or RTP payloads requiring SSRC multiplexing within that same session 🎙️📷. SDP also allows multiple RTP sessions to be defined in the same media description (m=), and these RTP sessions will also share the a=crypto parameters.
An application that uses a=crypto in this way serially shares a master key among RTP sessions or SSRCs, and MUST replace the master key when the aggregate number of packets among all SSRCs approaches 2^31 packets 🔄. SSRCs that share a master key MUST be unique from one another 💜.
6.5. Removal of Crypto Contexts ✨
okay so we already covered how crypto contexts get created 🎀 but bestie, people also want to delete them before the session even ends 🙈 and here's the tea: a crypto context holds stuff that can't just be figured out again, like the ROC 💀 so the sender and receiver need to be super clear about when it's okay to remove one, and even more importantly, when it's not 😤
Even when late binding is used for a unicast stream, the ROC is lost and cannot be recovered automatically (unless it is zero) once the crypto context is removed.
so here's how we handle it 🫶 when SRTP security descriptions are in use, crypto-context removal MUST follow the same rules as SSRC removal from the member table [RFC3550] 🦋 and yep, that can happen because of an SRTCP BYE packet or just a simple time-out from inactivity 😭 so if you're a quiet participant who doesn't want your crypto context timed out, you MUST thus send SRTCP packets at regular intervals 💅
7. SRTP-Specific Use of the Crypto Attribute 🦋
Section 5 gave us the general vibe of the crypto attribute, and this section finishes the job by covering the SRTP-specific stuff 💖
7.1. Use with Offer/Answer 🌸
this part is all about how SRTP security descriptions work with the offer/answer model 🤝 so we can negotiate crypto capabilities and pass along SRTP master keys 🔑 the rules here add to the general offer/answer rules in Section 5.1, which MUST be followed, unless otherwise specified. heads up though: these rules only cover unicast operation. support for multicast and multipoint unicast streams is for further study 🧚
7.1.1. Generating the Initial Offer - Unicast Streams ✨
when the initial offer gets made, the offerer MUST follow the steps in Section 5.1.1, plus the steps below 📝
for each unicast media line (m=) using the secure RTP transport where the offerer wants to specify cryptographic parameters, the offerer MUST provide at least one valid SRTP security description ("a=crypto" line), as defined in Section 6. if the media stream includes Forward Error Correction with a different IP-address and/or port from the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5 🔥
the inline parameter carries the SRTP master key that an endpoint uses to encrypt the SRTP and SRTCP streams it sends 🔐 the recipient uses that same key to decrypt them. but the receiver MUST NOT use that same key for the SRTP or SRTCP packets it sends to the session 🙅♀️ because the default SRTP cipher and mode is insecure when the master key gets reused across distinct SRTP streams 💀
the offerer MAY include one or more other SRTP session parameters, as defined in Section 6.3. just note that if any SRTP session parameters are included that the answerer doesn't know but that are still mandatory (see Section 6.3.6), the negotiation will fail if the answerer doesn't support them 😬
7.1.2. Generating the Initial Answer - Unicast Streams 🎀
when the initial answer is generated, the answerer MUST follow the steps in Section 5.1.2, plus the steps below 💅
for each unicast media line that uses the secure RTP transport and has one or more "a=crypto" lines in the offer, the answerer MUST either accept one (and only one) of the crypto lines for that media stream, or it MUST reject the media stream. only "a=crypto" lines that count as valid SRTP security descriptions, as defined in Section 6, can be accepted. also, all parameters (crypto-suite, key parameter, and mandatory session parameters) MUST be acceptable to the answerer for the offered media stream to be accepted 🙃 and if the media stream includes Forward Error Correction with a different IP-address and/or port from the media stream itself, an FEC_KEY parameter MUST be included, as described in Section 6.3.5 🫶
when the answerer accepts an SRTP unicast media stream with a crypto line, the answerer MUST include one or more master keys that fit the selected crypto algorithm 🔑 and the master key(s) in the answer MUST be different from the ones in the offer 🙅♀️
When the master key(s) are not shared between the offerer and answerer, SSRC collisions between the offerer and answerer will not lead to keystream reuse, and hence SSRC collisions do not necessarily have to be prevented.
if Forward Error Correction to a separate IP-address and/or port is included, the answer MUST include an FEC_KEY parameter, as described in Section 6.3.5 🧚
declarative session parameters may be added to the answer as usual 💖 however, the answerer SHOULD NOT add any mandatory session parameter (see Section 6.3.6) that the offerer might not know 🤔
if the answerer can't find any valid crypto line it supports, or if its configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter (e.g., KDR, FEC_ORDER), it MUST reject the media stream 🚫 unless it can successfully negotiate SRTP by other means outside the scope of this document (e.g., by use of MIKEY [mikey]) 🌈
7.1.3. Processing of the Initial Answer - Unicast Streams 🔍
when the offerer gets the answer, it MUST perform the steps in Section 5.1.3, plus the steps below for each SRTP media stream it offered with one or more crypto lines in it 📬
if the media stream was accepted and contains a crypto line, it MUST be checked that the crypto line is valid according to the constraints in Section 6 (including any FEC constraints) ✅
if the offerer either doesn't support or isn't willing to honor one or more of the SRTP parameters in the answer, the offerer MUST consider the crypto line invalid 🙅♀️
if the crypto line isn't valid, or the offerer's configured policy prohibits any cryptographic key parameter (e.g., key length) or cryptographic session parameter, the SRTP security negotiation MUST be deemed to have failed 💀
7.1.4. Modifying the Session 🦋
when a media stream using the SRTP security descriptions is already established and a new offer/answer exchange happens, the offerer and answerer MUST follow the steps in Section 5.1.4, plus the steps below 🔄
when modifying the session, every negotiated aspect of the SRTP media stream can change 🎀 for example, a new crypto suite can be used or a new master key can be set up. as RFC 3264 explains, when a new offer/answer exchange is made, there's a window of time where the offerer and the answerer must be prepared to receive media according to both the old and new offer/answer exchange ⏳
this requirement applies here too, but keep these in mind 👀
- when authentication isn't being used, it may not be possible for either the offerer or answerer to tell if a given packet was encrypted according to the old or new offer/answer exchange. RFC 3264 defines a couple of techniques to deal with this, e.g., changing the payload types used and/or the transport addresses. just know that changing transport addresses may have an impact on quality of service as well as on firewall and NAT traversal 🚧 the SRTP security descriptions use the MKI to handle this (which adds a few bytes to each SRTP packet), as described in Section 6.1. for more on the MKI, check out [RFC3711] 🔍
- if the answerer changes its master key, the offerer won't be able to process packets secured via this master key until the answer is received. this could be addressed by using a security "precondition" [sprecon] 🧠
if the offerer includes an IP address and/or port that differs from the one used before for a media stream (or FEC stream), the offerer MUST include a new master key with the offer (and in doing so, it will be creating a new crypto context where the ROC is set to zero) 🆕 similarly, if the answerer includes an IP address and/or port that differs from the one used before for a media stream (or FEC stream), the answerer MUST include a new master key with the answer (and so create a new crypto context with the ROC set to zero) 🌸 the reason is that when the answerer receives an offer, or the offerer receives an answer, with an updated IP address and/or port, it's not possible to tell if the other side still has access to the old crypto context parameters (and in particular the ROC) 🤷♀️ for example, if one side is a decomposed media gateway, or if a SIP back-to-back user agent is involved, the media endpoint might have changed and no longer have access to the old crypto context 😳 by always requiring a new master key in this case, the answerer/offerer knows the ROC is zero for this offer/answer, and any key lifetime constraints will trivially be satisfied too 🙌 one more thing for media relays: if the relay changes the media endpoint on one side without the other side knowing, the relay can't act as a simple packet reflector. it has to actively take part in SRTP packet processing and transformation (i.e., decryption and re-encryption, etc.) 🛠️
finally, if the new offer gets rejected, the old crypto parameters stay in place 🫶
7.1.5. Offer/Answer Example 🎬
in this example, the offerer supports two crypto suites (f8 and AES) 💜 the a=crypto line is really one long line, even though it's shown as two lines in this document because of page formatting 📄 the f8 example shows two inline parameters. as explained in Section 6.1, a crypto attribute can have one or more key (i.e., inline) parameters 🔑 this way, multiple keys get offered to support key rotation using a Master Key Identifier (MKI) 🔄
Offerer sends:
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
FEC_ORDER=FEC_SRTP
a=crypto:2 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTPAnswerer replies:
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4so in this case, the session would use the AES_CM_128_HMAC_SHA1_80 crypto suite for the RTP and RTCP traffic 🎧 if the answerer picked F8_128_HMAC_SHA1_80 instead, there'd be two inline keys tied to the SRTP cryptographic context 🙌 one key has an MKI value of 1 and the second has an MKI of 2 🦋
7.2. SRTP-Specific Use Outside Offer/Answer 🎀
Okay bestie, so using SRTP security descriptions outside the offer/answer model is just not defined. 🙅♀️
Use of SRTP security descriptions outside the offer/answer model could have been defined for sendonly media streams; however, there would not be a way to indicate the key to use for SRTCP by the receiver of said media stream.
It could have worked for sendonly streams, but the receiver would have no way to know which key to use for SRTCP. Literally a dealbreaker 💀
7.3. Support for SIP Forking 🍴
As I mentioned earlier, the security descriptions here don't support multicast media streams or multipoint unicast streams. BUT, in SIP it's totally possible to get several answers to one offer because of forking (see [SIP]). Getting multiple answers causes a couple of messy problems for SRTP security descriptions:
- Different answerers may pick different ciphers, keys, etc. Yet there's no way for the offerer to tie a particular incoming media packet to a particular answer. 😵💫
- Two or more answerers may pick the same SSRC, so the SSRC collision problems I talked about earlier may pop up. 💥
As I said before, those point-to-multipoint cases are outside the scope of the SDP security descriptions. Still, there are ways to support SIP forking, e.g., by turning the multipoint scenario from forking into multiple two-party unicast cases. Here's how that goes:
For each answer received beyond the initial answer, issue a new offer to that particular answerer using a new receive transport address (IP address and port). Note that this requires support for the SIP UPDATE method [RFC3311]. Also, to make sure two media sessions aren't accidentally set up before the UPDATE gets processed by one of them, use security preconditions [sprecon]. ⏳
Last but not least, every SIP User Agent that received the offer will know the key(s) being proposed by the initial offer. 😬 If the offerer wants to be secure against all the other User Agents that may have received the offer, a new offer/answer exchange with a new key needs to happen with the answerer too. Also, the offerer can't tell whether one or several SIP User Agents got the offer, since intermediate forking proxies may only forward a single answer to the offerer. 🫠
The above description is intended to suggest one possible way of supporting SIP forking. There are many details missing and it should not be considered a normative specification. Alternative approaches may also be possible
7.4. SRTP-Specific Backwards Compatibility Considerations 🔙
It's possible that the answerer supports the SRTP transport and accepts the offered media stream, but doesn't support the crypto attribute defined here. The offerer can spot this by seeing an accepted SRTP media stream in the answer that has no crypto line. In that case, the security negotiation defined here MUST be deemed to have failed. 🚫
Also, if a media stream with a given SRTP transport (e.g., "RTP/SAVP") is sent to a device that doesn't support SRTP, that media stream will get rejected. 🙈
7.5. Operation with KEYMGT= and k= lines 🔑
An offer MAY include both a=crypto and a=keymgt lines [keymgt]. Per SDP rules, the answerer will ignore attribute lines it doesn't understand. If the answerer supports both a=crypto and a=keymgt, the answer MUST include either a=crypto or a=keymgt, but not both, because including both is undefined. 🤷♀️
An offer MAY include both a=crypto and k= lines [RFC4566]. Per SDP rules, the answerer will ignore attribute lines it doesn't understand. If the answerer supports both a=crypto and k=, the answer MUST include either a=crypto or k= but not both, because including both is undefined. 🙃
8. Security Considerations 🛡️
Okay, this part is seriously important, so pay attention 🥺 Like all SDP messages, SDP messages containing security descriptions get carried inside an encapsulating application protocol (e.g., SIP, MGCP). It's the encapsulating protocol's job to protect the SDP security descriptions. So IT IS REQUIRED that the application invoke its own security mechanisms (e.g., secure multiparts such as S/MIME [smime]) or, alternatively, use a lower-layer security service (e.g., TLS or IPsec). IT IS REQUIRED that this security service provide strong message authentication and packet-payload encryption, as well as effective replay protection. 🔐
"Replay protection" is needed against an attacker who has enough access to the communications channel to intercept messages and deliver copies to the destination. A successful replay attack makes the recipient do duplicate processing on a message, and it's even worse when the duped recipient sends a duplicate reply to the initiator. 😱 Replay protections aren't found in S/MIME or in the other secure-multiparts standard, PGP/MIME. So S/MIME and PGP/MIME need to be augmented with some replay-protection mechanism that suits the encapsulating application protocol (e.g., SIP, MGCP). Three common ways to get replay protection are to put a sequence number in the message, to use a timestamp, or for the receiver to keep a hash of the message to compare with incoming messages. There typically needs to be a replay "window" and some policy for keeping state from previous messages in a "replay table" or list. 📋
The discussion that follows uses "message authentication" and "message confidentiality" in a way that's consistent with SRTP [RFC3711]. "Message confidentiality" means that only the holder of the secret decryption key can access the plain-text content of the message. The decryption key is the same key as the encryption key, using SRTP counter mode and f8 encryption transforms, which are vulnerable to message tampering and need SRTP message authentication to detect such tampering. "Message authentication" and "message integrity validation" generally mean the same thing in IETF security standards: an SRTP message is authenticated after a successful HMAC integrity check [RFC3711], which proves that the message came from the holder of an SRTP master key and wasn't altered en route. 🔍 Such an "authentic" message can still be captured by an attacker and "replayed" when the attacker re-inserts the packet into the channel. A replayed packet can cause a variety of bad effects on the session, so SRTP uses the extended sequence number to detect replayed SRTP packets [RFC3711]. 🫣
The SRTP specification identifies which services and features are default values that are normative-to-implement (such as AES_CM_128_80) versus normative-to-use (such as AES_CM_128_32). ✨
8.1. Authentication of Packets 📦
Security descriptions as defined herein signal security services for RTP packets. RTP messages are vulnerable to a variety of attacks, such as replay and forging. To limit these attacks, SRTP message integrity mechanisms SHOULD be used (SRTP replay protection is always enabled). 💪
8.2. Keystream Reuse 🔁
SRTP security descriptions signal configuration parameters for SRTP sessions. Misconfigured SRTP sessions are vulnerable to attacks on their encryption services when running the crypto suites defined in Sections 6.2.1, 6.2.2, and 6.2.3. An SRTP encryption service is "misconfigured" when two or more media streams are encrypted using the same keystream of AES blocks. When senders and receivers share derived session keys, SRTP requires that the SSRCs of session participants serve to make their corresponding keystreams unique. That gets violated in the case of SSRC collision: SRTP SSRC collision drastically weakens SRTP or SRTCP payload encryption during the time that identical keystreams are used [RFC3711]. 😭 An attacker, for example, might collect SRTP and SRTCP messages and wait for a collision. This attack on the AES-CM and AES-f8 encryption is avoided entirely when each media stream has its own unique master key in both the send and receive direction. This specification restricts use of SDP security descriptions to unicast point-to-point streams, so keys aren't shared between SRTP hosts, and the master keys used in the send and receive direction for a given media stream are unique. 🫶
8.3. Signaling Authentication and Signaling Encryption 🤫
There's no reason to take on the complexity and computational expense of SRTP when its key establishment is exposed to unauthorized parties. 🙅♀️ In most cases, the SRTP crypto attribute and its parameters are vulnerable to denial-of-service attacks when they're carried in an unauthenticated SDP message. In some cases, the integrity or confidentiality of the RTP stream can be compromised. For example, if an attacker sets UNENCRYPTED for the SRTP stream in an offer, this could result in the answerer not decrypting the encrypted SRTP messages. In the worst case, the answerer might itself send unencrypted SRTP and leave its data exposed to snooping. 👀
So, IT IS REQUIRED that MIME secure multiparts, IPsec, TLS, or some other data security service be used to provide message authentication for the encapsulating protocol that carries the SDP messages having a crypto attribute (a=crypto). Furthermore, IT IS REQUIRED that encryption of the encapsulating payload be used whenever a master key parameter (inline) appears in the message. Failing to encrypt the SDP message containing an inline SRTP master key renders the SRTP authentication or encryption service useless in practically all circumstances. Failing to authenticate an SDP message that carries SRTP parameters renders the SRTP authentication or encryption service useless in most practical applications. 💀
When the communication path of the SDP message goes through intermediate systems that inspect parts of the SDP message, security protocols such as [IPsec] or TLS SHOULD NOT be used for encrypting and/or authenticating the security description. In the case of intermediate-system processing of a message containing SDP security descriptions, the a=crypto attributes SHOULD be protected end-to-end, so that the intermediate system can neither modify the security description nor access the keying material. Network or transport security protocols that terminate at each intermediate system, therefore, SHOULD NOT be used for protecting SDP security descriptions. A security protocol SHOULD allow the security descriptions to be encrypted and authenticated end-to-end, independently of the portions of the SDP message that any intermediate system modifies or inspects. MIME secure multiparts are RECOMMENDED for protecting SDP messages that are processed by intermediate systems. 🧁
9. Grammar 📜
In this section, we first provide the ABNF grammar for the generic crypto attribute, and then we provide the ABNF grammar for the SRTP-specific use of the crypto attribute. 💖
9.1. Generic "Crypto" Attribute Grammar ✨
okay so this is where the grammar for the generic crypto attribute lives, and bestie, it's giving very precise energy 💅 Here's the ABNF, copy-pasted exactly so nothing gets lost in translation:
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = 1*(%x21-3A / %x3C-7E) ; visible (printing) chars
; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters
where WSP, ALPHA, DIGIT, and VCHAR are defined in [RFC4234].9.2. SRTP "Crypto" Attribute Grammar 🎀
this one is the SRTP-specific version, and it's honestly so main character 🦋 The text says it's an Augmented BNF [RFC4234] grammar for the SRTP-specific use of the SDP crypto attribute, and here it is:
crypto-suite = srtp-crypto-suite
key-method = srtp-key-method
key-info = srtp-key-info
session-param = srtp-session-param
srtp-crypto-suite = "AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext
srtp-key-method = "inline"
srtp-key-info = key-salt ["|" lifetime] ["|" mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 3 of
; RFC3548
lifetime = ["2^"] 1*(DIGIT) ; see section 6.1 for "2^"
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
srtp-session-param = kdr /
"UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" /
fec-order /
fec-key /
wsh /
srtp-session-extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24,
; power of two
fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC4234]
; first character must not be dash ("-")10. IANA Considerations 🌸
10.1. Registration of the "crypto" Attribute 💖
okay so IANA registered a brand new SDP attribute, and here's the full scoop 👑
Attribute name: crypto
Long form name: Security description cryptographic attribute
for media streams
Type of attribute: Media-level
Subject to charset: No
Purpose: Security descriptions
Appropriate values: See Section 410.2. New IANA Registries and Registration Procedures 🧚
this section defines a new IANA registry with sub-registries for the SDP security descriptions, and the IANA made an SDP Security Description registry that looks like this 🌈
SDP Security Descriptions
|
+- Key Methods (described in 10.2.1)
|
+- Media Stream Transports (described in 10.2.2)
|
+- Transport1 (e.g., SRTP)
| |
| +- Supported Key Methods (e.g., inline)
| |
| +- crypto suites
| |
| +- session parameters
|
+- Transport2
: :10.2.1. Key Method Registry and Registration 🔥
the IANA made a new subregistry for SDP security description key methods. An IANA key method registration MUST be documented in an RFC following the [RFC2434] Standards Action, and it MUST give the name of the key method following the grammar for key-method-ext in Section 9.1. no skipping this part, bestie 🙈
10.2.2. Media Stream Transport Registry and Registration 🦋
IANA also made a new subregistry for SDP security description Media Stream Transports. An IANA media stream transport registration MUST be documented in an RFC following the RFC 2434 Standards Action and the procedures in Sections 4 and 5 of this document. The registration MUST give the name of the transport and a list of supported key methods.
Also, every new media stream transport registry MUST... well, not MUST, it just has to contain a crypto-suite registry and a session parameter registry, plus IANA instructions for filling those in ✨ (the original says it "must contain", so that's the rule, periodt 💅)
10.3. Initial Registrations 🍓
10.3.1. Key Method 💜
the following security descriptions key methods are registered, no drama:
inline10.3.2. SRTP Media Stream Transport 🌙
IANA made an SDP Security Description Media Stream Transport subregistry for "SRTP". The supported key method is "inline". The reference for the SDP security description for SRTP is this document 🫶
10.3.2.1. SRTP Crypto Suite Registry and Registration 💫
IANA made a new subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions. An IANA SRTP crypto suite registration MUST indicate the crypto suite name following the grammar for srtp-crypto-suite-ext in Section 9.2.
The semantics of the SRTP crypto suite MUST be described in an RFC following the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters.
These SRTP crypto suites are registered:
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80The reference for these crypto suites is provided in this document ✨
10.3.2.2. SRTP Session Parameter Registration 🎀
IANA made a new subregistry for SRTP session parameters under the SRTP transport of the SDP Security Descriptions. An IANA SRTP session parameter registration MUST indicate the session parameter name (srtp-session-extension as defined in Section 9.2); the name MUST NOT begin with the dash character ("-").
The semantics of the parameter MUST be described in an RFC following the RFC 2434 Standards Action. If values can be assigned to the parameter, then the format and possible values that can be assigned MUST also be described in the RFC following the RFC 2434 Standards Action. Also, it MUST be specified whether the parameter is declarative or negotiated in the offer/answer model.
These SRTP session parameters are registered:
KDR
UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP
FEC_ORDER
FEC_KEY
WSHThe reference for these parameters is this document 🌸
11. Acknowledgements 💌
this document is a product of the IETF MMUSIC working group and has benefited from comments from its participants 🫶 It also benefited from discussions with Elisabetta Cararra, Earl Carter, Per Cederqvist, Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, Mike Thomas, Brian Weis, and Magnus Westerlund. Thank you all, you're the real MVPs 👑
12. Normative References 📚
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.13. Informative References ✨
Okay bestie, here's the extra reading list 📚 Every citation is kept exactly as written, so you can go chase down the originals 💅
- [sprecon] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol Media Streams", Work in Progress, October 2005.
- [RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
- [Bellovin] Bellovin, S., "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996.
- [GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [kink] Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
- [ike] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [ipsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [maxprate] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
- [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
- [s/mime] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
- [pgp/mime] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [keymgt] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
- [mikey] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [skeme] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for the Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
- [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
- [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [srtpf] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
Appendix A - Rationale for Keying Material Directionality 💖
okay so SDP security descriptions put the keying material for the sending direction right inside the SDP 🔐 which means the key in an SDP message is actually a decryption key for whoever receives that message. that's the total opposite of most of the stuff in SDP, which describes the receiving (or receiving and sending) direction. this reversed directionality makes things kinda messy with the offer/answer model, especially with SIP, where early media and forking need extra thought (see Section 7.3). but there are good reasons it was done this way ✨ here they are:
First of all, there's the general security philosophy of letting the entity that sends the traffic decide which key protects it. SRTP uses counter mode, which is secure when counters don't overlap among senders who share a master key 🫶 and the surest way to avoid counter overlap is for each endpoint to generate its own master key.
Secondly, if SDP security descriptions had kept the normal SDP directionality, early media and SIP forking would've been a whole mess 😭 if one offer makes multiple answers and the key was for the receive direction, some parameter values (like lifetime) would have to be shared between all the answerers (the media senders). that gets super complicated and might need changes or extensions to SRTP. and other problems popped up too, which we'll get into below 🙈
Scenario A: Non-Forking Case 🎀
in this one, the offer includes the receiving keying material, the answerer gets it and starts sending data packets toward the offerer. if there was a single crypto attribute in the offer, there's zero ambiguity about which crypto suite is being used, so the incoming packet can be processed ✅ but if the offer had multiple alternative crypto-attributes, the offerer wouldn't know which one got chosen. so if the offerer receives packets before the answer comes back, they literally can't process them (problem 1). (using the MKI has been suggested as one possible fix, but it adds per-packet overhead 💀)
Scenario B: Serial Forking Case 🦋
okay this one is giving drama 👑 Alice generates an offer to Bob, and Bob starts sending (early) media toward Alice before any answer comes back. we're assuming we're not also dealing with Scenario A (so the offer has only one crypto-attribute), and that Bob uses a Synchronization Source (SSRC) value of 1 for his SRTP and SRTCP packets. so Alice has a crypto-context for SSRC 1, including the associated ROC (Roll Over Counter) and SEQ (RTP Sequence Number). then Bob forwards the call to Carol (Bob still hasn't generated an answer) 😬 at this point Bob has Alice's key, which can sometimes be a security weakness. as things go on, Carol gets the original offer, including the offered crypto-attribute, and starts sending media packets toward Alice. and wouldn't you know it, Carol picks SSRC 1 too, just like Bob 🙃 now there's a chance for what RFC 3711 calls a "two-time pad" issue (problem 2), plus the ROC might be out of sync between Alice and Carol (problem 3). since Bob and Carol are (presumably) using different source transport addresses, the SSRC reuse doesn't count as an SSRC collision (although Alice might still read it that way). per RFC 3711, since the master key would be shared between Bob and Carol here, it is RECOMMENDED that Alice leave the session at that point to dodge the two-time pad issue. it's also worth noting that RFC 3711 recommends against sharing SRTP master keys, which forking can accidentally cause when the keying material is for the receiving direction.
now let's run the same scenario again, but this time the keying material in the offer (and answer) is the sending keying material, the way SDP security descriptions actually specify it ✨ Bob again picks SSRC 1, and Bob needs to send an answer back to Alice, because Alice has to learn Bob's sending key. Bob also starts sending media toward Alice (some clipping may happen until Alice gets Bob's answer). Bob forwards the call to Carol, who also starts sending early media using SSRC 1. but Carol has to generate a new answer (for the dialog between Alice and Carol) so Alice can process Carol's packets 💅 once Alice gets that answer, she can kick off a new offer/answer exchange to move the session to another transport address (as described in Section 7.3). in this case there's one master key per session and a unique keystream, whether or not the SSRCs collide 🌈
Scenario C: Parallel Forking Case 🧚
in this one, Alice generates an offer (with receive keying material) that gets forked to Bob and Carol in parallel. Bob and Carol both start sending packets (early media) to Alice. if Bob and Carol pick different SSRCs, everything's fine at first 🌸 but one of the crypto context parameters is the master key lifetime, and since Bob and Carol share the same master key (without either of them knowing), neither one knows when they need to rekey (problem 4) 😭 and if they pick the same SSRC, we're back to the two-time pad problem (problem 2).
In summary, if the keying material were for the receive direction, we'd run into these problems:
- Problem 1: Offerer does not know which of multiple crypto offers was chosen by the answerer.
- Problem 2: SSRC reuse (or SSRC collisions) between multiple answerers (serial or parallel forking) may lead to the two-time pad issue.
- Problem 3: Part of the crypto context parameters (specifically the ROC) is not communicated but derived, and if we allow multiple entities to use the same SSRC (sequentially), the ROC can be wrong.
- Problem 4: All crypto contexts that share a master key need to maintain a shared set of counters (master key lifetime), and if we allow multiple entities on different platforms to share a master key, we would need a mechanism to synchronize these counters.
Problem 1 could be addressed by using the MKI as proposed separately, but that means extra bandwidth for every SRTP media packet 📦 solving problem 2 means being able to synchronize SSRC values with the answerer (or abandoning the session when SSRC reuse or SSRC collisions happen). problem 3 means being able to synchronize ROC values on a per-SSRC basis (or abandoning the session when SSRC reuse occurs). problem 4 could be solved by having the offerer (Alice, i.e., the entity receiving media) work out how many packets have actually been generated by the whole set of senders to Alice, and then be the one to initiate the rekeying. with packet losses and so on this isn't foolproof, but in practice it could probably be handled with a reasonable safety margin 🫶
so to wrap up this appendix 💜 from an offer/answer and SIP point of view, it would be expected to have the offer (and answer) keying material be the receive keying material. but doing that would trade security for SIP friendliness (hello two-time pad and master key lifetime issues) and would violate the RFC 3711 rule for sharing an SRTP master key across SRTP sessions.
Authors' Addresses 🎀
These are the authors, along with their contact details, exactly as they appear in the document:
Flemming Andreasen
Cisco Systems, Inc.
499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA
EMail: fandreas@cisco.com
Mark Baugher
5510 SW Orchid Street
Portland, Oregon 97219 USA
EMail: mbaugher@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134 USA
EMail: dwing@cisco.comFull Copyright Statement 🌸
Copyright (C) The Internet Society (2006).
this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 💅
the document and the info in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty. here's the exact legal wording:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🦋
the IETF takes no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid or how far they reach, or on whether any license for them is available. it also doesn't say it has independently checked for any such rights. info about how rights work for RFC documents is in BCP 78 and BCP 79 📚
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be available, and the results of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍
the IETF invites anyone who's interested to tell it about 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 is provided by the IETF Administrative Support Activity (IASA) 👑
📦 where this page comes from
- ietf: rfc4568 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms