RFC 5763
Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
📜 RFC 5763, the title block tea ☕
- Number: RFC 5763 🎀
- Title: Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) 💖
- Authors: J. Fischl (Skype, Inc.), H. Tschofenig (Nokia Siemens Networks), and E. Rescorla (RTFM, Inc.) 🫶
- Category: Standards Track 🔥
- ISSN: 2070-1721
- Date: May 2010 🌸
- Obsoletes and updates: the title block doesn't list any RFCs this one obsoletes or updates 👀
Abstract ✨
okay so bestie, this doc is all about how to use the Session Initiation Protocol (SIP) to set up a Secure Real-time Transport Protocol (SRTP) security context with Datagram Transport Layer Security (DTLS). 🦋 The big idea is a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key you'll show during the DTLS handshake. 🔐
the key exchange happens on the media path, not the signaling path, which is giving main character energy 💅 And if you want the fingerprint protected from being changed by intermediate proxies, the SIP Identity mechanism can do that for you. 🫶
Status of This Memo 📋
this one is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). ✅ If you want more on Internet Standards, check Section 2 of RFC 5741 📚
you can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc5763 💜
Copyright Notice 💅
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. 📜 Please actually read these carefully, because they spell out your rights and restrictions for this document. 🙈
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License. ⚠️
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️ The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. 😬 So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🌍
Table of Contents 🧚
1. Introduction ....................................................4
2. Overview ........................................................5
3. Motivation ......................................................7
4. Terminology .....................................................8
5. Establishing a Secure Channel ...................................8
6. Miscellaneous Considerations ...................................10
6.1. Anonymous Calls ...........................................10
6.2. Early Media ...............................................11
6.3. Forking ...................................................11
6.4. Delayed Offer Calls .......................................11
6.5. Multiple Associations .....................................11
6.6. Session Modification ......................................12
6.7. Middlebox Interaction .....................................12
6.7.1. ICE Interaction ....................................12
6.7.2. Latching Control without ICE .......................13
6.8. Rekeying ..................................................13
6.9. Conference Servers and Shared Encryptions Contexts ........13
6.10. Media over SRTP ..........................................14
6.11. Best Effort Encryption ...................................14
7. Example Message Flow ...........................................14
7.1. Basic Message Flow with Early Media and SIP Identity ......14
7.2. Basic Message Flow with Connected Identity (RFC 4916) .....19
7.3. Basic Message Flow with STUN Check for NAT Case ...........23
8. Security Considerations ........................................25
8.1. Responder Identity ........................................25
8.2. SIPS ......................................................26
8.3. S/MIME ....................................................26
8.4. Continuity of Authentication ..............................26
8.5. Short Authentication String ...............................27
8.6. Limits of Identity Assertions .............................27
8.7. Third-Party Certificates ..................................29
8.8. Perfect Forward Secrecy ...................................29
9. Acknowledgments ................................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Requirements Analysis ................................33
A.1. Forking and Retargeting (R-FORK-RETARGET,
R-BEST-SECURE, R-DISTINCT) ...............................33
A.2. Distinct Cryptographic Contexts (R-DISTINCT) .............33
A.3. Reusage of a Security Context (R-REUSE) ..................33
A.4. Clipping (R-AVOID-CLIPPING) ..............................33
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) .........33
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) .......34
A.7. (R-SIG-MEDIA, R-ACT-ACT) .................................34
A.8. Binding to Identifiers (R-ID-BINDING) ....................34
A.9. Perfect Forward Secrecy (R-PFS) ..........................34
A.10. Algorithm Negotiation (R-COMPUTE) ........................35
A.11. RTP Validity Check (R-RTP-VALID) .........................35
A.12. Third-Party Certificates (R-CERTS, R-EXISTING) ...........35
A.13. FIPS 140-2 (R-FIPS) ......................................35
A.14. Linkage between Keying Exchange and SIP Signaling
(R-ASSOC) ................................................35
A.15. Denial-of-Service Vulnerability (R-DOS) ..................35
A.16. Crypto-Agility (R-AGILITY) ...............................35
A.17. Downgrading Protection (R-DOWNGRADE) .....................36
A.18. Media Security Negotiation (R-NEGOTIATE) .................36
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) ......36
A.20. Media Recording (R-RECORDING) ............................36
A.21. Interworking with Intermediaries (R-TRANSCODER) ..........36
A.22. PSTN Gateway Termination (R-PSTN) ........................36
A.23. R-ALLOW-RTP ..............................................36
A.24. R-HERFP ..................................................371. Introduction ✨
okay so SIP [RFC3261] and SDP [RFC4566] are the duo that sets up multimedia sessions or calls 📞 SDP also handles TCP [RFC4145] and TCP/TLS connections for media sessions [RFC4572]. RTP [RFC3550] carries real-time media over UDP and TCP [RFC4571]. Datagram TLS [RFC4347] was introduced so TLS could work with datagram transport protocols like UDP and DCCP 🦋 This document explains how to set up SRTP [RFC3711] security over UDP using an extension to DTLS (see [RFC5764]) 🔐
The goal here is a key negotiation technique that lets devices with no prior relationship talk in encrypted form 💖 It also doesn't require devices to trust every call signaling element that got involved in routing or session setup. And the best part? It doesn't ask end users to do any extra work, and it doesn't need certificates signed by a well-known certificate authority to be deployed on every device 🫶
The media travels over a mutually authenticated DTLS session where both sides have certificates. Important: certificates are only being used as a carrier for the peers' public keys 🎀 DTLS doesn't have a mode for carrying bare keys, so this is purely a formatting thing. The certificates can be self-signed and fully self-generated, and all major TLS stacks can make them on demand 💅 However, third-party certificates MAY also be used if the peers have them (which reduces the need to trust intermediaries). The certificate fingerprints get sent in SDP over SIP as part of the offer/answer exchange 🧚
The fingerprint mechanism lets one side of the connection check that the certificate in the DTLS handshake matches the one used by the party in the signaling. BUT this needs some form of integrity protection on the signaling 👀 S/MIME signatures, as described in RFC 3261, or SIP Identity, as described in [RFC4474], give the highest level of security because malicious intermediaries can't modify them. Even hop-by-hop security, like what SIPS provides, offers some protection against modification by attackers who aren't in control of on-path signaling elements. Because DTLS-SRTP only requires message integrity and not confidentiality for the signaling, the number of elements that must have credentials and be trusted is way smaller 🙈 Specifically, if RFC 4474 is used, only the Authentication Service needs a certificate and needs to be trusted. Intermediate elements cannot undetectably modify the message, so they can't pull off a man-in-the-middle (MITM) attack. Compare that to SDESCRIPTIONS [RFC4568], which requires confidentiality for the signaling, so every intermediate element has to be trusted 😭
This approach is different from earlier attempts to secure media, where the authentication and key exchange protocol (e.g., Multimedia Internet KEYing (MIKEY) [RFC3830]) got piggybacked onto the signaling message exchange. With DTLS-SRTP, the media endpoints set up protection for the media traffic themselves, with only a cryptographic binding of the media keying to the SIP/SDP communication 🦋 It lets RTP and SIP work the usual way when there's no encrypted media 🌸
In SIP, the caller typically sends an offer, and the callee may send one-way media back to the caller before the caller gets a SIP answer. The approach here decouples the media key negotiation from the SIP signaling. That means early media can be set up before the SIP answer arrives, while keeping the important security property of letting the media sender choose some of the keying material for the media ✨ It also means media sessions can be changed, rekeyed, and otherwise modified after the initial SIP signaling without any extra SIP signaling. Main character energy 👑
Design decisions that affect where this specification applies are discussed in Section 3.
2. Overview ✨
Endpoints that want to set up an RTP media session do it by exchanging offers and answers in SDP messages over SIP 💌 In a typical use case, two endpoints negotiate to send audio over RTP using UDP.
Figure 1 shows a typical message exchange in the SIP trapezoid.
+-----------+ +-----------+
|SIP | SIP/SDP |SIP |
+------>|Proxy |----------->|Proxy |-------+
| |Server X | (+finger- |Server Y | |
| +-----------+ print, +-----------+ |
| +auth.id.) |
| SIP/SDP SIP/SDP |
| (+fingerprint) (+fingerprint,|
| +auth.id.) |
| |
| v
+-----------+ Datagram TLS +-----------+
|SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP |
|User Agent | Media |User Agent |
|Alice@X | <=================================> |Bob@Y |
+-----------+ +-----------+
Legend:
------>: Signaling Traffic
<-+-+->: Key Management Traffic
<=====>: Data Traffic
Figure 1: DTLS Usage in the SIP TrapezoidPicture this: Alice wants an encrypted audio session with Bob 🎧 Both Bob and Alice could use public-key-based authentication to set up a confidentiality-protected channel using DTLS.
Public-key-based cryptography tends to be kind of problematic when two arbitrary endpoints on the Internet need mutual authentication, so we look at more deployment-friendly options 🥺 This document uses one approach, and several others are discussed in Section 8.
Alice sends an SDP offer to Bob over SIP. If Alice only uses self-signed certificates for the communication with Bob, a fingerprint gets included in the SDP offer/answer exchange. That fingerprint binds the DTLS key exchange in the media plane to the signaling plane 🔗
The fingerprint alone protects against active attacks on the media, but NOT against active attacks on the signaling. To prevent active attacks on the signaling, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] MAY be used. When Bob receives the offer, the peers set up some number of DTLS connections (depending on how many media sessions there are) with mutual DTLS authentication (meaning both sides provide certificates). At this point, Bob can verify that Alice's credentials offered in TLS match the fingerprint in the SDP offer, and Bob can start sending media to Alice 📤 Once Bob accepts Alice's offer and sends an SDP answer, Alice can start sending confidential media to Bob over the right streams. Alice and Bob both check that the fingerprints from the certificates received during the DTLS handshakes match the fingerprints received in the SDP of the SIP signaling 🧐 This gives the security property that Alice knows her media traffic is going to Bob, and vice versa, WITHOUT needing global Public Key Infrastructure (PKI) certificates for Alice and Bob. (See Section 8 for the detailed security analysis.) 🫶
3. Motivation ✨
There's already prior work in this area (e.g., Security Descriptions for SDP [RFC4568], and Key Management Extensions [RFC4567] combined with MIKEY [RFC3830] for authentication and key exchange), but this specification is motivated as follows 💜
- TLS will be used to offer security for connection-oriented media. The design of TLS is well-known, and implementations are widely available 🌈
- This approach deals with forking and early media without requiring support for Provisional Response ACKnowledgement (PRACK) [RFC3262], while preserving the important security property of letting the offerer choose keying material for encrypting the media 🎀
- The establishment of security protection for the media path is also provided along the media path, NOT over the signaling path. In many deployment scenarios, the signaling and media traffic travel along different paths through the network 🛣️
- When RFC 4474 is used, this solution works even when the SIP proxies downstream of the authentication service are not trusted. There is no need to reveal keys in the SIP signaling or in the SDP message exchange, which is what SDESCRIPTIONS [RFC4568] does. Retargeting of a dialog-forming request (changing the value of the Request-URI), the User Agent (UA) that receives it (the User Agent Server, UAS) can have a different identity from the one in the To header field. When RFC 4916 is used, it is possible to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service 🕵️♀️
- In this method, synchronization source (SSRC) collisions do NOT result in any extra SIP signaling 💅
- Many SIP endpoints already implement TLS. The changes to existing SIP and RTP usage are minimal even when DTLS-SRTP [RFC5764] is used 🍓
4. 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 [RFC2119]. Yes, these are the official BCP 14 vibes 📜
DTLS/TLS uses the term "session" to mean a long-lived set of keying material that spans associations. In this document, consistent with SIP/SDP usage, we use "session" for a multimedia session, and use the term "TLS session" for the TLS construct 🧠 We use the term "association" for a particular DTLS cipher suite and keying material set that's associated with a single host/port quartet. The same DTLS/TLS session can be used to establish the keying material for multiple associations 🔑 For consistency with other SIP/SDP usage, we use the term "connection" when we're talking about a multimedia stream that isn't specifically DTLS/TLS 🌸
In this document, the term "Mutual DTLS" means that both the DTLS client and server present certificates, even if one or both certificates are self-signed 🦋
5. Establishing a Secure Channel ✨
okay so both endpoints show each other who they are during the DTLS handshake, and they do it with certificates 🔐 this doc uses certs in the same style as the one described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572], so go check that one if you want the full tea 🍵
If self-signed certs are used, the subjectAltName attribute inside the cert MAY use the uniform resource identifier (URI) of the user 🎀 this is only for debugging, bestie, and you don't need it to bind the cert to one of the communication endpoints. the integrity of the cert is locked in through the fingerprint attribute in the SDP. subjectAltName is not an important part of cert verification, so don't stress about it 💅
Generating public/private key pairs is kinda expensive 😭 so endpoints are not required to make fresh certs for every session.
The offer/answer model in [RFC3264] is what protocols like the Session Initiation Protocol (SIP) [RFC3261] use to set up multimedia sessions 🦋 On top of the usual SDP [RFC4566] stuff, each media description ("m=" line and its associated parameters) also gets a bunch of attributes from [RFC5764], [RFC4145], and [RFC4572].
Here's how it goes down. When an endpoint wants a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint 💌 that offer includes, as part of the SDP payload, the fingerprint of the cert the endpoint wants to use. the endpoint SHOULD send that SIP message to the offerer's SIP proxy over an integrity protected channel. the proxy SHOULD add an Identity header field following the procedures in [RFC4474]. the SIP message containing the offer SHOULD be sent to the offerer's SIP proxy over an integrity protected channel. when the far endpoint gets the SIP message, it can verify who sent it using the Identity header field. since that Identity header is a digital signature across several SIP header fields plus the body of the SIP message, the receiver can also be certain the message hasn't been tampered with after the signature was applied and added 🕵️♀️
The far endpoint (the answerer) may now establish a DTLS association with the offerer. alternately, it can say in its answer that the offerer should start the TLS association. either way, mutual DTLS certificate-based authentication will be used 🤝 after the DTLS handshake is done, info about the authenticated identities, including the certs, gets handed up to the endpoint application. the answerer can then check that the offerer's cert used in the DTLS handshake matches the certificate fingerprint in the offer's SDP. at this point, the answerer may tell the end user that the media is secured ✨ the offerer may only tentatively accept the answerer's cert, since it might not have the answerer's certificate fingerprint yet 🫶
When the answerer accepts the offer, it sends back an answer with the answerer's certificate fingerprint in it 💖 now the offerer can accept or reject the peer's cert, and the offerer can tell the end user the media is secured too.
Real talk: the whole authentication and key exchange for securing the media traffic happens in the media path through DTLS. the signaling path is only there to verify the peers' certificate fingerprints 🧚
The offer and answer MUST conform to the following requirements.
- The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of
setup:actpassand be prepared to receive aclient_hellobefore it receives the answer. The answerer MUST use either a setup attribute value ofsetup:activeorsetup:passive. Note that if the answerer usessetup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency.setup:activeallows the answer and the DTLS handshake to occur in parallel. Thus,setup:activeis RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending aClientHelloover each flow (host/port quartet). - The endpoint MUST NOT use the connection attribute defined in [RFC4145].
- The endpoint MUST use the certificate fingerprint attribute as specified in [RFC4572].
- The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. The security properties of this mechanism are described in Section 8.
- If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects.
6. Miscellaneous Considerations 💅
6.1. Anonymous Calls
DTLS-SRTP doesn't give you anonymous calling 🙈 but it doesn't stop it either. however, if you're careless with anonymous calling features like the ones in [RFC3325] or [RFC5767], DTLS-SRTP may let people deanonymize an otherwise anonymous call 💀 when anonymous calls are happening, the following procedures SHOULD be used to stop deanonymization.
when making anonymous calls, a new self-signed certificate SHOULD be used for each call so the calls can't be correlated as coming from the same caller. in situations where some correlation is acceptable, the same certificate SHOULD be used for a number of calls to keep authentication continuous; see Section 8.4.
also, in networks that deploy [RFC3325], RFC 3325 requires that the Privacy header field value defined in [RFC3323] needs to be set to id. this works together with the SIP identity mechanism so the user's identity isn't asserted when anonymous calls are enabled 🎭 and the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of the user who wants to place an anonymous call. just know that following this recommendation is NOT enough to actually anonymize you 🫣
6.2. Early Media
If an endpoint that wants to provide early media receives an offer, it MUST take the setup:active role 🎬 it can immediately establish a DTLS association with the other endpoint and start sending media. the setup:passive endpoint may not have validated the fingerprint of the active endpoint's certificate yet. the security aspects of media handling in this situation are discussed in Section 8.
6.3. Forking
In SIP, a request can fork to multiple endpoints 🍴 each forked request can end up with a different answer. assuming the requester provided an offer, each answerer will give a unique answer, and each answerer will form a DTLS association with the offerer. the offerer can then securely correlate the SDP answer it got in the SIP message by comparing the fingerprint in the answer to the hashed certificate for each DTLS association 🧩
6.4. Delayed Offer Calls
An endpoint can send a SIP INVITE request with no offer in it 🕰️ when that happens, the receiver(s) of the INVITE provide the offer in the response, and the originator provides the answer in the subsequent ACK request, or in the PRACK request [RFC3262] if both endpoints support reliable provisional responses. either way, the active endpoint still establishes the DTLS association with the passive endpoint, as negotiated in the offer/answer exchange.
6.5. Multiple Associations
When there are multiple flows (for example, multiple media streams, or non-multiplexed RTP and RTCP) the active side MAY perform the DTLS handshakes in any order 🌈 [RFC5764] Appendix B gives some guidance on running parallel DTLS handshakes. note that if the answerer ends up being active, it may only start handshakes on some subset of the potential streams (say, if audio and video are offered but it only wants audio). if the offerer ends up being active, the complete answer will be received before the offerer starts initiating handshakes.
6.6. Session Modification
Once an answer is given to the offerer, either endpoint MAY request a session modification, and that modification MAY include an updated offer 🔄 this session modification can ride in either an INVITE or UPDATE request. the peers can reuse the existing associations if they're compatible (meaning they have the same key fingerprints and transport parameters), or set up a new one following the same rules as initial exchanges, tearing down the existing association as soon as the offer/answer exchange is completed. note that if the active/passive status of the endpoints changes, a new connection MUST be established 🚨
6.7. Middlebox Interaction
There are a bunch of potentially bad interactions between DTLS-SRTP and middleboxes 🙃 they're documented in [MMUSIC-MEDIA], which also gives recommendations for avoiding those problems.
6.7.1. ICE Interaction
Interactive Connectivity Establishment (ICE), specified in [RFC5245], gives participants in multimedia sessions a way to verify mutual connectivity 🤳 when ICE is being used, the ICE connectivity checks happen before the DTLS handshake begins. note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. so there's only one DTLS handshake even if there are multiple valid candidate pairs 🙌 this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just like it would if the DTLS packets were an ordinary media stream.
Note that Simple Traversal of the UDP Protocol through NAT (STUN) packets are sent directly over UDP, not over DTLS 📦 [RFC5764] explains how to demultiplex STUN packets from DTLS packets and SRTP packets.
6.7.2. Latching Control without ICE
If ICE isn't being used, there's potential for a bad interaction with Session Border Controllers (SBCs) via "latching," as described in [MMUSIC-MEDIA] 😬 to avoid this, if ICE isn't being used and the DTLS handshake hasn't completed when the other side's SDP is received, then the passive side MUST do a single unauthenticated STUN [RFC5389] connectivity check to open up the appropriate pinhole 🕳️ all implementations MUST be prepared to answer this request during the handshake period, even if they don't otherwise do ICE. however, the active side MUST proceed with the DTLS handshake as appropriate even if no such STUN check is received, and the passive MUST NOT wait for a STUN answer before sending its ServerHello 🫶
6.8. Rekeying 🔄
okay so, just like TLS, DTLS endpoints can rekey at any time by redoing the DTLS handshake 💅 While the rekey is in progress, the endpoints keep using the keying material they already set up for DTLS. Once the new session keys are ready, the session switches over to them and drops the old keys ✨ That means there's no latency hiccup during the rekey, which is iconic 🫶
If the SRTP security context is set up with DTLS, more rekeying details are in Section 3.7 of [RFC5764] 📖
6.9. Conference Servers and Shared Encryptions Contexts 🎀
so people have proposed that conference servers could use the same encryption context for every participant in a conference 🤔 The upside is that the server only has to encrypt the output for all the speakers once, instead of once per participant 🙌
this shared encryption context approach doesn't work under this specification 🙅♀️ Each DTLS handshake creates fresh keys, and neither side fully controls them. Still, the argument is that encrypting each RTP packet is pretty cheap compared to everything else the conference server is doing, like codec processing 💖
future extensions like [SRTP-EKT] or [KEY-TRANSPORT] could provide this functionality alongside the mechanisms in this specification 🦋
6.10. Media over SRTP 🌸
so DTLS's data transfer protocol is generic, which means it isn't as highly optimized for RTP as SRTP [RFC3711] is. SRTP was specifically tuned for that purpose 🧚 DTLS-SRTP [RFC5764] was defined to negotiate SRTP transport over a DTLS connection, so you get the performance perks of SRTP with the easy key management of DTLS 🔥 In some environments, being able to reuse existing SRTP software and hardware implementations is another big reason to pick DTLS-SRTP instead of RTP over DTLS 💜
Implementations of this specification MUST support DTLS-SRTP [RFC5764]. 🫶
6.11. Best Effort Encryption 🌈
[RFC5479] describes a best-effort encryption requirement. When SRTP is used and both endpoints support it and key negotiation succeeds, you get SRTP. Otherwise, you fall back to RTP 🙈
[MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as alternatives 🍓 This lets an offerer say it prefers SRTP, while RTP stays the default and gets understood by endpoints that don't know SRTP or this key exchange mechanism 💅
Implementations of this document MUST support [MMUSIC-SDP]. ✨
7. Example Message Flow 🦋
before the session is set up, both Alice and Bob generate self-signed certificates 🎀 They might use them for one session, or, more likely, reuse them across multiple sessions. In this example, Alice calls Bob 📞 We're also assuming that Alice and Bob share the same proxy 🧚
7.1. Basic Message Flow with Early Media and SIP Identity 💖
this example shows the SIP message flows where Alice is the passive endpoint and Bob is the active endpoint 👑 The moment Bob gets the INVITE from Alice, with DTLS specified in the "m=" line of the offer, Bob starts negotiating a DTLS association with Alice for both RTP and RTCP streams 🔥 Early media (RTP and RTCP) starts flowing from Bob to Alice as soon as Bob sends the DTLS finished message to Alice 🎶 Bi-directional media (RTP and RTCP) can flow once Alice gets the SIP 200 response and has sent her DTLS finished message 🫶
The SIP signaling from Alice to her proxy goes over TLS, so there's an integrity-protected channel between Alice and her identity service. Transport between proxies should also be protected somehow, especially if SIP Identity isn't in use 🔐
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
| <------------------|
|(9) 200 OK | |
|<----------------| |
| |(10) media |
|<---------------------------------->|
|(11) ACK | |
|----------------------------------->|Message (1): INVITE Alice -> Proxy 💌
this is the initial INVITE from Alice to Bob, carried over the TLS transport protocol so there's an integrity-protected channel between Alice and her proxy, which acts as Alice's identity service 🛡️ Alice has asked to be either the active or the passive endpoint by specifying a=setup:actpass in the SDP 🙋♀️ Bob chooses to act as the DTLS client and starts the session 🚀 Also, the SDP has a fingerprint attribute, which is computed from Alice's self-signed certificate 🔏
This offer includes a default "m=" line offering RTP in case the answerer doesn't support SRTP. The SRTP configuration is the preferred one, though 💜 For more on SDP capability negotiation details, check [MMUSIC-SDP] 📚
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1Message (2): INVITE Proxy -> Bob 🌸
this shows the INVITE getting relayed to Bob through Alice's proxy and Bob's proxy 🧚 Alice's proxy has added an Identity and an Identity-Info header 🪪 This example only shows one element for both proxies, just to keep things simple ✨ Bob verifies the identity sent with the INVITE 🕵️♀️
INVITE sip:bob@ua2.example.com SIP/2.0
To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:alice@ua1.example.com>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua1.example.com
s=example1
c=IN IP4 ua1.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1Message (3): ClientHello Bob -> Alice 👋
as long as Alice's identity checks out, line 3 shows Bob sending DTLS ClientHello(s) straight to Alice 💌 In this case, two DTLS ClientHello messages go to Alice: one to ua1.example.com:6056 for RTP and another to port 6057 for RTCP. For compactness, only one arrow is drawn in the figure 📐
Message (4): ServerHello+Certificate Alice -> Bob 🫶
Alice sends back a ServerHello, Certificate, and ServerHelloDone for both the RTP and RTCP associations 🎀 The same certificate is used for both associations. If RTP/RTCP multiplexing [RFC5761] were in use, only a single association would be needed 🦋
Message (5): Certificate Bob -> Alice 💜
Bob sends a Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec, and Finished for both the RTP and RTCP associations 🔐 Again, Bob uses the same server certificate for both associations 🍓
Message (6): Early Media Bob -> Alice 🎶
at this point Bob can start sending early media (RTP and RTCP) to Alice 🎤 But Alice can't trust the media yet, since the fingerprint hasn't been received 🙈 That lack of trusted, secure media gets shown to Alice through the UA user interface 🖥️
Message (7): Finished Alice -> Bob ✅
once Bob receives Message 7, Alice sends change_cipher_spec and Finished 🔒
Message (8): 200 OK Bob -> Alice 🎉
when Bob answers the call, he sends a 200 OK SIP message that includes the fingerprint for Bob's certificate 💅 Bob also signals the actual transport protocol configuration of SRTP over DTLS in the acfg parameter 👑
SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Record-Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1Message (9): 200 OK Proxy -> Alice 🥳
Alice gets the message from her proxy and validates the certificate presented in Message 7 🔍 The endpoint now shows Alice that the call is secured 🔐✨
Message (10): RTP+RTCP Alice -> Bob 🎶
now Alice can start sending RTP and RTCP to Bob too 🦋
Message (11): ACK Alice -> Bob 💖
finally, Alice sends the SIP ACK to Bob 🎀
7.2. Basic Message Flow with Connected Identity (RFC 4916) 💌
okay so the last example didn't show RFC 4916 for connected identity, and this one does 💅
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
|<-----------------------------------|
|(4) hello | |
|----------------------------------->|
| |(5) finished |
|<-----------------------------------|
| |(6) media |
|<-----------------------------------|
|(7) finished | |
|----------------------------------->|
| |(8) 200 OK |
|<-----------------------------------|
|(9) ACK | |
|----------------------------------->|
| |(10) UPDATE |
| |<-----------------|
|(11) UPDATE | |
|<----------------| |
|(12) 200 OK | |
|---------------->| |
| |(13) 200 OK |
| |----------------->|
| |(14) media |
|<---------------------------------->|the first 9 messages are the same as before ✨ but messages 10-13, which do the RFC 4916 UPDATE, are brand new 🦋
Message (10): UPDATE Bob -> Proxy 💖
bob sends an RFC 4916 UPDATE toward alice, and it has his fingerprint in it 🔍 his UPDATE carries the same session info he gave in his 200 OK (Message 8). ngl the key thing here: in principle an UPDATE can be used to change session parameters, but in this case it's only being used to confirm the fingerprint 🫶
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Route: <sip:proxy.example.com;lr>
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 70
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1Message (11): UPDATE Proxy -> Alice 🚀
this is the UPDATE getting relayed to alice from bob (and alice's proxy) 💌 bob's proxy slipped in an Identity and an Identity-Info header 🪪 same as before, we only show one element for both proxies to keep it simple. alice verifies the identity she gets. heads up: the actual identity signatures here are incorrect and only included as examples 🙈
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
Max-Forwards: 69
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert
v=0
o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com
s=example2
c=IN IP4 ua2.example.com
a=setup:active
a=fingerprint: SHA-1 \
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1Message (12): 200 OK Alice -> Bob 🎀
this is alice's 200 OK to bob's UPDATE 💅 bob only resent the same session params from his 200 OK, so alice can just replay her own view of the session params too ✨
SIP/2.0 200 OK
To: "Alice" <sip:alice@example.com>;tag=843c7b0b
From <sip:bob@example.com>;tag=6418913922105372816
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj
Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 2 UPDATE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: xxxx
Supported: from-change
v=0
o=- 1181923068 1181923196 IN IP4 ua2.example.com
s=example1
c=IN IP4 ua2.example.com
a=setup:actpass
a=fingerprint: SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0
m=audio 6056 RTP/AVP 0
a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=17.3. Basic Message Flow with STUN Check for NAT Case 🌸
in the earlier examples, the DTLS handshake is already done by the time alice gets bob's 200 OK (8), so no STUN check gets sent 🙌 but if alice had a NAT, bob's ClientHello might get blocked by it 😬 in that case alice would send the STUN check from Section 6.7.1 when she gets the 200 OK, like this:
Alice Proxies Bob
|(1) INVITE | |
|---------------->| |
| |(2) INVITE |
| |----------------->|
| |(3) hello |
| X<-----------------|
| |(4) 200 OK |
|<-----------------------------------|
| (5) conn-check | |
|----------------------------------->|
| |(6) conn-response |
|<-----------------------------------|
| |(7) hello (rtx) |
|<-----------------------------------|
|(8) hello | |
|----------------------------------->|
| |(9) finished |
|<-----------------------------------|
| |(10) media |
|<-----------------------------------|
|(11) finished | |
|----------------------------------->|
| |(11) media |
|----------------------------------->|
|(12) ACK | |
|----------------------------------->|the messages here match the first example (for simplicity this one skips an UPDATE 🫶), plus three new ones:
Message (5): STUN connectivity-check Alice -> Bob 🕳️
Section 6.7.1 describes an approach to dodge an SBC interaction issue where the endpoints don't support ICE 🔧 alice (the passive endpoint) sends a STUN connectivity check to bob, and that opens a pinhole in alice's NAT/firewall 💜
Message (6): STUN connectivity-check response Bob -> Alice ✅
bob (the active endpoint) sends a response to the STUN connectivity check (Message 3) back to alice 💅 this tells alice her check worked, so she can stop the retransmit state machine 🙌
Message (7): Hello (retransmit) Bob -> Alice 🎉
bob retransmits his DTLS ClientHello, and now it gets through the pinhole in alice's firewall 🦋 from here, the DTLS handshake carries on just like before ✨
8. Security Considerations 🔐
okay bestie, this part is SERIOUS, so read it carefully 🫣
DTLS or TLS media signaled with SIP needs a way to make sure the communicating peers' certificates are correct 🧐
the standard TLS/DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. the client then verifies the certificate and checks that the name in the certificate matches the server's domain name. this works because there are a relatively small number of servers with well-defined names, which usually doesn't happen in the VoIP context 📞
the design in this document is meant to lean on the authenticity of the signaling channel (while not requiring confidentiality) 🔒 as long as each side of the connection can verify the integrity of the SDP it received from the other side, the DTLS handshake can't be hijacked via a man-in-the-middle attack 🙅♀️ this integrity protection is easily provided by the caller to the callee (see Alice to Bob in Section 7) via the SIP Identity [RFC4474] mechanism. other mechanisms, like the S/MIME mechanism described in RFC 3261, or maybe future mechanisms that haven't been defined yet, could also do this job 🧚
this is the scary bit 😭 while this mechanism can still be used without such integrity mechanisms, the security it provides is limited to defense against passive attack by intermediaries. an active attack on the signaling plus an active attack on the media plane can let an attacker attack the connection (R-SIG-MEDIA in the notation of [RFC5479]).
8.1. Responder Identity 👑
SIP Identity doesn't support signatures in responses 😤 ideally, alice would want to know that bob's SDP hadn't been tampered with and who it came from, so her User Agent could show her that there's a secure phone call with bob 🔐 [RFC4916] defines an approach for a UA to supply its identity to its peer UA, with that identity signed by an authentication service 💅 for example, using this approach, bob sends an answer, then immediately follows up with an UPDATE that includes the fingerprint and uses the SIP Identity mechanism to assert that the message is from Bob@example.com. the downside is that it needs the extra round trip of the UPDATE 🥲 but it's simple and secure even when not all of the proxies are trusted. in this example, bob only needs to trust his proxy 🫶 Offerers SHOULD support this mechanism and answerers SHOULD use it.
in some cases, answerers won't send an UPDATE, and in lots of calls some media gets sent before the UPDATE is received 🫠 in these cases, no integrity is provided for the fingerprint from bob to alice. in this approach, an attacker that was on the signaling path could tamper with the fingerprint and insert themselves as a man-in-the-middle on the media 👀 alice would know that she had a secure call with someone, but wouldn't know if it was with bob or a man-in-the-middle. bob would know that an attack was happening 🚨 the fact that one side can detect this attack means that in most cases where alice and bob both want the communications to be encrypted, there isn't a problem 🙏 keep in mind that in any of the possible approaches, bob could always reveal the media that was received to anyone. we're assuming bob also wants secure communications 💜 in this do-nothing case, bob knows the media hasn't been tampered with or intercepted by a third party, and that it's from Alice@example.com. alice knows she's talking to someone, and whoever that is has probably checked that the media isn't being intercepted or tampered with 🕵️♀️ this approach is certainly less than ideal, but very usable for lots of situations ✨
8.2. SIPS 🔐
If SIP Identity isn't used but the signaling is protected by SIPS, the security guarantees get weaker 🥺. You still get some security as long as all proxies are trusted 🫶. That gives integrity for the fingerprint in a chain-of-trust security model. Note, however, that if the proxies aren't trusted, the level of security provided is limited 💀.
8.3. S/MIME 💌
RFC 3261 [RFC3261] defines an S/MIME security mechanism for SIP that could be used to sign that the fingerprint was from Bob. This would be secure ✨.
8.4. Continuity of Authentication 🔁
One desirable property of a secure media system is continuity of authentication: being able to make sure, cryptographically, that you're talking to the same person as before 👀. With DTLS, continuity of authentication is achieved by having each side use the same public key/self-signed certificate for each connection (at least with a given peer entity). Then it becomes possible to cache the credential (or its hash) and verify that it's unchanged. So once a single secure connection has been established, an implementation can establish a future secure channel even in the face of future insecure signaling 🦋.
To enable continuity of authentication, implementations SHOULD attempt to keep a constant long-term key 🔑. Verifying implementations SHOULD maintain a cache of the key used for each peer identity and alert the user if that key changes 🚨.
8.5. Short Authentication String 🗣️
Alice and Bob have an alternative here: use human speech to verify each other's identity, and then verify each other's fingerprints using human speech too 🎀. Assuming it's difficult to impersonate someone's speech and seamlessly modify the audio contents of a call, this approach is relatively safe 🔥. It wouldn't be effective if other forms of communication were being used, like video or instant messaging 🙈. DTLS supports this mode of operation. The minimal secure fingerprint length is around 64 bits.
ZRTP [AVT-ZRTP] includes Short Authentication String (SAS) mode, where a unique per-connection bitstring is generated as part of the cryptographic handshake 🧚. The SAS can be as short as 25 bits, so it's somewhat easier to read 📖. DTLS does not natively support this mode. Based on the level of deployment interest, a TLS extension [RFC5246] could provide support for it. Note that SAS schemes only work well when the endpoints recognize each other's voices, which is not true in many settings (e.g., call centers) 📞.
8.6. Limits of Identity Assertions 🚧
When RFC 4474 is used to bind the media keying material to the SIP signaling, the assurances about the provenance and security of the media are only as good as those for the signaling 🍓. There are two important cases to note here:
- RFC 4474 assumes that the proxy with the certificate "example.com" controls the namespace "example.com". Therefore, the RFC 4474 authentication service that is authoritative for a given namespace can control which user is assigned each name. Thus, the authentication service can take an address formerly assigned to Alice and transfer it to Bob. This is an intentional design feature of RFC 4474 and a direct consequence of the SIP namespace architecture 🏛️.
- When phone number URIs (e.g.,
sip:+17005551008@chicago.example.comorsip:+17005551008@chicago.example.com;user=phone) are used, there is no structural reason to trust that the domain name is authoritative for a given phone number, although individual proxies and UAs may have private arrangements that allow them to trust other domains. This is a structural issue in that Public Switched Telephone Network (PSTN) elements are trusted to assert their phone number correctly, and there's no real concept of a given entity being authoritative for some number space ☎️.
In both of these cases, the assurances that DTLS-SRTP provides in terms of data origin integrity and confidentiality are necessarily no better than what SIP provides for signaling integrity when RFC 4474 is used 😤. Implementors should therefore take care not to indicate misleading peer identity information in the user interface. That is, if the peer's identity is sip:+17005551008@chicago.example.com, it is not sufficient to display that the identity of the peer is +17005551008, unless there's some policy stating that the domain "chicago.example.com" is trusted to assert the E.164 numbers it's asserting 🙅♀️. In cases where the UA can determine that the peer identity is clearly an E.164 number, it may be less confusing to simply identify the call as encrypted but to an unknown peer 🔒.
In addition, some middleboxes (back-to-back user agents (B2BUAs) and Session Border Controllers) are known to modify portions of the SIP message that are included in the RFC 4474 signature computation, which breaks the signature 😭. This sort of man-in-the-middle operation is precisely the sort of message modification that RFC 4474 is intended to detect 🕵️♀️. In cases where the middlebox is itself permitted to generate valid RFC 4474 signatures (e.g., it's within the same administrative domain as the RFC 4474 authentication service), then it may generate a new signature on the modified message. Alternately, the middlebox may be able to sign with some other identity that it's permitted to assert. Otherwise, the recipient cannot rely on the RFC 4474 Identity assertion, and the UA MUST NOT indicate to the user that a secure call has been established to the claimed identity 🛑. Implementations that are configured to only establish secure calls SHOULD terminate the call in this case ⛔.
If SIP Identity or an equivalent mechanism isn't used, then only protection against attackers who cannot actively change the signaling is provided 🥀. While this is still superior to previous mechanisms, the security provided is inferior to what you get if integrity is provided for the signaling 💅.
8.7. Third-Party Certificates 📜
This specification doesn't depend on the certificates held by endpoints being independently verifiable (e.g., being issued by a trusted third party) 🤷♀️. However, there's no limitation on such certificates being used. Aside from the difficulty of obtaining such certificates, it's not clear what identities those certificates would contain. RFC 3261 specifies a convention for S/MIME certificates that could also be used here, but it has seen only minimal deployment 🥱. Still, in closed or semi-closed contexts where such a convention can be established, third-party certificates can reduce the reliance on trusting even proxies in the endpoint's domains 🌸.
8.8. Perfect Forward Secrecy 🌙
One concern about using a long-term key is that compromising that key may lead to compromising past communications 😱. To prevent this attack, DTLS supports modes with Perfect Forward Secrecy using Diffie-Hellman and Elliptic-Curve Diffie-Hellman cipher suites. When these modes are in use, the system is secure against such attacks ✨. Note that compromise of a long-term key may still lead to future active attacks. If this is a concern, a backup authentication channel, such as manual fingerprint establishment or a short authentication string, should be used 🗝️.
9. Acknowledgments 💖
Cullen Jennings contributed substantial text and comments to this document, and he's a legend for it 👑. This document benefited from discussions with Francois Audet, Nagendra Modadugu, and Dan Wing. Thanks also to Flemming Andreasen, Jonathan Rosenberg, Rohan Mahy, David McGrew, Miguel Garcia, Steffen Fries, Brian Stucker, Robert Gilman, David Oran, and Peter Schneider for their useful comments 🙌.
We'd also like to thank Thomas Belling, Guenther Horn, Steffen Fries, Brian Stucker, Francois Audet, Dan Wing, Jari Arkko, and Vesa Lehtovirta for their input on traversal of SBCs 🌈.
10. References 📚
10.1. Normative References 🧾
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.10.2. Informative References
Okay, now the bibliography bit 📚 Here are all the informative references, bestie:
- [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
- [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
- [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
- [RFC4567] 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.
- [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
- [AVT-ZRTP] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009.
- [SRTP-EKT] McGrew, D., Andreasen, F., and L. Dondeti, "Encrypted Key Transport for Secure RTP", Work in Progress, March 2009.
- [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
- [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, March 2009.
- [MMUSIC-SDP] Andreasen, F., "SDP Capability Negotiation", Work in Progress, February 2010.
- [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
- [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [SIPPING-SRTP] Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Johnston, "Secure Media Recording and Transcoding with the Session Initiation Protocol", Work in Progress, October 2008.
- [KEY-TRANSPORT] Wing, D., "DTLS-SRTP Key Transport (KTR)", Work in Progress, March 2009.
- [MMUSIC-MEDIA] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, March 2009.
- [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
Appendix A. Requirements Analysis 🔍✨
Okay so this appendix is the big checklist 💅 [RFC5479] lays out the security requirements for media keying, and this section goes through each one and checks how this proposal holds up. Let's go!
A.1. Forking and Retargeting (R-FORK-RETARGET, R-BEST-SECURE, R-DISTINCT) 🌸
Here the SDP offer (the one in the INVITE) is basically just an ad saying "hey, I can do security" 📣. That ad doesn't depend on who the other peer is, so forking and retargeting just work when every endpoint is doing SRTP. When you've got a mix of SRTP and non-SRTP endpoints, we lean on the SDP capabilities mechanism that's still being worked on [MMUSIC-SDP] to quietly negotiate security wherever it's possible. And since DTLS makes a brand new key for every session, only the entity the call actually ends up with gets the media encryption keys (R3) 🔐.
A.2. Distinct Cryptographic Contexts (R-DISTINCT) 🦋
DTLS runs a fresh handshake with each endpoint, so every endpoint ends up with its own distinct keys and cryptographic contexts. Separate, iconic, no mixing 👑.
A.3. Reusage of a Security Context (R-REUSE) 🔁
DTLS lets sessions get resumed using the 'TLS session resumption' feature. This can cut down how much crypto work has to happen when two peers start talking again 🧠. For more on session resumption in this context, check out [RFC5764].
A.4. Clipping (R-AVOID-CLIPPING) ✂️
Since the key establishment happens in the media plane, media doesn't have to get clipped before the SDP answer shows up 🎉. BUT, and this is a big but 🙈, only confidentiality is provided until the offerer gets the answer. The answerer knows they aren't sending data to an attacker, but the offerer can't know that they're receiving data from the answerer yet.
A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) 👀
The public key algorithms used by DTLS cipher suites, like RSA, Diffie-Hellman, and Elliptic Curve Diffie-Hellman, are secure against passive attacks 🛡️.
A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) 📡
DTLS protects against passive attackers on the signaling path too, because the only thing exchanged over SIP signaling is a fingerprint 🤏.
A.7. (R-SIG-MEDIA, R-ACT-ACT) 🚨
Okay, this one gets a little spicy 🌶️. An attacker who controls the media channel but not the signaling channel can pull off a MITM attack on the DTLS handshake. BUT that changes the certificates, which makes the fingerprint check fail. So any attack that actually works would need the attacker to also modify the signaling messages to swap out the fingerprints 💀.
If RFC 4474 Identity or an equivalent mechanism is used, then an attacker who controls the signaling channel at any point between the proxies doing the Identity signatures can't change the fingerprints without breaking the signature. So even an attacker who controls both the signaling and media paths can't successfully attack the media traffic 🙌.
Heads up, this part is super important! The channel between the UA and the authentication service MUST be secured, and the authentication service MUST verify the UA's identity, in order for this mechanism to be secure 🔒.
Also, an attacker who controls the authentication service can impersonate the UA using that authentication service. This is an intended feature of SIP Identity 💅, because the authentication service owns the namespace and so it's the one that decides which user has which identity.
A.8. Binding to Identifiers (R-ID-BINDING) 🔗
When an end-to-end mechanism is in play, like SIP-Identity [RFC4474], SIP-Connected-Identity [RFC4916], or S/MIME, they tie the endpoint's certificate fingerprints to the From: address in the signaling. The fingerprint is covered by the Identity signature 📝. When other mechanisms (for example, SIPS) are used instead, the binding is correspondingly weaker 😬.
A.9. Perfect Forward Secrecy (R-PFS) 🔮
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites that give you PFS ✨.
A.10. Algorithm Negotiation (R-COMPUTE) 🧮
DTLS negotiates cipher suites before doing any significant crypto computation. That means it supports algorithm negotiation and multiple cipher suites without adding extra computational expense 💖.
A.11. RTP Validity Check (R-RTP-VALID) 🕵️♀️
DTLS packets don't pass the RTP validity check. The first byte of a DTLS packet is the content type, and every current DTLS content type has the first two bits set to zero. That gives a version of zero, so the packet fails the first validity check 🚫. DTLS packets can also be told apart from STUN packets. For the details on demultiplexing, see [RFC5764] 🧩.
A.12. Third-Party Certificates (R-CERTS, R-EXISTING) 📜
Third-party certificates aren't needed, because signaling (for example [RFC4474]) is what authenticates the certificates DTLS uses 🙅♀️. That said, if the parties share an authentication infrastructure that's compatible with TLS (third-party certificates or shared keys), then it can be used 🤝.
A.13. FIPS 140-2 (R-FIPS) 🇺🇸
TLS implementations may already be FIPS 140-2 approved, and the algorithms used here line up with the approval of DTLS and DTLS-SRTP ✅.
A.14. Linkage between Keying Exchange and SIP Signaling (R-ASSOC) 🪢
The signaling exchange gets linked to the key management exchange through the fingerprints carried in SIP, and the certificates themselves get exchanged in DTLS 💌.
A.15. Denial-of-Service Vulnerability (R-DOS) 🛑
DTLS has some degree of Denial-of-Service (DoS) protection as a built-in feature (see Section 4.2.1 of [RFC4347]) 🛡️.
A.16. Crypto-Agility (R-AGILITY) 🔄
DTLS lets cipher suites get negotiated, so new algorithms can be rolled out bit by bit 🌱. Work on replacing the fixed MD5/SHA-1 key derivation function is still ongoing 🚧.
A.17. Downgrading Protection (R-DOWNGRADE) 🙅
DTLS protects against downgrading attacks because the selection of the offered cipher suites gets confirmed at a later stage of the handshake 🤳. This protection works well unless an adversary can break a cipher suite in real time. RFC 4474 can stop an active attacker on the signaling path from downgrading the call from SRTP to RTP 💪.
A.18. Media Security Negotiation (R-NEGOTIATE) 🤝
DTLS lets a User Agent negotiate media security parameters for each individual session 🎀.
A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) 🌈
The DTLS-SRTP framework doesn't rely on SIP. Any protocol that can exchange a fingerprint and the media description can be secured 🙌.
A.20. Media Recording (R-RECORDING) 🎙️
An extension, see [SIPPING-SRTP], was specified to support media recording without requiring intermediaries to act as an MITM 🎬.
When media recording is done by intermediaries, though, they do need to act as an MITM 😅.
A.21. Interworking with Intermediaries (R-TRANSCODER) 🔀
To interface with any intermediary that transcodes the media, the transcoder has to have access to the keying material and gets treated as an endpoint for the purposes of this document 🧚.
A.22. PSTN Gateway Termination (R-PSTN) ☎️
The DTLS-SRTP framework lets media security terminate at a PSTN gateway. That doesn't give you end-to-end security, but it still fits the security goals of this framework, because the gateway is authorized to speak for the PSTN namespace 🍓.
A.23. R-ALLOW-RTP 🎶
DTLS-SRTP lets RTP media be received by the calling party until SRTP has been negotiated with the answerer. After that, SRTP is preferred over RTP ⭐.
A.24. R-HERFP 🧵
The Heterogeneous Error Response Forking Problem (HERFP) doesn't apply to DTLS-SRTP. The key exchange protocol runs along the media path, so error messages travel along that path too, and proxies don't need to pass them along 💜.
Authors' Addresses ✨
okay bestie, the squad behind this spec!! 🎀 these are the three humans who wrote it, and here's where you can reach them 💖
Jason Fischl 💅
Jason Fischl
Skype, Inc.
2145 Hamilton Ave.
San Jose, CA 95135
USA
Phone: +1-415-692-1760
EMail: jason.fischl@skype.netHannes Tschofenig 🦋
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo, 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.atEric Rescorla 🌸
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
USA
EMail: ekr@rtfm.comand that's a wrap on RFC 5763!! 🌈👑 literally iconic work from all three of them 🫶
📦 where this page comes from
- ietf: rfc5763 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms