Srtp Using Dtls Protocol - AudioCodes Mediant 800B User Manual

14.7.1 SRTP using DTLS Protocol

For SBC calls, you can configure the device to use the Datagram Transport Layer Security
(DTLS) protocol to secure UDP-based media streams (according to RFC 4347 and 6347)
for specific SIP entities, using IP Profiles. DTLS allows datagram-based applications to
communicate in a way that is designed to prevent eavesdropping, tampering or message
forgery. The DTLS protocol is based on the stream-oriented TLS protocol, providing similar
security. The device can therefore, interwork in mixed environments where one network
may require DTLS and the other may require Session Description Protocol Security
Descriptions (SDES) or even non-secure RTP. The device supports DTLS negotiation for
RTP-to-SRTP and SRTP-to-SRTP calls.
DTLS support is important for deployments with WebRTC. WebRTC requires that media
channels be encrypted through DTLS for SRTP key exchange. Negotiation of SRTP keys
through DTLS is done during the DTLS handshake between WebRTC client and peer. For
more information on WebRTC, see 'WebRTC' on page 774.
In contrast to SDES, DTLS key encryption is done over the media channel (UDP), not
signaling. Thus, DTLS-SRTP is generally known as "secured key exchange over media".
DTLS is similar to TLS, but runs over UDP, whereas TLS is over TCP. Before the DTLS
handshake, the peers exchange DTLS parameters (fingerprint and setup) and algorithm
types in the SDP body of the SIP messages exchanged for establishing the call (INVITE
request and response). The peers participate in a DTLS handshake during which they
exchange certificates. These certificates are used to derive a symmetric key, which is used
to encrypt data (SRTP) flow between the peers. A hash value calculated over the certificate
is transported in the SDP using the 'a=fingerprint' attribute. At the end of the handshake,
each side verifies that the certificate it received from the other side fits the fingerprint from
the SDP. To indicate DTLS support, the SDP offer/answer of the SIP message uses the
'a=setup' attribute. The 'a=setup:actpass' attribute value is used in the SDP offer by the
device. This indicates that the device is willing to be either a client ('act') or a server ('pass')
in the handshake. The 'a=setup:active' attribute value is used in the SDP answer by the
device. This means that the device wishes to be the client ('active') in the handshake.
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
DTLS cipher suite reuses the TLS cipher suite. The DTLS handshake is done for every
new call configured for DTLS. In other words, unlike TLS where the connection remains
"open" for future calls, a new DTLS connection is required for every new call. Note that the
entire authentication and key exchange for securing the media traffic is handled in the
media path through DTLS. The signaling path is used only to verify the peers' certificate
fingerprints. DTLS messages are multiplexed onto the same ports that are used for the
media.

To configure DTLS:
1. In the TLS Context table (see 'Configuring TLS Certificate Contexts' on page 113),
configure a TLS Context with the DTLS version (TLSContexts_DTLSVersion).
2. Open the IP Groups table (see 'Configuring IP Groups' on page 365) and for the IP
Group associated with the SIP entity, assign it the TLS Context for DTLS, using the
'DTLS Context' parameter (IPGroup_DTLSContext).
3. Open the IP Profiles table (see 'Configuring IP Profiles' on page 436) and for the IP
Profile associated with the SIP entity, configure the following:
•
Configure the 'SBC Media Security Mode' parameter
(IPProfile_SBCMediaSecurityBehavior) to SRTP or Both.
•
Configure the 'Media Security Method' parameter
(IPProfile_SBCMediaSecurityMethod) to DTLS.
User's Manual
Mediant 800B Gateway & E-SBC
224 Document #: LTRT-10632