Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

[Jonathan Lennox <[e-mail]>]

On May 5, 2011, at 7:28 AM, Qin Wu wrote:

> Some fairly minor comments below.  Overall I think the document provides useful mechanism to deal with tradeoff between RTP header extension encryption and RTP header
> compression efficiency when we use multiple header extension.

That's good to hear!  Responses inline.

> Section 3 Encryption Mechanism
> "
>  To encrypt (or decrypt) an encrypted extension header, an SRTP
>   participant first generates a keystream for the SRTP extension
>   header.  This keystream is generated in the same manner as the
>   encryption keystream for the corresponding SRTP payload, except the
>   the SRTP encryption and salting keys k_e and k_s are replaced by the
>   keys k_he and k_hs, respectively.
> "
> [Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload
> to provide encryption for the payload of header extension element?
> What's the benefit to choose the different keystream and crypto-suite for header extension elements?
> Can we say the same keystream and  crypto-suite for SRTP payload can be applied to header extension elements?

It definitely uses the same cryptosuite, but it can't be the same keystream -- if the payload and the extension elements are encrypted with the same keystream, you have a two-time-pad security failure.

In principle you could use a different region of the same keystream, but there's no obvious way to do that in a way that's backward-compatible with existing SRTP.

Since SRTP implementations are already generating six separate keys based on the master key (encryption, salting, and authentication for both RTP and RTCP) and two keystreams (for RTP and RTCP), adding two additional keys and one additional keystream doesn't seem like a particularly large implementation burden.

> Section 4:
> "
> Encrypted header extension elements are signaled in the SDP extmap
>   attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt",
>   followed by the URI of the header extension element being encrypted
>   as well as any extensionattributes that extension normally takes.
> "
> [Qin]: Are you going to define new URI for Encryption of Header Extensions or use existing URI?

The intention is that the new URI you quoted specifies generic encryption, and the extmap attribute takes as a parameter the existing URI describing the header being encrypted.

For example, encrypted SMPTE timecodes would be described as:

a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24 

> Section 4:
> 
> [Qin]: If one header extension has three elements, 
> a) the header extension and elements header will not be encrypted, only payload of each elements need encryption 
> b) or both elements header and elements payload will be encrypted?
> I believe it is former.

That's correct.

> [Qin]: If the number of header extension element included in each RTP packet changes during a stream, e.g., Firstly three header extension elements
> to be encrypted carried in the first RTP packet are sent to the receiver, and then, two header extension elements carried in 
> the second RTP packet are sent to the same receiver, is the receiver aware of this change and  choosing the right encryption mask? How?
> based on non-encrypted header?

The header extension elements are identified by the (unencrypted) header extension element headers, and you know based on the SDP which ones are encrypted. Thus, the encryption mask can be computed on a packet-by-packet basis.

> [Qin]: If there are no payload for header extension elements, i.e., the length of header extension elements is zero, the mechanism described in this document
> does not apply to this case, right?

For the one-byte-header form of header extension elements (0xBEDE), RFC 5285 doesn't support zero-length header extension elements, so it's moot.

For the two-byte-header form of header extension elements (0x100x), indeed this mechanism doesn't apply to zero-length extension elements.  The mechanism also doesn't apply to the long-form extension's app bits (the unspecified four bits of the "specified by profile" field).

> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Jonathan Lennox" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, March 28, 2011 5:08 PM
> Subject: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> 
> 
> Hello, all --
> 
> I've updated my draft on encrypting RTP header extensions, targeting the draft at the AVTCore WG, in the hope that the group will find it a suitable starting point for the WG milestone.
> 
> This version of the draft has no substantial changes from draft-lennox-avt-srtp-encrypted-extension-headers-02, only the name change and some reference updates.
> 
> Begin forwarded message:
> 
>> From: "[e-mail]" <[e-mail]>
>> Date: March 28, 2011 11:00:01 AM GMT+02:00
>> To: "[e-mail]" <[e-mail]>
>> Subject: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
>> Reply-To: "[e-mail]" <[e-mail]>
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> Title           : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
>> Author(s)       : J. Lennox
>> Filename        : draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
>> Pages           : 8
>> Date            : 2011-03-28
>> 
>> The Secure Real-Time Transport Protocol (SRTP) provides
>> authentication, but not encryption, of the headers of Real-Time
>> Transport Protocol (RTP) packets.  However, RTP header extensions may
>> carry sensitive information for which participants in multimedia
>> sessions want confidentiality.  This document provides a mechanism,
>> extending the mechanisms of SRTP, to selectively encrypt RTP header
>> extensions in SRTP.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> 

--
Jonathan Lennox
[e-mail]