Network Working Group P. Jones Internet-Draft Cisco Intended status: Standards Track February 23, 2016 Expires: August 26, 2016 DTLS Tunnel between Media Distribution Device and Key Management Function to Facilitate Key Exchange draft-jones-perc-dtls-tunnel-00 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 key material used for end-to-end encryption and authentication is inaccessible to the MDD, while key material used for hop-by-hop encryption and authentication is accessible 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 26, 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 26, 2016 [Page 1] Internet-Draft PERC DTLS Tunnel 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 . . . . . . . . . . . . . . . . . . . . . . 4 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 8 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 9 5.2. Media Distribution Device Tunneling Procedures . . . . . 9 5.3. Key Management Function Tunneling Procedures . . . . . . 11 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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) key material used to encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] packets, while the Media Distribution Device (MDD) does not. At the same time, the MDD needs access to key material used for hop-by-hop (HBH) encryption and authentication. The procedures in this document depend on two important media security specifications, namely DTLS-SRTP [RFC5764] and [I-D.ietf-avtcore-srtp-ekt]. DTLS-SRTP [RFC5764] defines a set of procedures for establishing encryption and authentication keys between two entities (e.g., an endpoint and the MDD). [I-D.ietf-avtcore-srtp-ekt] defines a DTLS [RFC6347] extension that build on DTLS-SRTP to allow an entity to transmit a key encrypting key (the "EKT key") to its peer. The EKT key is used to securely convey an SRTP [RFC3711] master key to the peer via an SRTP packet. Together, these procedures would meet the needs of PERC, but care has to be taken to ensure that the MDD does not gain access to the E2E media encryption and authentication key material. Jones Expires August 26, 2016 [Page 2] Internet-Draft PERC DTLS Tunnel February 2016 To prevent the MDD from gaining access to the E2E key material, this specification defines a set of procedures for tunneling the DTLS signaling from the endpoint through the MDD to the Key Management Function (KMF). To accomplish this, a DTLS association is first established between the MDD and KMF ("tunnel"). DTLS packets received from the endpoint are encapsulated inside the tunnel as data to be sent to the KMF. Likewise, DTLS messages received inside the tunnel are extracted and forwarded to the endpoint. In effect, the DTLS association for the DTLS-SRTP procedures is established between the endpoint and the KMF, with the MDD simply forwarding packets between the two entities. 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 will share this information with the MDD via the tunneling protocol defined in this document. The EKT procedures are used to convey the an EKT key that is shared among all participants in a conference. It is the responsibility of the KMF to send the EKT key for the conference to the endpoint via the DTLS association established between the endpoint and the KMF. The endpoint can then securely transmit its SRTP master keys to other endpoints via SRTP following the procedures in [I-D.ietf-avtcore-srtp-ekt]. 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 key material and to derive the 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. Jones Expires August 26, 2016 [Page 3] Internet-Draft PERC DTLS Tunnel February 2016 3. Tunneling Concept A DTLS association (tunnel) 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: +------------------------------+ +-----+ | Switching MDD | | | | | | KMF |<===============>|<============+ (Tunnels DTLS) | | | DTLS | v | +-----+ Tunnel +------------------------------+ ^ | | DTLS (DLTS-SRTP and EKT) | 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 whose location is not dictated by this document. The KMF might be co-resident with an enterprise key management server, reside in one of the endpoints participating in the conference, or exist elsewhere. What is important is that the KMF is not co-resident with the MDD, as otherwise the MDD will be able to gain access to the E2E key material. 4. Example Message Flows This section provides some example message flows to help clarify the procedures described later in this document. Figure 2 shows the establishment of the DTLS tunnel between the MDD and the KMF. The MDD might establish a single tunnel for all communication between itself and the KMF, a single tunnel for each conference, or one tunnel per endpoint. Regardless of how many tunnels the MDD chooses to establish, they are each established in the same way. Jones Expires August 26, 2016 [Page 4] Internet-Draft PERC DTLS Tunnel February 2016 Endpoint MDD KMF | | | | |------------------------>| | | ClientHello | | | | | |<------------------------| | | HelloVerifyRequest | | | | | |------------------------>| | | ClientHello | | | | | |<------------------------| | | ServerHello | | | Certificate | | | ServerKeyExchange* | | | CertificateRequest | | | ServerHelloDone | | | | | |------------------------>| | | Certificate | | | ClientKeyExchange | | | CertificateVerify | | | [ChangeCipherSpec] | | | Finished | | | | | |<------------------------| | | [ChangeCipherSpec] | | | Finished | | | | | |<=======================>| | | DTLS Tunnel Established | | | | Figure 2: Establishing a DTLS Tunnel Note that the ServerKeyExchange(*) message is transmitted as required per [RFC5246]. The above flow is almost identical to Figure 1 of [RFC6347], with the only significant change being that, since both client and server certificates must be exchanged, those messages are present and non- optional. Once the tunnel is established, it is possible for the MDD to tunnel DTLS messages between the endpoint and the KMF. Figure 3 shows a message flow wherein the endpoint uses DTLS-SRTP to establish the HBH cipher and key material, the KMF provides the MDD with the HBH cipher and key material, and the KMF sends the E2E key material to the Jones Expires August 26, 2016 [Page 5] Internet-Draft PERC DTLS Tunnel February 2016 endpoint. The tunneled messages are shown with the name of the tunneling protocol message used within parentheses. Tunneled DTLS messages are always carried within the data structure "dtls_message", but the message type is shown in the figure to illustrate which message is sent at which point in the exchange. Jones Expires August 26, 2016 [Page 6] Internet-Draft PERC DTLS Tunnel February 2016 Endpoint MDD KMF | | | |------------------------>|========================>| | ClientHello + use_srtp | (SupportedProfiles) | | + EKT | ClientHello + use_srtp | | | + EKT | | | | |<------------------------|<========================| | HelloVerifyRequest | (Empty) | | | HelloVerifyRequest | | | | |------------------------>|========================>| | ClientHello + use_srtp | (Empty) | | + EKT | ClientHello + use_srtp | | | + EKT | | | | |<------------------------|<========================| | ServerHello + use+srtp | (Empty) | | + EKT | ServerHello + use+srtp | | Certificate | + EKT | | ServerKeyExchange* | Certificate | | CertificateRequest | ServerKeyExchange* | | ServerHelloDone | CertificateRequest | | | ServerHelloDone | | | | |------------------------>|========================>| | Certificate | (Empty) | | ClientKeyExchange | Certificate | | CertificateVerify | ClientKeyExchange | | [ChangeCipherSpec] | CertificateVerify | | Finished | [ChangeCipherSpec] | | | Finished | | | | |<------------------------|<========================| | [ChangeCipherSpec] | (SRTPKeyInformation) | | Finished | [ChangeCipherSpec] | | | Finished | | | | |<------------------------|<========================| | ekt_key | (Empty) | | | ekt_key | | | | |------------------------>|========================>| | ekt_key_ack | (Empty) | | | ekt_key_ack | | | | Figure 3: Sample DTLS-SRTP and EKT Exchange via a Tunnel Jones Expires August 26, 2016 [Page 7] Internet-Draft PERC DTLS Tunnel February 2016 Note that the ServerKeyExchange(*) message is transmitted as required per [RFC5246]. Each of these tunneled messages on the right-hand side of Figure 3 is a message of type "DTLSTunnelMessage" (see Section 6). Each message contains the following information: * Protocol version * Association ID * Conference ID * Message type (Empty, SupportedProfiles, or SRTPKeyInformation) * Type-specific content * DTLS message being tunneled Of particular interest are the "SupportedProfiles" and "SRTPKeyInformation" messages. The "SupportedProfiles" message allows the MDD to tell the KMF which protection profiles it uses. 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 be successfully performed. The "SRTPKeyInformation" message contains the KMF-selected cipher and derived key material for those hop-by-hop operations. The derivation of the hop-by-hop key material is performed independently by both the endpoint and the KMF per [RFC5764]. The MDD would extract this information when the message is received and use it for hop-by-hop encryption and authentication operations. The end-to-end key material is provided by the KMF to the endpoint via the "ekt_key" message as per [I-D.ietf-avtcore-srtp-ekt]. While the EKT message passes through the MDD, it is encrypted and, therefore, inaccessible to the MDD. The endpoint does not send an ekt_key message to the KMF, since only the KMF provides an EKT Key for use in the conference. 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). 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 carries endpoint- or MDD-generated DTLS messages as data inside of the DTLS tunnel established between the MDD and KMF. Jones Expires August 26, 2016 [Page 8] Internet-Draft PERC DTLS Tunnel February 2016 5.1. Endpoint Procedures The endpoint's role is actually quite simple: it follows the procedures outlined in [RFC5764] without any changes to the procedures defined in that specification in order to establish the keys used for HBH encryption and authentication. Additionally, it uses the procedures defined in [I-D.ietf-avtcore-srtp-ekt] to receive an EKT key to facilitate securing media end-to-end. The endpoint initiates signaling to establish the DTLS association and expects the KMF to act as the DTLS server. The endpoint MUST verify the KMF's server certificate. The endpoint MUST also provide its certificate to the MDD for verification as a part of the DTLS handshake. The endpoint exchanges EKT [I-D.ietf-avtcore-srtp-ekt] messages over the DTLS association between itself and the KMF in order to receive the EKT key. The EKT key is used by the endpoint to securely transmit the SRTP master key used for end-to-end media encryption and authentication. Since the DTLS association is established between the endpoint and the KMF, no entity along the path, including the MDD, will have access to the key material used for E2E encryption and authentication. 5.2. Media Distribution Device Tunneling Procedures The MDD, acting as a client, establishes a DTLS association between itself and the KMF, acting as a server, for the purpose of facilitating key exchange between an endpoint and the KMF. To differentiate this DTLS association from the one initiated by the endpoint, this association is called a "tunnel". A tunnel may be established when the first endpoint attempts to establish a DTLS association with the KMF, or the tunnel may be established in advance and independent of communication with an endpoint. A tunnel allows the MDD to relay DTLS messages for any number of endpoints. The MDD cannot see the plaintext contents of the encrypted exchanges between the KMF and an endpoint, but the protocol does enable the KMF to provide the HBH key material to the MDD for each of the individual DTLS associations. The MDD may establish a single DTLS tunnel to the KMF or it may establish more than one. However, the MDD MUST ensure that all DTLS messages received by the endpoint for the same DTLS association are transmitted over the same tunnel. Jones Expires August 26, 2016 [Page 9] Internet-Draft PERC DTLS Tunnel February 2016 When a DTLS message is received by the MDD from an endpoint, it blindly forwards that message to the KMF encapsulated in a "DTLSTunnelMessage" using the message type "Empty" (see Section 6) in all cases except the initial message for each association (as explained below). To uniquely identify a distinct endpoint- originated DTLS association, the MDD assigns a tunnel-unique "association identifier" for the association and includes a "conference identifier" known to both the MDD and the KMF. The association identifier is necessary since multiple DTLS messages from multiple endpoints might be relayed over the same tunnel. By uniquely assigning an association identifier, the MDD can determine which message received from the KMF needs to be forwarded to which endpoint. The conference identifier is necessary to allow the KMF to provide the endpoint with the correct E2E key material for the conference the endpoint is attempting to join. It is important to note that merely receiving the conference identifier is not an indication of authorization. Through some means defined outside the scope of this document, it is expected that the KMF will know for which conferences the endpoint is authorized to receive E2E key material. Editor's Note: If we enhance EKT so that the endpoint can convey a conference identifier or other information (e.g., a participant ID in the form of a UUID assigned to the endpoint for the conference) that allows the KMF to associate an endpoint and a particular conference, we could relieve the MDD of having to provide a conference ID as a part of the tunneling protocol. Modifying EKT to enable the endpoint to convey this information should be preferred. All messages for a given DTLS association MUST be sent via the same tunnel and MUST include the same association identifier. The MDD MUST forward all messages received from either the endpoint or the KMF to ensure proper communication between those two entities. When forwarding the first message received for a new endpoint- originated DTLS association (the "ClientHello + use_srtp + ekt"), the MDD relays the message inside a message of type "SupportedProfiles". This allows the MDD to advertise to the KMF which SRTP protection profiles it supports for HBH operations. When the MDD receives a message from the KMF of type "SRTPKeyInformation", it extracts the cipher and key material conveyed in that message in order to perform HBH encryption and authentication for RTP/RTCP packets sent to and from the endpoint. Since the HBH cipher and key material will be different for each Jones Expires August 26, 2016 [Page 10] Internet-Draft PERC DTLS Tunnel February 2016 endpoint, the MDD uses the association identifier to ensure the key material is associated with the correct endpoint. 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 does not initiate a tunnel. Rather, 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 via a tunnel, the MDD will include an association identifier that is unique per endpoint-originated DTLS association relayed via that tunnel. The association identifier remains constant for the life of the DTLS association. Since the same association identifier value might be used on different tunnels between the MDD and KMF, the KMF identifies each endpoint-originated distinct 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 KMF MUST use a certificate expected by the endpoint. How the endpoint learns of the KMF's certificate or certificate fingerprint is outside the scope of this document. The endpoint MUST provide a certificate to the KMF for validation. How the KMF is able to determine that a certificate belongs to a particular endpoint is outside the scope of this document. When sending a message to the endpoint, the KMF encapsulates the message in the DTLSTunnelMessage.dtls_message field of the tunnel protocol. Messages are normally tunneled using the message type "Empty", except when the KMF provides cipher and key material for HBH encryption and authentication (explained below). The KMF acts as the server in the DTLS-SRTP exchanges with the endpoint, so the KMF will dictate to the endpoint which cipher to employ for HBH operations. The selected cipher is conveyed in the ExtendedServerHello message (per [RFC5764]) to the endpoint, which is merely tunneled through the MDD and otherwise ignored by the MDD. Once the SRTP master key and salt values for HBH encryption and authentication are derived by the KMF, those values and the selected Jones Expires August 26, 2016 [Page 11] Internet-Draft PERC DTLS Tunnel February 2016 cipher are conveyed to the MDD when the KMF transmits the Finished message to the endpoint. The Finished message is encapsulated inside the tunnel in a message of type "SRTPKeyInformation". After sending the Finished message, the KMF will send an ekt_key message to the endpoint containing the EKT key used in the conference. 6. Tunneling Protocol The protocol syntax for the DTLS tunnel established between the MDD and KMF is shown below. The syntax is borrowed from [RFC5246]. enum { empty(0), supported_profiles(1), srtp_key_information(2), (255) } KMFMessageType; struct { uint8 major; uint8 minor; } ProtocolVersion; struct { ProtocolVersion version; /* Defined as {0x01, 0x00} */ opaque association_id[16]; /* MDD-defined */ opaque conference_id[16]; /* Conference identifier */ KMFMessageType type; /* Types defined above */ select(KMFMessageType) { case empty: Empty; /* Used for most tunneled messages */ case supported_profiles: SupportedProfiles; /* MDD->KMF only; supported profiles */ case srtp_key_information: SRTPKeyInformation; /* KMF->MDD only; HBH cipher and key info */ } body; opaque dtls_message<0..2^16-1>; /* Encapsulated DTLS message */ } DTLSTunnelMessage; struct { } Empty; /* Much of the following is borrowed from RFC 5764 */ uint8 SRTPProtectionProfile[2]; Jones Expires August 26, 2016 [Page 12] Internet-Draft PERC DTLS Tunnel February 2016 SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>; struct { SRTPProtectionProfiles SRTPProtectionProfiles; opaque srtp_mki<0..255>; } SupportedProfiles; struct { uint8 protection_profile[2]; opaque client_write_SRTP_master_key<1..2^16-1>; opaque server_write_SRTP_master_key<1..2^16-1>; opaque client_write_SRTP_master_salt<1..2^16-1>; opaque server_write_SRTP_master_salt<1..2^16-1>; } SRTPKeyInformation; 7. IANA Considerations There are no IANA considerations for this document. 8. Security Considerations [TBD] 9. Acknowledgments The author would like to thank David Benham for reviewing this document and providing constructive comments. 10. Normative References [I-D.ietf-avtcore-srtp-ekt] Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-03 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [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, . Jones Expires August 26, 2016 [Page 13] Internet-Draft PERC DTLS Tunnel February 2016 [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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Author's Address Paul Jones Cisco 7025 Kit Creek Rd. Research Trianle Park, North Carolina 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com Jones Expires August 26, 2016 [Page 14]