draft-ietf-avt-srtp-ekt-02.txt   draft-ietf-avt-srtp-ekt-03.txt 
AVT Working Group D. McGrew AVT 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: September 15, 2011 Cisco Expires: May 3, 2012 Cisco
K. Fischer K. Fischer
Siemens Enterprise Communications Siemens Enterprise Communications
March 14, 2011 October 31, 2011
Encrypted Key Transport for Secure RTP Encrypted Key Transport for Secure RTP
draft-ietf-avt-srtp-ekt-02 draft-ietf-avt-srtp-ekt-03
Abstract Abstract
SRTP Encrypted Key Transport (EKT) is an extension to SRTP that SRTP Encrypted Key Transport (EKT) is an extension to SRTP that
provides for the secure transport of SRTP master keys, Rollover provides for the secure transport of SRTP master keys, Rollover
Counters, and other information, within SRTP or SRTCP. This facility Counters, and other information, within SRTP or SRTCP. This facility
enables SRTP to work for decentralized conferences with minimal enables SRTP to work for decentralized conferences with minimal
control, and to handle situations caused by early media. control, and to handle situations caused by early media.
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 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 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 September 15, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used In This Document . . . . . . . . . . . . 5 1.1. Conventions Used In This Document . . . . . . . . . . . . 5
2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6 2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 6
2.1. Authentication Tag Formats . . . . . . . . . . . . . . . . 6 2.1. Authentication Tag Formats . . . . . . . . . . . . . . . . 6
2.2. Packet Processing and State Machine . . . . . . . . . . . 8 2.2. Packet Processing and State Machine . . . . . . . . . . . 8
2.2.1. Outbound (Tag Generation) . . . . . . . . . . . . . . 9 2.2.1. Outbound (Tag Generation) . . . . . . . . . . . . . . 9
2.2.2. Inbound (Tag Verification) . . . . . . . . . . . . . . 11 2.2.2. Inbound (Tag Verification) . . . . . . . . . . . . . . 11
2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 15 2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . . 15
2.3.2. The AES Key Wrap Cipher . . . . . . . . . . . . . . . 15 2.3.2. AES ECB . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 16 2.3.3. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 16
2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 16 2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 16
2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6. Timing and Reliability Consideration . . . . . . . . . . . 17 2.6. Timing and Reliability Consideration . . . . . . . . . . . 17
3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 19 3. Use of EKT with SDP Security Descriptions . . . . . . . . . . 19
3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 19 3.1. SDP Security Descriptions Recap . . . . . . . . . . . . . 19
3.2. Relationship between EKT and SDP Security Descriptions . . 20 3.2. Relationship between EKT and SDP Security Descriptions . . 20
3.3. Overview of Combined EKT and SDP Security Description 3.3. Overview of Combined EKT and SDP Security Description
Operation . . . . . . . . . . . . . . . . . . . . . . . . 22 Operation . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 22 3.4. EKT Extensions to SDP Security Descriptions . . . . . . . 22
skipping to change at page 3, line 15 skipping to change at page 3, line 15
4.2.3. Processing the Initial Answer . . . . . . . . . . . . 34 4.2.3. Processing the Initial Answer . . . . . . . . . . . . 34
4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 35 4.2.4. Modifying the Session . . . . . . . . . . . . . . . . 35
5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 36 5. Use of EKT with MIKEY . . . . . . . . . . . . . . . . . . . . 36
5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 37 5.1. EKT extensions to MIKEY . . . . . . . . . . . . . . . . . 37
5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 39 5.2. Offer/Answer considerations . . . . . . . . . . . . . . . 39
5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 39 5.2.1. Generating the Initial Offer . . . . . . . . . . . . . 39
5.2.2. Generating the Initial Answer . . . . . . . . . . . . 40 5.2.2. Generating the Initial Answer . . . . . . . . . . . . 40
5.2.3. Processing the Initial Answer . . . . . . . . . . . . 40 5.2.3. Processing the Initial Answer . . . . . . . . . . . . 40
5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 40 5.2.4. Modifying the Session . . . . . . . . . . . . . . . . 40
6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 42 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 6.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with Appendix A. Using EKT to Optimize Interworking DTLS-SRTP with
Security Descriptions . . . . . . . . . . . . . . . . 49 Security Descriptions . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
RTP is designed to allow decentralized groups with minimal control to RTP is designed to allow decentralized groups with minimal control to
establish sessions, such as for multimedia conferences. establish sessions, such as for multimedia conferences.
Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many
minimal-control scenarios, because it requires that SSRC values and minimal-control scenarios, because it requires that SSRC values and
other data be coordinated among all of the participants in a session. other data be coordinated among all of the participants in a session.
For example, if a participant joins a session that is already in For example, if a participant joins a session that is already in
progress, the SRTP rollover counter (ROC) of each SRTP source in the progress, the SRTP rollover counter (ROC) of each SRTP source in the
skipping to change at page 15, line 38 skipping to change at page 15, line 38
a random permutation and its inverse with non-negligible advantage. a random permutation and its inverse with non-negligible advantage.
This must be true even for adversaries that can query both the This must be true even for adversaries that can query both the
encryption and decryption functions adaptively. The advantage is encryption and decryption functions adaptively. The advantage is
defined as the difference between the probability that the adversary defined as the difference between the probability that the adversary
will identify the cipher as such and the probability that the will identify the cipher as such and the probability that the
adversary will identify the random permutation as the cipher, when adversary will identify the random permutation as the cipher, when
each case is equally likely. each case is equally likely.
2.3.1. The Default Cipher 2.3.1. The Default Cipher
The default cipher is the Advanced Encryption Standard (AES) The default EKT Cipher is the AES Key Wrap [RFC3394] algorithm, which
[FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its can be used with plaintexts larger than 16 bytes in length, and is
parameters are fixed at L=16, M=16, and T=2^48. Note that M matches thus suitable for keys of any size. It requires a plaintext length M
the size of the SRTP master keys used by the default SRTP key that is a multiple of eight bytes, and it returns a ciphertext with a
derivation function; if an SRTP cipher with a different SRTP master length of N = M + 8 bytes. It can be used with key sizes of L = 16,
key length is to be used with EKT, then another EKT cipher must be 24, and 32, and its use with those key sizes is indicated as
used. ECB is the simplest mode of operation of a block cipher, in AESKW_128, AESKW_192, and AESKW_256, respectively. The key size
which the block cipher is used in its raw form. determines the length of the AES key used by the Key Wrap algorithm.
With this cipher, T=2^48.
2.3.2. The AES Key Wrap Cipher 2.3.2. AES ECB
The AES Key Wrap [RFC3394] defines a cipher that can be used with The simplest EKT cipher is the Advanced Encryption Standard (AES)
plaintexts larger than 16 bytes in length. It requires a plaintext [FIPS197] with 128-bit keys, in Electronic Codebook (ECB) Mode. Its
length M that is a multiple of eight bytes, and it returns a use is indicated as AES_ECB, and its parameters are fixed at L=16,
ciphertext with a length of N = M + 8 bytes. It can be used with key M=16, and T=2^48. Note that M matches the size of the SRTP master
sizes of L = 16, 24, and 32. The key size determines the length of keys used by the default SRTP key derivation function; if an SRTP
the AES key used by the Key Wrap algorithm. With this cipher, cipher with a different SRTP master key length is to be used with
T=2^48. EKT, then another EKT cipher must be used. ECB is the simplest mode
of operation of a block cipher, in which the block cipher is used in
its raw form.
2.3.3. Other EKT Ciphers 2.3.3. Other EKT Ciphers
Other specification MAY extend this one by defining other EKT ciphers Other specification MAY extend this one by defining other EKT ciphers
per Section 8. This section defines how those ciphers interact with per Section 8. This section defines how those ciphers interact with
this specification. this specification.
An EKT cipher determines how the Encrypted Master Key field is An EKT cipher determines how the Encrypted Master Key field is
written, and how it is processed when it is read. This field is written, and how it is processed when it is read. This field is
opaque to the other aspects of EKT processing. EKT ciphers are free opaque to the other aspects of EKT processing. EKT ciphers are free
skipping to change at page 23, line 4 skipping to change at page 23, line 4
EKT_Key: The EKT key used to encrypt the SRTP Master Key EKT_Key: The EKT key used to encrypt the SRTP Master Key
EKT_SPI: The EKT Security Parameter Index EKT_SPI: The EKT Security Parameter Index
Below are details on each of these attributes. Below are details on each of these attributes.
3.4.1. EKT_Cipher 3.4.1. EKT_Cipher
The (optional) EKT_Cipher parameter defines the EKT cipher used to The (optional) EKT_Cipher parameter defines the EKT cipher used to
encrypt the EKT key with in SRTCP packets. The default value is encrypt the EKT key with in SRTCP packets. The default value is
"AES_128" in accordance with Section 2.3.1. For the AES Key Wrap "AESKW_128" in accordance with Section 2.3.1. For the AES Key Wrap
cipher (see Section 2.3.2, the values "AESKW_128", "AESKW_192", and cipher, the values "AESKW_128", "AESKW_192", and "AESKW_256" are
"AESKW_256" are defined for values of L=16, 24, and 32 respectively. defined for values of L=16, 24, and 32 respectively. For the AES ECB
In the Offer/Answer model, the EKT_Cipher parameter is a negotiated cipher, "AES_ECB" is defined. In the Offer/Answer model, the
parameter. EKT_Cipher parameter is a negotiated parameter.
3.4.2. EKT_Key 3.4.2. EKT_Key
The (mandatory) EKT_Key parameter is the key K used to encrypt the The (mandatory) EKT_Key parameter is the key K used to encrypt the
SRTP Master Key in SRTCP packets. The value is base64 encoded as SRTP Master Key in SRTCP packets. The value is base64 encoded as
described in Section 4 [RFC4648]. When base64 decoding the key, described in Section 4 [RFC4648]. When base64 decoding the key,
padding characters (i.e., one or two "=" at the end of the base64 padding characters (i.e., one or two "=" at the end of the base64
encoded data) are discarded (see [RFC4648] for details). Base64 encoded data) are discarded (see [RFC4648] for details). Base64
encoding assumes that the base64 encoding input is an integral number encoding assumes that the base64 encoding input is an integral number
of octets. If a given EKT cipher requires the use of a key with a of octets. If a given EKT cipher requires the use of a key with a
skipping to change at page 44, line 5 skipping to change at page 43, line 33
Using the SRTP and EKT defaults, the total overhead is 24 bytes. Using the SRTP and EKT defaults, the total overhead is 24 bytes.
This overhead does not detract from the total bandwidth used by SRTP, This overhead does not detract from the total bandwidth used by SRTP,
since it is included in the RTCP bandwidth computation. However, it since it is included in the RTCP bandwidth computation. However, it
will cause the control protocol to issue packets less frequently. will cause the control protocol to issue packets less frequently.
The main motivation for the use of the variable-length format is The main motivation for the use of the variable-length format is
bandwidth conservation. If EKT is used of SRTP, there will be a loss bandwidth conservation. If EKT is used of SRTP, there will be a loss
of bandwidth due to the additional 24 bytes in each RTP packet. For of bandwidth due to the additional 24 bytes in each RTP packet. For
some applications, this bandwidth loss is significant. some applications, this bandwidth loss is significant.
6.1. Alternatives
In its current design, EKT requires that the Master Salt be
established out of band. That requirement is undesirable. In an
offer/answer environment, it forces the answerer to re-use the same
Master Salt value used by the offerer. The Master Salt value could
be carried in EKT packets though that would consume yet more
bandwidth.
In some scenarios, two SRTP sessions may be combined into a single
session. When using EKT in such sessions, it is desirable to have an
SPI value that is larger than 15 bits, so that collisions between SPI
values in use in the two different sessions are unlikely (since each
collision would confuse the members of one of the sessions.)
An alternative that addresses both of these needs is as follows: the
SPI value can be lengthed from 15 bits to 63 bits, and the Master
Salt can be identical to, or constructed from, the SPI value. SRTP
conventionally uses a 14-byte Master Salt, but shorter values are
acceptable. This alternative would add six bytes to each EKT packet;
that overhead may be a reasonable tradeoff for addressing the
problems outlined above.
7. Security Considerations 7. Security Considerations
With EKT, each SRTP sender and receiver can generate distinct SRTP With EKT, each SRTP sender and receiver can 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.
Note that the inputs of EKT are the same as for SRTP with key- Note that the inputs of EKT are the same as for SRTP with key-
sharing: a single key is provided to protect an entire SRTP session. sharing: a single key is provided to protect an entire SRTP session.
However, EKT provides complete security, even in the absence of However, EKT provides complete security, even in the absence of
further out-of-band coordination of SSRCs, and even when SSRC values further out-of-band coordination of SSRCs, and even when SSRC values
collide. collide.
skipping to change at page 47, line 14 skipping to change at page 48, line 14
10. References 10. References
10.1. Normative References 10.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] [I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work
in progress), July 2010. 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
 End of changes. 13 change blocks. 
36 lines changed or deleted 63 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/