--- 1/draft-ietf-perc-dtls-tunnel-10.txt 2021-10-25 10:13:32.427365816 -0700 +++ 2/draft-ietf-perc-dtls-tunnel-11.txt 2021-10-25 10:13:32.471366916 -0700 @@ -1,22 +1,22 @@ Network Working Group P. Jones Internet-Draft Cisco Systems Intended status: Informational P. Ellenbogen -Expires: 28 March 2022 Princeton University +Expires: 28 April 2022 Princeton University N. Ohlmeier 8x8, Inc. - 24 September 2021 + 25 October 2021 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange - draft-ietf-perc-dtls-tunnel-10 + draft-ietf-perc-dtls-tunnel-11 Abstract This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the @@ -30,21 +30,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 March 2022. + This Internet-Draft will expire on 28 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -59,50 +59,48 @@ 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 4 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 10 + 6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 11 6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11 6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12 6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12 6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13 6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13 - 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 + 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 - 12. Informative References . . . . . . . . . . . . . . . . . . . 17 + 12. Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is to ensure that endpoints in a multimedia conference have access to the end-to-end (E2E) and hop-by-hop (HBH) keying material used to encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] packets, while the Media Distributor has access only to the HBH 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 - Media Distributor to tunnel DTLS [RFC6347] messages between an - endpoint and a Key Distributor, thus allowing an endpoint to use - DTLS-SRTP [RFC5764] for establishing encryption and authentication - keys with the Key Distributor. + Media Distributor to tunnel DTLS [I-D.ietf-tls-dtls13] messages + between an endpoint and a Key Distributor, thus allowing an endpoint + to use DTLS-SRTP [RFC5764] for establishing encryption and + authentication keys with the Key Distributor. The tunnel established between the Media Distributor and Key Distributor is a TLS [RFC8446] connection that is established before any messages are forwarded by the Media Distributor on behalf of endpoints. DTLS packets received from an endpoint are encapsulated by the Media Distributor inside this tunnel as data to be sent to the Key Distributor. Likewise, when the Media Distributor receives data from the Key Distributor over the tunnel, it extracts the DTLS message inside and forwards the DTLS message to the endpoint. In this way, the DTLS association for the DTLS-SRTP procedures is @@ -197,28 +195,28 @@ | | | | |<=======================>| | | TLS Connection Made | | | | | |========================>| | | SupportedProfiles | | | | |------------------------>|========================>| | DTLS handshake message | TunneledDtls | | | | - | |<========================| - | | MediaKeys | - | | | .... may be multiple handshake messages ... | | | |<------------------------|<========================| | DTLS handshake message | TunneledDtls | | | | + | | | + | |<========================| + | | MediaKeys | Figure 2: Sample DTLS-SRTP Exchange via the Tunnel After the initial TLS connection has been established each of the messages on the right-hand side of Figure 2 is a tunneling protocol message as defined in Section 6. SRTP protection profiles supported by the Media Distributor will be sent in a "SupportedProfiles" message when the TLS tunnel is initially established. The Key Distributor will use that information @@ -238,36 +236,36 @@ message. The Media Distributor will extract this keying material from the "MediaKeys" message when received and use it for HBH encryption and authentication. 5. Tunneling Procedures The following sub-sections explain in detail the expected behavior of the endpoint, the Media Distributor, and the Key Distributor. It is important to note that the tunneling protocol described in this - document is not an extension to TLS [RFC8446] or DTLS [RFC6347]. - Rather, it is a protocol that transports DTLS messages generated by - an endpoint or Key Distributor as data inside of the TLS connection - established between the Media Distributor and Key Distributor. + document is not an extension to TLS or DTLS. Rather, it is a + protocol that transports DTLS messages generated by an endpoint or + Key Distributor as data inside of the TLS connection established + between the Media Distributor and Key Distributor. 5.1. Endpoint Procedures The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] in order to establish the cipher and keys used for encryption and authentication, with the endpoint acting as the client and the Key Distributor acting as the server. The endpoint does not need to be aware of the fact that DTLS messages it transmits toward the Media Distributor are being tunneled to the Key Distributor. 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 this same unique identifier in the "external_session_id" extension [RFC8844] in the "ClientHello" message when establishing a DTLS association. When receiving a "external_session_id" value from the Key Distributor, the client MUST check to ensure that value matches 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 terminate the DTLS association. @@ -363,58 +361,67 @@ When processing an incoming endpoint association, the Key Distributor MUST extract the "external_session_id" value transmitted in the "ClientHello" message and match that against the "tls-id" value the endpoint transmitted via SDP. If the values in SDP and the "ClientHello" do not match, the DTLS association MUST be rejected. The process through which the "tls-id" in SDP is conveyed to the Key Distributor is outside the scope of this document. - The Key Distributor MUST match the certificate fingerprint [RFC4572] - and "external_session_id" received from endpoint's "ClientHello" - message with the values received from the SDP transmitted by the - endpoint [RFC8122]. It is through this process that the Key + The Key Distributor MUST match the certificate fingerprint and + "external_session_id" [RFC8844] received from endpoint via DTLS with + the expected fingerprint [RFC8122] and "tls-id" [RFC8842] values + received via SDP. It is through this process that the Key Distributor can be sure to deliver the correct conference key to the endpoint. - When sending the "ServerHello" message, the Key Distributor MUST - insert its own unique identifier in the "external_session_id" - extension. This value MUST also be conveyed back to the client via - SDP as a "tls-id" attribute. + The Key Distributor MUST report its own unique identifier in the + "external_session_id" extension. This extension is sent in the + "EncryptedExtensions" message in DTLS 1.3, and the "ServerHello" in + 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 endpoint inside a "TunneledDtls" message (see Section 6). The Key Distributor is not required to transmit all messages for a given DTLS association through the same tunnel if more than one tunnel has been established between it and the Media Distributor. The Key Distributor MUST use the same association identifier in messages sent to an endpoint as was received in messages from that endpoint. This ensures the Media Distributor can forward the messages to the correct endpoint. The Key Distributor extracts tunneled DTLS messages from an endpoint and acts on those messages as if that endpoint had established the DTLS association directly with the Key Distributor. The Key Distributor is acting as the DTLS server and the endpoint is acting as the DTLS client. The handling of the messages and certificates is exactly the same as normal DTLS-SRTP procedures between endpoints. 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 - profile), MKI [RFC3711] value (if any), SRTP master keys, and SRTP - master salt values. The Key Distributor MUST use the same + profile), MKI [RFC3711] value (if any), HBH SRTP master keys, and + SRTP master salt values. The Key Distributor MUST use the same association identifier in the "MediaKeys" message as is used in the "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 along with the unique identifier received in the "external_session_id" extension to determine which conference a given DTLS association is associated. The Key Distributor MUST select a cipher that is supported itself, the endpoint, and the Media Distributor to ensure proper HBH operations. When the DTLS association between the endpoint and the Key @@ -572,30 +579,31 @@ * "server_write_SRTP_master_salt": The value of the SRTP master salt used by the server (Media Distributor). 6.5. TunneledDtls Message The "TunneledDtls" message is defined as: struct { uuid association_id; - opaque dtls_message<0..2^16-1>; + opaque dtls_message<1..2^16-1>; } TunneledDtls; The fields are described as follows: * "association_id": A value that identifies a distinct DTLS association between an endpoint and the Key Distributor. * "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 The "EndpointDisconnect" message is defined as: struct { uuid association_id; } EndpointDisconnect; The fields are described as follows: @@ -658,21 +666,21 @@ (DTLS) Tunnel Protocol Message Types for Privacy Enhanced Conferencing". 9. Security Considerations Since the procedures in this document relies on TLS [RFC8446] for transport security, the security considerations for TLS should be reviewed when implementing the protocol defined in this document. 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 review of the security considerations found in that document may be useful. This document describes a means of securely exchanging keying material and cryptographic transforms for both E2E and HBH encryption and authentication of media between an endpoint and a Key Distributor via a Media Distributor. Additionally, the procedures result in delivering HBH information to the intermediary Media Distributor. The Key Distributor and endpoint are the only two entities with @@ -686,31 +694,48 @@ The reason for this requirement is to ensure that only an authorized Media Distributor receives the HBH keying material. If an unauthorized Media Distributor gains access to the HBH keying material, it can easily cause service degradation or denial by transmitting HBH-valid packets that ultimately fail E2E authentication or replay protection checks (see Section 3.3.2 of [RFC3711]). Even if service does not appear degraded in any way, transmitting and processing bogus packets are a waste of both 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 the protocol defined in this document, the Media Distributor has no means of gaining access to that information and therefore cannot affect the E2E media processing function in the endpoint except to present it with invalid or replayed data. That said, any entity along the path that interferes with the DTLS exchange between the endpoint and the Key Distributor, including a malicious Media Distributor that is not properly authorized, could prevent an endpoint from properly communicating with the Key Distributor and, 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 malicious Media Distributor might transmit an "EndpointDisconnect" message to the Key Distributor when the endpoint is, in fact, still connected. While the Security Considerations section of [RFC8871] describes various attacks one needs to consider with respect to the Key Distributor and denial-of-service, use of this protocol introduces another possible attack vector. Consider the case where a malicious endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor. @@ -718,107 +743,105 @@ Distributor and, if found invalid, such messages only serve to consume resources on both the Media Distributor and Key Distributor. 10. Acknowledgments 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] + 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, + . + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model - with Session Description Protocol (SDP)", RFC 3264, - DOI 10.17487/RFC3264, June 2002, - . - - [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, . + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session - Description Protocol", RFC 4566, DOI 10.17487/RFC4566, - July 2006, . - - [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, - . - [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . - [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, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . + [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, + . + [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, . [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)", RFC 8844, DOI 10.17487/RFC8844, January 2021, . + [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, . + 12. Informative References - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + . - [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer - Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, - January 2012, . + [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, . - [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, - . + [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, + . - [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, . + [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: + Session Description Protocol", RFC 8866, + DOI 10.17487/RFC8866, January 2021, + . Authors' Addresses Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 United States of America Phone: +1 919 476 2048