draft-ietf-perc-dtls-tunnel-06.txt   draft-ietf-perc-dtls-tunnel-07.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track P. Ellenbogen Intended status: Informational P. Ellenbogen
Expires: April 19, 2020 Princeton University Expires: August 14, 2021 Princeton University
N. Ohlmeier N. Ohlmeier
Mozilla Mozilla
October 17, 2019 February 10, 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-06 draft-ietf-perc-dtls-tunnel-07
Abstract Abstract
This document defines a DTLS tunneling protocol for use in multimedia This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor. exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor. and authentication is inaccessible to the media distributor.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 19, 2020. This Internet-Draft will expire on August 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . 9 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 9
6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10
6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10 6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10
7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is
that endpoints in a multimedia conference have access to the end-to- to ensure that endpoints in a multimedia conference have access to
end (E2E) and hop-by-hop (HBH) keying material used to encrypt and the end-to-end (E2E) and hop-by-hop (HBH) keying material used to
authenticate Real-time Transport Protocol (RTP) [RFC3550] packets, encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550]
while the Media Distributor has access only to the hop-by-hop (HBH) packets, while the Media Distributor has access only to the hop-by-
keying material for encryption and authentication. hop (HBH) 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 [RFC6347] messages between an media distributor to tunnel DTLS [RFC6347] messages between an
endpoint and the key distributor, thus allowing an endpoint to use endpoint and the key distributor, thus allowing an endpoint to use
DTLS-SRTP [RFC5764] for establishing encryption and authentication DTLS-SRTP [RFC5764] for establishing encryption and authentication
keys with the key distributor. 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 connection that is established before any distributor is a TLS connection that is established before any
messages are forwarded by the media distributor on behalf of the messages are forwarded by the media distributor on behalf of the
skipping to change at page 5, line 29 skipping to change at page 5, line 29
.... may be multiple handshake messages ... .... may be multiple handshake messages ...
| | | | | |
|<------------------------|<========================| |<------------------------|<========================|
| DTLS handshake message | TunneledDtls | | DTLS handshake message | TunneledDtls |
| | | | | |
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 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
to select a common profile supported by both the endpoint and the to select a common profile supported by both the endpoint and the
media distributor to ensure that hop-by-hop operations can be media distributor to ensure that hop-by-hop operations can be
successfully performed. successfully 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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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 the "sdp_tls_id" DTLS extension The endpoint MUST include a unique identifier in the "tls-id" SDP
[I-D.thomson-mmusic-sdp-uks] in the "ClientHello" message when [RFC4566] attribute sent by the endpoint in both offer and answer
establishing a DTLS association. Likewise, the "tls-id" SDP [RFC3264] messages as per [I-D.ietf-mmusic-dtls-sdp]. Further, the
[RFC4566] attribute MUST be included in SDP sent by the endpoint in endpoint MUST include this same unique identifier in the
both the offer and answer [RFC3264] messages as per "external_session_id" DTLS extension [I-D.ietf-mmusic-sdp-uks] in the
[I-D.ietf-mmusic-dtls-sdp]. "ClientHello" message when establishing a DTLS association.
When receiving a "tls_id" value from the key distributor, the client When receiving a "external_session_id" value from the key
MUST check to ensure that value matches the "tls-id" value received distributor, the client MUST check to ensure that value matches the
in SDP. If the values do not match, the endpoint MUST consider any "tls-id" value received in SDP. If the values do not match, the
received keying material to be invalid and terminate the DTLS endpoint MUST consider any received keying material to be invalid and
association. terminate the 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 8, line 33 skipping to change at page 8, line 33
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 "tls_id" value transmitted in the "ClientHello" MUST extract the "external_session_id" value transmitted in the
message and match that against "tls-id" value the endpoint "ClientHello" message and match that against "tls-id" value the
transmitted via SDP. If the values in SDP and the "ClientHello" do endpoint transmitted via SDP. If the values in SDP and the
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 correlate the certificate fingerprint and The key distributor MUST correlate the certificate fingerprint and
"tls_id" received from endpoint's "ClientHello" message with the "external_session_id" received from endpoint's "ClientHello" message
corresponding values received from the SDP transmitted by the with the corresponding values received from the SDP transmitted by
endpoint. It is through this correlation that the key distributor the endpoint. It is through this correlation that the key
can be sure to deliver the correct conference key to the endpoint. distributor can be sure to deliver the correct conference key to the
endpoint.
When sending the "ServerHello" message, the key distributor MUST When sending the "ServerHello" message, the key distributor MUST
insert its own "tls_id" value in the "sdp_tls_id" extension. This insert its own unique identifier in the "external_session_id"
value MUST also be conveyed back to the client via SDP as a "tls-id" extension. This value MUST also be conveyed back to the client via
attribute. 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 a given DTLS distributor is not required to transmit all messages 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 a media distributor. established between it and a 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
skipping to change at page 9, line 33 skipping to change at page 9, line 33
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 the HBH encryption key is computed and before distributor as soon as the HBH encryption key is computed and before
it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" it sends a DTLS "Finished" message to the endpoint. The "MediaKeys"
message includes the selected cipher (i.e. protection profile), MKI message includes the selected cipher (i.e. protection profile), MKI
[RFC3711] value (if any), SRTP master keys, and SRTP master salt [RFC3711] value (if any), SRTP master keys, and SRTP master salt
values. The key distributor MUST use the same association identifier values. The key distributor MUST use the same association identifier
in the "MediaKeys" message as is used in the "TunneledDtls" messages in the "MediaKeys" message as is used in the "TunneledDtls" messages
for the given endpoint. for the given endpoint.
The key distributor uses the certificate fingerprint of the endpoint The key distributor uses the certificate fingerprint of the endpoint
along with the "tls_id" value received in the "sdp_tls_id" extension along with the unique identifier received in the
to determine which conference a given DTLS association is associated. "external_session_id" extension to determine which conference a given
DTLS association is associated.
The key distributor MUST select a cipher that is supported by both The key distributor MUST select a cipher that is supported by both
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.
skipping to change at page 13, line 30 skipping to change at page 13, line 30
o association_id: An value that identifies a distinct DTLS o association_id: An value that identifies a distinct DTLS
association between an endpoint and the key distributor. association 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 [RFC5246]. This section provides an example of what the specified in [RFC5246]. 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 [I-D.ietf-perc-double]. DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723].
RFC Editor Note: Please replace the values 0009 and 000A in the
following two examples with whatever code points IANA assigned for
DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and
DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.
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 bytes order
skipping to change at page 15, line 11 skipping to change at page 15, line 4
the cryptographic algorithms supported by the media distributor. the cryptographic algorithms supported by the media distributor.
Further, it is still protected by the TLS connection between the Further, it is still protected by the TLS connection between the
media distributor and the key distributor. media distributor and the 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. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol 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)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.thomson-mmusic-sdp-uks] [I-D.ietf-mmusic-sdp-uks]
Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
uses of Transport Layer Security with the Session uses of TLS with the Session Description Protocol (SDP)",
Description Protocol (SDP)", draft-thomson-mmusic-sdp- draft-ietf-mmusic-sdp-uks-07 (work in progress), August
uks-00 (work in progress), April 2017. 2019.
[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 [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>.
skipping to change at page 16, line 20 skipping to change at page 16, line 15
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
11.2. Informative References [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>.
[I-D.ietf-perc-double] 11.2. Informative References
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Double Encryption Procedures", draft-ietf-perc-double-12
(work in progress), August 2019.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC8723] Jennings, C., Jones, P., Barnes, R., and A. 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>.
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
USA USA
Phone: +1 919 476 2048 Phone: +1 919 476 2048
Email: paulej@packetizer.com Email: paulej@packetizer.com
 End of changes. 22 change blocks. 
56 lines changed or deleted 57 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/