draft-ietf-perc-srtp-ekt-diet-06.txt   draft-ietf-perc-srtp-ekt-diet-07.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: May 3, 2018 Ericsson AB Expires: September 6, 2018 Ericsson AB
D. McGrew D. McGrew
D. Wing D. Wing
F. Andreason F. Andreason
Cisco Systems Cisco Systems
October 30, 2017 March 5, 2018
Encrypted Key Transport for DTLS and Secure RTP Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-06 draft-ietf-perc-srtp-ekt-diet-07
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to DTLS and Secure Encrypted Key Transport (EKT) is an extension to DTLS and Secure
Real-time Transport Protocol (SRTP) that provides for the secure Real-time Transport Protocol (SRTP) that provides for the secure
transport of SRTP master keys, rollover counters, and other transport of SRTP master keys, rollover counters, and other
information within SRTP. This facility enables SRTP for information within SRTP. This facility enables SRTP for
decentralized conferences by distributing a common key to all of the decentralized conferences by distributing a common key to all of the
conference endpoints. conference endpoints.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice 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. 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
(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 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 17, line 6 skipping to change at page 17, line 6
5.2.2. Establishing an EKT Key 5.2.2. Establishing an EKT Key
Once a client and server have concluded a handshake that negotiated 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 an EKT cipher, the server MUST provide to the client a key to be used
when encrypting and decrypting EKTCiphertext values. EKT keys are when encrypting and decrypting EKTCiphertext values. EKT keys are
sent in encrypted handshake records, using handshake type sent in encrypted handshake records, using handshake type
ekt_key(TBD). The body of the handshake message contains an EKTKey ekt_key(TBD). The body of the handshake message contains an EKTKey
structure: structure:
[[ NOTE: RFC Editor, please replace "TBD" above with the code point [[ NOTE: RFC Editor, please replace "TBD" above with the code point
assigend by IANA ]] assigned by IANA ]]
struct { struct {
opaque ekt_key_value<1..256>; opaque ekt_key_value<1..256>;
opaque srtp_master_salt<1..256>; opaque srtp_master_salt<1..256>;
uint16 ekt_spi; uint16 ekt_spi;
uint24 ekt_ttl; uint24 ekt_ttl;
} EKTKey; } EKTKey;
The contents of the fields in this message are as follows: The contents of the fields in this message are as follows:
skipping to change at page 17, line 42 skipping to change at page 17, line 42
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 either the its ServerHello, then EKTKey messages MUST NOT be sent by either the
client or the server. client 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 handshake message as described in Section 7
of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack must be 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 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 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. have built-in support for generating and processing Ack messages.
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
skipping to change at page 20, line 20 skipping to change at page 20, line 20
| Reserved | 63 | RFCAAAA | | Reserved | 63 | RFCAAAA |
| Reserved | 255 | RFCAAAA | | Reserved | 255 | RFCAAAA |
+--------------+-------+---------------+ +--------------+-------+---------------+
Table 2: EKT Messages Types Table 2: EKT Messages Types
Note to RFC Editor: Please replace RFCAAAA with the RFC number for Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification. this specification.
New entries to this table can be added via "Specification Required" 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 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, 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 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 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 values over odd ones until the even code points are consumed to avoid
conflicts with pre standard versions of EKT that have been deployed. 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 All new EKT messages MUST be defined to have a length as second from
the last element. the last element.
skipping to change at page 20, line 51 skipping to change at page 20, line 51
| AESKW256 | 2 | RFCAAAA | | AESKW256 | 2 | RFCAAAA |
| Reserved | 255 | RFCAAAA | | Reserved | 255 | RFCAAAA |
+----------+-------+---------------+ +----------+-------+---------------+
Table 3: EKT Cipher Types Table 3: EKT Cipher Types
Note to RFC Editor: Please replace RFCAAAA with the RFC number for Note to RFC Editor: Please replace RFCAAAA with the RFC number for
this specification. this specification.
New entries to this table can be added via "Specification Required" New entries to this table can be added via "Specification Required"
as defined in [RFC5226]. 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 RFCAAA. 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. Allocated values MUST be in the range of 1 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 "ExtensionType Values" table of the "Transport Layer name to the "ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this. specification and allocate a value of TBD to for this.
[[ Note to RFC Editor: TBD will be allocated by IANA. ]] [[ Note to RFC Editor: TBD will be allocated by IANA. ]]
skipping to change at page 21, line 47 skipping to change at page 21, line 47
Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean
Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions,
comments, and contributions to this document. comments, and contributions to this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002,
editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008,
editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008,
editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649,
DOI 10.17487/RFC5649, September 2009, <https://www.rfc- DOI 10.17487/RFC5649, September 2009,
editor.org/info/rfc5649>. <https://www.rfc-editor.org/info/rfc5649>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, <https://www.rfc- DOI 10.17487/RFC5764, May 2010,
editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
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-07 Double Encryption Procedures", draft-ietf-perc-double-07
(work in progress), September 2017. (work in progress), September 2017.
[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", draft-ietf-perc-private-media-framework-04 Conferencing", draft-ietf-perc-private-media-framework-05
(work in progress), July 2017. (work in progress), October 2017.
[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-02 (work in progress), October 1.3", draft-ietf-tls-dtls13-22 (work in progress),
2017. November 2017.
[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, <https://www.rfc- DOI 10.17487/RFC4086, June 2005,
editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
 End of changes. 22 change blocks. 
35 lines changed or deleted 35 lines changed or added

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