--- 1/draft-ietf-perc-srtp-ekt-diet-10.txt 2020-01-15 12:13:16.644584039 -0800 +++ 2/draft-ietf-perc-srtp-ekt-diet-11.txt 2020-01-15 12:13:16.696585370 -0800 @@ -1,25 +1,25 @@ Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track J. Mattsson -Expires: January 9, 2020 Ericsson AB +Expires: July 18, 2020 Ericsson AB D. McGrew Cisco Systems D. Wing - + Citrix Systems, Inc. F. Andreason Cisco Systems - July 8, 2019 + January 15, 2020 Encrypted Key Transport for DTLS and Secure RTP - draft-ietf-perc-srtp-ekt-diet-10 + draft-ietf-perc-srtp-ekt-diet-11 Abstract Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) 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. @@ -31,25 +31,25 @@ 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 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 January 9, 2020. + This Internet-Draft will expire on July 18, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 (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 @@ -238,35 +238,35 @@ BYTE = %x00-FF EKTMsgTypeFull = %x02 EKTMsgTypeShort = %x00 EKTMsgTypeExtension = %x03-FF EKTMsgLength = 2BYTE; SRTPMasterKeyLength = BYTE - SRTPMasterKey = 1\*256BYTE + SRTPMasterKey = 1*256BYTE SSRC = 4BYTE; SSRC from RTP ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC - EKTCiphertext = 1\*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) + EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) Epoch = 2BYTE SPI = 2BYTE FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull ShortEKTField = EKTMsgTypeShort - ExtensionData = 1\*1024BYTE + ExtensionData = 1*1024BYTE ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension EKTField = FullEKTField / ShortEKTField / ExtensionEKTField Figure 3: EKTField Syntax These fields and data elements are defined as follows: EKTPlaintext: The data that is input to the EKT encryption operation. This data never appears on the wire, and is used only in computations @@ -691,42 +691,42 @@ supported_ekt_ciphers and a new TLS handshake message type ekt_key. The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key. Figure 4 shows a message flow of DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section. (The initial cookie exchange and other normal DTLS messages are omitted.) 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. + in support for generating and processing ACK messages. Client Server ClientHello + use_srtp + supported_ekt_ciphers --------> ServerHello {EncryptedExtensions} + use_srtp + supported_ekt_ciphers {... Finished} <-------- {... Finished} --------> - [Ack] + [ACK] <-------- [EKTKey] - [Ack] --------> + [ACK] --------> |SRTP packets| <-------> |SRTP packets| + + {} Messages protected using DTLS handshake keys [] Messages protected using DTLS application traffic keys <> Messages protected using the EKTKey and EKT cipher @@ -820,45 +820,46 @@ ekt_ttl The maximum amount of time, in seconds, that this EKTKey can be 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 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 Section 4.2.4 of [RFC6347]. + MUST respond with an ACK message as described in Section 7 of + [I-D.ietf-tls-dtls13]. The EKTKey message and ACK MUST be + retransmitted following the rules of the negotiated version of DTLS. EKT MAY be used with versions of DTLS prior to 1.3. In such cases, - the Ack message is still used to provide reliability. Thus, DTLS + the ACK message is still used to provide reliability. Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have - explicit affordances for sending the Ack message in response to an - EKTKey message, and for verifying that an Ack message was received. - The retransmission rules for both sides are the same as in DTLS 1.3. + explicit affordances for sending the ACK message in response to an + EKTKey message, and for verifying that an ACK message was received. + The retransmission rules for both sides are otherwise defined by the + negotiated version of DTLS. 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 When using EKT with DTLS-SRTP, the negotiation to use EKT is done at the DTLS handshake level and does not change the [RFC3264] Offer / Answer messaging. 5.4. Sending the DTLS EKTKey Reliably The DTLS EKTKey message is sent using the retransmissions specified in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished - with an Ack message or an alert is received. + with an ACK message or an alert is received. 6. Security Considerations EKT inherits the security properties of the the key management protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP extension defined in this document. With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- use of keys, by empowering the SRTP layer to create keys on demand. @@ -995,35 +996,35 @@ defines the values for L and T as required in Section 4.4 of RFCAAAA. Allocated values MUST be in the range of 0 to 254. 7.3. TLS Extensions IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry: Value: [TBD-at-Registration] - Extension Name: supported\_ekt\_ciphers + Extension Name: supported_ekt_ciphers TLS 1.3: CH, SH Recommended: Y Reference: RFCAAAA [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 7.4. TLS Handshake Type IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry: Value: [TBD-at-Registration] - Description: ekt\_key + Description: ekt_key DTLS-OK: Y Reference: RFCAAAA Comment: [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 8. Acknowledgements Thank you to Russ Housley provided detailed review and significant help with crafting text for this document. Thanks to David Benham, @@ -1081,34 +1082,34 @@ May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 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-10 - (work in progress), October 2018. + Double Encryption Procedures", draft-ietf-perc-double-12 + (work in progress), August 2019. [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 (PERC)", draft-ietf-perc-private-media- framework-12 (work in progress), June 2019. [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-31 (work in progress), March - 2019. + 1.3", draft-ietf-tls-dtls13-34 (work in progress), + November 2019. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Authors' Addresses Cullen Jennings Cisco Systems @@ -1118,17 +1119,18 @@ Ericsson AB Email: john.mattsson@ericsson.com David A. McGrew Cisco Systems Email: mcgrew@cisco.com Dan Wing + Citrix Systems, Inc. Email: dwing-ietf@fuggles.com Flemming Andreason Cisco Systems Email: fandreas@cisco.com