One document matched: draft-jones-perc-dtls-tunnel-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-jones-perc-dtls-tunnel-04">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="DTLS Tunnel for PERC">DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange</title>
<author initials="P." surname="Jones" fullname="Paul E. Jones">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<code>27709</code>
<country>USA</country>
<region>North Carolina</region>
</postal>
<phone>+1 919 476 2048</phone>
<email>paulej@packetizer.com</email>
<uri></uri>
</address>
</author>
<author initials="P." surname="Ellenbogen" fullname="Paul M. Ellenbogen">
<organization>Princeton University</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone>+1 206 851 2069</phone>
<email>pe5@cs.princeton.edu</email>
<uri></uri>
</address>
</author>
<author initials="N." surname="Ohlmeier" fullname="Nils H. Ohlmeier">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone>+1 408 659 6457</phone>
<email>nils@ohlmeier.org</email>
<uri></uri>
</address>
</author>
<date year="2016" month="October" day="31"/>
<area>Internet</area>
<workgroup></workgroup>
<keyword>PERC</keyword>
<keyword>SRTP</keyword>
<keyword>RTP</keyword>
<keyword>DTLS</keyword>
<keyword>DTLS-SRTP</keyword>
<keyword>DTLS tunnel</keyword>
<keyword>conferencing</keyword>
<keyword>security</keyword>
<abstract>
<t>This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate
key exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption and
authentication is inaccessible to the media distributor.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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) keying material
used to encrypt and authenticate Real-time Transport Protocol (RTP)
<xref target="RFC3550"/> packets, while the Media Distributor has access only to the
hop-by-hop (HBH) keying material for encryption and authentication.
</t>
<t>This specification defines a tunneling protocol that enables the media
distributor to tunnel DTLS <xref target="RFC6347"/> messages between an endpoint and
the key distributor, thus allowing an endpoint to use DTLS-SRTP
<xref target="RFC5764"/> for establishing encryption and authentication keys with the
key distributor.
</t>
<t>The tunnel established between the media distributor and key distributor
is a TLS connection that is established before any messages are
forwarded by the media distributor on behalf of the endpoint. DTLS packets
received from the endpoint are encapsulated by the media distributor inside
this tunnel as data to be sent to the key distributor. Likewise, when the
media distributor receives data from the key distributor over the tunnel,
it extracts the DTLS message inside and forwards the DTLS message to the endpoint.
In this way, the DTLS association for the DTLS-SRTP procedures is
established between the endpoint and the key distributor, with the media
distributor simply forwarding packets between the two entities and having
no visibility into the confidential information exchanged.
</t>
<t>Following the existing DTLS-SRTP procedures, the endpoint and key
distributor will arrive at a selected cipher and keying material, which
are used for HBH encryption and authentication by both the endpoint and
the media distributor. However, since the media distributor would not
have direct access to this information, the key distributor explicitly
shares the HBH key information with the media distributor via the
tunneling protocol defined in this document. Additionally, the
endpoint and key distributor will agree on a cipher for E2E encryption
and authentication. The key distributor will transmit keying material
to the endpoint for E2E operations, but will not share that information
with the media distributor.
</t>
<t>By establishing this TLS tunnel between the media distributor and key
distributor and implementing the protocol defined in this document, it
is possible for the media distributor to facilitate the establishment of
a secure DTLS association between an endpoint and the key distributor in
order for the endpoint to receive E2E and HBH keying material. At the
same time, the key distributor can securely provide the HBH keying
material to the media distributor.
</t>
</section>
<section anchor="conventions-used-in-this-document" title="Conventions Used In This Document">
<t>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 <xref target="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.
</t>
</section>
<section anchor="tunneling-concept" title="Tunneling Concept">
<t>A TLS connection (tunnel) is established between the media distributor
and the key distributor. This tunnel is used to relay DTLS messages
between the endpoint and key distributor, as depicted in <xref target="fig-tunnel"/>:
</t>
<figure anchor="fig-tunnel" align="center" title="TLS Tunnel to Key Distributor
"><artwork align="center">
+-------------+
| Key |
| Distributor |
+-------------+
# ^ ^ #
# | | # <-- TLS Tunnel
# | | #
+----------+ +-------------+ +----------+
| | DTLS | | DTLS | |
| Endpoint |<------------| Media |------------>| Endpoint |
| | to Key | Distributor | to Key | |
| | Distributor | | Distributor | |
+----------+ +-------------+ +----------+
</artwork></figure>
<t>The three entities involved in this communication flow are the endpoint,
the media distributor, and the key distributor. The behavior of each
entity is described in <xref target="tunneling-procedures"/>.
</t>
<t>The key distributor 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 keying material.
</t>
</section>
<section anchor="example-message-flows" title="Example Message Flows">
<t>This section provides an example message flow to help clarify the
procedures described later in this document. It is necessary
that the key distributor and media distributor establish a mutually
authenticated TLS connection for the purpose of sending tunneled
messages, though the complete TLS handshake for the tunnel is not
shown in <xref target="fig-message-flow"/> since there is nothing new this document
introduces with regard to those procedures.
</t>
<t>Once the tunnel is established, it is possible for the media distributor
to relay the DTLS messages between the endpoint and the key distributor.
<xref target="fig-message-flow"/> shows a message flow wherein the endpoint uses
DTLS-SRTP to establish an association with the key distributor. In the
process, the media distributor shares its supported SRTP protection
profile information (see <xref target="RFC5764"/>) and the key distributor shares HBH
keying material and selected cipher with the media distributor.
</t>
<figure anchor="fig-message-flow" align="center" title="Sample DTLS-SRTP Exchange via the Tunnel
"><artwork align="center">
Endpoint media distributor key distributor
| | |
| |<=======================>|
| | TLS Connection Made |
| | |
| |========================>|
| | SupportedProfiles |
| | |
|------------------------>|========================>|
| DTLS handshake message | TunneledDtls |
| | |
| |<========================|
| | MediaKeys |
| | |
.... may be multiple handshake messages ...
| | |
|<------------------------|<========================|
| DTLS handshake message | TunneledDtls |
| | |
</artwork></figure>
<t>After the initial TLS connection has been established each of the messages
on the right-hand side of <xref target="fig-message-flow"/> is a tunneling protocol
message as defined in Section <xref target="tunneling-protocol"/>.
</t>
<t>SRTP protection profiles supported by the media distributor will be
sent in a <spanx style="verb">SupportedProfiles</spanx> message when the TLS tunnel is initially
established. The key distributor will use that information to select
a common profile supported by both the endpoint and the media
distributor to ensure that hop-by-hop operations can be successfully
performed.
</t>
<t>As DTLS messages are received from the endpoint by the media distributor,
they are forwarded to the key distributor encapsulated inside abbrev
<spanx style="verb">TunneledDtls</spanx> message. Likewise, as <spanx style="verb">TunneledDtls</spanx> messages are received
by the media distributor from the key distributor, the encapsulated
DTLS packet is forwarded to the endpoint.
</t>
<t>The key distributor will provide the SRTP <xref target="RFC3711"/> keying
material to the media distributor for HBH operations via the <spanx style="verb">MediaKeys</spanx>
message. The media distributor will extract this keying material
from the <spanx style="verb">MediaKeys</spanx> message when received and use it for hop-by-hop
encryption and authentication.
</t>
</section>
<section anchor="tunneling-procedures" title="Tunneling Procedures">
<t>The following sub-sections explain in detail the expected behavior of
the endpoint, the media distributor, and the key distributor.
</t>
<t>It is important to note that the tunneling protocol described in this
document is not an extension to TLS <xref target="RFC5246"/> or DTLS <xref target="RFC6347"/>.
Rather, it is a protocol that transports DTLS messages generated by an
endpoint or key distributor as data inside of the TLS connection
established between the media distributor and key distributor.
</t>
<section anchor="endpoint-procedures" title="Endpoint Procedures">
<t>The endpoint follows the procedures outlined for DTLS-SRTP <xref target="RFC5764"/>
in order to establish the cipher and keys used for encryption and
authentication, with the endpoint acting as the client and the
key distributor acting as the server. The endpoint does not need
to be aware of the fact that DTLS messages it transmits toward the
media distributor are being tunneled to the key distributor.
</t>
</section>
<section anchor="tunnel-establishment-procedures" title="Tunnel Establishment Procedures">
<t>Either the media distributor or key distributor initiates the
establishment of a TLS tunnel. Which entity acts as the TLS client
when establishing the tunnel and what event triggers the establishment
of the tunnel are outside the scope of this document. Further, how the
trust relationships are established between the key distributor and
media distributor are also outside the scope of this document.
</t>
<t>A tunnel MUST be a mutually authenticated TLS connection.
</t>
<t>The media distributor or key distributor MUST establish a tunnel
prior to forwarding tunneled DTLS messages. Given the time-sensitive
nature of DTLS-SRTP procedures, a tunnel SHOULD be
established prior to the media distributor receiving a DTLS message
from an endpoint.
</t>
<t>A single tunnel MAY be used to relay DTLS messages between any
number of endpoints and the key distributor.
</t>
<t>A media distributor MAY have more than one tunnel established
between itself and one or more key distributors. When multiple tunnels
are established, which tunnel or tunnels to use to send messages for a
given conference is outside the scope of this document.
</t>
</section>
<section anchor="versioning-considerations" title="Versioning Considerations">
<t>All messages for an established tunnel MUST utilize the same
version value. If the version of any subsequent message differs
from that of the initial message, that message MUST be
discarded and the tunnel connection closed.
</t>
<t>Since the media distributor sends the first message over the tunnel,
it effectively establishes the version of the protocol to be used.
If that version is not supported by the key distributor, it
MUST discard the message, transmit an <spanx style="verb">UnsupportedVersion</spanx> message,
and close the TLS connection.
</t>
<t>The media distributor MUST take note of the version received in an
<spanx style="verb">UnsupportedVersion</spanx> message and use that version when attempting to
re-establish a failed tunnel connection. Note that it is not necessary
for the media distributor to understand the newer version of the protocol to
understand that the first message received is <spanx style="verb">UnsupportedVersion</spanx>.
The media distributor can determine from the first two octets received
what the version number is and that the message is <spanx style="verb">UnsupportedVersion</spanx>.
The rest of the data received, if any, would be discarded and the
connection closed (if not already closed).
</t>
</section>
<section anchor="media-distributor-tunneling-procedures" title="Media Distributor Tunneling Procedures">
<t>The first message transmitted over the tunnel is the
<spanx style="verb">SupportedProfiles</spanx> (see <xref target="tunneling-protocol"/>). This message
informs the key distributor about which DTLS-SRTP profiles the media
distributor supports. This message MUST be sent each time a new
tunnel connection is established or, in the case of connection loss,
when a connection is re-established.
</t>
<t>The media distributor 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 key distributor.
</t>
<t><list style="empty">
<t>Editor's Note: Do we want to have the above requirement or would we
prefer to allow the media distributor to send messages over more
than one tunnel to more than one key distributor? The latter would
provide for higher availability, but at the cost of key distributor
complexity. The former would allow the usage of a load distributor in
front of the key distributor.
</t>
</list></t>
<t>The media distributor MUST assign a unique association identifier
for each endpoint-initiated DTLS association and include it in all
messages forwarded to the key distributor. The key distributor will
subsequently include this identifier in all messages it sends so
that the media distributor can map messages received via a tunnel and
forward those messages to the correct endpoint. The association
identifier SHOULD be randomly assigned and values not be re-used
for a short period of time (e.g., five minutes) to ensure any residual
state in the key distributor is clear and to ensure any packets already
transmitted from the key distributor are not directed to the wrong
endpoint.
</t>
<t>The tunnel protocol enables the key distributor to separately provide
HBH keying material to the media distributor for each of the individual
endpoint DTLS associations, though the media distributor cannot decrypt
messages between the key distributor and endpoints.
</t>
<t>When a DTLS message is received by the media distributor from an
endpoint, it forwards the UDP payload portion of that message to the key
distributor encapsulated in a <spanx style="verb">TuneledDtls</spanx> message. If the media
distributor knows which conference to which a given DTLS association
belongs, it can pass the conference identifier to the key distributor
using the <spanx style="verb">conf_id</spanx> field of the <spanx style="verb">TunneledDtls</spanx> message.
</t>
<t>The media distributor 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.
</t>
<t>When a <spanx style="verb">MediaKeys</spanx> message is received, the media
distributor MUST extract the cipher and keying 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 keying material will be different for each endpoint, the
media distributor uses the association identifier included by the key
distributor to ensure that the HBH keying material is used with the
correct endpoint.
</t>
<t>The media distributor MUST forward all DTLS messages received
from either the endpoint or the key distributor (via the <spanx style="verb">TunneledDtls</spanx>
message) to ensure proper communication between those two entities.
</t>
<t>When the media distributor detects an endpoint has disconnected or
when it receives conference control messages indicating the endpoint
is to be disconnected, the media distributors MUST send an
<spanx style="verb">EndpointDisconnect</spanx> message with the association identifier assigned to
the endpoint to the key distributor. The media distributor SHOULD
take a loss of all RTP and RTCP packets as an indicator that the endpoint
has disconnected. The particulars of how RTP and RTCP are to be used to
detect an endpoint disconnect, such as timeout period, is not specified.
The media distributor MAY use additional indicators to determine when
an endpoint has disconnected.
</t>
</section>
<section anchor="key-distributor-tunneling-procedures" title="Key Distributor Tunneling Procedures">
<t>When the media distributor relays a DTLS message from an endpoint, the
media distributor will include an association identifier that is unique
per endpoint-originated DTLS association. The association identifier
remains constant for the life of the DTLS association. The key
distributor identifies each distinct endpoint-originated DTLS
association by the association identifier.
</t>
<t>The key distributor MUST encapsulate any DTLS message it sends to
an endpoint inside a <spanx style="verb">TunneledDtls</spanx> message (see
<xref target="tunneling-protocol"/>).
</t>
<t>The key distributor MUST use the same association identifier in
messages sent to an endpoint as was received in messages from that
endpoint. This ensures the media distributor can forward the messages
to the correct endpoint.
</t>
<t>The key distributor extracts tunneled DTLS messages from an endpoint and
acts on those messages as if that endpoint had established the DTLS
association directly with the key distributor. The key distributor is
acting as the DTLS server and the endpoint is acting as the DTLS client. The
handling of the messages and certificates is exactly the same as normal
DTLS-SRTP procedures between endpoints.
</t>
<t>The key distributor MUST send a <spanx style="verb">MediaKeys</spanx> message to the media
distributor as soon as the HBH encryption key is computed and before it
sends a DTLS <spanx style="verb">Finished</spanx> message to the endpoint. The <spanx style="verb">MediaKeys</spanx> message
includes the selected cipher (i.e. protection profile), MKI <xref target="RFC3711"/>
value (if any), SRTP master keys, and SRTP master salt values. The key
distributor MUST use the same association identifier in the <spanx style="verb">MediaKeys</spanx>
message as is used in the <spanx style="verb">TunneledDtls</spanx> messages for the given endpoint.
</t>
<t>The key distributor, can use the certificate of the endpoint and
correlate that with signaling information to know which conference
this session is associated with. The key distributor informs the media
distributor of which conference this session is associated by
sending a globally unique conference identifier in the <spanx style="verb">conf_id</spanx>
attribute of the <spanx style="verb">MediaKeys</spanx>.
</t>
<t>The key distributor MUST select a cipher that is supported by both the
endpoint and the media distributor to ensure proper HBH operations.
</t>
</section>
</section>
<section anchor="tunneling-protocol" title="Tunneling Protocol">
<t>Tunneled messages are transported via the TLS tunnel as application
data between the media distributor and the key distributor. Tunnel
messages are specified using the format described in <xref target="RFC5246"/>
section 4. As in <xref target="RFC5246"/>, all values are stored in network byte
(big endian) order; the uint32 represented by the hex bytes 01 02 03 04
is equivalent to the decimal value 16909060.
</t>
<t>The protocol defines several different messages, each of which
containing the the following information:
</t>
<t>
<list style="symbols">
<t>Protocol version</t>
<t>Message type identifier</t>
<t>The message body</t>
</list>
</t>
<t>Each of these messages is a <spanx style="verb">TunnelMessage</spanx> in the syntax, with
a message type indicating the actual content of the message body.
</t>
<section anchor="tunnel-message-format" title="Tunnel Message Format">
<t>The syntax of the protocol is defined below. <spanx style="verb">TunnelMessage</spanx>
defines the structure of all messages sent via the tunnel protocol.
That structure includes a field called <spanx style="verb">msg_type</spanx> that identifies
the specific type of message contained within <spanx style="verb">TunnelMessage</spanx>.
</t>
<figure align="left"><artwork align="left">
enum {
unsupported_version(1),
supported_profiles(2),
media_keys(3),
tunneled_dtls(4),
endpoint_disconnect(5),
(255)
} MsgType;
struct {
uint8 version;
MsgType msg_type;
select (MsgType) {
case unsupported_version: UnsupportedVersion;
case supported_profiles: SupportedProfiles;
case media_keys: MediaKeys;
case tunneled_dtls: TunneledDtls;
case endpoint_disconnect: EndpointDisconnect;
} body;
} TunnelMessage;
</artwork></figure>
<t>The elements of <spanx style="verb">TunnelMessage</spanx> include:
</t>
<t>
<list style="symbols">
<t>version: indicates the version of this protocol (0x00).</t>
<t>msg_type: the type of message contained within the structure <spanx style="verb">body</spanx>.</t>
</list>
</t>
<t>The <spanx style="verb">UnsupportedVersion</spanx> message is defined as follows:
</t>
<figure align="left"><artwork align="left">
struct { } UnsupportedVersion;
</artwork></figure>
<t>The <spanx style="verb">UnsupportedVersion</spanx> message does not convey any additional information in the body.
</t>
<t>The <spanx style="verb">SupportedProfiles</spanx> message is defined as:
</t>
<figure align="left"><artwork align="left">
uint8 SRTPProtectionProfile[2]; // from RFC5764
struct {
SRTPProtectionProfile protection_profiles<0..2^16-1>;
} SupportedProfiles;
</artwork></figure>
<t>This message contains this single element:
* protection_profiles: The list of two-octet SRTP protection profile values as per <xref target="RFC5764"/> supported by the media distributor.
</t>
<t>The <spanx style="verb">MediaKeys</spanx> message is defined as:
</t>
<figure align="left"><artwork align="left">
struct {
uint32 association_id;
SRTPProtectionProfile protection_profile;
opaque mki<0..255>;
opaque client_write_SRTP_master_key<1..255>;
opaque server_write_SRTP_master_key<1..255>;
opaque client_write_SRTP_master_salt<1..255>;
opaque server_write_SRTP_master_salt<1..255>;
opaque conf_id<0..255>;
} MediaKeys;
</artwork></figure>
<t>The fields are described as follows:
</t>
<t>
<list style="symbols">
<t>association_id: A value that identifies a distinct DTLS association between an endpoint and the key distributor.</t>
<t>protection_profiles: The value of the two-octet SRTP protection profile value as per <xref target="RFC5764"/> used for this DTLS association.</t>
<t>mki: Master key identifier <xref target="RFC3711"/>.</t>
<t>client_write_SRTP_master_key: The value of the SRTP master key used by the client (endpoint).</t>
<t>server_write_SRTP_master_key: The value of the SRTP master key used by the server (media distributor).</t>
<t>client_write_SRTP_master_salt: The value of the SRTP master salt used by the client (endpoint).</t>
<t>server_write_SRTP_master_salt: The value of the SRTP master salt used by the server (media distributor).</t>
<t>conf_id: Identifier that uniquely specifies which conference the media distributor should place this media flow in.</t>
</list>
</t>
<t>The <spanx style="verb">TunneledDtls</spanx> message is defined as:
</t>
<figure align="left"><artwork align="left">
struct {
uint32 association_id;
opaque conf_id<0..255>;
opaque dtls_message<0..2^16-1>;
} TunneledDtls;
</artwork></figure>
<t>The fields are described as follows:
</t>
<t>
<list style="symbols">
<t>association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor.</t>
<t>conf_id: Optional identifier that uniquely specifies which conference this media flow is in.</t>
<t>dtls_message: the content of the DTLS message received by the endpoint or to be sent to the endpoint.</t>
</list>
</t>
<t>The <spanx style="verb">EndpointDisconect</spanx> message is defined as:
</t>
<figure align="left"><artwork align="left">
struct {
uint32 association_id;
} EndpointDisconnect;
</artwork></figure>
<t>The fields are described as follows:
</t>
<t>
<list style="symbols">
<t>association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor.</t>
</list>
</t>
</section>
</section>
<section anchor="example-binary-encoding" title="Example Binary Encoding">
<t>The <spanx style="verb">TunnelMessage</spanx> is encoded in binary following the procedures
specified in [!<xref target="RFC5246"/>]. This section provides an example of what
the bits on the wire would look like for the <spanx style="verb">SupportedProfiles</spanx> message
that advertises support for both SRTP_AEAD_AES_128_GCM and
SRTP_AEAD_AES_256_GCM <xref target="RFC7714"/>.
</t>
<figure align="left"><artwork align="left">
TunnelMessage:
version: 0x00
message_type: 0x01
SupportedProfiles:
protection_profiles: 0x0004 (length)
0x00070008 (value)
</artwork></figure>
<t>Thus, the encoding on the wire presented here in network bytes order
would be this stream of octets:
</t>
<figure align="left"><artwork align="left">
0x0001000400070008
</artwork></figure>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document establishes a new registry to contain message type values
used in the DTLS Tunnel protocol. These data type values are a single
octet in length. This document defines the values shown in <xref target="data_types"/>
below, leaving the balance of possible values reserved for future
specifications:
</t>
<texttable anchor="data_types" title="Data Type Values for the DTLS Tunnel Protocol
">
<ttcol align="center">MsgType</ttcol>
<ttcol align="left">Description</ttcol>
<c>0x01</c><c>Unsupported Version</c>
<c>0x02</c><c>Supported SRTP Protection Profiles</c>
<c>0x03</c><c>Media Keys</c>
<c>0x04</c><c>Tunneled DTLS</c>
<c>0x05</c><c>Endpoint Disconnect</c>
</texttable>
<t>The value 0x00 and all values in the range 0x06 to 0xFF are reserved.
</t>
<t>The name for this registry is "Datagram Transport Layer Security
(DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing".
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The encapsulated data is protected by the TLS connection from the endpoint
to key distributor, and the media distributor is merely an on path entity.
The media distributor does not have access to the end-to-end keying material
This does not introduce any additional security concerns beyond a normal
DTLS-SRTP association.
</t>
<t>The HBH keying material is protected by the mutual authenticated TLS
connection between the media distributor and key distributor. The key
distributor MUST ensure that it only forms associations with authorized
media distributors or it could hand HBH keying material to untrusted
parties.
</t>
<t>The supported profiles information sent from the media distributor to the
key distributor is not particularly sensitive as it only provides the
cryptographic algorithms supported by the media distributor. Further,
it is still protected by the TLS connection between the media distributor
and the key distributor.
</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The author would like to thank David Benham and Cullen Jennings for
reviewing this document and providing constructive comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7714.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:58 |