[PATCH 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764)
Martin Storsjo
martin at martin.st
Wed Oct 31 14:46:22 CET 2012
The code is heavily modelled on the server_name extension
implementation.
Open questions:
- Would it be necessary to add an accessor function for quering
the offered profiles that have been set?
- The profile name strings match the ones used in OpenSSL, but
compared with the RFC, they lack a "HMAC_" before "SHA1". Is
this ok?
- Is it ok to have both the setter and getter functions use strings?
The corresponding APIs in OpenSSL set the profiles based on a string,
but expose the selected profile via a struct.
---
doc/protocol/rfc5764.txt | 1459 +++++++++++++++++++++++++++++++++++++++
lib/ext/Makefile.am | 2 +-
lib/ext/srtp.c | 415 +++++++++++
lib/ext/srtp.h | 38 +
lib/gnutls_extensions.c | 5 +
lib/gnutls_int.h | 1 +
lib/includes/gnutls/gnutls.h.in | 6 +
7 files changed, 1925 insertions(+), 1 deletion(-)
create mode 100644 doc/protocol/rfc5764.txt
create mode 100644 lib/ext/srtp.c
create mode 100644 lib/ext/srtp.h
diff --git a/doc/protocol/rfc5764.txt b/doc/protocol/rfc5764.txt
new file mode 100644
index 0000000..6633f00
--- /dev/null
+++ b/doc/protocol/rfc5764.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. McGrew
+Request for Comments: 5764 Cisco Systems
+Category: Standards Track E. Rescorla
+ISSN: 2070-1721 RTFM, Inc.
+ May 2010
+
+
+ Datagram Transport Layer Security (DTLS) Extension to Establish Keys
+ for the Secure Real-time Transport Protocol (SRTP)
+
+Abstract
+
+ This document describes a Datagram Transport Layer Security (DTLS)
+ extension to establish keys for Secure RTP (SRTP) and Secure RTP
+ Control Protocol (SRTCP) flows. DTLS keying happens on the media
+ path, independent of any out-of-band signalling channel present.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5764.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 1]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, 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, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
+ 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
+ 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
+ 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
+ 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
+ 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
+ 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
+ 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
+ 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
+ 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
+ 6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
+ 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
+ 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
+ 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
+ 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
+ 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
+ Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 2]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+1. Introduction
+
+ The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality,
+ message authentication, and replay protection to RTP data and RTP
+ Control (RTCP) traffic. SRTP does not provide key management
+ functionality, but instead depends on external key management to
+ exchange secret master keys, and to negotiate the algorithms and
+ parameters for use with those keys.
+
+ Datagram Transport Layer Security (DTLS) [RFC4347] is a channel
+ security protocol that offers integrated key management, parameter
+ negotiation, and secure data transfer. Because DTLS data transfer
+ protocol is generic, it is less highly optimized for use with RTP
+ than is SRTP, which has been specifically tuned for that purpose.
+
+ This document describes DTLS-SRTP, a SRTP extension for DTLS that
+ combines the performance and encryption flexibility benefits of SRTP
+ with the flexibility and convenience of DTLS-integrated key and
+ association management. DTLS-SRTP can be viewed in two equivalent
+ ways: as a new key management method for SRTP, and a new RTP-specific
+ data format for DTLS.
+
+ The key points of DTLS-SRTP are that:
+
+ o application data is protected using SRTP,
+
+ o the DTLS handshake is used to establish keying material,
+ algorithms, and parameters for SRTP,
+
+ o a DTLS extension is used to negotiate SRTP algorithms, and
+
+ o other DTLS record-layer content types are protected using the
+ ordinary DTLS record format.
+
+ The remainder of this memo is structured as follows. Section 2
+ describes conventions used to indicate normative requirements.
+ Section 3 provides an overview of DTLS-SRTP operation. Section 4
+ specifies the DTLS extensions, while Section 5 discusses how RTP and
+ RTCP are transported over a DTLS-SRTP channel. Section 6 describes
+ use with multi-party sessions. Section 7 and Section 9 describe
+ Security and IANA considerations.
+
+2. Conventions Used In This Document
+
+ 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].
+
+
+
+
+McGrew & Rescorla Standards Track [Page 3]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+3. Overview of DTLS-SRTP Operation
+
+ DTLS-SRTP is defined for point-to-point media sessions, in which
+ there are exactly two participants. Each DTLS-SRTP session contains
+ a single DTLS association (called a "connection" in TLS jargon), and
+ either two SRTP contexts (if media traffic is flowing in both
+ directions on the same host/port quartet) or one SRTP context (if
+ media traffic is only flowing in one direction). All SRTP traffic
+ flowing over that pair in a given direction uses a single SRTP
+ context. A single DTLS-SRTP session only protects data carried over
+ a single UDP source and destination port pair.
+
+ The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP
+ flow the peers do a DTLS handshake on the same source and destination
+ port pair to establish a DTLS association. Which side is the DTLS
+ client and which side is the DTLS server must be established via some
+ out-of-band mechanism such as SDP. The keying material from that
+ handshake is fed into the SRTP stack. Once that association is
+ established, RTP packets are protected (becoming SRTP) using that
+ keying material.
+
+ RTP and RTCP traffic is usually sent on two separate UDP ports. When
+ symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions
+ are needed, one for the RTP port, one for the RTCP port. When RTP
+ flows are not symmetric, four unidirectional DTLS-SRTP sessions are
+ needed (for inbound and outbound RTP, and inbound and outbound RTCP).
+
+ Symmetric RTP [RFC4961] is the case in which there are two RTP
+ sessions that have their source and destination ports and addresses
+ reversed, in a manner similar to the way that a TCP connection uses
+ its ports. Each participant has an inbound RTP session and an
+ outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP
+ session can protect both of the RTP sessions. It is RECOMMENDED that
+ symmetric RTP be used with DTLS-SRTP.
+
+ RTP and RTCP traffic MAY be multiplexed on a single UDP port
+ [RFC5761]. In this case, both RTP and RTCP packets may be sent over
+ the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
+ needed. This improves the cryptographic performance of DTLS, but may
+ cause problems when RTCP and RTP are subject to different network
+ treatment (e.g., for bandwidth reservation or scheduling reasons).
+
+ Between a single pair of participants, there may be multiple media
+ sessions. There MUST be a separate DTLS-SRTP session for each
+ distinct pair of source and destination ports used by a media session
+ (though the sessions can share a single DTLS session and hence
+ amortize the initial public key handshake!).
+
+
+
+
+McGrew & Rescorla Standards Track [Page 4]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ A DTLS-SRTP session may be indicated by an external signaling
+ protocol like SIP. When the signaling exchange is integrity-
+ protected (e.g., when SIP Identity protection via digital signatures
+ is used), DTLS-SRTP can leverage this integrity guarantee to provide
+ complete security of the media stream. A description of how to
+ indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to
+ authenticate the endpoints using fingerprints can be found in
+ [RFC5763].
+
+ In a naive implementation, when there are multiple media sessions,
+ there is a new DTLS session establishment (complete with public key
+ cryptography) for each media channel. For example, a videophone may
+ be sending both an audio stream and a video stream, each of which
+ would use a separate DTLS session establishment exchange, which would
+ proceed in parallel. As an optimization, the DTLS-SRTP
+ implementation SHOULD use the following strategy: a single DTLS
+ association is established, and all other DTLS associations wait
+ until that connection is established before proceeding with their
+ handshakes. This strategy allows the later sessions to use DTLS
+ session resumption, which allows the amortization of the expensive
+ public key cryptography operations over multiple DTLS handshakes.
+
+ The SRTP keys used to protect packets originated by the client are
+ distinct from the SRTP keys used to protect packets originated by the
+ server. All of the RTP sources originating on the client for the
+ same channel use the same SRTP keys, and similarly, all of the RTP
+ sources originating on the server for the same channel use the same
+ SRTP keys. The SRTP implementation MUST ensure that all of the
+ synchronization source (SSRC) values for all of the RTP sources
+ originating from the same device over the same channel are distinct,
+ in order to avoid the "two-time pad" problem (as described in Section
+ 9.1 of RFC 3711). Note that this is not an issue for separate media
+ streams (on different host/port quartets) that use independent keying
+ material even if an SSRC collision occurs.
+
+4. DTLS Extensions for SRTP Key Establishment
+
+4.1. The use_srtp Extension
+
+ In order to negotiate the use of SRTP data protection, clients
+ include an extension of type "use_srtp" in the DTLS extended client
+ hello. This extension MUST only be used when the data being
+ transported is RTP or RTCP [RFC3550]. The "extension_data" field of
+ this extension contains the list of acceptable SRTP protection
+ profiles, as indicated below.
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 5]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ Servers that receive an extended hello containing a "use_srtp"
+ extension can agree to use SRTP by including an extension of type
+ "use_srtp", with the chosen protection profile in the extended server
+ hello. This process is shown below.
+
+ Client Server
+
+ ClientHello + use_srtp -------->
+ ServerHello + use_srtp
+ Certificate*
+ ServerKeyExchange*
+ CertificateRequest*
+ <-------- ServerHelloDone
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished -------->
+ [ChangeCipherSpec]
+ <-------- Finished
+ SRTP packets <-------> SRTP packets
+
+ Note that '*' indicates messages that are not always sent in DTLS.
+ The CertificateRequest, client and server Certificates, and
+ CertificateVerify will be sent in DTLS-SRTP.
+
+ Once the "use_srtp" extension is negotiated, the RTP or RTCP
+ application data is protected solely using SRTP. Application data is
+ never sent in DTLS record-layer "application_data" packets. Rather,
+ complete RTP or RTCP packets are passed to the DTLS stack, which
+ passes them to the SRTP stack, which protects them appropriately.
+ Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means
+ that RTP and RTCP packets may both be passed to the DTLS stack.
+ Because the DTLS layer does not process the packets, it does not need
+ to distinguish them. The SRTP stack can use the procedures of
+ [RFC5761] to distinguish RTP from RTCP.
+
+ When the "use_srtp" extension is in effect, implementations must not
+ place more than one application data "record" per datagram. (This is
+ only meaningful from the perspective of DTLS because SRTP is
+ inherently oriented towards one payload per packet, but this is
+ stated purely for clarification.)
+
+ Data other than RTP/RTCP (i.e., TLS control messages) MUST use
+ ordinary DTLS framing and MUST be placed in separate datagrams from
+ SRTP data.
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 6]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ A DTLS-SRTP handshake establishes one or more SRTP crypto contexts;
+ however, they all have the same SRTP Protection Profile and Master
+ Key Identifier (MKI), if any. MKIs are used solely to distinguish
+ the keying material and protection profiles between distinct
+ handshakes, for instance, due to rekeying. When an MKI is
+ established in a DTLS-SRTP session, it MUST apply for all of the
+ SSRCs within that session -- though a single endpoint may negotiate
+ multiple DTLS-SRTP sessions due, for instance, to forking. (Note
+ that RFC 3711 allows packets within the same session but with
+ different SSRCs to use MKIs differently; in contrast, DTLS-SRTP
+ requires that MKIs and the keys that they are associated with have
+ the same meaning and are uniform across the entire SRTP session.)
+
+4.1.1. use_srtp Extension Definition
+
+ The client MUST fill the extension_data field of the "use_srtp"
+ extension with an UseSRTPData value (see Section 9 for the
+ registration):
+
+ uint8 SRTPProtectionProfile[2];
+
+ struct {
+ SRTPProtectionProfiles SRTPProtectionProfiles;
+ opaque srtp_mki<0..255>;
+ } UseSRTPData;
+
+ SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
+
+ The SRTPProtectionProfiles list indicates the SRTP protection
+ profiles that the client is willing to support, listed in descending
+ order of preference. The srtp_mki value contains the SRTP Master Key
+ Identifier (MKI) value (if any) that the client will use for his SRTP
+ packets. If this field is of zero length, then no MKI will be used.
+
+ Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>"
+ indicates a variable-length value with a length between 0 and 255
+ (inclusive). Thus, the MKI may be up to 255 bytes long.
+
+ If the server is willing to accept the use_srtp extension, it MUST
+ respond with its own "use_srtp" extension in the ExtendedServerHello.
+ The extension_data field MUST contain a UseSRTPData value with a
+ single SRTPProtectionProfile value that the server has chosen for use
+ with this connection. The server MUST NOT select a value that the
+ client has not offered. If there is no shared profile, the server
+ SHOULD NOT return the use_srtp extension at which point the
+ connection falls back to the negotiated DTLS cipher suite. If that
+ is not acceptable, the server SHOULD return an appropriate DTLS
+ alert.
+
+
+
+McGrew & Rescorla Standards Track [Page 7]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+4.1.2. SRTP Protection Profiles
+
+ A DTLS-SRTP SRTP Protection Profile defines the parameters and
+ options that are in effect for the SRTP processing. This document
+ defines the following SRTP protection profiles.
+
+ SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
+ SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
+ SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
+ SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};
+
+ The following list indicates the SRTP transform parameters for each
+ protection profile. The parameters cipher_key_length,
+ cipher_salt_length, auth_key_length, and auth_tag_length express the
+ number of bits in the values to which they refer. The
+ maximum_lifetime parameter indicates the maximum number of packets
+ that can be protected with each single set of keys when the parameter
+ profile is in use. All of these parameters apply to both RTP and
+ RTCP, unless the RTCP parameters are separately specified.
+
+ All of the crypto algorithms in these profiles are from [RFC3711].
+
+ SRTP_AES128_CM_HMAC_SHA1_80
+ cipher: AES_128_CM
+ cipher_key_length: 128
+ cipher_salt_length: 112
+ maximum_lifetime: 2^31
+ auth_function: HMAC-SHA1
+ auth_key_length: 160
+ auth_tag_length: 80
+ SRTP_AES128_CM_HMAC_SHA1_32
+ cipher: AES_128_CM
+ cipher_key_length: 128
+ cipher_salt_length: 112
+ maximum_lifetime: 2^31
+ auth_function: HMAC-SHA1
+ auth_key_length: 160
+ auth_tag_length: 32
+ RTCP auth_tag_length: 80
+ SRTP_NULL_HMAC_SHA1_80
+ cipher: NULL
+ cipher_key_length: 0
+ cipher_salt_length: 0
+ maximum_lifetime: 2^31
+ auth_function: HMAC-SHA1
+ auth_key_length: 160
+ auth_tag_length: 80
+
+
+
+
+McGrew & Rescorla Standards Track [Page 8]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ SRTP_NULL_HMAC_SHA1_32
+ cipher: NULL
+ cipher_key_length: 0
+ cipher_salt_length: 0
+ maximum_lifetime: 2^31
+ auth_function: HMAC-SHA1
+ auth_key_length: 160
+ auth_tag_length: 32
+ RTCP auth_tag_length: 80
+
+ With all of these SRTP Parameter profiles, the following SRTP options
+ are in effect:
+
+ o The TLS PseudoRandom Function (PRF) is used to generate keys to
+ feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2
+ [DTLS1.2] is in use, the PRF is the one associated with the cipher
+ suite. Note that this specification is compatible with DTLS 1.0
+ or DTLS 1.2
+
+ o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are
+ not re-derived based on the SRTP sequence number.
+
+ o The key derivation procedures from Section 4.3 with the AES-CM PRF
+ from RFC 3711 are used.
+
+ o For all other parameters (in particular, SRTP replay window size
+ and FEC order), the default values are used.
+
+ If values other than the defaults for these parameters are required,
+ they can be enabled by writing a separate specification specifying
+ SDP syntax to signal them.
+
+ Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection
+ Profiles between the DTLS-SRTP session that protects an RTP flow and
+ the DTLS-SRTP session that protects the associated RTCP flow (in
+ those cases in which the RTP and RTCP are not multiplexed over a
+ common port). In particular, identical ciphers SHOULD be used.
+
+ New SRTPProtectionProfile values must be defined according to the
+ "Specification Required" policy as defined by RFC 5226 [RFC5226].
+ See Section 9 for IANA Considerations.
+
+4.1.3. srtp_mki value
+
+ The srtp_mki value MAY be used to indicate the capability and desire
+ to use the SRTP Master Key Identifier (MKI) field in the SRTP and
+ SRTCP packets. The MKI field indicates to an SRTP receiver which key
+ was used to protect the packet that contains that field. The
+
+
+
+McGrew & Rescorla Standards Track [Page 9]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ srtp_mki field contains the value of the SRTP MKI which is associated
+ with the SRTP master keys derived from this handshake. Each SRTP
+ session MUST have exactly one master key that is used to protect
+ packets at any given time. The client MUST choose the MKI value so
+ that it is distinct from the last MKI value that was used, and it
+ SHOULD make these values unique for the duration of the TLS session.
+
+ Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,
+ the server MUST either (assuming it accepts the extension at all):
+
+ 1. include a matching "srtp_mki" value in its "use_srtp" extension
+ to indicate that it will make use of the MKI, or
+ 2. return an empty "srtp_mki" value to indicate that it cannot make
+ use of the MKI.
+
+ If the client detects a nonzero-length MKI in the server's response
+ that is different than the one the client offered, then the client
+ MUST abort the handshake and SHOULD send an invalid_parameter alert.
+ If the client and server agree on an MKI, all SRTP packets protected
+ under the new security parameters MUST contain that MKI.
+
+ Note that any given DTLS-SRTP session only has a single active MKI
+ (if any). Thus, at any given time, a set of endpoints will generally
+ only be using one MKI (the major exception is during rehandshakes).
+
+4.2. Key Derivation
+
+ When SRTP mode is in effect, different keys are used for ordinary
+ DTLS record protection and SRTP packet protection. These keys are
+ generated using a TLS exporter [RFC5705] to generate
+
+ 2 * (SRTPSecurityParams.master_key_len +
+ SRTPSecurityParams.master_salt_len) bytes of data
+
+ which are assigned as shown below. The per-association context value
+ is empty.
+
+ client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
+ server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
+ client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
+ server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
+
+ The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The
+ "EXTRACTOR" prefix is for historical compatibility.)
+
+ The four keying material values (the master key and master salt for
+ each direction) are provided as inputs to the SRTP key derivation
+ mechanism, as shown in Figure 1 and detailed below. By default, the
+
+
+
+McGrew & Rescorla Standards Track [Page 10]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ mechanism defined in Section 4.3 of [RFC3711] is used, unless another
+ key derivation mechanism is specified as part of an SRTP Protection
+ Profile.
+
+ The client_write_SRTP_master_key and client_write_SRTP_master_salt
+ are provided to one invocation of the SRTP key derivation function,
+ to generate the SRTP keys used to encrypt and authenticate packets
+ sent by the client. The server MUST only use these keys to decrypt
+ and to check the authenticity of inbound packets.
+
+ The server_write_SRTP_master_key and server_write_SRTP_master_salt
+ are provided to one invocation of the SRTP key derivation function,
+ to generate the SRTP keys used to encrypt and authenticate packets
+ sent by the server. The client MUST only use these keys to decrypt
+ and to check the authenticity of inbound packets.
+
+ TLS master
+ secret label
+ | |
+ v v
+ +---------------+
+ | TLS extractor |
+ +---------------+
+ | +------+ SRTP
+ +-> client_write_SRTP_master_key ----+--->| SRTP |-> client
+ | | +->| KDF | write
+ | | | +------+ keys
+ | | |
+ +-> server_write_SRTP_master_key -- | | +------+ SRTCP
+ | \ \--->|SRTCP |-> client
+ | \ +->| KDF | write
+ | | | +------+ keys
+ +-> client_write_SRTP_master_salt ---|-+
+ | |
+ | | +------+ SRTP
+ | +--->| SRTP |-> server
+ +-> server_write_SRTP_master_salt -+-|--->| KDF | write
+ | | +------+ keys
+ | |
+ | | +------+ SRTCP
+ | +--->|SRTCP |-> server
+ +----->| KDF | write
+ +------+ keys
+
+ Figure 1: The derivation of the SRTP keys.
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 11]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ When both RTCP and RTP use the same source and destination ports,
+ then both the SRTP and SRTCP keys are needed. Otherwise, there are
+ two DTLS-SRTP sessions, one of which protects the RTP packets and one
+ of which protects the RTCP packets; each DTLS-SRTP session protects
+ the part of an SRTP session that passes over a single source/
+ destination transport address pair, as shown in Figure 2, independent
+ of which SSRCs are used on that pair. When a DTLS-SRTP session is
+ protecting RTP, the SRTCP keys derived from the DTLS handshake are
+ not needed and are discarded. When a DTLS-SRTP session is protecting
+ RTCP, the SRTP keys derived from the DTLS handshake are not needed
+ and are discarded.
+
+ Client Server
+ (Sender) (Receiver)
+ (1) <----- DTLS ------> src/dst = a/b and b/a
+ ------ SRTP ------> src/dst = a/b, uses client write keys
+
+ (2) <----- DTLS ------> src/dst = c/d and d/c
+ ------ SRTCP -----> src/dst = c/d, uses client write keys
+ <----- SRTCP ------ src/dst = d/c, uses server write keys
+
+ Figure 2: A DTLS-SRTP session protecting RTP (1) and another one
+ protecting RTCP (2), showing the transport addresses and keys used.
+
+4.3. Key Scope
+
+ Because of the possibility of packet reordering, DTLS-SRTP
+ implementations SHOULD store multiple SRTP keys sets during a rekey
+ in order to avoid the need for receivers to drop packets for which
+ they lack a key.
+
+4.4. Key Usage Limitations
+
+ The maximum_lifetime parameter in the SRTP protection profile
+ indicates the maximum number of packets that can be protected with
+ each single encryption and authentication key. (Note that, since RTP
+ and RTCP are protected with independent keys, those protocols are
+ counted separately for the purposes of determining when a key has
+ reached the end of its lifetime.) Each profile defines its own
+ limit. When this limit is reached, a new DTLS session SHOULD be used
+ to establish replacement keys, and SRTP implementations MUST NOT use
+ the existing keys for the processing of either outbound or inbound
+ traffic.
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 12]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+5. Use of RTP and RTCP over a DTLS-SRTP Channel
+
+5.1. Data Protection
+
+ Once the DTLS handshake has completed, the peers can send RTP or RTCP
+ over the newly created channel. We describe the transmission process
+ first followed by the reception process.
+
+ Within each RTP session, SRTP processing MUST NOT take place before
+ the DTLS handshake completes.
+
+5.1.1. Transmission
+
+ DTLS and TLS define a number of record content types. In ordinary
+ TLS/DTLS, all data is protected using the same record encoding and
+ mechanisms. When the mechanism described in this document is in
+ effect, this is modified so that data written by upper-level protocol
+ clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
+ rather than the standard TLS record encoding.
+
+ When a user of DTLS wishes to send an RTP packet in SRTP mode, it
+ delivers it to the DTLS implementation as an ordinary application
+ data write (e.g., SSL_write()). The DTLS implementation then invokes
+ the processing described in RFC 3711, Sections 3 and 4. The
+ resulting SRTP packet is then sent directly on the wire as a single
+ datagram with no DTLS framing. This provides an encapsulation of the
+ data that conforms to and interoperates with SRTP. Note that the RTP
+ sequence number rather than the DTLS sequence number is used for
+ these packets.
+
+5.1.2. Reception
+
+ When DTLS-SRTP is used to protect an RTP session, the RTP receiver
+ needs to demultiplex packets that are arriving on the RTP port.
+ Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If
+ these are the only types of packets present, the type of a packet can
+ be determined by looking at its first byte.
+
+ The process for demultiplexing a packet is as follows. The receiver
+ looks at the first byte of the packet. If the value of this byte is
+ 0 or 1, then the packet is STUN. If the value is in between 128 and
+ 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
+ RTP are being multiplexed over the same destination port). If the
+ value is between 20 and 63 (inclusive), the packet is DTLS. This
+ process is summarized in Figure 3.
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 13]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ +----------------+
+ | 127 < B < 192 -+--> forward to RTP
+ | |
+ packet --> | 19 < B < 64 -+--> forward to DTLS
+ | |
+ | B < 2 -+--> forward to STUN
+ +----------------+
+
+ Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
+ Here the field B denotes the leading byte of the packet.
+
+ If other packet types are to be multiplexed as well, implementors
+ and/or designers SHOULD ensure that they can be demultiplexed from
+ these three packet types.
+
+ In some cases, there will be multiple DTLS-SRTP associations for a
+ given SRTP endpoint. For instance, if Alice makes a call that is SIP
+ forked to both Bob and Charlie, she will use the same local host/port
+ pair for both of them, as shown in Figure 4, where XXX and YYY
+ represent different DTLS-SRTP associations. (The SSRCs shown are the
+ ones for data flowing to Alice.)
+
+ Bob (192.0.2.1:6666)
+ /
+ /
+ / SSRC=1
+ / DTLS-SRTP=XXX
+ /
+ v
+ Alice (192.0.2.0:5555)
+ ^
+ \
+ \ SSRC=2
+ \ DTLS-SRTP=YYY
+ \
+ \
+ Charlie (192.0.2.2:6666)
+
+ Figure 4: RTP sessions with SIP forking.
+
+ Because DTLS operates on the host/port quartet, the DTLS association
+ will still complete correctly, with the foreign host/port pair being
+ used, to distinguish the associations. However, in RTP the source
+ host/port is not used and sessions are identified by the destination
+ host/port and the SSRC. Thus, some mechanism is needed to determine
+ which SSRCs correspond to which DTLS associations. The following
+ method SHOULD be used.
+
+
+
+
+McGrew & Rescorla Standards Track [Page 14]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ For each local host/port pair, the DTLS-SRTP implementation maintains
+ a table listing all the SSRCs it knows about and the DTLS-SRTP
+ associations they correspond to. Initially, this table is empty.
+ When an SRTP packet is received for a given RTP endpoint (destination
+ IP/port pair), the following procedure is used:
+
+ 1. If the SSRC is already known for that endpoint, then the
+ corresponding DTLS-SRTP association and its keying material is
+ used to decrypt and verify the packet.
+ 2. If the SSRC is not known, then the receiver tries to decrypt it
+ with the keying material corresponding to each DTLS-SRTP
+ association for that endpoint.
+ 3. If the decryption and verification succeeds (the authentication
+ tag verifies), then an entry is placed in the table mapping the
+ SSRC to that association.
+ 4. If the decryption and verification fails, then the packet is
+ silently discarded.
+ 5. When a DTLS-SRTP association is closed (for instance, because the
+ fork is abandoned), its entries MUST be removed from the mapping
+ table.
+
+ The average cost of this algorithm for a single SSRC is the
+ decryption and verification time of a single packet times the number
+ of valid DTLS-SRTP associations corresponding to a single receiving
+ port on the host. In practice, this means the number of forks; so in
+ the case shown in Figure 4, that would be two. This cost is only
+ incurred once for any given SSRC, since afterwards that SSRC is
+ placed in the map table and looked up immediately. As with normal
+ RTP, this algorithm allows new SSRCs to be introduced by the source
+ at any time. They will automatically be mapped to the correct DTLS
+ association.
+
+ Note that this algorithm explicitly allows multiple SSRCs to be sent
+ from the same address/port pair. One way in which this can happen is
+ an RTP translator. This algorithm will automatically assign the
+ SSRCs to the correct associations. Note that because the SRTP
+ packets are cryptographically protected, such a translator must
+ either share keying material with one endpoint or refrain from
+ modifying the packets in a way which would cause the integrity check
+ to fail. This is a general property of SRTP and is not specific to
+ DTLS-SRTP.
+
+ There are two error cases that should be considered. First, if an
+ SSRC collision occurs, then only the packets from the first source
+ will be processed. When the packets from the second source arrive,
+ the DTLS association with the first source will be used for
+ decryption and verification, which will fail, and the packet will be
+ discarded. This is consistent with [RFC3550], which permits the
+
+
+
+McGrew & Rescorla Standards Track [Page 15]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ receiver to keep the packets from one source and discard those from
+ the other. Of course the RFC 3550 SSRC collision detection and
+ handling procedures MUST also be followed.
+
+ Second, there may be cases where a malfunctioning source is sending
+ corrupt packets that cannot be decrypted and verified. In this case,
+ the SSRC will never be entered into the mapping table because the
+ decryption and verification always fails. Receivers MAY keep records
+ of unmapped SSRCs that consistently fail decryption and verification
+ and abandon attempts to process them once they reach some limit.
+ That limit MUST be large enough to account for the effects of
+ transmission errors. Entries MUST be pruned from this table when the
+ relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD
+ time out faster than that (we do not offer a hard recommendation but
+ 10 to 30 seconds seems appropriate) in order to allow for the
+ possibility that the peer implementation has been corrected.
+
+5.2. Rehandshake and Rekey
+
+ Rekeying in DTLS is accomplished by performing a new handshake over
+ the existing DTLS channel. That is, the handshake messages are
+ protected by the existing DTLS cipher suite. This handshake can be
+ performed in parallel with data transport, so no interruption of the
+ data flow is required. Once the handshake is finished, the newly
+ derived set of keys is used to protect all outbound packets, both
+ DTLS and SRTP.
+
+ Because of packet reordering, packets protected by the previous set
+ of keys can appear on the wire after the handshake has completed. To
+ compensate for this fact, receivers SHOULD maintain both sets of keys
+ for some time in order to be able to decrypt and verify older
+ packets. The keys should be maintained for the duration of the
+ maximum segment lifetime (MSL).
+
+ If an MKI is used, then the receiver should use the corresponding set
+ of keys to process an incoming packet. If no matching MKI is
+ present, the packet MUST be rejected. Otherwise, when a packet
+ arrives after the handshake completed, a receiver SHOULD use the
+ newly derived set of keys to process that packet unless there is an
+ MKI. (If the packet was protected with the older set of keys, this
+ fact will become apparent to the receiver as an authentication
+ failure will occur.) If the authentication check on the packet fails
+ and no MKI is being used, then the receiver MAY process the packet
+ with the older set of keys. If that authentication check indicates
+ that the packet is valid, the packet should be accepted; otherwise,
+ the packet MUST be discarded and rejected.
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 16]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ Receivers MAY use the SRTP packet sequence number to aid in the
+ selection of keys. After a packet has been received and
+ authenticated with the new key set, any packets with sequence numbers
+ that are greater will also have been protected with the new key set.
+
+6. Multi-Party RTP Sessions
+
+ Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only
+ to protect unicast RTP sessions. This does not preclude its use with
+ RTP mixers. For example, a conference bridge may use DTLS-SRTP to
+ secure the communication to and from each of the participants in a
+ conference. However, because each flow between an endpoint and a
+ mixer has its own key, the mixer has to decrypt and then reencrypt
+ the traffic for each recipient.
+
+ A future specification may describe methods for sharing a single key
+ between multiple DTLS-SRTP associations thus allowing conferencing
+ systems to avoid the decrypt/reencrypt stage. However, any system in
+ which the media is modified (e.g., for level balancing or
+ transcoding) will generally need to be performed on the plaintext and
+ will certainly break the authentication tag, and therefore will
+ require a decrypt/reencrypt stage.
+
+7. Security Considerations
+
+ The use of multiple data protection framings negotiated in the same
+ handshake creates some complexities, which are discussed here.
+
+7.1. Security of Negotiation
+
+ One concern here is that attackers might be able to implement a bid-
+ down attack forcing the peers to use ordinary DTLS rather than SRTP.
+ However, because the negotiation of this extension is performed in
+ the DTLS handshake, it is protected by the Finished messages.
+ Therefore, any bid-down attack is automatically detected, which
+ reduces this to a denial-of-service attack -- which can be mounted by
+ any attacker who can control the channel.
+
+7.2. Framing Confusion
+
+ Because two different framing formats are used, there is concern that
+ an attacker could convince the receiver to treat an SRTP-framed RTP
+ packet as a DTLS record (e.g., a handshake message) or vice versa.
+ This attack is prevented by using different keys for Message
+ Authentication Code (MAC) verification for each type of data.
+ Therefore, this type of attack reduces to being able to forge a
+ packet with a valid MAC, which violates a basic security invariant of
+ both DTLS and SRTP.
+
+
+
+McGrew & Rescorla Standards Track [Page 17]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ As an additional defense against injection into the DTLS handshake
+ channel, the DTLS record type is included in the MAC. Therefore, an
+ SRTP record would be treated as an unknown type and ignored. (See
+ Section 6 of [RFC5246].)
+
+7.3. Sequence Number Interactions
+
+ As described in Section 5.1.1, the SRTP and DTLS sequence number
+ spaces are distinct. This means that it is not possible to
+ unambiguously order a given DTLS control record with respect to an
+ SRTP packet. In general, this is relevant in two situations: alerts
+ and rehandshake.
+
+7.3.1. Alerts
+
+ Because DTLS handshake and change_cipher_spec messages share the same
+ sequence number space as alerts, they can be ordered correctly.
+ Because DTLS alerts are inherently unreliable and SHOULD NOT be
+ generated as a response to data packets, reliable sequencing between
+ SRTP packets and DTLS alerts is not an important feature. However,
+ implementations that wish to use DTLS alerts to signal problems with
+ the SRTP encoding SHOULD simply act on alerts as soon as they are
+ received and assume that they refer to the temporally contiguous
+ stream. Such implementations MUST check for alert retransmission and
+ discard retransmitted alerts to avoid overreacting to replay attacks.
+
+7.3.2. Renegotiation
+
+ Because the rehandshake transition algorithm specified in Section 5.2
+ requires trying multiple sets of keys if no MKI is used, it slightly
+ weakens the authentication. For instance, if an n-bit MAC is used
+ and k different sets of keys are present, then the MAC is weakened by
+ log_2(k) bits to n - log_2(k). In practice, since the number of keys
+ used will be very small and the MACs in use are typically strong (the
+ default for SRTP is 80 bits), the decrease in security involved here
+ is minimal.
+
+ Another concern here is that this algorithm slightly increases the
+ work factor on the receiver because it needs to attempt multiple
+ validations. However, again, the number of potential keys will be
+ very small (and the attacker cannot force it to be larger) and this
+ technique is already used for rollover counter management, so the
+ authors do not consider this to be a serious flaw.
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 18]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+7.4. Decryption Cost
+
+ An attacker can impose computational costs on the receiver by sending
+ superficially valid SRTP packets that do not decrypt correctly. In
+ general, encryption algorithms are so fast that this cost is
+ extremely small compared to the bandwidth consumed. The SSRC-DTLS
+ mapping algorithm described in Section 5.1.2 gives the attacker a
+ slight advantage here because he can force the receiver to do more
+ then one decryption per packet. However, this advantage is modest
+ because the number of decryptions that the receiver does is limited
+ by the number of associations he has corresponding to a given
+ destination host/port, which is typically quite small. For
+ comparison, a single 1024-bit RSA private key operation (the typical
+ minimum cost to establish a DTLS-SRTP association) is hundreds of
+ times as expensive as decrypting an SRTP packet.
+
+ Implementations can detect this form of attack by keeping track of
+ the number of SRTP packets that are observed with unknown SSRCs and
+ that fail the authentication tag check. If under such attack,
+ implementations SHOULD prioritize decryption and verification of
+ packets that either have known SSRCs or come from source addresses
+ that match those of peers with which it has DTLS-SRTP associations.
+
+8. Session Description for RTP/SAVP over DTLS
+
+ This specification defines new tokens to describe the protocol used
+ in SDP media descriptions ("m=" lines and their associated
+ parameters). The new values defined for the proto field are:
+
+ o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
+ DTLS with the Datagram Congestion Control Protocol (DCCP), then
+ the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
+ respectively.
+
+ o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
+ UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
+ respectively.
+
+ The "fmt" parameter SHALL be as defined for RTP/SAVP.
+
+ See [RFC5763] for how to use offer/answer with DTLS-SRTP.
+
+ This document does not specify how to protect RTP data transported
+ over TCP. Potential approaches include carrying the RTP over TLS
+ over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that
+ in this document over TCP, either via TLS or DTLS, with DTLS being
+ used for consistency between reliable and unreliable transports. In
+
+
+
+
+McGrew & Rescorla Standards Track [Page 19]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ the latter case, it would be necessary to profile DTLS so that
+ fragmentation and retransmissions no longer occurred. In either
+ case, a new document would be required.
+
+9. IANA Considerations
+
+ This document adds a new extension for DTLS, in accordance with
+ [RFC5246]:
+ enum { use_srtp (14) } ExtensionType;
+
+ This extension MUST only be used with DTLS, and not with TLS
+ [RFC4572], which specifies that TLS can be used over TCP but does not
+ address TCP for RTP/SAVP.
+
+ Section 4.1.2 requires that all SRTPProtectionProfile values be
+ defined by RFC 5226 "Specification Required". IANA has created a
+ DTLS SRTPProtectionProfile registry initially populated with values
+ from Section 4.1.2 of this document. Future values MUST be allocated
+ via the "Specification Required" profile of [RFC5226].
+
+ This specification updates the "Session Description Protocol (SDP)
+ Parameters" registry as defined in Section 8.2.2 of [RFC4566].
+ Specifically, it adds the following values to the table for the
+ "proto" field.
+
+ Type SDP Name Reference
+ ---- ------------------ ---------
+ proto UDP/TLS/RTP/SAVP [RFC5764]
+ proto DCCP/TLS/RTP/SAVP [RFC5764]
+
+ proto UDP/TLS/RTP/SAVPF [RFC5764]
+ proto DCCP/TLS/RTP/SAVPF [RFC5764]
+
+ IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS
+ Extractor Label Registry to correspond to this specification.
+
+10. Acknowledgments
+
+ Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen,
+ Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing,
+ and Ben Campbell for input, discussions, and guidance. Pasi Eronen
+ provided Figure 1.
+
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 20]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
+ and K. Norrman, "The Secure Real-time Transport
+ Protocol (SRTP)", RFC 3711, March 2004.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
+ Layer Security", RFC 4347, April 2006.
+
+ [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
+ (RTCP)", BCP 131, RFC 4961, July 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [RFC5705] Rescorla, E., "Keying Material Exporters for
+ Transport Layer Security (TLS)", RFC 5705,
+ March 2010.
+
+ [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP
+ Data and Control Packets on a Single Port",
+ RFC 5761, April 2010.
+
+11.2. Informative References
+
+ [DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport
+ Layer Security version 1.2", Work in Progress,
+ October 2009.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [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.
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 21]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile
+ for Real-time Transport Control Protocol (RTCP)-
+ Based Feedback (RTP/SAVPF)", RFC 5124,
+ February 2008.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
+ Writing an IANA Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)",
+ RFC 5389, October 2008.
+
+ [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla,
+ "Framework for Establishing a Secure Real-time
+ Transport Protocol (SRTP) Security Context Using
+ Datagram Transport Layer Security (DTLS)", RFC 5763,
+ May 2010.
+
+ [SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not
+ Mandate a Single Security Mechanism", Work in
+ Progress, January 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 22]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+Appendix A. Overview of DTLS
+
+ This section provides a brief overview of Datagram TLS (DTLS) for
+ those who are not familiar with it. DTLS is a channel security
+ protocol based on the well-known Transport Layer Security (TLS)
+ [RFC5246] protocol. Where TLS depends on a reliable transport
+ channel (typically TCP), DTLS has been adapted to support unreliable
+ transports such as UDP. Otherwise, DTLS is nearly identical to TLS
+ and generally supports the same cryptographic mechanisms.
+
+ Each DTLS association begins with a handshake exchange (shown below)
+ during which the peers authenticate each other and negotiate
+ algorithms, modes, and other parameters and establish shared keying
+ material, as shown below. In order to support unreliable transport,
+ each side maintains retransmission timers to provide reliable
+ delivery of these messages. Once the handshake is completed,
+ encrypted data may be sent.
+
+ Client Server
+
+ ClientHello -------->
+ ServerHello
+ Certificate*
+ ServerKeyExchange*
+ CertificateRequest*
+ <-------- ServerHelloDone
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished -------->
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ '*' indicates messages that are not always sent.
+
+ Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).
+
+ Application data is protected by being sent as a series of DTLS
+ "records". These records are independent and can be processed
+ correctly even in the face of loss or reordering. In DTLS-SRTP, this
+ record protocol is replaced with SRTP [RFC3711]
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 23]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+Appendix B. Performance of Multiple DTLS Handshakes
+
+ Standard practice for security protocols such as TLS, DTLS, and SSH,
+ which do inline key management, is to create a separate security
+ association for each underlying network channel (TCP connection, UDP
+ host/port quartet, etc.). This has dual advantages of simplicity and
+ independence of the security contexts for each channel.
+
+ Three concerns have been raised about the overhead of this strategy
+ in the context of RTP security. The first concern is the additional
+ performance overhead of doing a separate public key operation for
+ each channel. The conventional procedure here (used in TLS and DTLS)
+ is to establish a master context that can then be used to derive
+ fresh traffic keys for new associations. In TLS/DTLS, this is called
+ "session resumption" and can be transparently negotiated between the
+ peers.
+
+ The second concern is network bandwidth overhead for the
+ establishment of subsequent connections and for rehandshake (for
+ rekeying) for existing connections. In particular, there is a
+ concern that the channels will have very narrow capacity requirements
+ allocated entirely to media that will be overflowed by the
+ rehandshake. Measurements of the size of the rehandshake (with
+ resumption) in TLS indicate that it is about 300-400 bytes if a full
+ selection of cipher suites is offered. (The size of a full handshake
+ is approximately 1-2 kilobytes larger because of the certificate and
+ keying material exchange.)
+
+ The third concern is the additional round-trips associated with
+ establishing the second, third, ... channels. In TLS/DTLS, these can
+ all be done in parallel, but in order to take advantage of session
+ resumption they should be done after the first channel is
+ established. For two channels, this provides a ladder diagram
+ something like this (parenthetical numbers are media channel numbers)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 24]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ Alice Bob
+ -------------------------------------------
+ <- ClientHello (1)
+ ServerHello (1) ->
+ Certificate (1)
+ ServerHelloDone (1)
+ <- ClientKeyExchange (1)
+ ChangeCipherSpec (1)
+ Finished (1)
+ ChangeCipherSpec (1)->
+ Finished (1)->
+ <--- Channel 1 ready
+
+ <- ClientHello (2)
+ ServerHello (2) ->
+ ChangeCipherSpec(2)->
+ Finished(2) ->
+ <- ChangeCipherSpec (2)
+ Finished (2)
+ <--- Channel 2 ready
+
+ Figure 6: Parallel DTLS-SRTP negotiations.
+
+ So, there is an additional 1 RTT (round-trip time) after Channel 1 is
+ ready before Channel 2 is ready. If the peers are potentially
+ willing to forego resumption, they can interlace the handshakes, like
+ so:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 25]
+
+RFC 5764 SRTP Extension for DTLS May 2010
+
+
+ Alice Bob
+ -------------------------------------------
+ <- ClientHello (1)
+ ServerHello (1) ->
+ Certificate (1)
+ ServerHelloDone (1)
+ <- ClientKeyExchange (1)
+ ChangeCipherSpec (1)
+ Finished (1)
+ <- ClientHello (2)
+ ChangeCipherSpec (1)->
+ Finished (1)->
+ <--- Channel 1 ready
+ ServerHello (2) ->
+ ChangeCipherSpec(2)->
+ Finished(2) ->
+ <- ChangeCipherSpec (2)
+ Finished (2)
+ <--- Channel 2 ready
+
+ Figure 7: Interlaced DTLS-SRTP negotiations.
+
+ In this case, the channels are ready contemporaneously, but if a
+ message in handshake (1) is lost, then handshake (2) requires either
+ a full rehandshake or that Alice be clever and queue the resumption
+ attempt until the first handshake completes. Note that just dropping
+ the packet works as well, since Bob will retransmit.
+
+Authors' Addresses
+
+ David McGrew
+ Cisco Systems
+ 510 McCarthy Blvd.
+ Milpitas, CA 95305
+ USA
+
+ EMail: mcgrew at cisco.com
+
+
+ Eric Rescorla
+ RTFM, Inc.
+ 2064 Edgewood Drive
+ Palo Alto, CA 94303
+ USA
+
+ EMail: ekr at rtfm.com
+
+
+
+
+
+McGrew & Rescorla Standards Track [Page 26]
+
diff --git a/lib/ext/Makefile.am b/lib/ext/Makefile.am
index ca6628e..0d97132 100644
--- a/lib/ext/Makefile.am
+++ b/lib/ext/Makefile.am
@@ -39,5 +39,5 @@ libgnutls_ext_la_SOURCES = max_record.c cert_type.c \
max_record.h cert_type.h server_name.h srp.h \
session_ticket.h signature.h safe_renegotiation.h \
session_ticket.c srp.c ecc.c ecc.h heartbeat.c heartbeat.h \
- status_request.h status_request.c
+ status_request.h status_request.c srtp.c srtp.h
diff --git a/lib/ext/srtp.c b/lib/ext/srtp.c
new file mode 100644
index 0000000..7b582ba
--- /dev/null
+++ b/lib/ext/srtp.c
@@ -0,0 +1,415 @@
+/*
+ * Copyright (C) 2012 Free Software Foundation, Inc.
+ *
+ * Author: Martin Storsjo
+ *
+ * This file is part of GnuTLS.
+ *
+ * The GnuTLS is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 3 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+
+#include "gnutls_int.h"
+#include "gnutls_auth.h"
+#include "gnutls_errors.h"
+#include "gnutls_num.h"
+#include <ext/srtp.h>
+
+static int _gnutls_srtp_recv_params (gnutls_session_t session,
+ const uint8_t * data,
+ size_t data_size);
+static int _gnutls_srtp_send_params (gnutls_session_t session,
+ gnutls_buffer_st* extdata);
+
+static int _gnutls_srtp_unpack (gnutls_buffer_st * ps,
+ extension_priv_data_t * _priv);
+static int _gnutls_srtp_pack (extension_priv_data_t _priv,
+ gnutls_buffer_st * ps);
+static void _gnutls_srtp_deinit_data (extension_priv_data_t priv);
+
+
+extension_entry_st ext_mod_srtp = {
+ .name = "SRTP",
+ .type = GNUTLS_EXTENSION_SRTP,
+ .parse_type = GNUTLS_EXT_APPLICATION,
+
+ .recv_func = _gnutls_srtp_recv_params,
+ .send_func = _gnutls_srtp_send_params,
+ .pack_func = _gnutls_srtp_pack,
+ .unpack_func = _gnutls_srtp_unpack,
+ .deinit_func = _gnutls_srtp_deinit_data,
+};
+
+typedef struct
+{
+ const char *name;
+ uint16_t id;
+} srtp_profile_st;
+
+static const srtp_profile_st profile_names[] = {
+ {
+ "SRTP_AES128_CM_SHA1_80",
+ 0x0001,
+ },
+ {
+ "SRTP_AES128_CM_SHA1_32",
+ 0x0002,
+ },
+ {
+ "SRTP_NULL_SHA1_80",
+ 0x0005,
+ },
+ {
+ "SRTP_NULL_SHA1_32",
+ 0x0006,
+ },
+ {
+ NULL,
+ 0
+ }
+};
+
+static uint16_t find_profile (const char *str, const char *end)
+{
+ const srtp_profile_st *prof = profile_names;
+ int len;
+ if (end != NULL)
+ {
+ len = end - str;
+ }
+ else
+ {
+ len = strlen (str);
+ }
+
+ while (prof->name != NULL)
+ {
+ if (strlen (prof->name) == len && !strncmp (str, prof->name, len))
+ {
+ return prof->id;
+ }
+ prof++;
+ }
+ return 0;
+}
+
+static int
+_gnutls_srtp_recv_params (gnutls_session_t session,
+ const uint8_t *data, size_t _data_size)
+{
+ int i, j, ret;
+ const uint8_t *p = data;
+ int len;
+ ssize_t data_size = _data_size;
+ srtp_ext_st *priv;
+ extension_priv_data_t epriv;
+ uint16_t profiles[MAX_SRTP_PROFILES];
+ unsigned int profiles_size = 0;
+
+ ret =
+ _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP,
+ &epriv);
+ if (ret < 0)
+ return 0;
+
+ priv = epriv.ptr;
+
+ DECR_LENGTH_RET (data_size, 2, 0);
+ len = _gnutls_read_uint16 (p);
+ p += 2;
+
+ while (len > 0)
+ {
+ DECR_LENGTH_RET (data_size, 2, 0);
+ if (profiles_size < MAX_SRTP_PROFILES)
+ profiles_size++;
+ profiles[profiles_size - 1] = _gnutls_read_uint16 (p);
+ p += 2;
+ len -= 2;
+ }
+
+ for (i = 0; i < priv->profiles_size && priv->selected_profile == 0; i++)
+ {
+ for (j = 0; j < profiles_size; j++)
+ {
+ if (priv->profiles[i] == profiles[j])
+ {
+ priv->selected_profile = profiles[j];
+ break;
+ }
+ }
+ }
+
+ return 0;
+}
+
+/* returns data_size or a negative number on failure
+ */
+static int
+_gnutls_srtp_send_params (gnutls_session_t session,
+ gnutls_buffer_st* extdata)
+{
+ uint16_t len;
+ unsigned i;
+ int total_size = 0, ret;
+ srtp_ext_st *priv;
+ extension_priv_data_t epriv;
+
+ ret =
+ _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP,
+ &epriv);
+ if (ret < 0)
+ return 0;
+
+ priv = epriv.ptr;
+
+ if (priv->profiles_size == 0)
+ return 0;
+
+ if (session->security_parameters.entity == GNUTLS_SERVER)
+ {
+ /* Don't send anything if no matching profile was found */
+ if (priv->selected_profile == 0)
+ return 0;
+
+ ret = _gnutls_buffer_append_prefix(extdata, 16, 2);
+ if (ret < 0)
+ return gnutls_assert_val(ret);
+ ret = _gnutls_buffer_append_prefix(extdata, 16, priv->selected_profile);
+ if (ret < 0)
+ return gnutls_assert_val(ret);
+ total_size = 4;
+ }
+ else
+ {
+ ret = _gnutls_buffer_append_prefix(extdata, 16, 2 * priv->profiles_size);
+ if (ret < 0)
+ return gnutls_assert_val(ret);
+
+ for (i = 0; i < priv->profiles_size; i++)
+ {
+ ret = _gnutls_buffer_append_prefix(extdata, 16, priv->profiles[i]);
+ if (ret < 0)
+ return gnutls_assert_val(ret);
+ }
+ total_size = 2 + 2 * priv->profiles_size;
+ }
+
+ /* use_mki, not supported yet */
+ ret = _gnutls_buffer_append_prefix(extdata, 8, 0);
+ if (ret < 0)
+ return gnutls_assert_val(ret);
+
+ return total_size + 1;
+}
+
+/**
+ * gnutls_srtp_get_selected_profile:
+ * @session: is a #gnutls_session_t structure.
+ * @profile: will hold the data
+ * @profile_length: will hold the data length. Must hold the maximum size of
+ * profile.
+ *
+ * This function will allow you to get the negotiated SRTP profile.
+ *
+ * If @profile has not enough size to hold the profile
+ * GNUTLS_E_SHORT_MEMORY_BUFFER is returned, and @profile_length will
+ * hold the required size.
+ *
+ * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned,
+ * otherwise a negative error code is returned.
+ **/
+int
+gnutls_srtp_get_selected_profile (gnutls_session_t session, char *profile,
+ size_t *profile_length)
+{
+ srtp_ext_st *priv;
+ int ret, len;
+ extension_priv_data_t epriv;
+ const srtp_profile_st *prof = profile_names;
+
+ ret =
+ _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP,
+ &epriv);
+ if (ret < 0)
+ {
+ gnutls_assert ();
+ return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE;
+ }
+
+ priv = epriv.ptr;
+
+ if (priv->selected_profile == 0)
+ {
+ return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE;
+ }
+
+ while (prof->name != NULL)
+ {
+ if (prof->id == priv->selected_profile)
+ break;
+ prof++;
+ }
+
+ if (prof->name == NULL)
+ {
+ /* We only ever set profiles that we've matched against the profile
+ * name list, and we only set selected_profile to one of the profiles
+ * we've chosen, so this shouldn't happen. */
+ gnutls_assert ();
+ return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE;
+ }
+
+ len = strlen (prof->name);
+
+ if (*profile_length > len)
+ {
+ *profile_length = len;
+ strcpy (profile, prof->name);
+ }
+ else
+ {
+ *profile_length = len + 1; /* Requires extra space for the null termination */
+ return GNUTLS_E_SHORT_MEMORY_BUFFER;
+ }
+
+ return 0;
+}
+
+/**
+ * gnutls_srtp_set_profiles:
+ * @session: is a #gnutls_session_t structure.
+ * @profiles: is a string that contains the supported SRTP profiles,
+ * separated by colons.
+ *
+ * This function is to be used by both clients and servers, to declare
+ * what SRTP profiles they support, to negotiate with the peer.
+ *
+ * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned,
+ * otherwise a negative error code is returned.
+ **/
+int
+gnutls_srtp_set_profiles (gnutls_session_t session,
+ const char *profiles)
+{
+ int server_names, ret;
+ srtp_ext_st *priv;
+ extension_priv_data_t epriv;
+ int set = 0;
+ const char *col;
+ uint16_t id;
+
+ ret =
+ _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP,
+ &epriv);
+ if (ret < 0)
+ {
+ set = 1;
+ }
+
+ if (set != 0)
+ {
+ priv = gnutls_calloc (1, sizeof (*priv));
+ if (priv == NULL)
+ {
+ gnutls_assert ();
+ return GNUTLS_E_MEMORY_ERROR;
+ }
+ epriv.ptr = priv;
+ }
+ else
+ priv = epriv.ptr;
+
+ do
+ {
+ col = strchr (profiles, ':');
+ id = find_profile (profiles, col);
+ if (id == 0)
+ {
+ if (set != 0)
+ {
+ gnutls_free (priv);
+ }
+ return GNUTLS_E_ILLEGAL_PARAMETER;
+ }
+
+ if (priv->profiles_size < MAX_SRTP_PROFILES)
+ {
+ priv->profiles_size++;
+ }
+ priv->profiles[priv->profiles_size - 1] = id;
+ profiles = col + 1;
+ } while (col != NULL);
+
+ if (set != 0)
+ _gnutls_ext_set_session_data (session, GNUTLS_EXTENSION_SRTP,
+ epriv);
+
+ return 0;
+}
+
+static void
+_gnutls_srtp_deinit_data (extension_priv_data_t priv)
+{
+ gnutls_free (priv.ptr);
+}
+
+static int
+_gnutls_srtp_pack (extension_priv_data_t epriv, gnutls_buffer_st * ps)
+{
+ srtp_ext_st *priv = epriv.ptr;
+ unsigned int i;
+ int ret;
+
+ BUFFER_APPEND_NUM (ps, priv->profiles_size);
+ for (i = 0; i < priv->profiles_size; i++)
+ {
+ BUFFER_APPEND_NUM (ps, priv->profiles[i]);
+ }
+ BUFFER_APPEND_NUM (ps, priv->selected_profile);
+ return 0;
+}
+
+static int
+_gnutls_srtp_unpack (gnutls_buffer_st * ps,
+ extension_priv_data_t * _priv)
+{
+ srtp_ext_st *priv;
+ unsigned int i;
+ int ret;
+ extension_priv_data_t epriv;
+
+ priv = gnutls_calloc (1, sizeof (*priv));
+ if (priv == NULL)
+ {
+ gnutls_assert ();
+ return GNUTLS_E_MEMORY_ERROR;
+ }
+
+ BUFFER_POP_NUM (ps, priv->profiles_size);
+ for (i = 0; i < priv->profiles_size; i++)
+ {
+ BUFFER_POP_NUM (ps, priv->profiles[i]);
+ }
+ BUFFER_POP_NUM (ps, priv->selected_profile);
+
+ epriv.ptr = priv;
+ *_priv = epriv;
+
+ return 0;
+
+error:
+ gnutls_free (priv);
+ return ret;
+}
diff --git a/lib/ext/srtp.h b/lib/ext/srtp.h
new file mode 100644
index 0000000..44d5b87
--- /dev/null
+++ b/lib/ext/srtp.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2012 Free Software Foundation, Inc.
+ *
+ * Author: Martin Storsjo
+ *
+ * This file is part of GnuTLS.
+ *
+ * The GnuTLS is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 3 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+#ifndef EXT_SRTP_H
+#define EXT_SRTP_H
+
+#include <gnutls_extensions.h>
+
+#define MAX_SRTP_PROFILES 4
+
+typedef struct
+{
+ uint16_t profiles[MAX_SRTP_PROFILES];
+ unsigned profiles_size;
+ uint16_t selected_profile;
+} srtp_ext_st;
+
+extern extension_entry_st ext_mod_srtp;
+
+#endif
diff --git a/lib/gnutls_extensions.c b/lib/gnutls_extensions.c
index aab0a67..28a852b 100644
--- a/lib/gnutls_extensions.c
+++ b/lib/gnutls_extensions.c
@@ -39,6 +39,7 @@
#include <ext/safe_renegotiation.h>
#include <ext/ecc.h>
#include <ext/status_request.h>
+#include <ext/srtp.h>
#include <gnutls_num.h>
@@ -354,6 +355,10 @@ _gnutls_ext_init (void)
if (ret != GNUTLS_E_SUCCESS)
return ret;
+ ret = _gnutls_ext_register (&ext_mod_srtp);
+ if (ret != GNUTLS_E_SUCCESS)
+ return ret;
+
return GNUTLS_E_SUCCESS;
}
diff --git a/lib/gnutls_int.h b/lib/gnutls_int.h
index 1f103cb..68a176e 100644
--- a/lib/gnutls_int.h
+++ b/lib/gnutls_int.h
@@ -261,6 +261,7 @@ typedef enum extensions_t
GNUTLS_EXTENSION_SUPPORTED_ECC_PF = 11,
GNUTLS_EXTENSION_SRP = 12,
GNUTLS_EXTENSION_SIGNATURE_ALGORITHMS = 13,
+ GNUTLS_EXTENSION_SRTP = 14,
GNUTLS_EXTENSION_HEARTBEAT = 15,
GNUTLS_EXTENSION_SESSION_TICKET = 35,
GNUTLS_EXTENSION_SAFE_RENEGOTIATION = 65281 /* aka: 0xff01 */
diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in
index e60914e..a6db1dd 100644
--- a/lib/includes/gnutls/gnutls.h.in
+++ b/lib/includes/gnutls/gnutls.h.in
@@ -960,6 +960,12 @@ gnutls_ecc_curve_t gnutls_ecc_curve_get(gnutls_session_t session);
int gnutls_session_ticket_enable_server (gnutls_session_t session,
const gnutls_datum_t * key);
+ /* SRTP, RFC 5764 */
+ int gnutls_srtp_set_profiles (gnutls_session_t session,
+ const char *profiles);
+ int gnutls_srtp_get_selected_profile (gnutls_session_t session,
+ char *profile, size_t *profile_length);
+
int gnutls_key_generate (gnutls_datum_t * key, unsigned int key_size);
/* if you just want some defaults, use the following.
--
1.7.9.4
More information about the Gnutls-devel
mailing list