Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)
updated by
- rfc-8842 — Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
Extracted elements (32)
Certificates used in DTLS are treated purely as carriers for public keys and may be completely self-signed and self-generated on demand. This eliminates the need for a global PKI and makes deployment practical for arbitrary Internet endpoints with no prior relationships.
Conference servers cannot share a single encryption context for all participants because each DTLS handshake establishes fresh keys not fully under either side's control. Future extensions (SRTP-EKT or KEY-TRANSPORT) would be needed to enable shared encryption contexts.
DTLS-SRTP (RFC 5764) is mandated over plain RTP-over-DTLS because DTLS's generic data transfer protocol is less optimized for RTP than SRTP, which was specifically tuned for real-time media. Reuse of existing SRTP hardware/software is an additional motivation.
Key exchange is performed along the media path via DTLS, not in SIP signaling as with MIKEY or SDESCRIPTIONS. This means intermediate proxies never see keying material and need not be trusted for confidentiality; only integrity protection of the fingerprint is required from the signaling path.
DTLS packets fail the RTP validity check by design: all current DTLS content type values have the first two bits set to zero, producing a version of zero in RTP terms. This property is exploited by RFC 5764 to demultiplex DTLS, STUN, and SRTP packets on the same port.
When ICE is used, ICE connectivity checks must complete before the DTLS handshake begins. If aggressive nomination mode is used, multiple candidate pairs may be marked valid; all must be treated as part of the same DTLS association so only one handshake occurs, with endpoint IP addresses adjusted if the selected pair shifts.
If a middlebox breaks the RFC 4474 signature and cannot regenerate a valid one, the UA MUST NOT indicate to the user that a secure call has been established to the claimed identity. Implementations configured to only establish secure calls SHOULD terminate the call in this case.
If an offer is received by an endpoint that wishes to provide early media, it MUST take the setup:active role and can immediately establish a DTLS association with the other endpoint and begin sending media.
If ICE is not being used and the DTLS handshake has not completed upon receiving the other side's SDP, the passive side MUST perform a single unauthenticated STUN connectivity check to open the appropriate pinhole. All implementations MUST be prepared to answer this request; the active side MUST proceed with the DTLS handshake even if no STUN check is received, and the passive MUST NOT wait for a STUN answer before sending its ServerHello.
If the active/passive status of the endpoints changes during session modification, a new DTLS connection MUST be established.
Implementations MUST support DTLS-SRTP (RFC 5764) to allow the performance benefits of SRTP with the easy key management of DTLS.
Implementations MUST support the SDP capability negotiation mechanism (MMUSIC-SDP) to allow best-effort encryption where SRTP is preferred but RTP remains the default understood by non-SRTP endpoints.
Offerers SHOULD support the RFC 4916 connected identity mechanism for responder authentication, and answerers SHOULD use it to supply their identity to the peer UA signed by an Authentication Service.
The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. If the fingerprint does not match the hashed certificate, the endpoint MUST tear down the media session immediately.
The endpoint MUST use the certificate fingerprint attribute as specified in RFC 4572, and MUST NOT use the connection attribute defined in RFC 4145.
The endpoint SHOULD send the SIP message containing the offer to the offerer's SIP proxy over an integrity-protected channel, and the proxy SHOULD add an Identity header field according to the procedures outlined in RFC 4474.
The offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a ClientHello before it receives the answer. The answerer MUST use either setup:active or setup:passive; setup:active is RECOMMENDED because it allows the answer and the DTLS handshake to occur in parallel.
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.
When ICE is being used, implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association, resulting in only one DTLS handshake even if there are multiple valid candidate pairs.
When making anonymous calls, the content of the subjectAltName attribute inside the certificate MUST NOT contain information that allows correlation or identification of the user. A new self-signed certificate SHOULD be used for each call to prevent call correlation.
Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet).
In the forking scenario, each answerer that responds to a forked INVITE establishes an independent DTLS association with the offerer. The offerer correlates each SDP answer to the correct DTLS association by comparing the fingerprint in the answer to the hashed certificate.
Mutual DTLS is required: both the DTLS client and server present certificates, even if one or both are self-signed. Certificates serve purely as a carrier for public keys; their validity is established through the SDP fingerprint, not a PKI chain.
Session modification (via INVITE or UPDATE) may reuse existing DTLS associations if they have the same key fingerprints and transport parameters; otherwise a new association is established following the same rules as initial setup, and the old association is torn down after the offer/answer exchange completes.
The fingerprint attribute (a=fingerprint) carried in SDP over SIP cryptographically binds the DTLS key exchange on the media path to the signaling plane. Each side computes the fingerprint from its certificate and includes it in the offer/answer; the peer verifies it against the certificate received in the DTLS handshake.
The setup attribute (a=setup) in SDP determines DTLS client/server roles: the offerer uses actpass, leaving the choice to the answerer. The active side sends the ClientHello; the passive side waits. Separate setup attributes may be used for each media stream.
The SIP Identity mechanism (RFC 4474) provides a digital signature across SIP header fields and body, including the SDP fingerprint. This prevents undetectable modification of the fingerprint by intermediate proxies, blocking MITM attacks on the DTLS handshake.
DTLS-SRTP may allow deanonymizing an otherwise anonymous call if the same self-signed certificate is reused across calls, allowing call correlation. A new certificate per call prevents this correlation but sacrifices continuity of authentication.
DTLS supports Diffie-Hellman and Elliptic Curve Diffie-Hellman cipher suites providing Perfect Forward Secrecy. Compromise of a long-term key cannot decrypt past communications when PFS cipher suites are used, though future active attacks remain possible.
When RFC 4474 is used, the channel between the UA and the authentication service MUST be secured and the authentication service MUST verify the UA's identity. An attacker controlling the authentication service can impersonate the UA; this is an intentional feature of SIP Identity, as the auth service owns the namespace.
When SIPS is used without SIP Identity, security is limited to a chain-of-trust model requiring all proxies to be trusted. If any proxy is compromised, fingerprint integrity is lost and a MITM attack becomes possible.
Without RFC 4474 or equivalent signaling integrity, DTLS-SRTP only defends against passive attackers on the media path. An active attacker controlling both the media channel and the signaling path can modify fingerprints and mount an undetected MITM attack.