Diff: draft-ietf-perc-srtp-ekt-diet-06.txt - draft-ietf-perc-srtp-ekt-diet-07.txt

	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/