--- 1/draft-ietf-perc-srtp-ekt-diet-06.txt 2018-03-05 09:13:25.349489130 -0800 +++ 2/draft-ietf-perc-srtp-ekt-diet-07.txt 2018-03-05 09:13:25.397490266 -0800 @@ -1,58 +1,58 @@ Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track J. Mattsson -Expires: May 3, 2018 Ericsson AB +Expires: September 6, 2018 Ericsson AB D. McGrew D. Wing F. Andreason Cisco Systems - October 30, 2017 + March 5, 2018 Encrypted Key Transport for DTLS and Secure RTP - draft-ietf-perc-srtp-ekt-diet-06 + draft-ietf-perc-srtp-ekt-diet-07 Abstract Encrypted Key Transport (EKT) is an extension to DTLS and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. 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/. + Drafts is at https://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 May 3, 2018. + This Internet-Draft will expire on September 6, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 + (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -715,21 +715,21 @@ 5.2.2. Establishing an EKT Key Once a client and server have concluded a handshake that negotiated an EKT cipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values. EKT keys are sent in encrypted handshake records, using handshake type ekt_key(TBD). The body of the handshake message contains an EKTKey structure: [[ NOTE: RFC Editor, please replace "TBD" above with the code point - assigend by IANA ]] + assigned by IANA ]] struct { opaque ekt_key_value<1..256>; opaque srtp_master_salt<1..256>; uint16 ekt_spi; uint24 ekt_ttl; } EKTKey; The contents of the fields in this message are as follows: @@ -751,21 +751,21 @@ used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires. If the server did not provide a supported_ekt_ciphers extension in its ServerHello, then EKTKey messages MUST NOT be sent by either the client or the server. When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be - retransmitted following the rules in Secton 4.2.4 of [RFC6347]. + retransmitted following the rules in Section 4.2.4 of [RFC6347]. Note: To be clear, EKT can be used with versions of DTLS prior to 1.3. The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. 5.3. Offer/Answer Considerations @@ -868,21 +868,21 @@ | Reserved | 63 | RFCAAAA | | Reserved | 255 | RFCAAAA | +--------------+-------+---------------+ Table 2: EKT Messages Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" - as defined in [RFC5226]. When requesting a new value, the requestor + as defined in [RFC8126]. When requesting a new value, the requestor needs to indicate if it is mandatory to understand or not. If it is mandatory to understand, IANA needs to allocate a value less than 64, if it is not mandatory to understand, a value greater than or equal to 64 needs to be allocated. IANA SHOULD prefer allocation of even values over odd ones until the even code points are consumed to avoid conflicts with pre standard versions of EKT that have been deployed. All new EKT messages MUST be defined to have a length as second from the last element. @@ -899,22 +899,22 @@ | AESKW256 | 2 | RFCAAAA | | Reserved | 255 | RFCAAAA | +----------+-------+---------------+ Table 3: EKT Cipher Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" - as defined in [RFC5226]. The expert SHOULD ensure the specification - defines the values for L and T as required in Section 4.4 of RFCAAA. + as defined in [RFC8126]. The expert SHOULD ensure the specification + defines the values for L and T as required in Section 4.4 of RFCAAAA. Allocated values MUST be in the range of 1 to 254. 7.3. TLS Extensions IANA is requested to add supported_ekt_ciphers as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] @@ -943,86 +943,86 @@ Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, comments, and contributions to this document. 9. References 9.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, . + 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, + . [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, . - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, . - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, . + DOI 10.17487/RFC5234, January 2008, + . [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, + . [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, - DOI 10.17487/RFC5649, September 2009, . + DOI 10.17487/RFC5649, September 2009, + . [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, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + 9.2. Informative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-07 (work in progress), September 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-04 - (work in progress), July 2017. + Conferencing", draft-ietf-perc-private-media-framework-05 + (work in progress), October 2017. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version - 1.3", draft-ietf-tls-dtls13-02 (work in progress), October - 2017. + 1.3", draft-ietf-tls-dtls13-22 (work in progress), + November 2017. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, - DOI 10.17487/RFC4086, June 2005, . + DOI 10.17487/RFC4086, June 2005, + . [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, . Authors' Addresses Cullen Jennings Cisco Systems