[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 02 draft-ietf-avt-dtls-srtp

Network Working Group                                          D. McGrew
Internet-Draft                                             Cisco Systems
Expires:  December 12, 2006                                  E. Rescorla
                                                       Network Resonance
                                                           June 10, 2006


Datagram Transport Layer Security (DTLS) Extension to Establish Keys for
               Secure Real-time Transport Protocol (SRTP)
                      draft-mcgrew-tls-srtp-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Secure Real-time Transport Protocol (SRTP) is a profile of the
   Real-time Transport Protocol that can provide confidentiality,
   message authentication, and replay protection to the RTP traffic and
   to the control traffic for RTP, the Real-time Transport Control
   Protocol (RTCP).  This document describes a method of using DTLS key
   management for SRTP by using a new extension that indicates that SRTP



McGrew & Rescorla       Expires December 12, 2006               [Page 1]


Internet-Draft           SRTP Extension for DTLS               June 2006


   is to be used for data protection, and which establishes SRTP keys.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Usage Model  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  The use_srtp Extension . . . . . . . . . . . . . . . . . .  4
       3.2.1.  use_srtp Extension Definition  . . . . . . . . . . . .  5
       3.2.2.  SRTP Protection Profiles . . . . . . . . . . . . . . .  6
       3.2.3.  srtp_mki value . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Key Scope  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.5.  Key Usage Limitations  . . . . . . . . . . . . . . . . . . 11
     3.6.  Data Protection  . . . . . . . . . . . . . . . . . . . . . 11
       3.6.1.  Transmission . . . . . . . . . . . . . . . . . . . . . 11
       3.6.2.  Reception  . . . . . . . . . . . . . . . . . . . . . . 11
     3.7.  Rehandshake and Re-key . . . . . . . . . . . . . . . . . . 12
   4.  Multi-party RTP Sessions . . . . . . . . . . . . . . . . . . . 13
     4.1.  SIP Forking  . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     5.1.  Security of Negotiation  . . . . . . . . . . . . . . . . . 13
     5.2.  Framing Confusion  . . . . . . . . . . . . . . . . . . . . 13
     5.3.  Sequence Number Interactions . . . . . . . . . . . . . . . 14
       5.3.1.  Alerts . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.3.2.  Renegotiation  . . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informational References . . . . . . . . . . . . . . . . . 16
   Appendix A.  Open Issue: Key/Stream Interaction  . . . . . . . . . 16
   Appendix B.  Open Issue: Using a single DTLS session per SRTP
                session . . . . . . . . . . . . . . . . . . . . . . . 18
     B.1.  Definition . . . . . . . . . . . . . . . . . . . . . . . . 19
       B.1.1.  SRTP Parameter Profiles for Single-DTLS  . . . . . . . 20
     B.2.  Pros and Cons of Single-DTLS . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23










McGrew & Rescorla       Expires December 12, 2006               [Page 2]


Internet-Draft           SRTP Extension for DTLS               June 2006


1.  Introduction

   The Secure Real-time Transport Protocol (SRTP) [6] is a profile of
   the Real-time Transport Protocol (RTP) [1] that can provide
   confidentiality, message authentication, and replay protection to RTP
   traffic and to the control traffic for RTP, the Real-time Transport
   Control Protocol (RTCP).  SRTP does not provide key management
   functionality but instead depends on external key management to
   provide secret master keys and the algorithms and parameters for use
   with those keys.

   Datagram Transport Layer Security (DTLS) [5] is a channel security
   protocol that offers integrated key management, parameter
   negotiation, and secure data transfer.  Because DTLS's 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, an SRTP extension for DTLS which
   combine the performance and encryption flexibility benefits of SRTP
   with the flexibility and convenience of DTLS's 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.

   This extension MUST only be used when the data being transported is
   RTP and RTCP [4].

   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 used to negotiate SRTP algorithms, and
   o  other DTLS record layer content types are protected using the
      ordinary DTLS record format.
   The next section provides details of the new extension.


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 [2].


3.  Protocol Description

   In this section we define the DTLS extension and its use.




McGrew & Rescorla       Expires December 12, 2006               [Page 3]


Internet-Draft           SRTP Extension for DTLS               June 2006


3.1.  Usage Model

   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
   an SRTP context.  Each RTCP flow is protected by a separate DTLS-SRTP
   session that is independent from the DTLS-SRTP session that protects
   the RTP packet flow.  Between a single pair of participants, there
   may be multiple media sessions; each session MUST have its own DTLS-
   SRTP session.  One or both of the DTLS-SRTP session participants MAY
   be RTP mixers.

   A DTLS-SRTP session can 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, and how to authenticate
   the endpoints using fingerprints can be found in [8] and [7].

   Each RTP stream participates in a single DTLS session.  In a naive
   implementation, this results in 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 connection is established, and all other DTLS sessions wait
   until that connection is established before proceeding with their
   session establishment exchanges.  This strategy allows the later
   sessions to use the DTLS session re-start, which allows the
   amortization of the expensive public key cryptography operations over
   multiple DTLS session establishment instances.

   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 use the
   same SRTP keys, and similarly, all of the RTP sources originating on
   the server over the same channel use the same SRTP keys.  The SRTP
   implementation MUST ensure that all of the SSRC values for all of the
   RTP sources originating from the same device are distinct, in order
   to avoid the "two-time pad" problem (as described in Section 9.1 of
   RFC 3711).

3.2.  The use_srtp Extension

   In order to negotiate the use of SRTP data protection, clients MAY
   include an extension of type "use_srtp" in the extended client hello.



McGrew & Rescorla       Expires December 12, 2006               [Page 4]


Internet-Draft           SRTP Extension for DTLS               June 2006


   The "extension_data" field of this extension contains the list of
   acceptable SRTP protection profiles, as indicated below.

   Servers that receive an extended hello containing a "use_srtp"
   extension MAY 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

   Once the "use_srtp" extension is negotiated, packets of type
   "application_data" in the newly negotiated association (i.e., after
   the change_cipher_spec) MUST be protected using SRTP and packets of
   type "application_data" MUST NOT be sent.  Records of type other than
   "application_data" MUST use ordinary DTLS framing.  When the
   "use_srtp" extension is in effect, implementations MUST NOT place
   more than one "record" per datagram.  (This is only meaningful from
   the perspective of DTLS because SRTP is inherently oriented towards
   one payload per packet, but is stated purely for clarification.)

3.2.1.  use_srtp Extension Definition

   The client MUST fill the extension_data field of the "use_srtp"
   extension with an UseSRTPData value:

      uint8 SRTPProtectionProfile[2];

      struct {
         SRTPProtectionProfiles SRTPProtectionProfiles;
         uint8 srtp_mki<255>;
      } UseSRTPData;

      SRTPProtectionProfile SRTPProtectionProfiles<2^16-1>;



McGrew & Rescorla       Expires December 12, 2006               [Page 5]


Internet-Draft           SRTP Extension for DTLS               June 2006


   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
   MasterKeyIdentifier (MKI) value (if any) which the client will use
   for his SRTP messages.

   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 which the server has chosen for
   use with this connection.  The server MUST NOT select a value which
   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.

3.2.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_SHA1_80 = {0x00, 0x01};
      SRTPProtectionProfile SRTP_AES128_CM_SHA1_32 = {0x00, 0x02};
      SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03};
      SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04};
      SRTPProtectionProfile SRTP_NULL_SHA1_80      = {0x00, 0x05};
      SRTPProtectionProfile SRTP_NULL_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 the crypto algorithms in these profiles are from [6], except
   for the AES256_CM cipher, which is specified in [13].

   SRTP_AES128_CM_HMAC_SHA1_80
         cipher:  AES_128_CM







McGrew & Rescorla       Expires December 12, 2006               [Page 6]


Internet-Draft           SRTP Extension for DTLS               June 2006


         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 Because of the short authentication tag
      provides limited authentication, this profile SHOULD NOT be used
      with RTCP.
         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
   SRTP_AES256_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_AES256_CM_HMAC_SHA1_32 Because of the short authentication tag
      provides limited authentication, this profile SHOULD NOT be used
      with RTCP.
         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
   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
   SRTP_NULL_HMAC_SHA1_32 Because the short authentication tag provides
      limited authentication, this profile SHOULD NOT be used with RTCP.







McGrew & Rescorla       Expires December 12, 2006               [Page 7]


Internet-Draft           SRTP Extension for DTLS               June 2006


         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
   With all of these SRTP Parameter profiles, the following SRTP options
   are in effect:
      The TLS Key Derivation Function (KDF) is used to generate keys to
      feed into the SRTP KDF.
      The Key Derivation Rate (KDR) is equal to zero.  Thus, keys are
      not re-derived based on the SRTP sequence number.
      For all other parameters, the default values are used.
   All SRTP parameters that are not determined by the SRTP Protection
   Profile MAY be established via the signaling system.  In particular,
   the relative order of Forward Error Correction and SRTP processing,
   and a suggested SRTP replay window size SHOULD be established in this
   manner.  An example of how these parameters can be defined for SDP by
   is contained in [9].

   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
   particular, identical ciphers SHOULD be used.

   New SRTPProtectionProfile values must be defined by RFC 2434
   Standards Action.  See Section Section 6 for IANA Considerations.

3.2.3.  srtp_mki value

   The srtp_mki value can be used to indicate the capability and desire
   to use the SRTP Master Key Indicator (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
   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.

   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




McGrew & Rescorla       Expires December 12, 2006               [Page 8]


Internet-Draft           SRTP Extension for DTLS               June 2006


   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 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.

3.3.  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 as additional keying material at the end of the DTLS key
   block.  Thus, the key block becomes:

   client_write_MAC_secret[SecurityParameters.hash_size]
   server_write_MAC_secret[SecurityParameters.hash_size]
   client_write_key[SecurityParameters.key_material_len]
   server_write_key[SecurityParameters.key_material_len]
   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 last four values are provided as inputs to the SRTP key
   derivation mechanism, as shown in Figure 5 and detailed below.  By
   default, the mechanism defined in Section 4.3 of [6] 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.









McGrew & Rescorla       Expires December 12, 2006               [Page 9]


Internet-Draft           SRTP Extension for DTLS               June 2006


       +------- TLS master secret
       |
       v    +-> client_write_MAC_secret
   +-----+  |
   | TLS |--+-> server_write_MAC_secret
   | KDF |  |
   +-----+  +-> client_write_key
            |
            +-> server_write_key
            |                                       +------+   SRTP
            +-> client_write_SRTP_master_key  ----->| SRTP |-> client
            |                                  +--->|  KDF |   write
            +-> server_write_SRTP_master_key --|-+  +------+   keys
            |                                  | |
            +-> client_write_SRTP_master_salt -+ |  +------+   SRTP
            |                                    +->| SRTP |-> server
            +-> server_write_SRTP_master_salt ----->|  KDF |   write
                                                    +------+   keys

   Figure 5: The derivation of the SRTP keys.

   Each DTLS-SRTP session protects the part of an SRTP session that
   passes over a single source/destinaation transport address pair, as
   shown in Figure 6.  When SRTP is run over that port, the SRTCP keys
   are not needed and are discarded.  When SRTCP is run over that port,
   the SRTP keys 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 6: A DTLS-SRTP session protecting RTP (1) and another one
   protecting RTCP (2), showing the transport addresses and keys used.

3.4.  Key Scope

   Because of the possibility of packet reorder, DTLS-SRTP
   implementations SHOULD store multiple SRTP keys sets during a re-key
   in order to avoid the need for receivers to drop packets for which
   they lack a key.






McGrew & Rescorla       Expires December 12, 2006              [Page 10]


Internet-Draft           SRTP Extension for DTLS               June 2006


3.5.  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.  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.

3.6.  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.

3.6.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 of type "application_data"
   (used to transport data traffic) 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 a single write of type
   "application_data".  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.

3.6.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[12].  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



McGrew & Rescorla       Expires December 12, 2006              [Page 11]


Internet-Draft           SRTP Extension for DTLS               June 2006


   191 (inclusive), then the packet is RTP.  If the value is between 20
   and 63 (inclusive), the packet is DTLS.  This processes is summarized
   in Figure 7.

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 2   -+--> forward to STUN
                   +----------------+

   Figure 7: The DTLS-SRTP receiver's packet demultiplexing
   algorithm.  Here the field B denotes the leading byte of the packet.

3.7.  Rehandshake and Re-key

   Rekeying in DTLS is accomplished by performing a new handshake over
   the existing DTLS channel.  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.  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.

   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.





McGrew & Rescorla       Expires December 12, 2006              [Page 12]


Internet-Draft           SRTP Extension for DTLS               June 2006


4.  Multi-party RTP Sessions

   Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only
   to protect RTP sessions in which there are exactly two participants.
   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.

4.1.  SIP Forking

   When SIP parallel forking occurs while establishing an RTP session, a
   situation may arise in which two or more sources are sending RTP
   packets to a single RTP destination transport address.  When this
   situation arises and DTLS-SRTP is in use, the receiver MUST use the
   source transport IP address and port of each packet to distinguish
   between the senders, and treat the flow of packets from each distinct
   source transport address as a distinct DTLS-SRTP session for the
   purposes of the DTLS association.

   When SIP forking occurs, two methods can be used to correlate each
   answer to the corresponding DTLS-SRTP session.  If the answers have
   different certificates then fingerprints in the answers can be used
   to correlate the SIP dialogs with the associated DTLS session.  Note
   that two forks with the same certificate cannot be distinguished at
   the DTLS level, but this problem is a generic problem with SIP
   forking and should be solved at a higher level.


5.  Security Considerations

   The use of multiple data protection framings negotiated in the same
   handshake creates some complexities, which are discussed here.

5.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 any attacker who
   can control the channel can always mount.

5.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.



McGrew & Rescorla       Expires December 12, 2006              [Page 13]


Internet-Draft           SRTP Extension for DTLS               June 2006


   This attack is prevented by using different keys for 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.

   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 [10]).

5.3.  Sequence Number Interactions

   As described in Section Section 3.6.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.

5.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 which 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.

5.3.2.  Renegotiation

   Because the rehandshake transition algorithm specified in Section
   Section 3.7 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       Expires December 12, 2006              [Page 14]


Internet-Draft           SRTP Extension for DTLS               June 2006


6.  IANA Considerations

   This document a new extension for DTLS, in accordance with [11]:
        enum { use_srtp (??) } ExtensionType;

   [[ NOTE:  This value needs to be assigned by IANA ]]

   This extension MUST only be used with DTLS, and not with TLS.

   Section Section 3.2.2 requires that all SRTPProtectionProfile values
   be defined by RFC 2434 Standards Action.  IANA SHOULD create a DTLS
   SRTPProtectionProfile registry initially populated with values from
   Section Section 3.2.2 of this document.  Future values MUST be
   allocated via Standards Action as described in [3]


7.  Acknowledgments

   Special thanks to Jason Fischl, Flemming Andreasen, Dan Wing, and
   Cullen Jennings for input, discussions, and guidance.


8.  References

8.1.  Normative References

   [1]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications",
        RFC 1889, January 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [4]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.

   [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
        Security", RFC 4347, April 2006.

   [6]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
        RFC 3711, March 2004.





McGrew & Rescorla       Expires December 12, 2006              [Page 15]


Internet-Draft           SRTP Extension for DTLS               June 2006


8.2.  Informational References

   [7]   Fischl, J., "Session Initiation Protocol (SIP) for Media Over
         Datagram Transport Layer  Security (DTLS)",
         draft-fischl-sipping-media-dtls-00 (work in progress),
         March 2006.

   [8]   Fischl, J. and H. Tschofenig, "Session Description Protocol
         (SDP) Indicators for Datagram Transport Layer  Security
         (DTLS)", draft-fischl-mmusic-sdp-dtls-00 (work in progress),
         March 2006.

   [9]   Andreasen, F., "Session Description Protocol Security
         Descriptions for Media Streams",
         draft-ietf-mmusic-sdescriptions-12 (work in progress),
         September 2005.

   [10]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
         draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.

   [11]  Blake-Wilson, S., "Transport Layer Security (TLS) Extensions",
         draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005.

   [12]  Rosenberg, J., "Simple Traversal of UDP Through Network Address
         Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03
         (work in progress), March 2006.

   [13]  McGrew, D., "The use of AES-192 and AES-256 in Secure RTP",
         draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006.


Appendix A.  Open Issue: Key/Stream Interaction

   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 which 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.  Similar techniques could be applied to other inline RTP
   security protocols.



McGrew & Rescorla       Expires December 12, 2006              [Page 16]


Internet-Draft           SRTP Extension for DTLS               June 2006


   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 which 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-2k larger because of the certificate and keying
   material exchange).

   The third concern is the additional round-trips associated with
   establishing the 2nd, 3rd, ... 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 #s are media channel #s)

   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

   So, there is an additional 1 RTT 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       Expires December 12, 2006              [Page 17]


Internet-Draft           SRTP Extension for DTLS               June 2006


   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

   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.

   We don't know if this is a problem yet or whether it is possible to
   use some of the capacity allocated to other channels (e.g., RTCP) to
   perform the rehandshake.  Another alternative that has been proposed
   is to use one security association connection on a single channel and
   reuse the keying material across multiple channels, but this gives up
   the simplicity and independence benefits mentioned above and so is
   architecturally undesirable unless absolutely necessary.

   Another alternative is to take advantage of the fact that an (S)RTP
   channel is intended to be paired with an (S)RTCP channel.  The DTLS
   handshake could be performed on just one of those channels and the
   same keys used for both the RTP and RTCP channels.  This alternative
   is defined in Appendix B for study and discussion.


Appendix B.  Open Issue: Using a single DTLS session per SRTP session

   In order to address the performance, bandwidth, and latency concerns
   described in Appendix A, it may be desirable to use a single DTLS
   session for each SRTP session.  This appendix outlines one approach
   for achieving that goal in the next subsection, and then describes
   its benefits in the following one.



McGrew & Rescorla       Expires December 12, 2006              [Page 18]


Internet-Draft           SRTP Extension for DTLS               June 2006


B.1.  Definition

   This section defines the "Single DTLS" model by descibing its
   differences from the DTLS-SRTP as defined in the body of this
   document.  A point-to-point SRTP session consists of a unidirectional
   SRTP flow and a bidirectional SRTCP flow.  In the Single-DTLS model,
   a DTLS-SRTP session contains a single SRTP session and a single DTLS
   connection.  Within each SRTP session, there may be multiple SRTP
   sources; all of these sources use a single SRTP master key.  See
   Figure 11.  As before, the DTLS connection uses the same transport
   addresses as the RTP flow; receivers demultiplex packets by
   inspection of their first byte.

   +------------------------------------------------+
   |              TLS Master Secret                 |
   |                       |                        |
   |                       v                        |
   |                    TLS PRF                     |
   |                       |                        |
   |  +--------------------+---------------------+  |
   |  |                    |                     |  |
   |  |                    v                     |  |
   |  |              SRTP Master Key             |  |
   |  |                    |                     |  |
   |  |       +------------+------------+        |  |
   |  |       |            |            |        |  |
   |  |       v            v            v        |  |
   |  |  +----------+ +----------+               |  |
   |  |  |   SRTP   | |   SRTP   |     ...       |  |
   |  |  | Source A | | Source B |               |  |
   |  |  +----------+ +----------+               |  |
   |  |                                          |  |
   |  |               SRTP Session               |  |
   |  +------------------------------------------+  |
   |                                                |
   |                DTLS-SRTP Session               |
   +------------------------------------------------+

   Figure 11: Key derivation in the Single-DTLS model.

   Until the SRTP keys have been established by the DTLS handshake, the
   participants MUST reject all SRTP and SRTCP packets that they receive
   in the DTLS-SRTP session.

   The SRTP keys are derived as defined in Section 3.3, and are used as
   shown in Figure 12.  This figure should be contrasted with Figure 6.





McGrew & Rescorla       Expires December 12, 2006              [Page 19]


Internet-Draft           SRTP Extension for DTLS               June 2006


      Client            Server
     (Sender)         (Receiver)
         <----- DTLS ------>    src/dst = a/b and b/a
         ------ SRTP ------>    src/dst = a/b, uses client write keys
         ------ SRTCP ----->    src/dst = c/d, uses client write keys
         <----- SRTCP ------    src/dst = d/c, uses server write keys

   Figure 12: A DTLS-SRTP session in the Single-DTLS model.

B.1.1.  SRTP Parameter Profiles for Single-DTLS

   The following list indicates the SRTP transform parameters for each
   protection profile in the Single-DTLS model.  The main difference is
   that, in this model, an SRTP Parameter Profile determines the policy
   for the protection of RTP and RTCP packets.

   SRTP_AES128_CM_HMAC_SHA1_80
         SRTP and SRTCP cipher:  AES_128_CM
         SRTP and SRTCP cipher_key_length:  128
         SRTP and SRTCP cipher_salt_length:  112
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP and SRTCP auth_tag_length:  80
   SRTP_AES128_CM_HMAC_SHA1_32
         SRTP and SRTCP cipher:  AES_128_CM
         SRTP and SRTCP cipher_key_length:  128
         SRTP and SRTCP cipher_salt_length:  112
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP auth_tag_length:  32
         SRTCP auth_tag_length:  80
   SRTP_AES256_CM_HMAC_SHA1_80
         SRTP and SRTCP cipher:  AES_128_CM
         SRTP and SRTCP cipher_key_length:  128
         SRTP and SRTCP cipher_salt_length:  112
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP and SRTCP auth_tag_length:  80







McGrew & Rescorla       Expires December 12, 2006              [Page 20]


Internet-Draft           SRTP Extension for DTLS               June 2006


   SRTP_AES256_CM_HMAC_SHA1_32
         SRTP and SRTCP cipher:  AES_128_CM
         SRTP and SRTCP cipher_key_length:  128
         SRTP and SRTCP cipher_salt_length:  112
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP auth_tag_length:  32
         SRTCP auth_tag_length:  80
   SRTP_NULL_HMAC_SHA1_80
         SRTP and SRTCP cipher:  NULL
         SRTP and SRTCP cipher_key_length:  0
         SRTP and SRTCP cipher_salt_length:  0
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP and SRTCP auth_tag_length:  80
   SRTP_NULL_HMAC_SHA1_32
         SRTP and SRTCP cipher:  NULL
         SRTP and SRTCP cipher_key_length:  0
         SRTP and SRTCP cipher_salt_length:  0
         SRTP maximum_lifetime:  2^48
         SRTCP maximum_lifetime:  2^31
         SRTP and SRTCP auth_function:  HMAC-SHA1
         SRTP and SRTCP auth_key_length:  160
         SRTP auth_tag_length:  32
         SRTCP auth_tag_length:  80

B.2.  Pros and Cons of Single-DTLS

   Using a single DTLS session per SRTP session has potential
   performance benefits in terms of reducing latency and compution.  The
   discussion of the performance of multiple parallel DTLS connections
   in Appendix A applies here as well.  In addition.  It provides a good
   match for existing SRTP implementations, since it matches their SRTP
   policy definitions for cryptographic algorithm configuration and
   makes use of all of the derived keys rather than having to discard
   half as described in Section 3.3.











McGrew & Rescorla       Expires December 12, 2006              [Page 21]


Internet-Draft           SRTP Extension for DTLS               June 2006


Authors' Addresses

   David McGrew
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, CA  95305
   USA

   Email:  mcgrew@cisco.com


   Eric Rescorla
   Network Resonance
   2483 E. Bayshore #212
   Palo Alto, CA  94303
   USA

   Email:  ekr@networkresonance.com

































McGrew & Rescorla       Expires December 12, 2006              [Page 22]


Internet-Draft           SRTP Extension for DTLS               June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




McGrew & Rescorla       Expires December 12, 2006              [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/