[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

AVT Working Group                                                D. Wing
Internet-Draft                                             Cisco Systems
Intended status:  Standards Track                      February 15, 2008
Expires:  August 18, 2008


           Datagram TLS Secure RTP (DTLS-SRTP) Key Transport
               draft-wing-avt-dtls-srtp-key-transport-01

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 August 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The existing DTLS-SRTP specification allows SRTP keys to be
   established between a pair of SRTP endpoints.  However, when there
   are more than two participants in an RTP session, DTLS-SRTP is unable
   to provide a single key for all of the participants.  This existing
   limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain
   scenarios.

   This document describes an extension to DTLS-SRTP which transports



Wing                     Expires August 18, 2008                [Page 1]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   SRTP keying material from one DTLS-SRTP peer to another, so the same
   SRTP keying material can be used by multiple DTLS-SRTP peers.  This
   extension reduces (and often eliminates) the need to key each SRTP
   session individually, allowing deployment of several DTLS-SRTP
   scenarios.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Point to Multipoint using the RFC 3550 mixer model . . . .  3
     3.2.  Point to Multipoint using Multicast  . . . . . . . . . . .  5
     3.3.  Point to Multipoint Using Video Switching MCUs . . . . . .  5
     3.4.  Voicemail Storage and Retrieval  . . . . . . . . . . . . .  7
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  key_transport extension  . . . . . . . . . . . . . . . . .  9
     4.2.  SRTP Key Transport Protocol  . . . . . . . . . . . . . . . 10
     4.3.  Key Transport SSRC and RTP SSRC Collisions . . . . . . . . 13
     4.4.  Fragmentation, Reassembly, and Retransmission  . . . . . . 13
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     6.1.  Group Policy when Joining/Leaving  . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informational References . . . . . . . . . . . . . . . . . 17
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 17
     A.1.  Changes from -00 to -01  . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19


















Wing                     Expires August 18, 2008                [Page 2]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


1.  Introduction

   Unique SRTP master keys can be established, in each direction, using
   DTLS-SRTP [I-D.ietf-avt-dtls-srtp].  Using DTLS, each peer
   contributes part of the keying material to generate the eventual SRTP
   master key.

   In some scenarios after the DTLS handshake has completed, it is
   desirable for one peer to change its SRTP key and to transmit SRTP
   packets using an SRTP key that was not derived from the DTLS key
   exchange.  These scenarios are described in Section 3.

   The extensions described in this document allow transporting an SRTP
   master key from one DTLS peer to the other.  Thus, DTLS Key Transport
   differs from normal DTLS-SRTP in that the SRTP master key is not
   derived from the TLS handshake.


2.  Notational Conventions

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


3.  Scenarios

   DTLS Key Transport allows mixers and video switchers to avoid having
   to encrypt each packet multiple times under multiple SRTP keys.  DTLS
   Key Transport causes sharing of SRTP keys.

   Several SRTP scenarios that benefit from DTLS-SRTP Key Transport are
   described in the following sections, using terminology from RTP
   Topologies [RFC5117].

3.1.  Point to Multipoint using the RFC 3550 mixer model

   This RTP scenario is described in Section 3.4 of RTP Topologies
   [RFC5117].

   With DTLS-SRTP, this topology is computationally expensive for the
   video switcher because it has to encrypt the payload uniquely for
   each SRTP listener.  Additionally, the architecture of a typical
   mixer requires each listener's SRTP to be encrypted serially,
   incurring additional delay for each successive listener.  This is
   depicted below in Figure 1.





Wing                     Expires August 18, 2008                [Page 3]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


                +-------key=F-------+
                |                   |
                V               +-------+         +------------+
           +----+----+          |       +--key=C->+ listener 1 |
           | speaker +--key=A-->+       |         +------------+
           +---------+          |       |         +------------+
                                | mixer +--key=D->+ listener 2 |
           +---------+          |       |         +------------+
           | speaker +--key=B-->+       |         +------------+
           +----+----+          |       +--key=E->+ listener 3 |
                ^               +---+---+         +------------+
                |                   |
                +-------key=G-------+

      Figure 1: Point to Multipoint Mixer, without DTLS Key Transport

   With DTLS Key Transport, the mixer can maintain one outbound SRTP
   cryptographic context, and encrypt the SRTP once for all listeners.
   This is depicted below in Figure 2.

   In the following figure, "=" indicates sessions where DTLS-SRTP Key
   Transport is used, and "-" indicates where only DTLS-SRTP is
   necessary.  In this topology, only the listeners need support DTLS-
   SRTP Key Transport so that the switcher and the listeners can benefit
   from DTLS-SRTP Key Transport.  In this scenario with DTLS-SRTP Key
   Transport, the mixer assumes an additional role -- group's key server
   -- and provides a common group SRTP key ("C") to all of the
   listeners.  This group SRTP key is shared between all of the
   listeners.

                +=======key=C=======+
                |                   |
                V               +---+---+         +------------+
           +---------+          |       +==key=C=>+ listener 1 |
           | speaker +--key=A-->+       |         +------------+
           +---------+          |       |         +------------+
                                | mixer +==key=C=>+ listener 2 |
           +---------+          |       |         +------------+
           | speaker +--key=B-->+       |         +------------+
           +----+----+          |       +==key=C=>+ listener 3 |
                ^               +---+---+         +------------+
                |                   |
                +=======key=C=======+

       Figure 2: Point to Multipoint Mixer, with DTLS Key Transport

   The mixer is aware of listeners leaving or joining, and the mixer can
   rekey the remaining active listeners.



Wing                     Expires August 18, 2008                [Page 4]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


3.2.  Point to Multipoint using Multicast

   This RTP topology is described in Section 3.2 of RTP Topologies
   [RFC5117].

   With DTLS-SRTP, this scenario is not attainable because each listener
   has a unique SRTP key.  For this reason, [I-D.ietf-msec-gdoi-srtp]
   was developed by the MSEC working group.

   With DTLS-SRTP Key Transport, this scenario is attainable because the
   same key can be provided to multiple listeners, as depicted below in
   Figure 3.  This compares favorably with [I-D.ietf-msec-gdoi-srtp]
   when the group size is small enough that the speaker can perform key
   server functions (i.e., perform DTLS-SRTP Key Transport) for all of
   the listeners.

                                +-------+            +------------+
                               /         \==key=A===>+ listener 1 |
                              /           \          +------------+
        +---------+           | multicast |          +------------+
        | speaker +==key=A===>+  network  +==key=A==>+ listener 2 |
        +---------+           |           |          +------------+
                              \           /          +------------+
                               \         /===key=A==>+ listener 3 |
                                +-------+            +------------+

     Figure 3: Point to Multipoint using Multicast with Key Transport

      [[For future study:  could we express, in SDP, alternate DTLS-SRTP
      key servers to support large groups for this scenario, so that the
      speaker can be offloaded from DTLS-SRTP Key Transport duties?
      That alternate key server would need authorize new participants.
      This seems to begin stepping into GDOI territory, but how does a
      DTLS-SRTP endpoint know when it will join a large group and need
      GDOI code inside the DTLS-SRTP endpoint?  Ideally we would want to
      split the effort and protocols so that endpoint needs *no*
      additional code with really large groups.]]

3.3.  Point to Multipoint Using Video Switching MCUs

   This RTP topology is described in Section 3.5 of RTP Topologies
   [RFC5117].

   With DTLS-SRTP, this topology is computationally expensive for the
   video switcher because it has to encrypt the payload uniquely for
   each SRTP listener.  Additionally, the architecture of a typical
   video switcher requires each listener's SRTP to be encrypted
   serially, incurring additional delay for each successive listener.



Wing                     Expires August 18, 2008                [Page 5]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   This is depicted below in Figure 4.

   In the following figure, DTLS-SRTP Key Transport is used on all
   sessions and depicted by "=".  In this scenario, both the speakers
   and listeners must support DTLS-SRTP Key Transport so that the
   switcher and the listeners can benefit from DTLS-SRTP Key Transport.

               +-------key=F-------+
               |                   |
               V               +---+------+         +------------+
          +---------+          |          +==key=C=>+ listener 1 |
          | speaker +==key=A==>+selected  |         +------------+
          +---------+          |          |         +------------+
                               | switcher +==key=D=>+ listener 2 |
          +---------+          |          |         +------------+
          | speaker +==key=B==>+dropped   |         +------------+
          +----+----+          |          +==key=E=>+ listener 3 |
               ^               +---+------+         +------------+
               |                   |
               +-------key=G-------+

      Figure 4: Point to Multipoint Video Switching, without DTLS Key
                                 Transport

   With DTLS key transport, this becomes easier; in fact, the video
   switcher doesn't need to decrypt the SRTP at all, but just make its
   decision (select the stream or drop the stream) and transmit the SRTP
   packets to the listeners.  This is depicted below in Figure 5.























Wing                     Expires August 18, 2008                [Page 6]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


               +-------key=B-------+
               |                   |
               V               +---+------+         +------------+
          +----+----+          |          +==key=A=>+ listener 1 |
          | speaker +==key=A==>+selected  |         +------------+
          +---------+          |          |         +------------+
                               | switcher +==key=A=>+ listener 2 |
          +---------+          |          |         +------------+
          | speaker +==key=B==>+prev.spkr |         +------------+
          +---------+          |          +==key=A=>+ listener 3 |
               ^               +----------+         +------------+
               |                   |
               +-------key=A-------+

       Figure 5: Point to Multipoint Video Switching, with DTLS Key
                                 Transport

   The video switcher is aware of listeners leaving or joining.  The
   protocol described in this document allows the switcher to dictate,
   to the speaker, that the speaker use a new encryption key.  This
   allows the switcher to enforce security, based on the switcher's
   policy (Section 6.1).  This is done by the video switcher sending a
   DTLS "your_new_srtp_key" message.  The speaker will respond with a
   DTLS "new_srtp_key" message which echos the same key.  The
   "new_srtp_key" message is relayed, by the switcher, to each of the
   active listeners.

   When there are multiple speakers, as shown in Figure 5 above, each
   speaker transmits with his own SRTP key.  That SRTP key is derived
   from the DTLS handshake with the switcher.  Each speaker uses DTLS-
   SRTP Key Transport to signal the SSRC that it will use.

3.4.  Voicemail Storage and Retrieval

   With DTLS-SRTP, voicemail storage servers have to decrypt the SRTP
   when the message is recorded.  In some voicemail server
   architectures, the recorded message is re-encrypted, using a new key
   to protect the content while it is on disk.  Then, later, the
   voicemail is retrieved, which involves encrypting the message using
   SRTP again.  This is depicted below in Figure 6.  This SRTP
   decryption and encryption can create a significant computational load
   on a voicemail storage server.









Wing                     Expires August 18, 2008                [Page 7]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


                              +-----------+
         +---------+          |           |
         | speaker +--key=A-->| voicemail |
         +---------+          |  storage  |
                              |  server   |          +-----------+
                              |           +--key=B-->+ voicemail |
                              | (store    |          | retrieval |
                              | decrypted |          +-----------+
                              |  content) |
                              +-----------+

      Figure 6: Voicemail Storage and Retrieval without Key Transport

   DTLS-SRTP Key Transport removes the need for the voicemail storage
   server to decrypt the incoming SRTP and to re-encrypt upon message
   retrieval.  With DTLS-SRTP Key Transport, the voicemail storage
   server can store the speaker's DTLS-SRTP key along with the encrypted
   message (including RTP headers), and then use DTLS-SRTP Key Transport
   to communicate that key during voicemail retrieval.  This is depicted
   below in Figure 7.

   In the following figure, DTLS-SRTP Key Transport is used on all
   sessions and depicted by "=".  In this scenario, only the device
   performing the voicemail retrieval needs to implement DTLS-SRTP Key
   Transport to help offload SRTP processing from the voicemail storage
   server.

                              +-----------+
         +---------+          |           |
         | speaker +--key=A-->| voicemail |
         +---------+          |  storage  |
                              |  server   |          +-----------+
                              |           +==key=A==>+ voicemail |
                              | (store    |          | retrieval |
                              | encrypted |          +-----------+
                              | content & |
                              | SRTP key  |
                              +-----------+

       Figure 7: Voicemail Storage and Retrieval with Key Transport


4.  Protocol Description

   This section describes the extension to the DTLS protocol for DTLS-
   SRTP key transport, which allows securely communicating the SRTP key
   to the DTLS peer.




Wing                     Expires August 18, 2008                [Page 8]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


4.1.  key_transport extension

   This document adds a new negotiated extension called "key_transport",
   which MUST only be requested in conjunction with the "use_srtp"
   extension (Section 3.2 of [I-D.ietf-avt-dtls-srtp]).  The DTLS server
   indicates its support for key_transport by including key_transport in
   its ServerHello message.  If a DTLS client includes key_transport in
   its ClientHello, but does not receive key_transport in the
   ServerHello, the DTLS client MUST NOT send DTLS packets with the
   srtp_key_transport content-type.

   Support for the DTLS Key Transport extension is indicated in SDP with
   the "srtp-kt" attribute.  Advertising support for the extension is
   necessary in SDP because in some cases it is required to establish an
   SRTP call.  For example, a mixer may be able to only support SRTP
   listeners if those listeners implement DTLS Key Transport (because it
   lacks the CPU cycles necessary to encrypt SRTP uniquely for each
   listener).

   A message flow showing a DTLS client and DTLS server using the
   key_transport extension

        Client                                               Server

        ClientHello + use_srtp + key_transport
                                     -------->
                             ServerHello + use_srtp + key_transport
                                                       Certificate*
                                                 ServerKeyExchange*
                                                CertificateRequest*
                                     <--------      ServerHelloDone
        Certificate*
        ClientKeyExchange
        CertificateVerify*
        [ChangeCipherSpec]
        Finished                     -------->
                                                 [ChangeCipherSpec]
                                     <--------             Finished
        SRTP packets                 <------->      SRTP packets

                     Figure 8: Handshake Message Flow

   After successful negotiation of the key_transport extension, the DTLS
   client and server MAY exchange SRTP packets, encrypted using the KDF
   described in [I-D.ietf-avt-dtls-srtp].  This is normal and expected,
   even if Key Transport was negotiated by both sides, as neither side
   may (yet) have a need to alter the SRTP key.  However, it is also
   possible that one (or both) peers will immediately send a



Wing                     Expires August 18, 2008                [Page 9]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   new_srtp_key message before sending any SRTP.

4.2.  SRTP Key Transport Protocol

   A new protocol is defined, called the srtp_key_transport protocol
   which uses srtp_key_transport content-type which consists of the
   following message types:

   new_srtp_key_request:  request that the DTLS peer choose a new key.
      Valid responses are new_srtp_key and new_srtp_key_error.

   your_new_srtp_key:  Dictates a new SRTP key for the peer to use when
      the peer transmits its SRTP packets.

   new_srtp_key:  contains the new SRTP keying material.  This message
      is sent by a DTLS endpoint that wants to change its SRTP key.
      This does not change any cryptographic parameters (a new DTLS
      handshake is necessary for that), but only the DTLS key for the
      associated SRTP session.  This message includes the SSRC that will
      be used for this key, which allows listeners to establish one SRTP
      crypto-context per speaker (necessary for the video switching
      scenario).  The key chosen MUST be cryptographically random
      [RFC4086].

   new_key_activate:  indicates receiver is prepared to receive SRTP
      packets encrypted with the new key.

   delete_srtp_key:  indicates the security association related to this
      key can be deleted.

   new_srtp_key_failure:  indicates a failure.

   At any time, the DTLS client or DTLS server MAY send a key_transport
   message, as shown in Figure 9.  The sender of the new_srtp_key
   message MAY immediately start transmitting SRTP packets with this new
   key.  However, to account for loss of the new_srtp_key message it is
   RECOMMENDED that the sender wait before changing to the new SRTP key
   until it receives the new_key_activate message or it times out
   waiting for the new_key_activate_message.  The duration of this
   timeout may vary depending on the sensitivity of the content (e.g., 1
   second or 10 seconds).  In any case, the new_srtp_key message is
   retransmitted until acknowledged by receipt of a new_key_activate
   message.








Wing                     Expires August 18, 2008               [Page 10]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


        Client / Server                             Server / Client

        [new_srtp_key_request]        -------->
                                     <--------         new_srtp_key
        new_srtp_key_activiate        -------->

                      Figure 9: New Key Message Flow

   The following figure shows the state machine for the protocol.

                   receive new_srtp_key_request from peer
                      or decide to choose new SRTP key
                                  |
                                  |
             send                 V
             new_srtp_key  +---------------+    timeout
                 +---------| Communicate   |--------+
                 |         |     Key       |        |
                 +-------->|               |        |
                           +---------------+        |
                             |           ^          |
                  receive    |           |   +----------------+
             new_key_activate|           +---| send SRTP using|
                             |               |  new SRTP key  |
                     +----------------+      +----------------+
                     | send SRTP using|
                     |  new SRTP key  |
                     +----------------+
                             |
                             V
                            done

              Figure 10: Key Transport protocol state machine

   Using the syntax described in TLS [RFC4346], the following structures
   are used:

       enum {
          new_srtp_key_request(0),
          your_new_srtp_key(1),
          new_srtp_key(2),
          new_srtp_key_activate(3),
          delete_srtp_key(4),
          new_srtp_key_failure(128),
          (255)
       } SRTPKeyTransportType;

       struct {



Wing                     Expires August 18, 2008               [Page 11]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


          SRTPKeyTransportType keytrans_type;
          uint24 length;
          uint16 message_seq;
          uint24 fragment_offset;
          uint24 fragment_length;
          select (SRTPKeyTransportType) {
             case new_srtp_key_request:         NewSRTPKeyRequest;
             case your_new_srtp_key:            YourNewSRTPKey;
             case new_srtp_key:                 NewSRTPKey;
             case new_srtp_key_activate:        NewSRTPKeyActivate;
             case delete_srtp_key:              DeleteSRTPKey;
             case new_srtp_key_failure:         NewSRTPKeyFailure;
           };
       } KeyTransport;

       struct {
           uint  random<64>;           // additional entropy for peer
       } NewSRTPKeyRequest;

       struct {
           uint32 ssrc;                // SSRC used for this key
           uint   key<16..32>;         // The last change_cipher_spec
           uint   auth_tag<4..10>      // decides the length of key
                                       // and auth_tag
           uint  random<64>;           // additional entropy for peer
       } NewSRTPKey;

       struct {
           uint   key<16..32>;         // The last change_cipher_spec
           uint   auth_tag<4..10>      // decides the length of key
                                       // and auth_tag
       } YourNewSRTPKey;

       struct {
           uint  random<64>;           // additional entropy for peer
       } NewSRTPKeyActivate;

       struct {
           uint32 ssrc;                // SSRC used for this key
       } DeleteSRTPKey;

       struct { } NewSRTPKeyFailure;

                        Figure 11: Data Structures







Wing                     Expires August 18, 2008               [Page 12]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


4.3.  Key Transport SSRC and RTP SSRC Collisions

   Per [RFC3550], if an RTP source notices an RTP SSRC collision, it is
   required to change its SSRC.  If it has negotiated support for DTLS-
   SRTP Key Transport, it then MUST also send a new_srtp_key message
   indicating the new SSRC.  As part of this procedure, it does not need
   to also change its SRTP key.

   The communication of the SSRC used for each key is necessary if there
   are multiple speakers in the video switching scenario.  However,
   because a speaker is not able to determine if their audio or their
   video is being switched, a speaker MUST always adhere indicate a
   change in SSRC by following the procedure in this section for any
   SRTP stream (audio, video, or other).

4.4.  Fragmentation, Reassembly, and Retransmission

   Much like the DTLS handshake itself, this extension also needs to
   handle fragmentation and reassembly (to send a large key) and
   retransmission (to account for packet loss).  Using the same
   technique as DTLS's handshake, the message_seq, fragment_offset,
   fragment_length are used.

   When transmitting the key transport message, the sender divides the
   message into a series of N contiguous data ranges.  These ranges MUST
   NOT be larger than the maximum handshake fragment size and MUST
   jointly contain the entire key transport message.  The ranges SHOULD
   NOT overlap.  The sender then creates N key transport messages, all
   with the same message_seq value as the original key transport
   message.  Each new message is labelled with the fragment_offset (the
   number of bytes contained in previous fragments) and the
   fragment_length (the length of this fragment).  The length field in
   all messages is the same as the length field of the original message.
   An unfragmented message is a degenerate case with fragment_offset=0
   and fragment_length=length.

   When a DTLS implementation receives a key transport message fragment,
   it MUST buffer it until it has the entire key transport message.
   DTLS implementations MUST be able to handle overlapping fragment
   ranges.  This allows senders to retransmit key transport messages
   with smaller fragment sizes during path MTU discovery.










Wing                     Expires August 18, 2008               [Page 13]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


5.  Examples

   The following example shows how Key Transport would be requested in
   an offer, using "a=dtls-srtp-kt".

         v=0
         o=- 25678 753849 IN IP4 192.0.2.1
         s=
         c=IN IP4 192.0.2.1
         t=0 0
         m=audio 53456 UDP/TLS/RTP/SAVP 0
         a=fingerprint:SHA-1 \
           4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
         a=dtls-srtp-kt

       Figure 12: Simple SDP offer showing Key Transport is required

   Using the SDP syntax described in
   [I-D.ietf-mmusic-sdp-capability-negotiation], the following figure
   shows an offerer that requires DTLS Key Transport in order to set up
   this call as an SRTP call, otherwise it can set up this call as an
   RTP call.  This is indicated by the ",2" on the "a=pcfg" line.  If
   the answerer does not understand "a=dtls-srtp-kt" but does understand
   DTLS-SRTP and [I-D.ietf-mmusic-sdp-capability-negotiation], this can
   cannot be established using DTLS-SRTP; however, it can be established
   using RTP.

         v=0
         o=- 25678 753849 IN IP4 192.0.2.1
         s=
         c=IN IP4 192.0.2.1
         t=0 0
         m=audio 53456 RTP/AVP 0
         a=tcap:1 UDP/TLS/RTP/SAVP
         a=acap:1 fingerprint:SHA-1 \
           4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
         a=acap:2 dtls-srtp-kt
         a=pcfg:1 t=1 a=1,2

      Figure 13: Example SDP offer showing Key Transport is required











Wing                     Expires August 18, 2008               [Page 14]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   Using the SDP syntax described in
   [I-D.ietf-mmusic-sdp-capability-negotiation], the following figure
   shows an offerer that indicates support for DTLS Key Transport but
   does not require DTLS Key Transport in order to set up this call as
   an SRTP call.  This is indicated by the ",[2]" on the "a=pcfg" line.
   If the answerer does not understand "a=dtls-srtp-kt" but does
   understand DTLS-SRTP and
   [I-D.ietf-mmusic-sdp-capability-negotiation], this call can still be
   established using DTLS-SRTP.

         v=0
         o=- 25678 753849 IN IP4 192.0.2.1
         s=
         c=IN IP4 192.0.2.1
         t=0 0
         m=audio 53456 RTP/AVP 0
         a=tcap:1 UDP/TLS/RTP/SAVP
         a=acap:1 fingerprint:SHA-1 \
             4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
         a=acap:2 dtls-srtp-kt
         a=pcfg:1 t=1 a=1,[2]

      Figure 14: Example SDP offer showing Key Transport is optional


6.  Security Considerations

   In the point-to-multipoint scenario, Section 3.1, all of the
   listeners know the key being used by the mixer.  Any of those
   listeners could create SRTP packets that are encrypted with this same
   key, and send those SRTP packets to other listeners.  In order to
   reduce the vulnerability to this threat, it is RECOMMENDED that the
   source transport address of received SRTP packets be discarded if
   they do not match the source transport address of the associated
   DTLS-SRTP session.  Additionally, the network SHOULD prevent IP
   address spoofing [RFC2827].

6.1.  Group Policy when Joining/Leaving

   When sharing SRTP keys with several listeners, it is imperative that
   the SRTP is changed when a new listener is added or a listener is
   removed.  This is because a legitimate listener should only be able
   to decrypt the SRTP stream while he is listening; he should not be
   able to decrypt the SRTP stream prior to joining the conference or
   after leaving the conference.  Failing to change the key when a
   listener joins (or leaves) allows a listener to decrypt SRTP traffic
   prior to (or after) they are authorized participants in the
   conference.



Wing                     Expires August 18, 2008               [Page 15]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   Policies for a specific user's access to a conference may be
   different from conference to conference.  For example, a company-
   internal event announcing promotions might be accessible to all
   employees and have no need for re-keying when listeners join or leave
   the conference.  As another example, a conference where a job
   candidate is interviewed should be rekeyed when the job candidate
   joins the conference and again when the job candidate leaves the
   conference.

   The protocol described in this document allows whichever policy is
   needed for a particular situation.  The protocol itself does not
   enforce a certain policy; that is, the protocol itself does not
   ensure the SRTP key is changed when a listener leaves (or joins) the
   conference.


7.  Acknowledgements

   Thanks to David McGrew for his improvements to this document and to
   the underlying protocol.  Thanks to Brian Weis, Sheela Rowles, and
   Mark Baugher for suggesting how GDOI-SRTP's key management could be
   used by DTLS-SRTP; these suggestions have been incorporated into
   DTLS-SRTP Key Transport.


8.  IANA Considerations

   [[This section will be completed in a future version of this
   document.]]

   To do:

   o  Register new SDP attribute "dtls-srtp-kt"

   o  new TLS content-type "key_transport" (26?)


9.  References

9.1.  Normative References

   [I-D.ietf-avt-dtls-srtp]
              McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for  Secure
              Real-time Transport Protocol (SRTP)",
              draft-ietf-avt-dtls-srtp-01 (work in progress),
              November 2007.




Wing                     Expires August 18, 2008               [Page 16]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


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

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [I-D.ietf-mmusic-sdp-capability-negotiation]
              Andreasen, F., "SDP Capability Negotiation",
              draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
              progress), December 2007.

9.2.  Informational References

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

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

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [I-D.ietf-msec-gdoi-srtp]
              Baugher, M., Rueegsegger, A., and S. Rowles, "GDOI Key
              Establishment for the SRTP Data Security Protocol",
              draft-ietf-msec-gdoi-srtp-01 (work in progress),
              December 2007.


Appendix A.  Changes

   [[Note to RFC Editor:  Please remove this section prior to
   publication]]

A.1.  Changes from -00 to -01

   o  more closely aligned with RTP Topologies [RFC5117]

   o  added multicast scenario

   o  added voicemail storage/retrieval scenario





Wing                     Expires August 18, 2008               [Page 17]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


   o  added delete_srtp_key

   o  added your_new_srtp_key

   o  aligned SDP for DTLS-SRTP with draft-ietf-mmusic-sdp-dtls-00

   o  key change rules are now discussed in Security Considerations


Author's Address

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com

































Wing                     Expires August 18, 2008               [Page 18]


Internet-Draft           DTLS-SRTP Key Transport           February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgments

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).  This document was produced
   using xml2rfc v1.33pre6 (of http://xml.resource.org/) from a source
   in RFC-2629 XML format.



Wing                     Expires August 18, 2008               [Page 19]


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