diff options
Diffstat (limited to 'doc/rfc/rfc5764.txt')
| -rw-r--r-- | doc/rfc/rfc5764.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5764.txt b/doc/rfc/rfc5764.txt new file mode 100644 index 0000000..6633f00 --- /dev/null +++ b/doc/rfc/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@cisco.com + + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + USA + + EMail: ekr@rtfm.com + + + + + +McGrew & Rescorla Standards Track [Page 26] + |