draft-ietf-avtcore-srtp-ekt-00.txt   draft-ietf-avtcore-srtp-ekt-01.txt 
AVT Working Group D. McGrew AVTCORE Working Group D. McGrew
Internet-Draft F. Andreasen Internet-Draft F. Andreasen
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: January 10, 2013 Cisco Expires: April 24, 2014 Cisco
K. Fischer October 21, 2013
Siemens Enterprise Communications
July 9, 2012
Encrypted Key Transport for Secure RTP Encrypted Key Transport for Secure RTP
draft-ietf-avtcore-srtp-ekt-00 draft-ietf-avtcore-srtp-ekt-01
Abstract Abstract
Encrypted Key Transport (EKT) is an extension to Secure Real-time Encrypted Key Transport (EKT) is an extension to Secure Real-time
Transport Protocol (SRTP) that provides for the secure transport of Transport Protocol (SRTP) that provides for the secure transport of
SRTP master keys, Rollover Counters, and other information, within SRTP master keys, Rollover Counters, and other information, within
SRTP or SRTCP. This facility enables SRTP to work for decentralized SRTP or SRTCP. This facility enables SRTP to work for decentralized
conferences with minimal control. conferences with minimal control.
This note defines EKT, and also describes how to use it with SDP This note defines EKT, and also describes how to use it with SDP
skipping to change at page 1, line 42 skipping to change at page 1, line 40
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 http://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 10, 2013. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://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 28, line 5 skipping to change at page 28, line 5
This document adds a new TLS negotiated extension called "ekt". This This document adds a new TLS negotiated extension called "ekt". This
adds a new TLS content type, EKT, and a new negotiated extension EKT. adds a new TLS content type, EKT, and a new negotiated extension EKT.
The negotiated extension MUST only be requested in conjunction with The negotiated extension MUST only be requested in conjunction with
the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server the "use_srtp" extension (Section 3.2 of [RFC5764]). The DTLS server
indicates its support for EKT by including "dtls-srtp-ekt" in its SDP indicates its support for EKT by including "dtls-srtp-ekt" in its SDP
and "ekt" in its TLS ServerHello message. If a DTLS client includes and "ekt" in its TLS ServerHello message. If a DTLS client includes
"ekt" in its ClientHello, but does not receive "ekt" in the "ekt" in its ClientHello, but does not receive "ekt" in the
ServerHello, the DTLS client MUST NOT send DTLS packets with the ServerHello, the DTLS client MUST NOT send DTLS packets with the
"ekt" content-type. "ekt" content-type.
Using the syntax described in DTLS [I-D.ietf-tls-rfc4347-bis], the Using the syntax described in DTLS [RFC6347], the following
following structures are used: structures are used:
enum { enum {
ekt_key(0), ekt_key(0),
ekt_key_ack(1), ekt_key_ack(1),
ekt_key_error(254), ekt_key_error(254),
(255) (255)
} SRTPKeyTransportType; } SRTPKeyTransportType;
struct { struct {
SRTPKeyTransportType keytrans_type; SRTPKeyTransportType keytrans_type;
skipping to change at page 40, line 36 skipping to change at page 40, line 36
EKT is especially useful for multi-party sessions, and for the case EKT is especially useful for multi-party sessions, and for the case
where multiple RTP sessions are sent to the same destination where multiple RTP sessions are sent to the same destination
transport address (see the example in the definition of "RTP session" transport address (see the example in the definition of "RTP session"
in [RFC3550]). A SIP offer that is forked in parallel (sent to in [RFC3550]). A SIP offer that is forked in parallel (sent to
multiple endpoints at the same time) can cause multiple RTP sessions multiple endpoints at the same time) can cause multiple RTP sessions
to be sent to the same transport address, making EKT useful for use to be sent to the same transport address, making EKT useful for use
with SIP. with SIP.
EKT can also be used in conjunction with a scalable group-key EKT can also be used in conjunction with a scalable group-key
management system like GDOI [RFC3547]. Such a system provides a management system like GDOI [RFC6407]. Such a system provides a
secure entity authentication method and a way to revoke group secure entity authentication method and a way to revoke group
membership, both of which are out of scope of EKT. membership, both of which are out of scope of EKT.
It is natural to use SRTCP to transport encrypted keying material for It is natural to use SRTCP to transport encrypted keying material for
SRTP, as it provides a secure control channel for (S)RTP. However, SRTP, as it provides a secure control channel for (S)RTP. However,
there are several different places in SRTCP in which the encrypted there are several different places in SRTCP in which the encrypted
SRTP master key and ROC could be conveyed. We briefly review some of SRTP master key and ROC could be conveyed. We briefly review some of
the alternatives in order to motivate the particular choice used in the alternatives in order to motivate the particular choice used in
this specification. One alternative is to have those values carried this specification. One alternative is to have those values carried
as a new SDESC item or RTCP packet. This would require that the as a new SDESC item or RTCP packet. This would require that the
skipping to change at page 46, line 12 skipping to change at page 46, line 12
multicast. Thanks to Felix Wyss for his review and comments multicast. Thanks to Felix Wyss for his review and comments
regarding ciphers. regarding ciphers.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal
Information Processing Standard. Information Processing Standard.
[I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work
in progress), July 2011.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[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,
skipping to change at page 47, line 19 skipping to change at page 47, line 13
Transform Carrying Roll-Over Counter for the Secure Real- Transform Carrying Roll-Over Counter for the Secure Real-
time Transport Protocol (SRTP)", RFC 4771, January 2007. time Transport Protocol (SRTP)", RFC 4771, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
September 2009.
[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, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
11.2. Informative References [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 11.2. Informative References
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
September 2009.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
[iana-sdp-attr] [iana-sdp-attr]
IANA, "SDP Parameters", 2011, <http://www.iana.org/ IANA, "SDP Parameters", 2011, <http://www.iana.org/
assignments/sdp-parameters/sdp-parameters.xml>. assignments/sdp-parameters/sdp-parameters.xml>.
[iana-sdp-sdesc] [iana-sdp-sdesc]
IANA, "SDP Security Descriptions", 2011, <http:// IANA, "SDP Security Descriptions", 2011, <http://
www.iana.org/assignments/sdp-security-descriptions/ www.iana.org/assignments/sdp-security-descriptions/
sdp-security-descriptions.xml>. sdp-security-descriptions.xml>.
Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Security
skipping to change at page 51, line 33 skipping to change at line 2032
Email: fandreas@cisco.com Email: fandreas@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
US US
Phone: (408) 853 4197 Phone: (408) 853 4197
Email: dwing@cisco.com Email: dwing@cisco.com
Kai Fischer
Siemens Enterprise Communications GmbH & Co. KG
Hofmannstr. 51
Munich, Bavaria 81739
Germany
Email: kai.fischer@siemens-enterprise.com
 End of changes. 13 change blocks. 
23 lines changed or deleted 19 lines changed or added

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