Network Working Group P. Jones Internet-Draft Cisco Systems Intended status: Standards Track N. Ohlmeier Expires: September 14, 2017 Mozilla March 13, 2017 Transporting the SDP attribute 'dtls-id' in TLS and DTLS draft-jones-perc-dtls-id-00 Abstract This draft defines a new extension to carry the "dtls-id" value defined for use in the Session Description Protocol within TLS and DTLS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 14, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jones & Ohlmeier Expires September 14, 2017 [Page 1] Internet-Draft dtls-id in TLS and DTLS March 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 2 3. Endpoint procedures . . . . . . . . . . . . . . . . . . . . . 3 4. Media distributor procedures . . . . . . . . . . . . . . . . 3 5. Key distributor procedures . . . . . . . . . . . . . . . . . 3 6. The dtls_id TLS extension . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The Privacy-Enhanced RTP Conferencing (PERC) working group specified a DTLS [RFC6347] tunneling mechanism [I-D.ietf-perc-dtls-tunnel] that enables a media distributor to forward DTLS messages between an endpoint and a key distributor. In the process, the media distributor is able to securely receive only the hop-by-hop keying material, while the endpoints are able to securely receive both end- to-end and hob-by-hop keying material. An open issue with the current design is how the key distributor can determine which one of several conferences an endpoint is attempting to join. The only information that the key distributor receives via the DTLS tunnel is the endpoint's certificate. However, the same certificate might be used to join several conferences in parallel, thus creating a need for additional information. [I-D.ietf-mmusic-dtls-sdp] defines an attribute in SDP [RFC4566] called the "dlts-id". The "dtls-id" presented by the endpoint's in SDP will be unique for each DTLS association established using the same certificate. By signaling the certificate fingerprint and "dtls-id" in SDP, along with including the same in the DTLS signaling sent to the key distributor, it would be possible for the key distributor to unambiguously determine which conference key the endpoint should receive. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. Jones & Ohlmeier Expires September 14, 2017 [Page 2] Internet-Draft dtls-id in TLS and DTLS March 2017 The terms key distributor, media distributor, endpoint, conference, hop-by-hop keying material, and end-to-end keying material used in this document are introduced in [I-D.ietf-perc-private-media-framework]. 3. Endpoint procedures The endpoint MUST include the "dtls_id" DTLS extension in the "ClientHello" message when establishing a DTLS tunnel in a PERC conference. Likewise, the "dtls-id" SDP 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 "dtls_id" value from the key distributor, the client MUST check to ensure that value matches the "dtls-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. 4. Media distributor procedures The media distributor is not required to inspect the "dtls_id" extension, as it merely forwards DTLS messages between the endpoint and the key distributor. 5. Key distributor procedures This draft assumes that when the endpoint inserts the "dtls-id" into SDP, the information will be conveyed in some way to the key distributor. The process through which the "dtls-id" in SDP is conveyed to the key distributor is outside the scope of this document. The key distributor MUST extract the "dtls_id" value transmitted in the "ClientHello" message and match that against "dtls-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 key distributor MUST correlate the certificate fingerprint and "dtls_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 "dtls-id" value. This value MUST also be conveyed back to the client via SDP. Jones & Ohlmeier Expires September 14, 2017 [Page 3] Internet-Draft dtls-id in TLS and DTLS March 2017 6. The dtls_id TLS extension The "dtls_id" TLS extension may be used either with TLS [RFC5246] or DTLS. It carries only "dtls-id" value defined in [I-D.ietf-mmusic-dtls-sdp] in the field called "dtls_id". The syntax for the "dtls_id" extension is shown below. struct { opaque dtls_id<20..255>; } SdpDtlsIdData; 7. IANA Considerations This document registers an extension in the TLS "ExtensionType Values" registry established in [RFC5246]. The extension is called "dtls_id" and is assigned the code point TBD. The following addition is made to the registry. +-----------+-------------+-----------+---------------------+ | Extension | Recommended | TLS 1.3 | HelloRetryRequested | +-----------+-------------+-----------+---------------------+ | dlts_id | Yes | Encrypted | Yes | +-----------+-------------+-----------+---------------------+ 8. Security Considerations The "dtls-id" value is a random value that has no personal identifiable information associated with it. Thus, the value does not expose such information. It also has no particular security properties in and of itself, so being in plaintext in the "ClientHello" or "ServerHello" is not viewed as a security concern. However, the value does have significance to the receiver, thus changes to the "dtls-id" may result in unexpected behavior. For example, if Alice attempts to join a PERC-enabled conference and the "dtls_id" field is modified in route to the key distributor, Alice may either fail to receive the conference key or receive the wrong conference key. However, since Alice will only be provided keys for conferences for which she is authorized to join based on her client certificate, receiving the wrong key will not compromise the security of the conference. However, receipt of the wrong key will deny Alice access to the plaintext of media transmitted by other participants. Additionally, if Alice transmits media using the wrong conference key, the media will be undecipherable by other conference participants. As prescribed in these procedures, if the "dtls_id" field transmitted from the key distributor to Alice is modified, Alice will tear down Jones & Ohlmeier Expires September 14, 2017 [Page 4] Internet-Draft dtls-id in TLS and DTLS March 2017 the DTLS association and fail to join the conference. The result is a denial of service for Alice, but not worse than when any other part of the DTLS message is modified. 9. Acknowledgments The authors would like to thank Martin Thomson for discussing the idea and providing some initial feedback before the draft was written. We also want to express our appreciation to Cullen Jennings for reviewing the text and providing constructive input. 10. 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-20 (work in progress), February 2017. [I-D.ietf-perc-dtls-tunnel] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00 (work in progress), March 2017. [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing", draft-ietf-perc-private-media-framework-02 (work in progress), October 2016. [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . Jones & Ohlmeier Expires September 14, 2017 [Page 5] Internet-Draft dtls-id in TLS and DTLS March 2017 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . 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 Nils H. Ohlmeier Mozilla Phone: +1 408 659 6457 Email: nils@ohlmeier.org Jones & Ohlmeier Expires September 14, 2017 [Page 6]