rfc9185.original   rfc9185.txt 
Network Working Group P. Jones Internet Engineering Task Force (IETF) P. Jones
Internet-Draft Cisco Systems Request for Comments: 9185 Cisco Systems
Intended status: Informational P. Ellenbogen Category: Informational P. Ellenbogen
Expires: 16 May 2022 Princeton University ISSN: 2070-1721 Princeton University
N. Ohlmeier N. Ohlmeier
8x8, Inc. 8x8, Inc.
12 November 2021 April 2022
DTLS Tunnel between a Media Distributor and Key Distributor to DTLS Tunnel between a Media Distributor and Key Distributor to
Facilitate Key Exchange Facilitate Key Exchange
draft-ietf-perc-dtls-tunnel-12
Abstract Abstract
This document defines a protocol for tunneling DTLS traffic in This document defines a protocol for tunneling DTLS traffic in
multimedia conferences that enables a Media Distributor to facilitate multimedia conferences that enables a Media Distributor to facilitate
key exchange between an endpoint in a conference and the Key key exchange between an endpoint in a conference and the Key
Distributor. The protocol is designed to ensure that the keying Distributor. The protocol is designed to ensure that the keying
material used for hop-by-hop encryption and authentication is material used for hop-by-hop encryption and authentication is
accessible to the Media Distributor, while the keying material used accessible to the Media Distributor, while the keying material used
for end-to-end encryption and authentication is inaccessible to the for end-to-end encryption and authentication is inaccessible to the
Media Distributor. Media Distributor.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 16 May 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9185.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document
3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 4 3. Tunneling Concept
4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 4. Example Message Flows
5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 5. Tunneling Procedures
5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 5.1. Endpoint Procedures
5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 5.2. Tunnel Establishment Procedures
5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7 5.3. Media Distributor Tunneling Procedures
5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 5.4. Key Distributor Tunneling Procedures
5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 5.5. Versioning Considerations
6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 6. Tunneling Protocol
6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 11 6.1. TunnelMessage Structure
6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11 6.2. SupportedProfiles Message
6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12 6.3. UnsupportedVersion Message
6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12 6.4. MediaKeys Message
6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13 6.5. TunneledDtls Message
6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13 6.6. EndpointDisconnect Message
7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 14 7. Example Binary Encoding
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References
11. Normative References . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References
12. Informative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is
to ensure that endpoints in a multimedia conference have access to 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 the end-to-end (E2E) and hop-by-hop (HBH) keying material used to
encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] encrypt and authenticate Real-time Transport Protocol (RTP) packets
packets, while the Media Distributor has access only to the HBH [RFC3550], while the Media Distributor has access only to the HBH
keying material for encryption and authentication. keying material for encryption and authentication.
This specification defines a tunneling protocol that enables the This specification defines a tunneling protocol that enables the
Media Distributor to tunnel DTLS [I-D.ietf-tls-dtls13] messages Media Distributor to tunnel DTLS messages [RFC9147] between an
between an endpoint and a Key Distributor, thus allowing an endpoint endpoint and a Key Distributor, thus allowing an endpoint to use DTLS
to use DTLS-SRTP [RFC5764] for establishing encryption and for the Secure Real-time Transport Protocol (DTLS-SRTP) [RFC5764] for
authentication keys with the Key Distributor. establishing encryption and authentication keys with the Key
Distributor.
The tunnel established between the Media Distributor and Key The tunnel established between the Media Distributor and Key
Distributor is a TLS [RFC8446] connection that is established before Distributor is a TLS connection [RFC8446] that is established before
any messages are forwarded by the Media Distributor on behalf of any messages are forwarded by the Media Distributor on behalf of
endpoints. DTLS packets received from an endpoint are encapsulated endpoints. DTLS packets received from an endpoint are encapsulated
by the Media Distributor inside this tunnel as data to be sent to the by the Media Distributor inside this tunnel as data to be sent to the
Key Distributor. Likewise, when the Media Distributor receives data Key Distributor. Likewise, when the Media Distributor receives data
from the Key Distributor over the tunnel, it extracts the DTLS from the Key Distributor over the tunnel, it extracts the DTLS
message inside and forwards the DTLS message to the endpoint. In message inside and forwards the DTLS message to the endpoint. In
this way, the DTLS association for the DTLS-SRTP procedures is this way, the DTLS association for the DTLS-SRTP procedures is
established between an endpoint and the Key Distributor, with the established between an endpoint and the Key Distributor, with the
Media Distributor forwarding DTLS messages between the two entities Media Distributor forwarding DTLS messages between the two entities
via the established tunnel to the Key Distributor and having no via the established tunnel to the Key Distributor and having no
skipping to change at page 3, line 34 skipping to change at line 122
Following the existing DTLS-SRTP procedures, the endpoint and Key Following the existing DTLS-SRTP procedures, the endpoint and Key
Distributor will arrive at a selected cipher and keying material, Distributor will arrive at a selected cipher and keying material,
which are used for HBH encryption and authentication by both the which are used for HBH encryption and authentication by both the
endpoint and the Media Distributor. However, since the Media endpoint and the Media Distributor. However, since the Media
Distributor would not have direct access to this information, the Key Distributor would not have direct access to this information, the Key
Distributor explicitly shares the HBH key information with the Media Distributor explicitly shares the HBH key information with the Media
Distributor via the tunneling protocol defined in this document. Distributor via the tunneling protocol defined in this document.
Additionally, the endpoint and Key Distributor will agree on a cipher Additionally, the endpoint and Key Distributor will agree on a cipher
for E2E encryption and authentication. The Key Distributor will for E2E encryption and authentication. The Key Distributor will
transmit keying material to the endpoint for E2E operations, but will transmit keying material to the endpoint for E2E operations but will
not share that information with the Media Distributor. not share that information with the Media Distributor.
By establishing this TLS tunnel between the Media Distributor and Key By establishing this TLS tunnel between the Media Distributor and Key
Distributor and implementing the protocol defined in this document, Distributor and implementing the protocol defined in this document,
it is possible for the Media Distributor to facilitate the it is possible for the Media Distributor to facilitate the
establishment of a secure DTLS association between an endpoint and establishment of a secure DTLS association between an endpoint and
the Key Distributor in order for the endpoint to generate E2E and HBH the Key Distributor in order for the endpoint to generate E2E and HBH
keying material. At the same time, the Key Distributor can securely keying material. At the same time, the Key Distributor can securely
provide the HBH keying material to the Media Distributor. provide the HBH keying material to the Media Distributor.
2. Conventions Used In This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terms "endpoint", "Media Distributor", and This document uses the terms "endpoint", "Media Distributor", and
"Key Distributor" defined in [RFC8871]. "Key Distributor" defined in [RFC8871].
3. Tunneling Concept 3. Tunneling Concept
A TLS connection (tunnel) is established between the Media A TLS connection (tunnel) is established between the Media
Distributor and the Key Distributor. This tunnel is used to relay Distributor and the Key Distributor. This tunnel is used to relay
DTLS messages between the endpoint and Key Distributor, as depicted DTLS messages between the endpoint and Key Distributor, as depicted
skipping to change at page 4, line 36 skipping to change at line 172
| | Distributor | | Distributor | | | | Distributor | | Distributor | |
+----------+ +-------------+ +----------+ +----------+ +-------------+ +----------+
Figure 1: TLS Tunnel to Key Distributor Figure 1: TLS Tunnel to Key Distributor
The three entities involved in this communication flow are the The three entities involved in this communication flow are the
endpoint, the Media Distributor, and the Key Distributor. The endpoint, the Media Distributor, and the Key Distributor. The
behavior of each entity is described in Section 5. behavior of each entity is described in Section 5.
The Key Distributor is a logical function that might be co-resident The Key Distributor is a logical function that might be co-resident
with a key management server operated by an enterprise, reside in one with a key management server operated by an enterprise, might reside
of the endpoints participating in the conference, or elsewhere that in one of the endpoints participating in the conference, or might
is trusted with E2E keying material. reside at some other location that is trusted with E2E keying
material.
4. Example Message Flows 4. Example Message Flows
This section provides an example message flow to help clarify the This section provides an example message flow to help clarify the
procedures described later in this document. It is necessary that procedures described later in this document. It is necessary that
the Key Distributor and Media Distributor establish a mutually the Key Distributor and Media Distributor establish a mutually
authenticated TLS connection for the purpose of sending tunneled authenticated TLS connection for the purpose of sending tunneled
messages, though the complete TLS handshake for the tunnel is not messages, though the complete TLS handshake for the tunnel is not
shown in Figure 2 since there is nothing new this document introduces shown in Figure 2 because there is nothing new this document
with regard to those procedures. introduces with regard to those procedures.
Once the tunnel is established, it is possible for the Media Once the tunnel is established, it is possible for the Media
Distributor to relay the DTLS messages between the endpoint and the Distributor to relay the DTLS messages between the endpoint and the
Key Distributor. Figure 2 shows a message flow wherein the endpoint Key Distributor. Figure 2 shows a message flow wherein the endpoint
uses DTLS-SRTP to establish an association with the Key Distributor. uses DTLS-SRTP to establish an association with the Key Distributor.
In the process, the Media Distributor shares its supported SRTP In the process, the Media Distributor shares its supported SRTP
protection profile information (see [RFC5764]) and the Key protection profile information (see [RFC5764]), and the Key
Distributor shares HBH keying material and selected cipher with the Distributor shares the HBH keying material and selected cipher with
Media Distributor. the Media Distributor.
Endpoint Media Distributor Key Distributor Endpoint Media Distributor Key Distributor
| | | | | |
| |<=======================>| | |<=======================>|
| | TLS Connection Made | | | TLS Connection Made |
| | | | | |
| |========================>| | |========================>|
| | SupportedProfiles | | | SupportedProfiles |
| | | | | |
|------------------------>|========================>| |------------------------>|========================>|
skipping to change at page 5, line 32 skipping to change at line 218
| | | | | |
|<------------------------|<========================| |<------------------------|<========================|
| DTLS handshake message | TunneledDtls | | DTLS handshake message | TunneledDtls |
| | | | | |
| | | | | |
| |<========================| | |<========================|
| | MediaKeys | | | MediaKeys |
Figure 2: Sample DTLS-SRTP Exchange via the Tunnel Figure 2: Sample DTLS-SRTP Exchange via the Tunnel
After the initial TLS connection has been established each of the After the initial TLS connection has been established, each of the
messages on the right-hand side of Figure 2 is a tunneling protocol messages on the right-hand side of Figure 2 is a tunneling protocol
message as defined in Section 6. message, as defined in Section 6.
SRTP protection profiles supported by the Media Distributor will be SRTP protection profiles supported by the Media Distributor will be
sent in a "SupportedProfiles" message when the TLS tunnel is sent in a SupportedProfiles message when the TLS tunnel is initially
initially established. The Key Distributor will use that information established. The Key Distributor will use that information to select
to select a common profile supported by both the endpoint and the a common profile supported by both the endpoint and the Media
Media Distributor to ensure that HBH operations can be successfully Distributor to ensure that HBH operations can be successfully
performed. performed.
As DTLS messages are received from the endpoint by the Media As DTLS messages are received from the endpoint by the Media
Distributor, they are forwarded to the Key Distributor encapsulated Distributor, they are forwarded to the Key Distributor encapsulated
inside a "TunneledDtls" message. Likewise, as "TunneledDtls" inside a TunneledDtls message. Likewise, as TunneledDtls messages
messages are received by the Media Distributor from the Key are received by the Media Distributor from the Key Distributor, the
Distributor, the encapsulated DTLS packet is forwarded to the encapsulated DTLS packet is forwarded to the endpoint.
endpoint.
The Key Distributor will provide the SRTP [RFC3711] keying material The Key Distributor will provide the SRTP keying material [RFC3711]
to the Media Distributor for HBH operations via the "MediaKeys" to the Media Distributor for HBH operations via the MediaKeys
message. The Media Distributor will extract this keying material message. The Media Distributor will extract this keying material
from the "MediaKeys" message when received and use it for HBH from the MediaKeys message when received and use it for HBH
encryption and authentication. encryption and authentication.
5. Tunneling Procedures 5. Tunneling Procedures
The following sub-sections explain in detail the expected behavior of The following subsections explain in detail the expected behavior of
the endpoint, the Media Distributor, and the Key Distributor. the endpoint, the Media Distributor, and the Key Distributor.
It is important to note that the tunneling protocol described in this It is important to note that the tunneling protocol described in this
document is not an extension to TLS or DTLS. Rather, it is a document is not an extension to TLS or DTLS. Rather, it is a
protocol that transports DTLS messages generated by an endpoint or protocol that transports DTLS messages generated by an endpoint or
Key Distributor as data inside of the TLS connection established Key Distributor as data inside of the TLS connection established
between the Media Distributor and Key Distributor. between the Media Distributor and Key Distributor.
5.1. Endpoint Procedures 5.1. Endpoint Procedures
The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764]
in order to establish the cipher and keys used for encryption and in order to establish the cipher and keys used for encryption and
authentication, with the endpoint acting as the client and the Key authentication, with the endpoint acting as the client and the Key
Distributor acting as the server. The endpoint does not need to be Distributor acting as the server. The endpoint does not need to be
aware of the fact that DTLS messages it transmits toward the Media aware of the fact that DTLS messages it transmits toward the Media
Distributor are being tunneled to the Key Distributor. Distributor are being tunneled to the Key Distributor.
The endpoint MUST include a unique identifier in the "tls-id" SDP The endpoint MUST include a unique identifier in the tls-id Session
[RFC8866] attribute in all offer and answer messages [RFC3264] that Description Protocol (SDP) attribute [RFC8866] in all offer and
it generates as per [RFC8842]. Further, the endpoint MUST include answer messages [RFC3264] that it generates, as per [RFC8842].
this same unique identifier in the "external_session_id" extension Further, the endpoint MUST include this same unique identifier in the
[RFC8844] in the "ClientHello" message when establishing a DTLS external_session_id extension [RFC8844] in the ClientHello message
association. when establishing a DTLS association.
When receiving a "external_session_id" value from the Key When receiving an external_session_id value from the Key Distributor,
Distributor, the client MUST check to ensure that value matches the the client MUST check to ensure that value matches the tls-id value
"tls-id" value received in SDP. If the values do not match, the received in SDP. If the values do not match, the endpoint MUST
endpoint MUST consider any received keying material to be invalid and consider any received keying material to be invalid and terminate the
terminate the DTLS association. DTLS association.
5.2. Tunnel Establishment Procedures 5.2. Tunnel Establishment Procedures
Either the Media Distributor or Key Distributor initiates the Either the Media Distributor or Key Distributor initiates the
establishment of a TLS tunnel. Which entity acts as the TLS client establishment of a TLS tunnel. Which entity acts as the TLS client
when establishing the tunnel and what event triggers the when establishing the tunnel and what event triggers the
establishment of the tunnel are outside the scope of this document. establishment of the tunnel are outside the scope of this document.
Further, how the trust relationships are established between the Key Further, how the trust relationships are established between the Key
Distributor and Media Distributor are also outside the scope of this Distributor and Media Distributor are also outside the scope of this
document. document.
skipping to change at page 7, line 23 skipping to change at line 302
of endpoints and the Key Distributor. of endpoints and the Key Distributor.
A Media Distributor MAY have more than one tunnel established between A Media Distributor MAY have more than one tunnel established between
itself and one or more Key Distributors. When multiple tunnels are itself and one or more Key Distributors. When multiple tunnels are
established, which tunnel or tunnels to use to send messages for a established, which tunnel or tunnels to use to send messages for a
given conference is outside the scope of this document. given conference is outside the scope of this document.
5.3. Media Distributor Tunneling Procedures 5.3. Media Distributor Tunneling Procedures
The first message transmitted over the tunnel is the The first message transmitted over the tunnel is the
"SupportedProfiles" (see Section 6). This message informs the Key SupportedProfiles message (see Section 6). This message informs the
Distributor about which DTLS-SRTP profiles the Media Distributor Key Distributor about which DTLS-SRTP profiles the Media Distributor
supports. This message MUST be sent each time a new tunnel 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 established or, in the case of connection loss, when a
connection is re-established. The Media Distributor MUST support the connection is re-established. The Media Distributor MUST support the
same list of protection profiles for the duration of any endpoint- same list of protection profiles for the duration of any endpoint-
initiated DTLS association and tunnel connection. initiated DTLS association and tunnel connection.
The Media Distributor MUST assign a unique association identifier for The Media Distributor MUST assign a unique association identifier for
each endpoint-initiated DTLS association and include it in all each endpoint-initiated DTLS association and include it in all
messages forwarded to the Key Distributor. The Key Distributor will messages forwarded to the Key Distributor. The Key Distributor will
subsequently include this identifier in all messages it sends so that subsequently include this identifier in all messages it sends so that
the Media Distributor can map messages received via a tunnel and the Media Distributor can map messages received via a tunnel and
forward those messages to the correct endpoint. The association forward those messages to the correct endpoint. The association
identifier MUST be randomly assigned UUID value as described identifier MUST be a version 4 Universally Unique Identifier (UUID),
Section 4.4 of [RFC4122]. as described in Section 4.4 of [RFC4122].
When a DTLS message is received by the Media Distributor from an When a DTLS message is received by the Media Distributor from an
endpoint, it forwards the UDP payload portion of that message to the endpoint, it forwards the UDP payload portion of that message to the
Key Distributor encapsulated in a "TuneledDtls" message. The Media Key Distributor encapsulated in a TunneledDtls message. The Media
Distributor is not required to forward all messages received from an Distributor is not required to forward all messages received from an
endpoint for a given DTLS association through the same tunnel if more endpoint for a given DTLS association through the same tunnel if more
than one tunnel has been established between it and a Key than one tunnel has been established between it and a Key
Distributor. Distributor.
When a "MediaKeys" message is received, the Media Distributor MUST When a MediaKeys message is received, the Media Distributor MUST
extract the cipher and keying material conveyed in order to extract the cipher and keying material conveyed in order to
subsequently perform HBH encryption and authentication operations for subsequently perform HBH encryption and authentication operations for
RTP and RTCP packets sent between it and an endpoint. Since the HBH RTP and RTP Control Protocol (RTCP) packets sent between it and an
keying material will be different for each endpoint, the Media endpoint. Since the HBH keying material will be different for each
Distributor uses the association identifier included by the Key endpoint, the Media Distributor uses the association identifier
Distributor to ensure that the HBH keying material is used with the included by the Key Distributor to ensure that the HBH keying
correct endpoint. material is used with the correct endpoint.
The Media Distributor MUST forward all DTLS messages received from The Media Distributor MUST forward all DTLS messages received from
either the endpoint or the Key Distributor (via the "TunneledDtls" either the endpoint or the Key Distributor (via the TunneledDtls
message) to ensure proper communication between those two entities. message) to ensure proper communication between those two entities.
When the Media Distributor detects an endpoint has disconnected or When the Media Distributor detects an endpoint has disconnected or
when it receives conference control messages indicating the endpoint when it receives conference control messages indicating the endpoint
is to be disconnected, the Media Distributors MUST send an is to be disconnected, the Media Distributor MUST send an
"EndpointDisconnect" message with the association identifier assigned EndpointDisconnect message with the association identifier assigned
to the endpoint to the Key Distributor. The Media Distributor SHOULD 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 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 endpoint has disconnected. The particulars of how RTP and RTCP are
to be used to detect an endpoint disconnect, such as timeout period, to be used to detect an endpoint disconnect, such as timeout period,
is not specified. The Media Distributor MAY use additional are not specified. The Media Distributor MAY use additional
indicators to determine when an endpoint has disconnected. indicators to determine when an endpoint has disconnected.
5.4. Key Distributor Tunneling Procedures 5.4. Key Distributor Tunneling Procedures
Each TLS tunnel established between the Media Distributor and the Key Each TLS tunnel established between the Media Distributor and the Key
Distributor MUST be mutually authenticated. Distributor MUST be mutually authenticated.
When the Media Distributor relays a DTLS message from an endpoint, When the Media Distributor relays a DTLS message from an endpoint,
the Media Distributor will include an association identifier that is the Media Distributor will include an association identifier that is
unique per endpoint-originated DTLS association. The association unique per endpoint-originated DTLS association. The association
identifier remains constant for the life of the DTLS association. identifier remains constant for the life of the DTLS association.
The Key Distributor identifies each distinct endpoint-originated DTLS The Key Distributor identifies each distinct endpoint-originated DTLS
association by the association identifier. association by the association identifier.
When processing an incoming endpoint association, the Key Distributor When processing an incoming endpoint association, the Key Distributor
MUST extract the "external_session_id" value transmitted in the MUST extract the external_session_id value transmitted in the
"ClientHello" message and match that against the "tls-id" value the ClientHello message and match that against the tls-id value the
endpoint transmitted via SDP. If the values in SDP and the endpoint transmitted via SDP. If the values in SDP and the
"ClientHello" do not match, the DTLS association MUST be rejected. ClientHello message do not match, the DTLS association MUST be
rejected.
The process through which the "tls-id" in SDP is conveyed to the Key The process through which the tls-id value in SDP is conveyed to the
Distributor is outside the scope of this document. Key Distributor is outside the scope of this document.
The Key Distributor MUST match the fingerprint of the certificate and The Key Distributor MUST match the fingerprint of the certificate and
"external_session_id" [RFC8844] received from endpoint via DTLS with external_session_id [RFC8844] received from the endpoint via DTLS
the expected fingerprint [RFC8122] and "tls-id" [RFC8842] values with the expected fingerprint [RFC8122] and tls-id [RFC8842] values
received via SDP. It is through this process that the Key received via SDP. It is through this process that the Key
Distributor can be sure to deliver the correct conference key to the Distributor can be sure to deliver the correct conference key to the
endpoint. endpoint.
The Key Distributor MUST report its own unique identifier in the The Key Distributor MUST report its own unique identifier in the
"external_session_id" extension. This extension is sent in the external_session_id extension. This extension is sent in the
"EncryptedExtensions" message in DTLS 1.3, and the "ServerHello" in EncryptedExtensions message in DTLS 1.3 and the ServerHello message
previous DTLS versions. This value MUST also be conveyed back to the in previous DTLS versions. This value MUST also be conveyed back to
client via SDP as a "tls-id" attribute. the client via SDP as a tls-id attribute.
The Key Distributor MUST encapsulate any DTLS message it sends to an The Key Distributor MUST encapsulate any DTLS message it sends to an
endpoint inside a "TunneledDtls" message (see Section 6). The Key endpoint inside a TunneledDtls message (see Section 6). The Key
Distributor is not required to transmit all messages for a given DTLS Distributor is not required to transmit all messages for a given DTLS
association through the same tunnel if more than one tunnel has been association through the same tunnel if more than one tunnel has been
established between it and the Media Distributor. established between it and the Media Distributor.
The Key Distributor MUST use the same association identifier in The Key Distributor MUST use the same association identifier in
messages sent to an endpoint as was received in messages from that messages sent to an endpoint as was received in messages from that
endpoint. This ensures the Media Distributor can forward the endpoint. This ensures the Media Distributor can forward the
messages to the correct endpoint. messages to the correct endpoint.
The Key Distributor extracts tunneled DTLS messages from an endpoint The Key Distributor extracts tunneled DTLS messages from an endpoint
and acts on those messages as if that endpoint had established the and acts on those messages as if that endpoint had established the
DTLS association directly with the Key Distributor. The Key DTLS association directly with the Key Distributor. The Key
Distributor is acting as the DTLS server and the endpoint is acting Distributor is acting as the DTLS server, and the endpoint is acting
as the DTLS client. The handling of the messages and certificates is as the DTLS client. The handling of the messages and certificates is
exactly the same as normal DTLS-SRTP procedures between endpoints. exactly the same as normal DTLS-SRTP procedures between endpoints.
The Key Distributor MUST send a "MediaKeys" message to the Media The Key Distributor MUST send a MediaKeys message to the Media
Distributor immediately after the DTLS handshake completes. The Distributor immediately after the DTLS handshake completes. The
"MediaKeys" message includes the selected cipher (i.e. protection MediaKeys message includes the selected cipher (i.e., protection
profile), MKI [RFC3711] value (if any), HBH SRTP master keys, and profile), Master Key Identifier (MKI) value [RFC3711] (if any), HBH
SRTP master salt values. The Key Distributor MUST use the same SRTP master keys, and SRTP master salt values. The Key Distributor
association identifier in the "MediaKeys" message as is used in the MUST use the same association identifier in the MediaKeys message as
"TunneledDtls" messages for the given endpoint. is used in the TunneledDtls messages for the given endpoint.
There are presently two SRTP protection profiles defined for PERC, There are presently two SRTP protection profiles defined for PERC,
namely "DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and namely DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
"DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. As [RFC8723] DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723]. As explained in
explains in Section 5.2, the Media Distributor is only given the SRTP Section 5.2 of [RFC8723], the Media Distributor is only given the
master key for HBH operations. As such, the SRTP master key length SRTP master key for HBH operations. As such, the SRTP master key
advertised in the "MediaKeys" message is half the length of the key length advertised in the MediaKeys message is half the length of the
normally associated with selected "double" protection profile. key normally associated with the selected "double" protection
profile.
The Key Distributor uses the certificate fingerprint of the endpoint The Key Distributor uses the certificate fingerprint of the endpoint
along with the unique identifier received in the along with the unique identifier received in the external_session_id
"external_session_id" extension to determine which conference a given extension to determine with which conference a given DTLS association
DTLS association is associated. is associated.
The Key Distributor MUST select a cipher that is supported itself, The Key Distributor MUST select a cipher that is supported by itself,
the endpoint, and the Media Distributor to ensure proper HBH the endpoint, and the Media Distributor to ensure proper HBH
operations. operations.
When the DTLS association between the endpoint and the Key When the DTLS association between the endpoint and the Key
Distributor is terminated, regardless of which entity initiated the Distributor is terminated, regardless of which entity initiated the
termination, the Key Distributor MUST send an "EndpointDisconnect" termination, the Key Distributor MUST send an EndpointDisconnect
message with the association identifier assigned to the endpoint to message with the association identifier assigned to the endpoint to
the Media Distributor. the Media Distributor.
5.5. Versioning Considerations 5.5. Versioning Considerations
Since the Media Distributor sends the first message over the tunnel, Since the Media Distributor sends the first message over the tunnel,
it effectively establishes the version of the protocol to be used. it effectively establishes the version of the protocol to be used.
If that version is not supported by the Key Distributor, the Key If that version is not supported by the Key Distributor, the Key
Distributor MUST transmit an "UnsupportedVersion" message containing Distributor MUST transmit an UnsupportedVersion message containing
the highest version number supported, and close the TLS connection. the highest version number supported and close the TLS connection.
The Media Distributor MUST take note of the version received in an The Media Distributor MUST take note of the version received in an
"UnsupportedVersion" message and use that version when attempting to UnsupportedVersion message and use that version when attempting to
re-establish a failed tunnel connection. Note that it is not re-establish a failed tunnel connection. Note that it is not
necessary for the Media Distributor to understand the newer version necessary for the Media Distributor to understand the newer version
of the protocol to understand that the first message received is of the protocol to understand that the first message received is an
"UnsupportedVersion". The Media Distributor can determine from the UnsupportedVersion message. The Media Distributor can determine from
first four octets received what the version number is and that the the first four octets received what the version number is and that
message is "UnsupportedVersion". The rest of the data received, if the message is an UnsupportedVersion message. The rest of the data
any, would be discarded and the connection closed (if not already received, if any, would be discarded and the connection closed (if
closed). not already closed).
6. Tunneling Protocol 6. Tunneling Protocol
Tunneled messages are transported via the TLS tunnel as application Tunneled messages are transported via the TLS tunnel as application
data between the Media Distributor and the Key Distributor. Tunnel data between the Media Distributor and the Key Distributor. Tunnel
messages are specified using the format described in [RFC8446] messages are specified using the format described in [RFC8446],
section 3. As in [RFC8446], all values are stored in network byte Section 3. As in [RFC8446], all values are stored in network byte
(big endian) order; the uint32 represented by the hex bytes 01 02 03 (big endian) order; the uint32 represented by the hex bytes 01 02 03
04 is equivalent to the decimal value 16909060. 04 is equivalent to the decimal value 16909060.
This protocol defines several different messages, each of which This protocol defines several different messages, each of which
contains the following information: contains the following information:
* Message type identifier * message type identifier
* Message body length * message body length
* The message body * the message body
Each of the tunnel messages is a "TunnelMessage" structure with the Each of the tunnel messages is a TunnelMessage structure with the
message type indicating the actual content of the message body. message type indicating the actual content of the message body.
6.1. TunnelMessage Structure 6.1. TunnelMessage Structure
The "TunnelMessage" defines the structure of all messages sent via TunnelMessage defines the structure of all messages sent via the
the tunnel protocol. That structure includes a field called tunnel protocol. That structure includes a field called msg_type
"msg_type" that identifies the specific type of message contained that identifies the specific type of message contained within
within "TunnelMessage". TunnelMessage.
enum { enum {
supported_profiles(1), supported_profiles(1),
unsupported_version(2), unsupported_version(2),
media_keys(3), media_keys(3),
tunneled_dtls(4), tunneled_dtls(4),
endpoint_disconnect(5), endpoint_disconnect(5),
(255) (255)
} MsgType; } MsgType;
skipping to change at page 11, line 35 skipping to change at line 506
uint16 length; uint16 length;
select (MsgType) { select (MsgType) {
case supported_profiles: SupportedProfiles; case supported_profiles: SupportedProfiles;
case unsupported_version: UnsupportedVersion; case unsupported_version: UnsupportedVersion;
case media_keys: MediaKeys; case media_keys: MediaKeys;
case tunneled_dtls: TunneledDtls; case tunneled_dtls: TunneledDtls;
case endpoint_disconnect: EndpointDisconnect; case endpoint_disconnect: EndpointDisconnect;
} body; } body;
} TunnelMessage; } TunnelMessage;
The elements of "TunnelMessage" include: The elements of TunnelMessage include:
* "msg_type": the type of message contained within the structure msg_type: the type of message contained within the structure body.
"body".
* "length": the length in octets of the following "body" of the length: the length in octets of the following body of the message.
message.
* "body": the actual message being conveyed within this body: the actual message being conveyed within this TunnelMessage
"TunnelMessage" structure. structure.
6.2. SupportedProfiles Message 6.2. SupportedProfiles Message
The "SupportedProfiles" message is defined as: The SupportedProfiles message is defined as:
uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ uint8 SRTPProtectionProfile[2]; /* from RFC 5764 */
struct { struct {
uint8 version; uint8 version;
SRTPProtectionProfile protection_profiles<2..2^16-1>; SRTPProtectionProfile protection_profiles<2..2^16-1>;
} SupportedProfiles; } SupportedProfiles;
This message contains this single element: The elements of SupportedProfiles include:
* "version": This document specifies version 0x00. version: this document specifies version 0x00.
* "protection_profiles": The list of two-octet SRTP protection protection_profiles: the list of two-octet SRTP protection profile
profile values as per [RFC5764] supported by the Media values, as per [RFC5764], supported by the Media Distributor.
Distributor.
6.3. UnsupportedVersion Message 6.3. UnsupportedVersion Message
The "UnsupportedVersion" message is defined as follows: The UnsupportedVersion message is defined as:
struct { struct {
uint8 highest_version; uint8 highest_version;
} UnsupportedVersion; } UnsupportedVersion;
The elements of "UnsupportedVersion" include: UnsupportedVersion contains this single element:
* "highest_version": indicates the highest version of the protocol highest_version: indicates the highest version of the protocol
supported by the Key Distributor. supported by the Key Distributor.
6.4. MediaKeys Message 6.4. MediaKeys Message
The "MediaKeys" message is defined as: The MediaKeys message is defined as:
struct { struct {
uuid association_id; uuid association_id;
SRTPProtectionProfile protection_profile; SRTPProtectionProfile protection_profile;
opaque mki<0..255>; opaque mki<0..255>;
opaque client_write_SRTP_master_key<1..255>; opaque client_write_SRTP_master_key<1..255>;
opaque server_write_SRTP_master_key<1..255>; opaque server_write_SRTP_master_key<1..255>;
opaque client_write_SRTP_master_salt<1..255>; opaque client_write_SRTP_master_salt<1..255>;
opaque server_write_SRTP_master_salt<1..255>; opaque server_write_SRTP_master_salt<1..255>;
} MediaKeys; } MediaKeys;
The fields are described as follows: The fields are described as follows:
* "association_id": A value that identifies a distinct DTLS association_id: a value that identifies a distinct DTLS association
association between an endpoint and the Key Distributor. between an endpoint and the Key Distributor.
* "protection_profiles": The value of the two-octet SRTP protection protection_profiles: the value of the two-octet SRTP protection
profile value as per [RFC5764] used for this DTLS association. profile value, as per [RFC5764], used for this DTLS association.
* "mki": Master key identifier [RFC3711]. A zero-length field mki: master key identifier [RFC3711]; a zero-length field indicates
indicates that no MKI value is present. that no MKI value is present.
* "client_write_SRTP_master_key": The value of the SRTP master key client_write_SRTP_master_key: the value of the SRTP master key used
used by the client (endpoint). by the client (endpoint).
* "server_write_SRTP_master_key": The value of the SRTP master key server_write_SRTP_master_key: the value of the SRTP master key used
used by the server (Media Distributor). by the server (Media Distributor).
* "client_write_SRTP_master_salt": The value of the SRTP master salt client_write_SRTP_master_salt: the value of the SRTP master salt
used by the client (endpoint). used by the client (endpoint).
* "server_write_SRTP_master_salt": The value of the SRTP master salt server_write_SRTP_master_salt: the value of the SRTP master salt
used by the server (Media Distributor). used by the server (Media Distributor).
6.5. TunneledDtls Message 6.5. TunneledDtls Message
The "TunneledDtls" message is defined as: The TunneledDtls message is defined as:
struct { struct {
uuid association_id; uuid association_id;
opaque dtls_message<1..2^16-1>; opaque dtls_message<1..2^16-1>;
} TunneledDtls; } TunneledDtls;
The fields are described as follows: The fields are described as follows:
* "association_id": A value that identifies a distinct DTLS association_id: a value that identifies a distinct DTLS association
association between an endpoint and the Key Distributor. between an endpoint and the Key Distributor.
* "dtls_message": the content of the DTLS message received by the dtls_message: the content of the DTLS message received by the
endpoint or to be sent to the endpoint. This includes one or more endpoint or to be sent to the endpoint, including one or more
complete DTLS records. complete DTLS records.
6.6. EndpointDisconnect Message 6.6. EndpointDisconnect Message
The "EndpointDisconnect" message is defined as: The EndpointDisconnect message is defined as:
struct { struct {
uuid association_id; uuid association_id;
} EndpointDisconnect; } EndpointDisconnect;
The fields are described as follows: The field is described as follows:
* "association_id": An value that identifies a distinct DTLS association_id: a value that identifies a distinct DTLS association
association between an endpoint and the Key Distributor. between an endpoint and the Key Distributor.
7. Example Binary Encoding 7. Example Binary Encoding
The "TunnelMessage" is encoded in binary following the procedures The TunnelMessage is encoded in binary, following the procedures
specified in [RFC8446]. This section provides an example of what the specified in [RFC8446]. This section provides an example of what the
bits on the wire would look like for the "SupportedProfiles" message bits on the wire would look like for the SupportedProfiles message
that advertises support for both that advertises support for both
"DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
"DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723].
TunnelMessage: TunnelMessage:
message_type: 0x01 message_type: 0x01
length: 0x0007 length: 0x0007
SupportedProfiles: SupportedProfiles:
version: 0x00 version: 0x00
protection_profiles: 0x0004 (length) protection_profiles: 0x0004 (length)
0x0009000A (value) 0x0009000A (value)
Thus, the encoding on the wire presented here in network bytes order Thus, the encoding on the wire, presented here in network byte order,
would be this stream of octets: would be this stream of octets:
0x0100070000040009000A 0x0100070000040009000A
8. IANA Considerations 8. IANA Considerations
This document establishes a new registry to contain message type This document establishes the "Datagram Transport Layer Security
values used in the DTLS Tunnel protocol. These message type values (DTLS) Tunnel Protocol Message Types for Privacy Enhanced
are a single octet in length. This document defines the values shown Conferencing" registry to contain message type values used in the
in Table 1 below, leaving the balance of possible values reserved for DTLS tunnel protocol. These message type values are a single octet
future specifications: in length. This document defines the values shown in Table 1 below,
leaving the balance of possible values reserved for future
specifications:
+=========+====================================+ +=========+====================================+
| MsgType | Description | | MsgType | Description |
+=========+====================================+ +=========+====================================+
| 0x01 | Supported SRTP Protection Profiles | | 0x01 | Supported SRTP Protection Profiles |
+---------+------------------------------------+ +---------+------------------------------------+
| 0x02 | Unsupported Version | | 0x02 | Unsupported Version |
+---------+------------------------------------+ +---------+------------------------------------+
| 0x03 | Media Keys | | 0x03 | Media Keys |
+---------+------------------------------------+ +---------+------------------------------------+
| 0x04 | Tunneled DTLS | | 0x04 | Tunneled DTLS |
+---------+------------------------------------+ +---------+------------------------------------+
| 0x05 | Endpoint Disconnect | | 0x05 | Endpoint Disconnect |
+---------+------------------------------------+ +---------+------------------------------------+
Table 1: Message Type Values for the DTLS Table 1: Message Type Values for the DTLS
Tunnel Protocol Tunnel Protocol
The value 0x00 is reserved and all values in the range 0x06 to 0xFF The value 0x00 is reserved, and all values in the range 0x06 to 0xFF
are available for allocation. The procedures for updating this table are available for allocation. The procedures for updating this table
are those defined as "IETF Review" in section 4.8 of [RFC8126]. are those defined as "IETF Review" in Section 4.8 of [RFC8126].
The name for this registry is "Datagram Transport Layer Security
(DTLS) Tunnel Protocol Message Types for Privacy Enhanced
Conferencing".
9. Security Considerations 9. Security Considerations
Since the procedures in this document relies on TLS [RFC8446] for Since the procedures in this document rely on TLS [RFC8446] for
transport security, the security considerations for TLS should be transport security, the security considerations for TLS should be
reviewed when implementing the protocol defined in this document. reviewed when implementing the protocol defined in this document.
While the tunneling protocol defined in this document does not use While the tunneling protocol defined in this document does not use
DTLS-SRTP [RFC5764] directly, it does convey and negotiate some of DTLS-SRTP [RFC5764] directly, it does convey and negotiate some of
the same information (e.g., protection profile data). As such, a the same information (e.g., protection profile data). As such, a
review of the security considerations found in that document may be review of the security considerations found in that document may be
useful. useful.
This document describes a means of securely exchanging keying This document describes a means of securely exchanging keying
material and cryptographic transforms for both E2E and HBH encryption material and cryptographic transforms for both E2E and HBH encryption
and authentication of media between an endpoint and a Key Distributor and authentication of media between an endpoint and a Key Distributor
via a Media Distributor. Additionally, the procedures result in via a Media Distributor. Additionally, the procedures result in
delivering HBH information to the intermediary Media Distributor. delivering HBH information to the intermediary Media Distributor.
The Key Distributor and endpoint are the only two entities with The Key Distributor and endpoint are the only two entities with
access to both the E2E and HBH keys, while the Media Distributor has access to both the E2E and HBH keys, while the Media Distributor has
access to only HBH information. Section 8.2 of [RFC8871] enumerates access to only HBH information. Section 8.2 of [RFC8871] enumerates
various attacks against which one must guard when implementing a various attacks against which one must guard when implementing a
Media Distributor and are important to note. Media Distributor; these scenarios are important to note.
A requirement in this document is that a TLS connection between the A requirement in this document is that a TLS connection between the
Media Distributor and the Key Distributor be mutually authenticated. Media Distributor and the Key Distributor be mutually authenticated.
The reason for this requirement is to ensure that only an authorized The reason for this requirement is to ensure that only an authorized
Media Distributor receives the HBH keying material. If an Media Distributor receives the HBH keying material. If an
unauthorized Media Distributor gains access to the HBH keying unauthorized Media Distributor gains access to the HBH keying
material, it can easily cause service degradation or denial by material, it can easily cause service degradation or denial by
transmitting HBH-valid packets that ultimately fail E2E transmitting HBH-valid packets that ultimately fail E2E
authentication or replay protection checks (see Section 3.3.2 of authentication or replay protection checks (see Section 3.3.2 of
[RFC3711]). Even if service does not appear degraded in any way, [RFC3711]). Even if service does not appear degraded in any way,
transmitting and processing bogus packets are a waste of both transmitting and processing bogus packets are a waste of both
computational and network resources. computational and network resources.
The procedures defined in this document assume that the Media The procedures defined in this document assume that the Media
Distributor will properly convey DTLS messages between the endpoint Distributor will properly convey DTLS messages between the endpoint
and Key Distributor. Should it fail in that responsibility by and Key Distributor. Should it fail in that responsibility by
forwarding DTLS messages from endpoint A advertised as being from forwarding DTLS messages from endpoint A advertised as being from
endpoint B, this will result in a failure at the DTLS layer those endpoint B, this will result in a failure at the DTLS layer of those
DTLS sessions. This could be an additional attack vector that Key DTLS sessions. This could be an additional attack vector that Key
Distributor implementations should consider. Distributor implementations should consider.
While E2E keying material passes through the Media Distributor via While E2E keying material passes through the Media Distributor via
the protocol defined in this document, the Media Distributor has no the protocol defined in this document, the Media Distributor has no
means of gaining access to that information and therefore cannot means of gaining access to that information and therefore cannot
affect the E2E media processing function in the endpoint except to affect the E2E media processing function in the endpoint except to
present it with invalid or replayed data. That said, any entity present it with invalid or replayed data. That said, any entity
along the path that interferes with the DTLS exchange between the along the path that interferes with the DTLS exchange between the
endpoint and the Key Distributor, including a malicious Media endpoint and the Key Distributor, including a malicious Media
Distributor that is not properly authorized, could prevent an Distributor that is not properly authorized, could prevent an
endpoint from properly communicating with the Key Distributor and, endpoint from properly communicating with the Key Distributor and
therefore, prevent successful conference participation. therefore prevent successful conference participation.
It is worth noting that a compromised Media Distributor can convey It is worth noting that a compromised Media Distributor can convey
information to an adversary such as participant IP addresses, information to an adversary, such as participant IP addresses,
negotiates protection profiles, or other metadata. While [RFC8871] negotiated protection profiles, or other metadata. While [RFC8871]
explains that a malicious or compromised Media Distributor can explains that a malicious or compromised Media Distributor can
disrupt communications, an additional attack vector introduced by disrupt communications, an additional attack vector introduced by
this protocol is the potential disruption of DTLS negotiation or this protocol is the potential disruption of DTLS negotiation or
premature removal of a participant from a conference by sending an premature removal of a participant from a conference by sending an
"EndpointDisconnect" disconnect message to the Key Distributor. EndpointDisconnect message to the Key Distributor.
The Key Distributor should be aware of the possibility that a The Key Distributor should be aware of the possibility that a
malicious Media Distributor might transmit an "EndpointDisconnect" malicious Media Distributor might transmit an EndpointDisconnect
message to the Key Distributor when the endpoint is, in fact, still message to the Key Distributor when the endpoint is in fact still
connected. connected.
While the Security Considerations section of [RFC8871] describes While the Security Considerations section of [RFC8871] describes
various attacks one needs to consider with respect to the Key various attacks one needs to consider with respect to the Key
Distributor and denial-of-service, use of this protocol introduces Distributor and denial of service, use of this protocol introduces
another possible attack vector. Consider the case where a malicious another possible attack vector. Consider the case where a malicious
endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor. endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor.
The Media Distributor will normally forward those messages to the Key The Media Distributor will normally forward those messages to the Key
Distributor and, if found invalid, such messages only serve to Distributor and, if found invalid, such messages only serve to
consume resources on both the Media Distributor and Key Distributor. consume resources on both the Media Distributor and Key Distributor.
10. Acknowledgments 10. References
The author would like to thank David Benham and Cullen Jennings for
reviewing this document and providing constructive comments.
11. Normative References
[I-D.ietf-tls-dtls13] 10.1. Normative References
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021,
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-43>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
skipping to change at page 18, line 21 skipping to change at line 805
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)", Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, January 2021, RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/info/rfc8844>. <https://www.rfc-editor.org/info/rfc8844>.
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy-Enhanced RTP Framework for Private Media in Privacy-Enhanced RTP
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
January 2021, <https://www.rfc-editor.org/info/rfc8871>. January 2021, <https://www.rfc-editor.org/info/rfc8871>.
12. Informative References [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
10.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
skipping to change at page 18, line 43 skipping to change at line 832
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
Acknowledgements
The authors would like to thank David Benham and Cullen Jennings for
reviewing this document and providing constructive comments.
Authors' Addresses Authors' Addresses
Paul E. Jones Paul E. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
United States of America United States of America
Phone: +1 919 476 2048 Phone: +1 919 476 2048
Email: paulej@packetizer.com Email: paulej@packetizer.com
Paul M. Ellenbogen Paul M. Ellenbogen
Princeton University Princeton University
Phone: +1 206 851 2069 Phone: +1 206 851 2069
Email: pe5@cs.princeton.edu Email: pe5@cs.princeton.edu
Nils H. Ohlmeier Nils H. Ohlmeier
8x8, Inc. 8x8, Inc.
Phone: +1 408 659 6457 Phone: +1 408 659 6457
Email: nils@ohlmeier.org Email: nils@ohlmeier.org
 End of changes. 106 change blocks. 
240 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/