--- 1/draft-ietf-perc-dtls-tunnel-01.txt 2017-10-30 17:13:13.292433855 -0700 +++ 2/draft-ietf-perc-dtls-tunnel-02.txt 2017-10-30 17:13:13.324434616 -0700 @@ -1,22 +1,22 @@ Network Working Group P. Jones Internet-Draft Cisco Systems Intended status: Standards Track P. Ellenbogen -Expires: October 30, 2017 Princeton University +Expires: May 3, 2018 Princeton University N. Ohlmeier Mozilla - April 28, 2017 + October 30, 2017 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange - draft-ietf-perc-dtls-tunnel-01 + draft-ietf-perc-dtls-tunnel-02 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 October 30, 2017. + This Internet-Draft will expire on May 3, 2018. 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 @@ -57,21 +57,21 @@ 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. Media Distributor Tunneling Procedures . . . . . . . . . 7 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 - 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 + 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -352,26 +352,20 @@ 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. @@ -648,80 +643,82 @@ 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. + Holmberg, C. and R. Shpount, "Session Description Protocol + (SDP) Offer/Answer Considerations for Datagram Transport + Layer Security (DTLS) and Transport Layer Security (TLS)", + draft-ietf-mmusic-dtls-sdp-32 (work in progress), October + 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, - . + 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, - . + 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, . + 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, - . + 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, - . + 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, - . + 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, . + 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-03 (work in - progress), March 2017. + Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP + Double Encryption Procedures", draft-ietf-perc-double-07 + (work in progress), September 2017. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, - July 2006, . + 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