RFC 5124
Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
part 1 of 4 🧚 more coming, bestie!
RFC 5124: Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) 🎀
okay so here's the title block, bestie 💅
- Network Working Group: this one came from the Network Working Group 🌸
- RFC number: 5124 📜
- Authors: J. Ott (Helsinki University of Technology) and E. Carrara (KTH) 🫶
- Category: Standards Track 🔥
- Date: February 2008 🦋
- Obsoletes and updates: the title block doesn't list anything here, so nothing to obsolete or update 🙈
Status of This Memo ✨
so this part is the official stuff 💅 It's an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 And yes, distribution of this memo is unlimited 🌈
Abstract 🌸
okay so the abstract is giving main character energy 👑 An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) for timely feedback from receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo combines both profiles so you can have secure RTP communications with feedback 🔐✨
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Definitions ................................................4
1.2. Terminology ................................................4
2. SAVPF Rules .....................................................4
2.1. Packet Formats .............................................5
2.2. Extensions .................................................5
2.3. Implications from Combining AVPF and SAVP ..................6
3. SDP Definitions .................................................6
3.1. Profile Definition .........................................6
3.2. Attribute Definitions ......................................6
3.3. Profile Negotiation ........................................6
3.3.1. Offer/Answer-Based Negotiation of Session
Descriptions ........................................7
3.3.2. RTSP-Based Negotiation of Session Descriptions ......8
3.3.3. Announcing Session Descriptions .....................9
3.3.4. Describing Alternative Session Profiles .............9
3.4. Examples ..................................................10
4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities ............13
5. Security Considerations ........................................14
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................161. Introduction ✨
okay so the Real-time Transport Protocol, its RTP Control Protocol buddy (RTP/RTCP, RFC 3550) [1], and the audiovisual profile for minimal control (RFC 3551) [2] together define how time-based media gets sent across an IP network 🎬 RTP keeps timing intact and spots packet losses, and RTP payload formats frame (continuous) media properly in a packet-based world 📦 RTCP lets receivers report on reception quality and lets everyone in an RTP session learn about each other 💕
RTP only gives you rudimentary encryption for RTP and RTCP packets, so that's kinda sad 😭 Secure RTP (RFC 3711) [4] defines an RTP profile ("SAVP") for secure RTP media sessions, with methods for proper RTP and RTCP packet encryption, integrity, and replay protection 🔐 The initial negotiation of SRTP and its security parameters needs to happen out-of-band, for example with the Session Description Protocol (SDP, RFC 4566) [6] plus the extensions for conveying keying material (RFC 4567 [7], RFC 4568 [8]) 🗝️
RTP also gives limited support for timely feedback from receivers to senders, usually through reception statistics reports at somewhat regular intervals that depend on group size, average RTCP packet size, and available RTCP bandwidth 📊 The extended RTP profile for RTCP-based feedback ("AVPF") (RFC 4585, [3]) lets session participants give immediate feedback statistically while keeping the average RTCP data rate for all senders 💨 Just like SAVP, AVPF and its parameters need to be negotiated out-of-band with SDP (RFC 4566, [6]) and the extensions defined in RFC 4585 [3] 🧚
Both SRTP and AVPF are RTP profiles and both need to be negotiated 🤔 That means one or the other can be used, but both profiles can't be negotiated for the same RTP session (using one SDP session level description) 🙃 Still, secure communications and timely feedback together is super desirable, so this document specifies a new RTP profile ("SAVPF") that combines the features of SAVP and AVPF 💖
SAVP and AVPF are largely orthogonal, so combining them is mostly straightforward 🫶 No sophisticated algorithms need to be specified here. Instead, this document refers to both existing profiles and only describes the implications of their combination, the possible deviations from the rules of the existing profiles, and the negotiation process 🦋
1.1. Definitions 🌸
The definitions of RFC 3550 [1], RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] apply 📜
The following definitions are specifically used in this document:
RTP session: An association among a set of participants communicating with RTP as defined in RFC 3550 [1]. 🎀
(SDP) media description: This term refers to the specification given in a single m= line in an SDP message. An SDP media description can define only one RTP session 🍓
Media session: A media session is a collection of SDP media descriptions that are semantically grouped to represent alternatives of the same communications means. One of them gets negotiated or chosen for a communication relationship, and the corresponding RTP session gets instantiated. If no common session parameters suitable for the involved endpoints can be found, the media session gets rejected. In the simplest case, a media session equals an SDP media description and equals an RTP session 💅
1.2. Terminology 🔥
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 RFC 2119 [5] 🧠
2. SAVPF Rules 💖
SAVP is defined as an intermediate layer between RTP (following the regular RTP profile AVP) and the transport layer (usually UDP) ✨ That gives a two-layer hierarchy inside the Real-time Transport Protocol. In SAVPF, the upper (AVP) layer gets replaced by the extended RTP profile for feedback (AVPF) 🦋
AVPF changes the timing rules for sending RTCP packets and adds extra RTCP packet formats specific to feedback 🕰️ These functions don't depend on whether RTCP packets are encrypted and/or integrity protected afterward. The functioning of the AVPF layer stays unchanged in SAVPF 🫶
The AVPF profile derives from RFC 3550 [1] the (optional) use of the encryption prefix for RTCP. The encryption prefix MUST NOT be used within the SAVPF profile. It isn't used in SAVP either, since it only applies to the encryption method specified in [1] 🙅♀️
The SAVP part adds extra fields to the end of RTP and RTCP packets and runs cryptographic transforms on (some of) the RTP/RTCP packet contents 🔐 This behaviour stays unchanged in SAVPF. The average RTCP packet size calculation that the AVPF layer does for timing purposes MUST take into account the fields added by the SAVP layer 🧮
The SRTP part only kicks in when the RTP or RTCP was scheduled by the "higher" AVPF layer or received from the transport protocol, no matter its timing and contents ⭐
2.1. Packet Formats 🎀
AVPF defines extra packet formats to provide feedback information. Those extra packet formats defined in RFC 4585 [3] (and further ones defined elsewhere for use with AVPF) MAY be used with SAVPF 💕
SAVP defines a modified packet format for SRTP and SRTCP packets. It's basically the RTP/RTCP packet formats plus some trailing protocol fields for security purposes 🍰 For SAVPF, all RTCP packets MUST be encapsulated as defined in Section 3.4 of RFC 3711 [4] 📦
2.2. Extensions 🌈
Extensions to AVPF RTCP feedback packets defined elsewhere MAY be used with the SAVPF profile, as long as those extensions conform to the extension rules of RFC 4585 [3] 🧩
Additional extensions (e.g., transforms) defined for SAVP following the rules of Section 6 of RFC 3711 [4] MAY also be used with the SAVPF profile. The overhead per RTCP packet depends on the extensions and transforms chosen. New extensions and transforms added in the future MAY introduce yet unknown further per-packet overhead 👀
Finally, further extensions specifically to SAVPF MAY be defined elsewhere 🧚
2.3. Implications from Combining AVPF and SAVP 🔥
AVPF aims at -- statistically -- allowing receivers to provide timely feedback to senders ⏱️ How often receivers, on average, get to send feedback depends on the RTCP bandwidth, the group size, and the average size of an RTCP packet 📈 SRTCP (see Section 3.4 of RFC 3711 [4]) adds extra fields (some of them configurable in length) at the end of each RTCP packet. Those fields are probably at least some 10 to 20 bytes in size (14 bytes as default) 🫠
Note that extensions and transforms defined in the future, as well as the configuration of each field length, MAY add greater overhead 👀 By using SRTP, the average size of an RTCP packet increases, which reduces how often (timely) feedback can be provided. Application designers need to be aware of this and take precautions so that the RTCP bandwidth shares are maintained ⚠️
This MUST be done by adjusting the RTCP variable avg_rtcp_size to reflect the size of the SRTCP packets 🚨
3. SDP Definitions 🧚
3.1. Profile Definition 💅
The AV profiles defined in RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] are referred to as "AVP", "AVPF", and "SAVP", respectively, in the context of, e.g., the Session Description Protocol (SDP) [3]. The combined profile specified in this document is called "SAVPF" 🎀
3.2. Attribute Definitions 🌸
SDP attributes for negotiating SAVP sessions are defined in RFC 4567 [7] and RFC 4568 [8]. Those attributes MAY also be used with SAVPF. The rules defined in [7] and [8] apply 🗝️
SDP attributes for negotiating AVPF sessions are defined in RFC 4585 [3]. Those attributes MAY also be used with SAVPF. The rules defined in [3] apply 💖
3.3. Profile Negotiation 💖
Okay so session descriptions for RTP sessions can get passed around by multimedia-specific protocols, like the SDP offer/answer model (RFC 3264, [9]) that works with the Session Initiation Protocol (SIP) [15], the Real Time Streaming Protocol (RTSP) [10], or the Session Announcement Protocol (SAP) [11]. But they can also travel over email, NetNews, web pages, etc. 🦋
The offer/answer model lets the session parameters get negotiated using the SDP attributes from RFC 4567 [7] and RFC 4568 [8]. Below, we walk through the negotiation process in terms of the offer/answer model. ✨
After that, we cover the cases that don't use offer/answer. RTSP-specific negotiation support comes from RFC 4567 [7], as discussed in Section 3.3.2, and support for SAP announcements (with no negotiation at all) is in Section 3.3.3. 💅
3.3.1. Offer/Answer-Based Negotiation of Session Descriptions
Negotiations (like RTP profiles, codecs, transport addresses, etc.) happen per media session (for example, per m= line in SDP). If one media session's negotiation fails, the others MAY still succeed. 🎀
Different RTP profiles MAY be used in different media sessions. When you're negotiating a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Heads up, though: SAVP and SAVPF entities MAY be mixed in a single RTP session (see Section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session and let the answerer choose one of the profiles. 🌸
Provided a mechanism for offering alternative security profiles shows up (which is still in the works [14]), an offerer that can support more than one of these profiles for a certain media session SHOULD always offer all the alternatives acceptable in a certain situation. The alternatives SHOULD be listed in order of preference, and the offerer SHOULD prefer secure profiles over non-secure ones. The offer SHOULD NOT include both a secure alternative (SAVP and SAVPF) and an insecure alternative (e.g., AVP and AVPF) in the same offer, because this may enable bidding down and other attacks. So if both secure and non-secure RTP profiles are offered (e.g., for best-effort SRTP [14]), the negotiation signaling MUST be protected appropriately to avoid such attacks. 😭
Bidding down and other attacks are not something to ignore, bestie. That's why the rule about protecting the negotiation signaling is a MUST, not a suggestion. 💀
If an offer contains multiple alternative profiles, the answerer SHOULD prefer a secure profile (if supported) over non-secure ones. Among the secure or insecure profiles, the answerer SHOULD select the first acceptable alternative to respect the offerer's preference. 🧚
If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. 🙈
If a media description in an offer does not use SAVPF but the answerer wants to use SAVPF, the answerer MUST reject the media session. The answerer MAY provide a counter-offer with a media description indicating SAVPF in a subsequently initiated offer/answer exchange. 👑
3.3.2. RTSP-Based Negotiation of Session Descriptions
RTSP [10] does not support the offer/answer model. However, RTSP can still exchange media session parameters (including profile and address information) by means of the Transport header. SDP-based key management as defined in RFC 4567 [7] adds an RTSP header (KeyMgmt) to carry a key management protocol (including keying material). 🦋
The RTSP Transport header MAY be used to determine the profile for the media session. Conceptually, the rules defined in Section 3.3.1 apply accordingly. Here's the detailed flow: an SDP description (e.g., retrieved from the RTSP server by means of DESCRIBE) contains the description of the media streams of the particular RTSP resource. ✨
The RTSP client MUST select exactly one of the profiles per media stream it wants to receive. It MUST do so in the SETUP request. The RTSP client MUST indicate the chosen RTP profile by indicating the profile and the full server transport address (IP address and port number) in the Transport header included in the SETUP request. The RTSP server's response to the client's SETUP message MUST confirm this profile selection or refuse the SETUP request (the latter of which it should not do after offering the profiles in the first place). 💖
Note: To change any of the profiles in use, the client needs to tear down this media stream (and possibly the whole RTSP session) using theTEARDOWNmethod and re-establish it usingSETUP. This may change as soon as media updating (similar to a SIPUPDATEorre-INVITE) becomes specified. 🍓
When using the SDP key management [7], the KeyMgmt header MUST be included in the appropriate RTSP messages if a secure profile is chosen. If different secure profiles are offered in the SDP description (e.g., SAVP and SAVPF) and different keying material is provided for these, then after choosing one profile in the SETUP message, only the KeyMgmt header for the chosen one MUST be provided. The rules for matching KeyMgmt headers to media streams according to RFC 4567 [7] apply. 🔥
3.3.3. Announcing Session Descriptions
Protocols that don't let you negotiate session descriptions interactively (e.g., SAP [11], or descriptions posted on a web page or sent by mail) put the responsibility for adequate access to the media sessions on the initiator of a session. 🌈
The initiator SHOULD provide alternative session descriptions for multiple RTP profiles, as far as that's acceptable to the application and the purpose of the session. If security is desired, SAVP may be offered as an alternative to SAVPF, but AVP or AVPF sessions SHOULD NOT be announced unless other security means not relying on SRTP are employed. 🧚♀️
The SDP attributes defined in RFC 4567 [7] and RFC 4568 [8] may also be used for the security parameter distribution of announced session descriptions. ⭐
The security scheme description defined in RFC 4568 [8] requires a secure communications channel to keep third parties from eavesdropping on the keying parameters and messing with them. Therefore, SAP security (as defined in RFC 2974 [11]), S/MIME [12], HTTPS [13], or other suitable mechanisms SHOULD be used for distributing or accessing these session descriptions. 🫶
3.3.4. Describing Alternative Session Profiles
SAVP and SAVPF entities MAY be mixed in the same RTP session (see also Section 4), and so MAY AVP and AVPF entities. Other combinations, i.e., between secure and insecure profiles, in the same RTP session are incompatible and MUST NOT be used together. 💜
If negotiation between the involved peers is possible (as with the offer/answer model per Section 3.3.1 or RTSP per Section 3.3.2), alternative (secure and non-secure) profiles MAY be specified by one entity (e.g., the offerer), and a choice of one profile MUST be made by the other. If no such negotiation is possible (e.g., with SAP as per Section 3.3.3), incompatible profiles MUST NOT be specified as alternatives. 🦋
The negotiation of alternative profiles is for further study. 🔮
RTP profiles MAY be mixed arbitrarily across different RTP sessions. 🌸
3.4. Examples ✨
okay bestie, this section is all about showing how SDP negotiates secure and non-secure profiles, and it's literally so cute 🎀. Depending on which keying mechanism you use and how you set it up, your SDP messages usually need integrity protection, and for some mechanisms they also need confidentiality protection 🔐. For example, you could say integrity protection is required for the a=fingerprint of Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], and confidentiality is required for the a=crypto line from RFC 4568 [8] (Security Descriptions) 💜.
Example 1 is a secure session with audio and dual tone multi-frequency (DTMF) for point-to-point calls, where the DTMF stream uses Generic NACKs 🦋. The key management protocol here is MIKEY. This session description (the offer) can go inside a SIP INVITE or a 200 OK, and it tells the other side that the sender can handle and wants feedback for the DTMF stream it sends 🫶. The answer can come back in a 200 OK or an ACK. The security protocol parameters get negotiated using the SDP extensions from RFC 4567 [7] ✨.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...Example 2 shows the same feedback parameters as Example 1, but this time it uses the secure descriptions syntax [8] 🌸. Heads up, though: the key part of the a=crypto attribute is not protected against eavesdropping 😭. That means the session description has to be exchanged over a secure communication channel, no exceptions 🔒.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
:32Example 3 is basically Example 1 again, but now it shows the back-and-forth between the offerer and the answerer in an offer/answer exchange, still using MIKEY to negotiate the keying material 🍓.
Offer:
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nackAnswer:
v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nackExample 4 is video streaming controlled over RTSP, and it's giving full main character energy 🎬👑. A client grabs a media description from a server with DESCRIBE and gets a static SDP description with no keying parameters, but the media description shows that both secure and non-secure (S)AVPF media sessions are available 🧚. There's a mechanism that lets you explicitly flag these alternatives (secure vs. non-secure) in the session description, and it's still being defined [14] 🔜. The client then sends a SETUP request and picks its choice by putting the matching profile in the Transport parameter. It also includes a KeyMgmt header to carry its security parameters, and the server matches that with its own KeyMgmt header in the response 🤝. Only one media session gets chosen here, so the aggregate RTSP URI is enough to identify it 💖.
RTSP DESCRIBE request-response pair (optional):
DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp
200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316
v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
+-Alternative one-----------------+
|m=video 49170 RTP/SAVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+
+-Alternative two-----------------+
|m=video 49172 RTP/AVPF 96 |
|a=rtpmap:96 H263-2000/90000 |
|a=rtcp-fb:96 nack |
+---------------------------------+RTSP SETUP request-response pair:
SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."
200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTEExample 5 is a multicast audio/video session 📡🎶. It uses PCMU for audio and either H.261 or H.263+ for video, and the video source accepts Generic NACKs for both codecs and Reference Picture Selection for H.263 💅. The security protocol parameters get negotiated using the SDP extensions from RFC 4567 [7], applied at the session level. A description like this could be shared using the Session Announcement Protocol (SAP) 📣.
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities 🦋
okay so the SAVPF profile in this document is basically a combo of the SAVP profile [4] and the AVPF profile [3], and AVPF is itself an extension of the RTP profile from RFC 3551 [2] 💜.
SAVP and SAVPF use SRTP [4] for security 🔐. AVP and AVPF use plain RTP [1], so they don't give you security by themselves (unless external security mechanisms are applied, as discussed in Section 9.1 of RFC 3550 [1]) 😬. SRTP and RTP are not meant to interoperate, and their protocol entities aren't supposed to be part of the same RTP session. So AVP and AVPF on one side and SAVP and SAVPF on the other MUST NOT be mixed 🚫. That's a hard no, bestie.
RTP entities using the SAVP and SAVPF profiles MAY be mixed in a single RTP session 🌈. The interworking considerations from Section 5 of RFC 4585 [3] apply here ✨.
5. Security Considerations 🔐💅
The SAVPF profile inherits its security properties from the SAVP profile, so it's subject to the security considerations discussed in RFC 3711 [4] 💖. Compared to SAVP, SAVPF doesn't add or take away any security services, so no new powers, no lost powers 🙌.
There's a real desire to support security for media streams and, at the same time, backward compatibility with non-SAVP(F) nodes. It's a balancing act, and it's kind of a lot 😵💫.
Application designers, please hear me: security SHOULD NOT be traded for interoperability 🚨. If information is going to be distributed to closed groups (i.e., confidentially protected), it's RECOMMENDED not to offer alternatives for a media session other than SAVP and SAVPF, as described in Sections 3.3 and 3.4, unless other security mechanisms are used, e.g., the ones described in Section 9.1 of RFC 3550 [1] 🙅♀️. Similarly, if integrity protection matters to you, it's RECOMMENDED not to offer the alternatives other than SAVP and SAVPF, unless other mechanisms are known to be in place that can guarantee it, e.g., the lower-layer mechanisms described in Section 9 of RFC 3550 [1] 🛡️.
Offering secure and insecure profiles at the same time may open you up to bidding down attacks 💀. So such a mix of profile offers SHOULD NOT be made. Don't do it, periodt 🙅♀️.
Note that the rules for sharing master keys apply as described in RFC 3711 [4] (e.g., Section 9.1) 🗝️. In particular, the same rules for avoiding the two-time pad (keystream reuse) apply: a master key MUST NOT be shared among different RTP sessions unless the SSRCs used are unique across all the RTP streams of the RTP sessions that share the same master key 🧩.
When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever comes first), the key management MUST be called to provide new master key(s), and previously stored and used keys MUST NOT be used again. Otherwise, the session MUST be terminated 😱⏳.
Different media sessions may use a mix of different profiles, especially a secure profile and an insecure profile together 🎭. However, mixing secure and insecure media sessions may reveal information to third parties, so the decision to do so MUST be in line with a local security policy 🕵️♀️. For example, the local policy MUST specify whether it's acceptable to have, e.g., the audio stream unsecured while the related video is secured 🎥.
The security considerations in RFC 4585 [3] are valid, too 💜. Note in particular that applying the SAVPF profile implies mandatory integrity protection on RTCP. While this solves the problem of false packets from members not belonging to the group, it does not solve the issues related to a malicious member acting improperly 👀. Yikes, bestie.
6. IANA Considerations 📋🎀
The following contact information shall be used for all registrations included here:
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-451-2460The secure RTP feedback profile, as a combination of Secure RTP and the feedback profile, has been registered for the Session Description Protocol (specifically the type "proto"): RTP/SAVPF 🌸.
SDP Protocol ("proto"):
Name: RTP/SAVPF
Long form: Secure RTP Profile with RTCP-based Feedback
Type of name: proto
Type of attribute: Media level only
Purpose: RFC 5124
Reference: RFC 5124All the SDP attributes defined for RTP/SAVP and RTP/AVPF are valid for RTP/SAVPF, too 🧚.
7. Acknowledgements 🫶
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF 🌈. The authors would like to thank Magnus Westerlund, Colin Perkins, and Cullen Jennings for their comments 💖.
8. References ✨
8.1. Normative References 📚
Okay bestie, these are the docs this spec leans on hardcore, so you need them to read it. Here they are, fr fr 💅
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🎀
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 🦋
[3] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. ✨
[4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🔐
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🌸
[7] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. 🗝️
[8] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. 🍓
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 🧚
[10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. 🌈
8.2. Informative References 🫶
These ones are just for context, so they're giving background vibes rather than hard rules. Still super useful to peek at 👀
[11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. 📢
[12] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 📧
[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🌐
[14] Andreasen, F., "SDP Capability Negotiation", Work in Progress, December 2007. 🚧
[15] 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. 📞
[16] McGrew, D. and Rescorla, E., "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, November 2007. 🚧
Authors' Addresses 🎀
Meet the brains behind it, the people who wrote this whole thing!
Joerg Ott
Helsinki University of Technology
Otakaari 5A
FI-02150 Espoo
Finland
EMail: jo@comnet.tkk.fi
Phone: +358-9-451-2460
Elisabetta Carrara
Royal Institute of Technology
Stockholm
Sweden
EMail: carrara@kth.seFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 🔍
Legal stuff, but it matters, so here's the tea ☕
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5124 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms