--- 1/draft-ietf-perc-double-06.txt 2017-09-01 12:13:28.805160709 -0700 +++ 2/draft-ietf-perc-double-07.txt 2017-09-01 12:13:28.841161582 -0700 @@ -1,21 +1,21 @@ Network Working Group C. Jennings Internet-Draft P. Jones Intended status: Standards Track R. Barnes -Expires: February 9, 2018 Cisco Systems +Expires: March 5, 2018 Cisco Systems A. Roach Mozilla - August 8, 2017 + September 1, 2017 SRTP Double Encryption Procedures - draft-ietf-perc-double-06 + draft-ietf-perc-double-07 Abstract In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data scheme or take @@ -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 February 9, 2018. + This Internet-Draft will expire on March 5, 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 @@ -393,38 +393,38 @@ 7.2. RED TODO - Add text to explain how to use RED as described in Option A of slides presented at IETF 99. 7.3. FEC When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with double, the negotiation of double for the crypto is the out of band - signaling that indicates that the repair packets MUST use the order + signalling that indicates that the repair packets MUST use the order of operations of SRTP followed by FEC when encrypting. This is to - ensure that the original media is not reveled to the Media + ensure that the original media is not revealed to the Media Distributor but at the same time allow the Media Distributor to repair media. When encrypting a packet that contains the Flex FEC data, which is already encrypted, it MUST be encrypted in repair mode packet. The algorithm recommend in [I-D.ietf-rtcweb-fec] for repair of video is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not using additional FEC only m-line in SDP for the repair packets. 7.4. DTMF When DTMF is sent with [RFC4733], it is end-to-end encrypted and the - relay can not read it so it can not be used to controll the relay. - Other out of band methods to controll the relay need to be used + relay can not read it so it can not be used to control the relay. + Other out of band methods to control the relay need to be used instead. 8. Recommended Inner and Outer Cryptographic Algorithms This specification recommends and defines AES-GCM as both the inner and outer cryptographic algorithms, identified as DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide for authenticated encryption and will consume additional processing time double-encrypting for hop-by-hop and end-to-end. However, the @@ -557,58 +557,59 @@ auth_tag_length: N/A maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets The first half of the key and salt is used for the inner (end-to-end) algorithm and the second half is used for the outer (hop-by-hop) algorithm. 11. Acknowledgments - Many thanks to Richard Barnes for sending significant text for this - specification. Thank you for reviews and improvements from David - Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus - Westerlund. + Thank you for reviews and improvements to this specification from + Alex Gouaillard, David Benham, Magnus Westerlund, Nils Ohlmeier, Paul + Jones, Roni Even, and Suhas Nandakumar. In addition, thank you to + Sergio Garcia Murillo proposed the change of transporting the OHB + information in the RTP payload instead of the RTP header. 12. References 12.1. Normative References [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, . [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, - . + . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July - 2008, . + 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, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure - Real-time Transport Protocol (SRTP)", RFC 6904, DOI - 10.17487/RFC6904, April 2013, - . + Real-time Transport Protocol (SRTP)", RFC 6904, + DOI 10.17487/RFC6904, April 2013, . [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption - in the Secure Real-time Transport Protocol (SRTP)", RFC - 7714, DOI 10.17487/RFC7714, December 2015, - . + in the Secure Real-time Transport Protocol (SRTP)", + RFC 7714, DOI 10.17487/RFC7714, December 2015, + . 12.2. Informative References [I-D.ietf-payload-flexible-fec-scheme] Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in progress), July 2017. [I-D.ietf-perc-dtls-tunnel] @@ -628,33 +629,33 @@ "Encrypted Key Transport for DTLS and Secure RTP", draft- ietf-perc-srtp-ekt-diet-05 (work in progress), June 2017. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-06 (work in progress), July 2017. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, - DOI 10.17487/RFC4588, July 2006, - . + DOI 10.17487/RFC4588, July 2006, . [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, - DOI 10.17487/RFC4733, December 2006, - . + DOI 10.17487/RFC4733, December 2006, . [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- - to-Client Audio Level Indication", RFC 6465, DOI 10.17487/ - RFC6465, December 2011, - . + to-Client Audio Level Indication", RFC 6465, + DOI 10.17487/RFC6465, December 2011, . Appendix A. Encryption Overview The following figure shows a double encrypted SRTP packet. The sides indicate the parts of the packet that are encrypted and authenticated by the hob-by-hop and end-to-end operations. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+