draft-ietf-perc-dtls-tunnel-10.txt   draft-ietf-perc-dtls-tunnel-11.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational P. Ellenbogen Intended status: Informational P. Ellenbogen
Expires: 28 March 2022 Princeton University Expires: 28 April 2022 Princeton University
N. Ohlmeier N. Ohlmeier
8x8, Inc. 8x8, Inc.
24 September 2021 25 October 2021
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-10 draft-ietf-perc-dtls-tunnel-11
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 4 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 4
4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4
5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6
5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6
5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6
5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7 5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7
5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8
5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10
6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10
6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 10 6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 11
6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11 6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11
6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12 6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12
6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12 6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12
6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13 6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13
6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13 6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13
7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . 17 12. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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) [RFC3550]
packets, while the Media Distributor has access only to the HBH packets, while the Media Distributor has access only to the HBH
keying material for encryption and authentication. keying material for encryption and authentication.
[RFC EDITOR: References to RFC 6347 can be changed to the RFC for
DTLS 1.3 if available.]
This specification defines a tunneling protocol that enables the This specification defines a tunneling protocol that enables the
Media Distributor to tunnel DTLS [RFC6347] messages between an Media Distributor to tunnel DTLS [I-D.ietf-tls-dtls13] messages
endpoint and a Key Distributor, thus allowing an endpoint to use between an endpoint and a Key Distributor, thus allowing an endpoint
DTLS-SRTP [RFC5764] for establishing encryption and authentication to use DTLS-SRTP [RFC5764] for establishing encryption and
keys with the Key Distributor. 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 [RFC8446] connection 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
skipping to change at page 5, line 21 skipping to change at page 5, line 21
| | | | | |
| |<=======================>| | |<=======================>|
| | TLS Connection Made | | | TLS Connection Made |
| | | | | |
| |========================>| | |========================>|
| | SupportedProfiles | | | SupportedProfiles |
| | | | | |
|------------------------>|========================>| |------------------------>|========================>|
| DTLS handshake message | TunneledDtls | | DTLS handshake message | TunneledDtls |
| | | | | |
| |<========================|
| | MediaKeys |
| | |
.... may be multiple handshake messages ... .... may be multiple handshake messages ...
| | | | | |
|<------------------------|<========================| |<------------------------|<========================|
| DTLS handshake message | TunneledDtls | | DTLS handshake message | TunneledDtls |
| | | | | |
| | |
| |<========================|
| | 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 established. The Key Distributor will use that information initially established. The Key Distributor will use that information
skipping to change at page 6, line 17 skipping to change at page 6, line 17
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 sub-sections 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 [RFC8446] or DTLS [RFC6347]. document is not an extension to TLS or DTLS. Rather, it is a
Rather, it is a protocol that transports DTLS messages generated by protocol that transports DTLS messages generated by an endpoint or
an endpoint or Key Distributor as data inside of the TLS connection Key Distributor as data inside of the TLS connection established
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" SDP
[RFC4566] attribute in all offer and answer messages [RFC3264] that [RFC8866] attribute in all offer and answer messages [RFC3264] that
it generates as per [RFC8842]. Further, the endpoint MUST include it generates as per [RFC8842]. Further, the endpoint MUST include
this same unique identifier in the "external_session_id" extension this same unique identifier in the "external_session_id" extension
[RFC8844] in the "ClientHello" message when establishing a DTLS [RFC8844] in the "ClientHello" message when establishing a DTLS
association. association.
When receiving a "external_session_id" value from the Key When receiving a "external_session_id" value from the Key
Distributor, the client MUST check to ensure that value matches the Distributor, the client MUST check to ensure that value matches the
"tls-id" value received in SDP. If the values do not match, the "tls-id" value received in SDP. If the values do not match, the
endpoint MUST consider any received keying material to be invalid and endpoint MUST consider any received keying material to be invalid and
terminate the DTLS association. terminate the DTLS association.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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" 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" in SDP is conveyed to the Key
Distributor is outside the scope of this document. Distributor is outside the scope of this document.
The Key Distributor MUST match the certificate fingerprint [RFC4572] The Key Distributor MUST match the certificate fingerprint and
and "external_session_id" received from endpoint's "ClientHello" "external_session_id" [RFC8844] received from endpoint via DTLS with
message with the values received from the SDP transmitted by the the expected fingerprint [RFC8122] and "tls-id" [RFC8842] values
endpoint [RFC8122]. 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.
When sending the "ServerHello" message, the Key Distributor MUST The Key Distributor MUST report its own unique identifier in the
insert its own unique identifier in the "external_session_id" "external_session_id" extension. This extension is sent in the
extension. This value MUST also be conveyed back to the client via "EncryptedExtensions" message in DTLS 1.3, and the "ServerHello" in
SDP as a "tls-id" attribute. previous DTLS versions. This value MUST also be conveyed back to 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 as soon as a HBH encryption key is computed. 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), SRTP master keys, and SRTP profile), MKI [RFC3711] value (if any), HBH SRTP master keys, and
master salt values. The Key Distributor MUST use the same SRTP master salt values. The Key Distributor MUST use the same
association identifier in the "MediaKeys" message as is used in the association identifier in the "MediaKeys" message as is used in the
"TunneledDtls" messages for the given endpoint. "TunneledDtls" messages for the given endpoint.
There are presently two SRTP protection profiles defined for PERC,
namely "DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and
"DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. As [RFC8723]
explains in Section 5.2, the Media Distributor is only given the SRTP
master key for HBH operations. As such, the SRTP master key length
advertised in the "MediaKeys" message is half the length of the key
normally associated with 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" extension to determine which conference a given "external_session_id" extension to determine which conference a given
DTLS association is associated. DTLS association is associated.
The Key Distributor MUST select a cipher that is supported itself, The Key Distributor MUST select a cipher that is supported 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
skipping to change at page 13, line 17 skipping to change at page 13, line 29
* "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<0..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 between an endpoint and the Key Distributor. association 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. endpoint or to be sent to the endpoint. This includes one or more
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 fields are described as follows:
skipping to change at page 15, line 12 skipping to change at page 15, line 20
(DTLS) Tunnel Protocol Message Types for Privacy Enhanced (DTLS) Tunnel Protocol Message Types for Privacy Enhanced
Conferencing". Conferencing".
9. Security Considerations 9. Security Considerations
Since the procedures in this document relies on TLS [RFC8446] for Since the procedures in this document relies 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
skipping to change at page 15, line 40 skipping to change at page 16, line 5
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
Distributor will properly convey DTLS messages between the endpoint
and Key Distributor. Should it fail in that responsibility by
forwarding DTLS messages from endpoint A advertised as being from
endpoint B, this will result in a failure at the DTLS layer those
DTLS sessions. This could be an additional attack vector that Key
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
information to an adversary such as participant IP addresses,
negotiates protection profiles, or other metadata. While [RFC8871]
explains that a malicious or compromised Media Distributor can
disrupt communications, an additional attack vector introduced by
this protocol is the potential disruption of DTLS negotiation or
premature removal of a participant from a conference by sending an
"EndpointDisconnect" disconnect 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.
skipping to change at page 16, line 26 skipping to change at page 17, line 5
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. Acknowledgments
The author would like to thank David Benham and Cullen Jennings for The author would like to thank David Benham and Cullen Jennings for
reviewing this document and providing constructive comments. reviewing this document and providing constructive comments.
11. Normative References 11. Normative References
[I-D.ietf-tls-dtls13]
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>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
with Session Description Protocol (SDP)", RFC 3264, Norrman, "The Secure Real-time Transport Protocol (SRTP)",
DOI 10.17487/RFC3264, June 2002, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006,
<https://www.rfc-editor.org/info/rfc4572>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
"Double Encryption Procedures for the Secure Real-Time
Transport Protocol (SRTP)", RFC 8723,
DOI 10.17487/RFC8723, April 2020,
<https://www.rfc-editor.org/info/rfc8723>.
[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
RFC 8842, DOI 10.17487/RFC8842, January 2021, RFC 8842, DOI 10.17487/RFC8842, January 2021,
<https://www.rfc-editor.org/info/rfc8842>. <https://www.rfc-editor.org/info/rfc8842>.
[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
Framework for Private Media in Privacy-Enhanced RTP
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
January 2021, <https://www.rfc-editor.org/info/rfc8871>.
12. Informative References 12. Informative References
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Norrman, "The Secure Real-time Transport Protocol (SRTP)", with Session Description Protocol (SDP)", RFC 3264,
RFC 3711, DOI 10.17487/RFC3711, March 2004, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Jacobson, "RTP: A Transport Protocol for Real-Time
January 2012, <https://www.rfc-editor.org/info/rfc6347>. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
"Double Encryption Procedures for the Secure Real-Time Writing an IANA Considerations Section in RFCs", BCP 26,
Transport Protocol (SRTP)", RFC 8723, RFC 8126, DOI 10.17487/RFC8126, June 2017,
DOI 10.17487/RFC8723, April 2020, <https://www.rfc-editor.org/info/rfc8126>.
<https://www.rfc-editor.org/info/rfc8723>.
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Framework for Private Media in Privacy-Enhanced RTP Session Description Protocol", RFC 8866,
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, DOI 10.17487/RFC8866, January 2021,
January 2021, <https://www.rfc-editor.org/info/rfc8871>. <https://www.rfc-editor.org/info/rfc8866>.
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
 End of changes. 33 change blocks. 
75 lines changed or deleted 98 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/