Skip to main content

DTLS Tunnel between Media Distribution Device and Key Management Function to Facilitate Key Exchange
draft-jones-perc-dtls-tunnel-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Paul Jones
Last updated 2016-02-28
Replaced by draft-ietf-perc-dtls-tunnel, RFC 9185
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jones-perc-dtls-tunnel-01
Network Working Group                                           P. Jones
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                       February 28, 2016
Expires: August 31, 2016

    DTLS Tunnel between Media Distribution Device and Key Management
                  Function to Facilitate Key Exchange
                    draft-jones-perc-dtls-tunnel-01

Abstract

   This document defines a DTLS tunneling protocol for use in multimedia
   conferences that enables a Media Distribution Device (MDD) to
   facilitate key exchange between an endpoint in a conference and the
   Key Management Function (KMF) responsible for key distribution.  The
   protocol is designed to ensure that the key material used for hop-by-
   hop encryption and authentication is accessible to the MDD, while the
   key material used for end-to-end encryption and authentication is
   inaccessible to the MDD.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 31, 2016.

Copyright Notice

   Copyright (c) 2016 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

Jones                    Expires August 31, 2016                [Page 1]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used In This Document . . . . . . . . . . . . . .   3
   3.  Tunneling Concept . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Example Message Flows . . . . . . . . . . . . . . . . . . . .   4
   5.  Tunneling Procedures  . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Endpoint Procedures . . . . . . . . . . . . . . . . . . .   6
     5.2.  Media Distribution Device Tunneling Procedures  . . . . .   6
     5.3.  Key Management Function Tunneling Procedures  . . . . . .   7
   6.  Tunneling Protocol  . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Tunnel Message  . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Tunnel Message + Profiles . . . . . . . . . . . . . . . .   9
     6.3.  Tunnel Message + Key Info . . . . . . . . . . . . . . . .  10
   7.  To-Do List  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   An objective of the work in the Privacy-Enhanced RTP Conferencing
   (PERC) working group is to ensure that endpoints in a multimedia
   conference have access to the end-to-end (E2E) and hop-by-hop (HBH)
   key material used to encrypt and authenticate Real-time Transport
   Protocol (RTP) [RFC3550] packets, while the Media Distribution Device
   (MDD) has access only to the hop-by-hop (HBH) key material for
   encryption and authentication.

   This specification defines a tunneling protocol that enables the MDD
   to tunnel DTLS [RFC6347] messages between an endpoint and the KMF,
   thus allowing an endpoint to use DTLS-SRTP [RFC5764] for establishing
   encryption and authentication keys with the KMF.

   The tunnel established between the MDD and KMF is a DTLS association
   that is established before any messages are forwarded on behalf of
   the endpoint by the MDD.  DTLS packets received from the endpoint are
   encapsulated by the MDD inside this tunnel as data to be sent to the
   KMF.  Likewise, when the MDD receives data from the KMF over the
   tunnel, it extracts the DTLS message inside and forwards that to the
   endpoint.  In this way, the DTLS association for the DTLS-SRTP

Jones                    Expires August 31, 2016                [Page 2]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   procedures is established between the endpoint and the KMF, with the
   MDD simply forwarding packets between the two entities and having no
   visibility into the confidential information exchanged or derived.

   Following the existing DTLS-SRTP procedures, the endpoint and KMF
   will arrive at a selected cipher and key material, which are used for
   HBH encryption and authentication by both the endpoint and the MDD.
   However, since the MDD would not have direct access to this
   information, the KMF explicitly shares the HBH key information with
   the MDD via the tunneling protocol defined in this document.

   By establishing this DTLS tunnel between the MDD and KMF and
   implementing the protocol defined in this document, it is possible
   for the MDD to facilitate the establishment of a secure DTLS
   association between an endpoint and the KMF in order for the endpoint
   to receive E2E and HBH key material.  At the same time, the KMF can
   securely provide the HBH key material to the MDD.

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 RFC 2119 [RFC2119]
   when they appear in ALL CAPS.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

3.  Tunneling Concept

   A DTLS association (tunnel) is established between the MDD and the
   KMF.  This tunnel is used to relay DTLS messages between the endpoint
   and KMF, as depicted in Figure 1:

Jones                    Expires August 31, 2016                [Page 3]
Internet-Draft            DTLS Tunnel for PERC             February 2016

                                 +------------------------------+
         +-----+                 |        Switching MDD         |
         |     |                 |                              |
         | KMF |<===============>|<============+ (Tunnels DTLS) |
         |     |     DTLS        |             v                |
         +-----+     Tunnel      +------------------------------+
                                               ^
                                               |
                                               | DLTS-SRTP
                                               |
                                               v
                                          +----------+
                                          | Endpoint |
                                          +----------+

                       Figure 1: DTLS Tunnel to KMF

   The three entities involved in this communication flow are the
   endpoint, the MDD, and the KMF.  The behavior of each entity is
   described in Section 5.

   The KMF is a logical function that might might be co-resident with a
   key management server operated by an enterprise, reside in one of the
   endpoints participating in the conference, or elsewhere that is
   trusted with E2E key material.  This document does not preclude any
   location, it only requires that the KMF not allow the MDD to gain
   access to the E2E key material by following the operations defined.

4.  Example Message Flows

   This section provides an example message flow to help clarify the
   procedures described later in this document.  Note that it is assumed
   that a mutually authenticated DTLS association is already established
   between the MDD and KMF for the purpose of sending tunneled messages.

   Once the tunnel is established, it is possible for the MDD to relay
   the DTLS messages between the endpoint and the KMF.  Figure 2 shows a
   message flow wherein the endpoint uses DTLS-SRTP to establish an
   association with the KMF.  In the process, the MDD shares its
   supported SRTP protection profile information and the KMF shares HBH
   key material and selected cipher with the MDD.  The message used to
   tunnel the DTLS messages is named "Tunnel" and can include Profiles
   or Key Info data.

Jones                    Expires August 31, 2016                [Page 4]
Internet-Draft            DTLS Tunnel for PERC             February 2016

        Endpoint                     MDD                       KMF
            |                         |                         |
            |------------------------>|========================>|
            | DTLS handshake message  | Tunnel + Profiles       |
            |                         |                         |
            |<------------------------|<========================|
            | DTLS handshake message  |                  Tunnel |
            |                         |                         |
               .... may be multiple handshake messages ...
            |------------------------>|========================>|
            | DTLS handshake message  | Tunnel + Profiles       |
            |                         |                         |
            |<------------------------|<========================|
            |  DTLS handshake message |       Tunnel + Key Info |
            |    (including Finished) |                         |
            |                         |                         |

            Figure 2: Sample DTLS-SRTP Exchange via the Tunnel

   Each of these tunneled messages on the right-hand side of Figure 2 is
   a message of type "Tunnel" (see Section 6).  Each message contains
   the following information:

   o  Protocol version
   o  Association ID
   o  DTLS message being tunneled

   Additionally, all messages sent by the MDD will contain MDD-supported
   SRTP protection profiles at the end of the Tunnel message.  The KMF
   will need to select a common profile supported by both the endpoint
   and the MDD to ensure that hop-by-hop operations can successfully be
   performed.

   Further, the KMF will provide the SRTP [RFC3711] key material for HBH
   operations at the time it sends a DTLS Finished message to the
   endpoint via the tunnel.  The MDD would extract this Key Info when
   received and use it for hop-by-hop encryption and authentication.
   The delivery of the keying information along with the completion of
   the DTLS handshake ensures the delivery of the keying information is
   fate shared with completion of the DTLS handshake so that the MDD is
   guaranteed to have the HBH keying information before it receives any
   media that is encrypted or authenticated with that key.

5.  Tunneling Procedures

   The following sub-sections explain in detail the expected behavior of
   the endpoint, the media distribution device (MDD), and the key
   management function (KMF).

Jones                    Expires August 31, 2016                [Page 5]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   It is important to note that the tunneling protocol described in this
   document is not an extension to TLS [RFC5246] or DTLS [RFC6347].
   Rather, it is a protocol that transports endpoint or KMF-generated
   DTLS messages as data inside of the DTLS association established
   between the MDD and KMF.

5.1.  Endpoint Procedures

   The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764]
   in order to establish the keys used for encryption and
   authentication.  The endpoint uses the normal procedures to establish
   a DTLS-SRTP association with the KMF.

5.2.  Media Distribution Device Tunneling Procedures

   The MDD, acting as a client, establishes a mutually authenticated
   DTLS association between itself and a KMF to relay DTLS messages from
   any number of endpoints to that KMF.  This MDD initiated DTLS
   association is called a "tunnel" to differentiate it from the DTLS
   associations initiated by endpoints.

   The MDD MUST establish a tunnel with the KMF in advance of, or no
   later than the point, when an endpoint attempts to establish a DTLS
   association with the KMF.

   The MDD MUST forward all messages received from an endpoint for a
   given DTLS association through the same tunnel if more than one
   tunnel has been established between it and a KMF.  An MDD is not
   precluded from establishing more than one tunnel to a given KMF.

   The MDD MUST assign a tunnel-unique "association identifier" for each
   endpoint-initiated DTLS association and include it in all messages
   forwarded to the KMF.  The KMF will subsequently include in this
   identifier in all messages it sends so that the MDD can map messages
   received via a given tunnel and forward those messages to the correct
   endpoint.

   The tunnel protocol enables the KMF to separately provide HBH key
   material to the MDD for each of the individual endpoint DTLS
   associations, though the MDD cannot decrypt messages between the KMF
   and endpoints.

   When a DTLS message is received by the MDD from an endpoint, it
   forwards the UDP payload portion of that message to the KMF
   encapsulated in a Tunnel + Profiles message (see Section 6).  The
   Tunnel + Profiles message allows the MDD to signal which SRTP
   protection profiles it supports for HBH operations.

Jones                    Expires August 31, 2016                [Page 6]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   The MDD MUST support the same list of protection profiles for the
   life of a given endpoint's DTLS association, which is represented by
   the association identifier.

   When a message from the KMF includes "Key Info," the MDD MUST extract
   the cipher and key material conveyed in order to subsequently perform
   HBH encryption and authentication operations for RTP and RTCP packets
   sent between it and an endpoint.  Since the HBH key material will be
   different for each endpoint, the MDD uses the tunnel-unique
   association identifier included by the KMF to ensure that the HBH
   material is used with the correct endpoint.

   The MDD MUST forward all messages received from either the endpoint
   or the KMF to ensure proper communication between those two entities.

5.3.  Key Management Function Tunneling Procedures

   The KMF MUST be prepared to establish one or more tunnels (DTLS
   associations) with the MDD for the purpose of relaying DTLS messages
   between an endpoint and the KMF.  The KMF acts as a server and the
   MDD acts as a client to establish a tunnel.

   When the MDD relays a DTLS message from an endpoint, the MDD will
   include an association identifier that is unique per endpoint-
   originated DTLS association and is relayed via the tunnel.  The
   association identifier remains constant for the life of the DTLS
   association.  The KMF identifies each distinct endpoint-originated
   DTLS association by the association identifier and the tunnel over
   which the DTLS association was established.  The KMF MUST use the
   same association identifier in messages it sends to the endpoint and
   MUST send all messages for a given DTLS association via the same
   tunnel.  This is to ensure that the MDD can properly relay messages
   to the correct endpoint.

   The KMF extracts tunneled DTLS messages and acts on those messages as
   if the endpoint had established the DTLS association directly with
   the KMF.  The handling of the messages and certificates is exactly
   the same as normal DTLS-SRTP procedures between endpoints.

   When sending a message to the endpoint, the KMF encapsulates the DTLS
   message inside a Tunnel message (see Section 6).  At the point the
   DTLS handshake completes with the endpoint, the KMF will send a DTLS
   Finished message (perhaps along with other messages) to the endpoint.
   As it sends the Finished message, the KMF will also provide key
   information to the MDD.  This is accomplished by utilizing the Tunnel
   + Key Info message.  The Key Info includes the selected cipher, MKI
   [RFC3711] value (if any), SRTP master keys, and SRTP master salt
   values.

Jones                    Expires August 31, 2016                [Page 7]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   Since the KMF acts as the server in the DTLS-SRTP exchanges with the
   endpoint, it will negotiate with the endpoint which cipher to employ
   for encryption and authentication.  To ensure successful HBH
   operations, the ciphers negotiated by the KMF MUST be a cipher that
   is supported by the MDD.

6.  Tunneling Protocol

   The tunneling protocol is transmitted over the DTLS association
   established between the MDD and KMF as application data.  The basic
   message is referred to as the Tunnel message.  The MDD will append
   supported SRTP protection profiles to all Tunnel messages it sends,
   forming the Tunnel + Profiles message.  The KMF will append
   information necessary for the MDD to perform HBH encryption and
   authentication as it transmits the DTLS Finished message to the
   endpoint, forming the Tunnel + Key Info message.  The Tunnel, Tunnel
   + Profiles, and Tunnel + Key Info messages are detailed in the
   following sub-sections.

6.1.  Tunnel Message

   Tunneled DTLS messages are transported via the "Tunnel" message as
   application data between the MDD and the KMF.  The "Tunnel" Message
   has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+-------------------------------+
     | Version (H)   | Version (L)   |                               |
     +---------------+---------------+                               |
     |                                                               |
     |   Association Identifier                                      |
     |                                                               |
     |                               +-------------------------------+
     |                               |  DTLS Message Length          |
     +-------------------------------+-------------------------------:
     :                                                               :
     :                     Tunneled DTLS Message                     :
     :                                                               :
     +---------------------------------------------------------------+

   Version (H): This is the protocol major version number (set to 0x01).

   Version (L): This is the protocol minor version number (set to 0x00).

   Association Identifier: This is the 16-octet association identifier.

Jones                    Expires August 31, 2016                [Page 8]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   DTLS Message Length: Length in octets of following Tunneled DTLS
   Message.

   Tunneled DTLS Message: This is the DTLS message exchanged between the
   endpoint and KMF.

6.2.  Tunnel Message + Profiles

   Each Tunnel message transmitted by the MDD contains an array of SRTP
   protection profiles at the end of the message.  The format of the
   message is shown below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+-------------------------------+
     | Version (H)   | Version (L)   |                               |
     +---------------+---------------+                               |
     |                                                               |
     |                     Association Identifier                    |
     |                                                               |
     |                               +-------------------------------+
     |                               |  DTLS Message Length          |
     +-------------------------------+-------------------------------:
     :                                                               :
     :                     Tunneled DTLS Message                     :
     :                                                               :
     +---------------+---------------+-------------------------------+
     | Data Type     | Length        |                               :
     +---------------+---------------+                               :
     :                      Protection Profiles                      :
     +---------------------------------------------------------------+

   Beyond the fields included in the Tunnel message, this message
   introduces the following additional fields.

   Data Type: Indicates the type of data that follows.  For MDD
   supported SRTP protection profiles, this value is 0x01.

   Length: This is the length in octets of the protection profiles.
   This length must be greater than or equal to 2.

   Protection Profiles: This is an array of two-octet SRTP protection
   profile values as per [RFC5764], with each value represented in
   network byte order.

Jones                    Expires August 31, 2016                [Page 9]
Internet-Draft            DTLS Tunnel for PERC             February 2016

6.3.  Tunnel Message + Key Info

   When the KMF has key information to share with the MDD so it can
   perform HBH encryption and authentication on received media packets,
   the KMF will send a Tunnel message with the Key Info appended as
   shown below:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+-------------------------------+
     | Version (H)   | Version (L)   |                               |
     +---------------+---------------+                               |
     |                                                               |
     |   Association Identifier                                      |
     |                                                               |
     |                               +---------------+---------------+
     |                               |  DTLS Message Length          |
     +-------------------------------+-------------------------------:
     :                                                               :
     :                     Tunneled DTLS Message                     :
     :                                                               :
     +---------------+-------------------------------+---------------+
     | Data Type     | MKI Length    | Master Key Identifier (MKI)   ~
     +---------------+---------------+-------------------------------+
     | CWSMK Length                  |                               :
     +-------------------------------+                               :
     :                 Client Write SRTP Master Key                  :
     +-------------------------------+-------------------------------+
     | SWSMK Length                  |                               :
     +-------------------------------+                               :
     :                 Server Write SRTP Master Key                  :
     +-------------------------------+-------------------------------+
     | CWSMS Length                  |                               :
     +-------------------------------+                               :
     :                 Client Write SRTP Master Salt                 :
     +-------------------------------+-------------------------------+
     | SWSMS Length                  |                               :
     +-------------------------------+                               :
     :                 Server Write SRTP Master Salt                 :
     +---------------------------------------------------------------+

   Beyond the fields included in the Tunnel message, this message
   introduces the following additional fields.

   Data Type: Indicates the type of data that follows.  For key
   information, this value is 0x02.

Jones                    Expires August 31, 2016               [Page 10]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   MKI Length: This is the length in octets of the MKI field.  A value
   of zero indicates that the MKI field is absent.

   CWSMK Length: The length of the "Client Write SRTP Master Key" field.

   Client Write SRTP Master Key: The value of the SRTP master key used
   by the client (endpoint).

   SWSMK Length: The length of the "Server Write SRTP Master Key" field.

   Server Write SRTP Master Key: The value of the SRTP master key used
   by the server (MDD).

   CWSMS Length: The length of the "Client Write SRTP Master Salt"
   field.

   Client Write SRTP Master Salt: The value of the SRTP master salt used
   by the client (endpoint).

   SWSMS Length: The length of the "Server Write SRTP Master Salt"
   field.

   Server Write SRTP Master Salt: The value of the SRTP master salt used
   by the server (MDD).

7.  To-Do List

   The MDD and KMF may need to coordinate or exchange a "conference
   identifier" common to the endpoints a MDD is bridging together.
   Alternatively, information the KMF needs to know about conference-to-
   endpoint correlations might be satisfied by getting info directly
   from the endpoints, or some trusted entity on their behalf, via some
   other means.  Need to revisit this design choice in the context of
   all the alternatives.

8.  IANA Considerations

   There are no IANA considerations for this document.

9.  Security Considerations

   TODO - Much more needed.

   The encapsulated data is protected by the DTLS session from the
   endpoint to KMF and the MDD is merely an on path entity.  This does
   not introduce any additional security concerns beyond a normal DTLS-
   SRTP session.

Jones                    Expires August 31, 2016               [Page 11]
Internet-Draft            DTLS Tunnel for PERC             February 2016

   The HBH keying material is protected by the mutual authenticated DTLS
   session between the MDD and KMF.  The KMF MUST ensure that it only
   forms associations with authorized MDDs or it could hand HBH keying
   information to untrusted parties.

   The supported profile information send from the MDD to the KMF is not
   particularly sensitive as it only provides the crypt algorithms
   supported by the MDD but it is still protected by the DTLS session
   from the MDD to KMF.

10.  Acknowledgments

   The author would like to thank David Benham and Cullen Jennings for
   reviewing this document and providing constructive comments.

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
              RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, DOI
              10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

Jones                    Expires August 31, 2016               [Page 12]
Internet-Draft            DTLS Tunnel for PERC             February 2016

Author's Address

   Paul Jones
   Cisco Systems
   7025 Kit Creek Rd.
   Research Triangle Park, North Carolina  27709
   USA

   Phone: +1 919 476 2048
   Email: paulej@packetizer.com

Jones                    Expires August 31, 2016               [Page 13]