One document matched: draft-jones-perc-dtls-tunnel-00.txt
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,
<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>.
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,
<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>.
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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:52:17 |