--- 1/draft-ietf-perc-dtls-tunnel-00.txt 2017-04-28 09:13:13.639244853 -0700 +++ 2/draft-ietf-perc-dtls-tunnel-01.txt 2017-04-28 09:13:13.675245719 -0700 @@ -1,22 +1,22 @@ Network Working Group P. Jones Internet-Draft Cisco Systems Intended status: Standards Track P. Ellenbogen -Expires: September 13, 2017 Princeton University +Expires: October 30, 2017 Princeton University N. Ohlmeier Mozilla - March 12, 2017 + April 28, 2017 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange - draft-ietf-perc-dtls-tunnel-00 + draft-ietf-perc-dtls-tunnel-01 Abstract This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor. @@ -29,21 +29,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 http://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 September 13, 2017. + This Internet-Draft will expire on October 30, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,33 +55,33 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 - 5.3. Versioning Considerations . . . . . . . . . . . . . . . . 7 - 5.4. Media Distributor Tunneling Procedures . . . . . . . . . 7 - 5.5. Key Distributor Tunneling Procedures . . . . . . . . . . 9 + 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. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 11.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + 11.2. Informative References . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction An objective of Privacy-Enhanced RTP Conferencing (PERC) 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 hop-by-hop (HBH) keying material for encryption and authentication. @@ -242,20 +242,33 @@ 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 the "sdp_tls_id" DTLS extension + [I-D.thomson-mmusic-sdp-uks] in the "ClientHello" message when + establishing a DTLS association. Likewise, the "tls-id" SDP + [RFC4566] attribute MUST be included in SDP sent by the endpoint in + both the offer and answer [RFC3264] messages as per + [I-D.ietf-mmusic-dtls-sdp]. + + When receiving a "tls_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. + 5.2. Tunnel Establishment Procedures Either the media distributor or key distributor initiates the establishment of a TLS tunnel. Which entity acts as the TLS client when establishing the tunnel and what event triggers the establishment of the tunnel are outside the scope of this document. Further, how the trust relationships are established between the key distributor and media distributor are also outside the scope of this document. @@ -267,97 +280,46 @@ to the media distributor receiving a DTLS message from an endpoint. A single tunnel MAY be used to relay DTLS messages between any number of endpoints and the key distributor. A media distributor MAY have more than one tunnel established between itself and one or more key distributors. When multiple tunnels are established, which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document. -5.3. Versioning Considerations - - All messages for an established tunnel MUST utilize the same version - value. If the version of any subsequent message differs from that of - the initial message, that message MUST be discarded and the tunnel - connection closed. - - Since the media distributor sends the first message over the tunnel, - it effectively establishes the version of the protocol to be used. - If that version is not supported by the key distributor, it MUST - discard the message, transmit an "UnsupportedVersion" message, and - close the TLS connection. - - The media distributor MUST take note of the version received in an - "UnsupportedVersion" message and use that version when attempting to - re-establish a failed tunnel connection. Note that it is not - necessary for the media distributor to understand the newer version - of the protocol to understand that the first message received is - "UnsupportedVersion". The media distributor can determine from the - first two octets received what the version number is and that the - message is "UnsupportedVersion". The rest of the data received, if - any, would be discarded and the connection closed (if not already - closed). - -5.4. Media Distributor Tunneling Procedures +5.3. Media Distributor Tunneling Procedures The first message transmitted over the tunnel is the "SupportedProfiles" (see Section 6). This message informs the key distributor about which DTLS-SRTP profiles the media distributor supports. This message MUST be sent each time a new tunnel connection is established or, in the case of connection loss, when a - connection is re-established. - - The media distributor MUST forward all messages received from an - endpoint for a given DTLS association through the same tunnel if more - than one tunnel has been established between it and a key - distributor. - - Editor's Note: Do we want to have the above requirement or would - we prefer to allow the media distributor to send messages over - more than one tunnel to more than one key distributor? The latter - would provide for higher availability, but at the cost of key - distributor complexity. The former would allow the usage of a - load distributor in front of the key distributor. + connection is re-established. The media distributor MUST support the + same list of protection profiles for the duration of any endpoint- + initiated DTLS association and tunnel connection. The media distributor MUST assign a unique association identifier for each endpoint-initiated DTLS association and include it in all messages forwarded to the key distributor. The key distributor will subsequently include this identifier in all messages it sends so that the media distributor can map messages received via a tunnel and forward those messages to the correct endpoint. The association - identifier SHOULD be randomly assigned and values not be re-used for - a short period of time (e.g., five minutes) to ensure any residual - state in the key distributor is clear and to ensure any packets - already transmitted from the key distributor are not directed to the - wrong endpoint. - - The tunnel protocol enables the key distributor to separately provide - HBH keying material to the media distributor for each of the - individual endpoint DTLS associations, though the media distributor - cannot decrypt messages between the key distributor and endpoints. + identifier MUST be randomly assigned UUID [RFC4122] value. When a DTLS message is received by the media distributor from an endpoint, it forwards the UDP payload portion of that message to the - key distributor encapsulated in a "TuneledDtls" message. If the - media distributor knows the conference to which a given DTLS - association belongs, it can pass the conference identifier to the key - distributor using the "conf_id" field of the "TunneledDtls" message. - - Editor's Note: if the PERC WG adopts the "dtls-id" concept - presented in [I-D.jones-tls-perc-dtls-id], we can remove "conf_id" - from this draft, since the "dtls-id" can convey enough information - for the key distributor to determine the correct conference. - - The media distributor MUST support the same list of protection - profiles for the life of a given endpoint's DTLS association, which - is represented by the association identifier. + key distributor encapsulated in a "TuneledDtls" message. The media + distributor is not required to forward all messages received from an + endpoint for a given DTLS association through the same tunnel if more + than one tunnel has been established between it and a key + distributor. When a "MediaKeys" message is received, the media distributor MUST extract the cipher and keying material conveyed in order to subsequently perform HBH encryption and authentication operations for RTP and RTCP packets sent between it and an endpoint. Since the HBH keying material will be different for each endpoint, the media distributor uses the association identifier included by the key distributor to ensure that the HBH keying material is used with the correct endpoint. @@ -369,31 +331,63 @@ when it receives conference control messages indicating the endpoint is to be disconnected, the media distributors MUST send an "EndpointDisconnect" message with the association identifier assigned to the endpoint to the key distributor. The media distributor SHOULD take a loss of all RTP and RTCP packets as an indicator that the endpoint has disconnected. The particulars of how RTP and RTCP are to be used to detect an endpoint disconnect, such as timeout period, is not specified. The media distributor MAY use additional indicators to determine when an endpoint has disconnected. -5.5. Key Distributor Tunneling Procedures +5.4. Key Distributor Tunneling Procedures + + Each TLS tunnel established between the media distributor and the key + distributor MUST be mutually authenticated. When the media distributor relays a DTLS message from an endpoint, the media distributor will include an association identifier that is unique per endpoint-originated DTLS association. The association identifier remains constant for the life of the DTLS association. The key distributor identifies each distinct endpoint-originated DTLS association by the association identifier. + When processing an incoming endpoint association, the key distributor + MUST extract the "tls_id" value transmitted in the "ClientHello" + message and match that against "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. + + Editor's Note: The above can be removed if we agree that the media + distributor will always forward SDP to the key distributor. That + said, should the media server take on this function or should some + other call control function do this? The former assumes the media + distributor always has the SDP. + + The key distributor MUST correlate the certificate fingerprint and + "tls_id" received from endpoint's "ClientHello" message with the + corresponding values received from the SDP transmitted by the + endpoint. It is through this correlation 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 "tls_id" value in the "sdp_tls_id" extension. 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). + endpoint inside a "TunneledDtls" message (see Section 6). The key + distributor is not required to transmit all messages a given DTLS + association through the same tunnel if more than one tunnel has been + established between it and a 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 @@ -402,31 +396,56 @@ The key distributor MUST send a "MediaKeys" message to the media distributor as soon as the HBH encryption key is computed and before it sends a DTLS "Finished" message to the endpoint. 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 association identifier in the "MediaKeys" message as is used in the "TunneledDtls" messages for the given endpoint. - The key distributor, can use the certificate of the endpoint and - correlate that with signaling information to know which conference - this session is associated with. The key distributor informs the - media distributor of which conference this session is associated by - sending a globally unique conference identifier in the "conf_id" - attribute of the "MediaKeys". + The key distributor uses the certificate fingerprint of the endpoint + along with the "tls_id" value received in the "sdp_tls_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 endpoint and the media distributor to ensure proper HBH operations. + When the DTLS association between the endpoint and the key + distributor is terminated, regardless of which entity initiated the + termination, the key distributor MUST send an "EndpointDisconnect" + message with the association identifier assigned to the endpoint to + the media distributor. + +5.5. Versioning Considerations + + All messages for an established tunnel MUST utilize the same version + value. + + Since the media distributor sends the first message over the tunnel, + it effectively establishes the version of the protocol to be used. + If that version is not supported by the key distributor, it MUST + discard the message, transmit an "UnsupportedVersion" message, and + close the TLS connection. + + The media distributor MUST take note of the version received in an + "UnsupportedVersion" message and use that version when attempting to + re-establish a failed tunnel connection. Note that it is not + necessary for the media distributor to understand the newer version + of the protocol to understand that the first message received is + "UnsupportedVersion". The media distributor can determine from the + first two octets received what the version number is and that the + message is "UnsupportedVersion". The rest of the data received, if + any, would be discarded and the connection closed (if not already + closed). + 6. Tunneling Protocol Tunneled messages are transported via the TLS tunnel as application data between the media distributor and the key distributor. Tunnel messages are specified using the format described in [RFC5246] section 4. As in [RFC5246], all values are stored in network byte (big endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060. The protocol defines several different messages, each of which @@ -440,163 +459,168 @@ message type indicating the actual content of the message body. 6.1. Tunnel Message Format The syntax of the protocol is defined below. "TunnelMessage" defines the structure of all messages sent via the tunnel protocol. That structure includes a field called "msg_type" that identifies the specific type of message contained within "TunnelMessage". enum { - unsupported_version(1), - supported_profiles(2), + supported_profiles(1), + unsupported_version(2), media_keys(3), tunneled_dtls(4), endpoint_disconnect(5), (255) } MsgType; + opaque uuid[16]; + struct { - uint8 version; MsgType msg_type; + uint16 length; select (MsgType) { - case unsupported_version: UnsupportedVersion; case supported_profiles: SupportedProfiles; + case unsupported_version: UnsupportedVersion; case media_keys: MediaKeys; case tunneled_dtls: TunneledDtls; case endpoint_disconnect: EndpointDisconnect; } body; } TunnelMessage; The elements of "TunnelMessage" include: - o version: indicates the version of this protocol (0x00). o msg_type: the type of message contained within the structure "body". - - The "UnsupportedVersion" message is defined as follows: - - struct { } UnsupportedVersion; - - The "UnsupportedVersion" message does not convey any additional - information in the body. + o length: the length in octets of the following "body" of the + message. The "SupportedProfiles" message is defined as: uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ struct { + uint8 version; SRTPProtectionProfile protection_profiles<0..2^16-1>; } SupportedProfiles; - This message contains this single element: * protection_profiles: The - list of two-octet SRTP protection profile values as per [RFC5764] - supported by the media distributor. + This message contains this single element: + + o version: indicates the version of this protocol (0x00). + o protection_profiles: The list of two-octet SRTP protection profile + values as per [RFC5764] supported by the media distributor. + + The "UnsupportedVersion" message is defined as follows: + + struct { + uint8 highest_version; + } UnsupportedVersion; + + The elements of "UnsupportedVersion" include: + + o highest_version: indicates the highest supported protocol version. The "MediaKeys" message is defined as: struct { - uint32 association_id; + uuid association_id; SRTPProtectionProfile protection_profile; opaque mki<0..255>; opaque client_write_SRTP_master_key<1..255>; opaque server_write_SRTP_master_key<1..255>; opaque client_write_SRTP_master_salt<1..255>; opaque server_write_SRTP_master_salt<1..255>; - opaque conf_id<0..255>; } MediaKeys; The fields are described as follows: o association_id: A value that identifies a distinct DTLS association between an endpoint and the key distributor. o protection_profiles: The value of the two-octet SRTP protection profile value as per [RFC5764] used for this DTLS association. o mki: Master key identifier [RFC3711]. o client_write_SRTP_master_key: The value of the SRTP master key used by the client (endpoint). o server_write_SRTP_master_key: The value of the SRTP master key used by the server (media distributor). o client_write_SRTP_master_salt: The value of the SRTP master salt used by the client (endpoint). o server_write_SRTP_master_salt: The value of the SRTP master salt used by the server (media distributor). - o conf_id: Identifier that uniquely specifies which conference the - media distributor should place this media flow in. The "TunneledDtls" message is defined as: struct { - uint32 association_id; - opaque conf_id<0..255>; + uuid association_id; opaque dtls_message<0..2^16-1>; } TunneledDtls; The fields are described as follows: o association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor. - o conf_id: Optional identifier that uniquely specifies which - conference this media flow is in. + o dtls_message: the content of the DTLS message received by the endpoint or to be sent to the endpoint. The "EndpointDisconect" message is defined as: struct { - uint32 association_id; + uuid association_id; } EndpointDisconnect; The fields are described as follows: o association_id: An value that identifies a distinct DTLS association between an endpoint and the key distributor. 7. Example Binary Encoding The "TunnelMessage" is encoded in binary following the procedures - specified in [![RFC5246]]. This section provides an example of what - the bits on the wire would look like for the "SupportedProfiles" - message that advertises support for both + specified in [RFC5246]. This section provides an example of what the + bits on the wire would look like for the "SupportedProfiles" message + that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [I-D.ietf-perc-double]. 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: - version: 0x00 message_type: 0x01 + length: 0x0007 SupportedProfiles: + version: 0x00 protection_profiles: 0x0004 (length) 0x0009000A (value) Thus, the encoding on the wire presented here in network bytes order would be this stream of octets: - 0x000100040009000A + 0x0100070000040009000A 8. IANA Considerations This document establishes a new registry to contain message type values used in the DTLS Tunnel protocol. These data type values are a single octet in length. This document defines the values shown in Table 1 below, leaving the balance of possible values reserved for future specifications: +---------+------------------------------------+ | MsgType | Description | +---------+------------------------------------+ - | 0x01 | Unsupported Version | - | 0x02 | Supported SRTP Protection Profiles | + | 0x01 | Supported SRTP Protection Profiles | + | 0x02 | Unsupported Version | | 0x03 | Media Keys | | 0x04 | Tunneled DTLS | | 0x05 | Endpoint Disconnect | +---------+------------------------------------+ Table 1: Data Type Values for the DTLS Tunnel Protocol The value 0x00 and all values in the range 0x06 to 0xFF are reserved. The name for this registry is "Datagram Transport Layer Security @@ -623,62 +647,84 @@ media distributor and the key distributor. 10. Acknowledgments The author would like to thank David Benham and Cullen Jennings for reviewing this document and providing constructive comments. 11. References 11.1. Normative References + [I-D.ietf-mmusic-dtls-sdp] + Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer + Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-24 (work + in progress), April 2017. + + [I-D.thomson-mmusic-sdp-uks] + Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on + uses of Transport Layer Security with the Session + Description Protocol (SDP)", draft-thomson-mmusic-sdp- + uks-00 (work in progress), April 2017. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + 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, + . + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ - RFC5246, August 2008, + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, . [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, + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . 11.2. Informative References [I-D.ietf-perc-double] Jennings, C., Jones, P., and A. Roach, "SRTP Double - Encryption Procedures", draft-ietf-perc-double-02 (work in - progress), October 2016. + Encryption Procedures", draft-ietf-perc-double-03 (work in + progress), March 2017. - [I-D.jones-tls-perc-dtls-id] - Jones, P. and N. Ohlmeier, "Transporting the SDP attribute - 'dtls-id' in TLS and DTLS", March 2017. + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, . Authors' Addresses + Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com Paul M. Ellenbogen