draft-ietf-perc-srtp-ekt-diet-10.txt   draft-ietf-perc-srtp-ekt-diet-11.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Mattsson Intended status: Standards Track J. Mattsson
Expires: January 9, 2020 Ericsson AB Expires: July 18, 2020 Ericsson AB
D. McGrew D. McGrew
Cisco Systems Cisco Systems
D. Wing D. Wing
Citrix Systems, Inc.
F. Andreason F. Andreason
Cisco Systems Cisco Systems
July 8, 2019 January 15, 2020
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-10 draft-ietf-perc-srtp-ekt-diet-11
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
Transport Layer Security) and Secure Real-time Transport Protocol Transport Layer Security) and Secure Real-time Transport Protocol
(SRTP) that provides for the secure transport of SRTP master keys, (SRTP) that provides for the secure transport of SRTP master keys,
rollover counters, and other information within SRTP. This facility rollover counters, and other information within SRTP. This facility
enables SRTP for decentralized conferences by distributing a common enables SRTP for decentralized conferences by distributing a common
key to all of the conference endpoints. key to all of the conference endpoints.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 16 skipping to change at page 6, line 16
BYTE = %x00-FF BYTE = %x00-FF
EKTMsgTypeFull = %x02 EKTMsgTypeFull = %x02
EKTMsgTypeShort = %x00 EKTMsgTypeShort = %x00
EKTMsgTypeExtension = %x03-FF EKTMsgTypeExtension = %x03-FF
EKTMsgLength = 2BYTE; EKTMsgLength = 2BYTE;
SRTPMasterKeyLength = BYTE SRTPMasterKeyLength = BYTE
SRTPMasterKey = 1\*256BYTE SRTPMasterKey = 1*256BYTE
SSRC = 4BYTE; SSRC from RTP SSRC = 4BYTE; SSRC from RTP
ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC
EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
EKTCiphertext = 1\*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
Epoch = 2BYTE Epoch = 2BYTE
SPI = 2BYTE SPI = 2BYTE
FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
ShortEKTField = EKTMsgTypeShort ShortEKTField = EKTMsgTypeShort
ExtensionData = 1\*1024BYTE ExtensionData = 1*1024BYTE
ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
EKTField = FullEKTField / ShortEKTField / ExtensionEKTField EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
Figure 3: EKTField Syntax Figure 3: EKTField Syntax
These fields and data elements are defined as follows: These fields and data elements are defined as follows:
EKTPlaintext: The data that is input to the EKT encryption operation. EKTPlaintext: The data that is input to the EKT encryption operation.
This data never appears on the wire, and is used only in computations This data never appears on the wire, and is used only in computations
skipping to change at page 15, line 41 skipping to change at page 15, line 41
supported_ekt_ciphers and a new TLS handshake message type ekt_key. supported_ekt_ciphers and a new TLS handshake message type ekt_key.
The extension negotiates the cipher to be used in encrypting and The extension negotiates the cipher to be used in encrypting and
decrypting EKTCiphertext values, and the handshake message carries decrypting EKTCiphertext values, and the handshake message carries
the corresponding key. the corresponding key.
Figure 4 shows a message flow of DTLS 1.3 client and server using EKT 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 configured using the DTLS extensions described in this section. (The
initial cookie exchange and other normal DTLS messages are omitted.) 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 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- 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 Client Server
ClientHello ClientHello
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
+ use_srtp + use_srtp
+ supported_ekt_ciphers + supported_ekt_ciphers
{... Finished} {... Finished}
<-------- <--------
{... Finished} --------> {... Finished} -------->
[Ack] [ACK]
<-------- [EKTKey] <-------- [EKTKey]
[Ack] --------> [ACK] -------->
|SRTP packets| <-------> |SRTP packets| |SRTP packets| <-------> |SRTP packets|
+ <EKT tags> + <EKT tags> + <EKT tags> + <EKT tags>
{} Messages protected using DTLS handshake keys {} Messages protected using DTLS handshake keys
[] Messages protected using DTLS application traffic keys [] Messages protected using DTLS application traffic keys
<> Messages protected using the EKTKey and EKT cipher <> Messages protected using the EKTKey and EKT cipher
skipping to change at page 18, line 40 skipping to change at page 18, line 40
ekt_ttl ekt_ttl
The maximum amount of time, in seconds, that this EKTKey can be 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 used. The ekt_key_value in this message MUST NOT be used for
encrypting or decrypting information after the TTL expires. encrypting or decrypting information after the TTL expires.
If the server did not provide a supported_ekt_ciphers extension in If the server did not provide a supported_ekt_ciphers extension in
its ServerHello, then EKTKey messages MUST NOT be sent by the client its ServerHello, then EKTKey messages MUST NOT be sent by the client
or the server. or the server.
When an EKTKey is received and processed successfully, the recipient When an EKTKey is received and processed successfully, the recipient
MUST respond with an Ack handshake message as described in Section 7 MUST respond with an ACK message as described in Section 7 of
of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be [I-D.ietf-tls-dtls13]. The EKTKey message and ACK MUST be
retransmitted following the rules in Section 4.2.4 of [RFC6347]. 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, 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 implementations supporting EKT with DTLS pre-1.3 will need to have
explicit affordances for sending the Ack message in response to an explicit affordances for sending the ACK message in response to an
EKTKey message, and for verifying that an Ack message was received. 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. 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 If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert. recipient MUST respond with an appropriate DTLS alert.
5.3. Offer/Answer Considerations 5.3. Offer/Answer Considerations
When using EKT with DTLS-SRTP, the negotiation to use EKT is done at 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 / the DTLS handshake level and does not change the [RFC3264] Offer /
Answer messaging. Answer messaging.
5.4. Sending the DTLS EKTKey Reliably 5.4. Sending the DTLS EKTKey Reliably
The DTLS EKTKey message is sent using the retransmissions specified The DTLS EKTKey message is sent using the retransmissions specified
in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished 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 6. Security Considerations
EKT inherits the security properties of the the key management EKT inherits the security properties of the the key management
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP
extension defined in this document. extension defined in this document.
With EKT, each SRTP sender and receiver MUST generate distinct SRTP With EKT, each SRTP sender and receiver MUST generate distinct SRTP
master keys. This property avoids any security concern over the re- master keys. This property avoids any security concern over the re-
use of keys, by empowering the SRTP layer to create keys on demand. use of keys, by empowering the SRTP layer to create keys on demand.
skipping to change at page 22, line 30 skipping to change at page 22, line 30
as defined in [RFC8126]. The expert SHOULD ensure the specification 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. 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. Allocated values MUST be in the range of 0 to 254.
7.3. TLS Extensions 7.3. TLS Extensions
IANA is requested to add supported_ekt_ciphers as a new extension IANA is requested to add supported_ekt_ciphers as a new extension
name to the "TLS ExtensionType Values" table of the "Transport Layer name to the "TLS ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry: Security (TLS) Extensions" registry:
Value: [TBD-at-Registration] Value: [TBD-at-Registration]
Extension Name: supported\_ekt\_ciphers Extension Name: supported_ekt_ciphers
TLS 1.3: CH, SH TLS 1.3: CH, SH
Recommended: Y Recommended: Y
Reference: RFCAAAA Reference: RFCAAAA
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
7.4. TLS Handshake Type 7.4. TLS Handshake Type
IANA is requested to add ekt_key as a new entry in the "TLS IANA is requested to add ekt_key as a new entry in the "TLS
HandshakeType Registry" table of the "Transport Layer Security (TLS) HandshakeType Registry" table of the "Transport Layer Security (TLS)
Parameters" registry: Parameters" registry:
Value: [TBD-at-Registration] Value: [TBD-at-Registration]
Description: ekt\_key Description: ekt_key
DTLS-OK: Y DTLS-OK: Y
Reference: RFCAAAA Reference: RFCAAAA
Comment: Comment:
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
8. Acknowledgements 8. Acknowledgements
Thank you to Russ Housley provided detailed review and significant Thank you to Russ Housley provided detailed review and significant
help with crafting text for this document. Thanks to David Benham, help with crafting text for this document. Thanks to David Benham,
skipping to change at page 24, line 22 skipping to change at page 24, line 22
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-perc-double] [I-D.ietf-perc-double]
Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
Double Encryption Procedures", draft-ietf-perc-double-10 Double Encryption Procedures", draft-ietf-perc-double-12
(work in progress), October 2018. (work in progress), August 2019.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing (PERC)", draft-ietf-perc-private-media- Conferencing (PERC)", draft-ietf-perc-private-media-
framework-12 (work in progress), June 2019. framework-12 (work in progress), June 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1.3", draft-ietf-tls-dtls13-34 (work in progress),
2019. November 2019.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
skipping to change at page 25, line 15 skipping to change at page 25, line 15
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
David A. McGrew David A. McGrew
Cisco Systems Cisco Systems
Email: mcgrew@cisco.com Email: mcgrew@cisco.com
Dan Wing Dan Wing
Citrix Systems, Inc.
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
Flemming Andreason Flemming Andreason
Cisco Systems Cisco Systems
Email: fandreas@cisco.com Email: fandreas@cisco.com
 End of changes. 21 change blocks. 
30 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/