1. Introduction

1. Introduction

This document describes a mechanism for using DTLS [RFC4347] to establish keys for SRTP [RFC3711] and SRTCP [RFC3711] flows. SRTP and SRTCP (together referred to as SRTP when there is no ambiguity) use symmetric key encryption and authentication. They require a master key, a master salt, a SRTP encryption algorithm, a SRTP authentication algorithm, and SRTP parameters. DTLS is a channel security protocol that allows for mutual authentication of endpoints and negotiation of cryptographic parameters. After the DTLS handshake is completed, encrypted data is sent as a series of DTLS records. By signaling SRTP parameters in the DTLS handshake, DTLS can be used to establish keys for SRTP flows.

This document defines a new extension to DTLS that allows a DTLS peer to negotiate the use of SRTP and provide parameters for both policies. The extension does not provide complete negotiation of the SRTP policy; the policy offered in the extension MUST include every parameter needed for the receiving endpoint to correctly decrypt traffic. The extension does not provide a way to negotiate the use of DTLS-SRTP, nor does it provide a way to negotiate which SRTP policy to use. The DTLS handshake MUST be performed to provide key agreement needed for SRTP.

One motivating factor for the development of DTLS-SRTP is the current proliferation of mechanisms for key management for SRTP [RFC4568][RFC4567][SDESCRIPTIONS] [MIKEY]. Another motivation is to support future development of features such as a cryptographically bound identity.

It should be noted that DTLS-SRTP is highly similar to and largely compatible with SDP Security Descriptions [RFC4568]. The major differences are:

• DTLS-SRTP produces end-to-end security for the media, because the keying happens on the media path. With SDP Security Descriptions, security is only known to be hop-by-hop.
• DTLS-SRTP provides limited identity authentication, useful when strong identity is needed. With SDP Security Descriptions, identity is provided entirely out of band.
• DTLS-SRTP allows for rekeying of long-duration sessions. With SDP Security Descriptions, rekeying generally requires another offer/answer exchange.

The interface to the application is intended to be very simple. The only application information needed is the usage of the keying material; e.g., that it is to be used for SRTP. The application does not need to extract the keys or crypto algoritms, as the RTP stack already has access to them.

This document also describes how to multiplex RTP, RTCP, DTLS, and STUN packets on a single UDP port. STUN [RFC5389] is used to allow the media to pass through Network Address Translators (NATs) and firewalls. Since RTP and RTCP run on the same host and port, they share the same NAT binding.