Subject: [AVT] IETF Draft - Support for Selective Encryption in SRTP

From: Sunil Mahajan <[email-masked]>
Date: Fri, 22 Dec 2006 18:34:54 +0530

Hi All,

We have submitted an ietf draft on support for selective encryption in 
SRTP, this draft is available at 
 
http://www.ietf.org/internet-drafts/draft-smahajan-srtp-selective-encryption-00.txt

Would request the members on the list to go through the draft and provide 
their valuable feedback.

All of us know that selective encryption is a mechanism to improve the 
need of processing power at
end points involved in multi-media communication and still maintains the 
basic requirements of
media confidentiality and integrity. Assuming that SRTP is the most 
popular transport mechanism of
secured media communication on IP networks, enhacements to SRTP for 
"selective encryption" are
useful. 

Method proposed in the draft is an optional mechanism and shall be used by 
endpoint if needed, in 
addition the method proposed in the draft does not change syntax of SRTP 
protocol and is purely
backward compatible.

Please share your thoughts on the proposed method.

Regards,
Sunil Mahajan
ARICENT, INDIA

***********************  Aricent-Unclassified   ***********************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 22 Dec 2006 09:38:58 -0500

Dear Suni Mahajan;

I read through this draft, and I must admit that I would worry about
the security
implications of encrypting, say, only the iFrames of a video stream. I
have seen, wiith H.264, streams with an infinite GOP (only 1 I frame)
and also streams with "I slices" (I am not aware of the proper
terminology, but in H.264 a slice can be inserted that does not depend
in previous content.)  These two techniques can be combined (i.e., a
very long GOP together with a raster scan "I slice" means that the
picture will recover from packet losses). Clearly, encrypting the I
frame and not the I slice would be a security hole, so possible holes
in this process are application dependent.

But also imagine what happens if you try to reconstruct an MPEG
without the iframes. The security would depend on the content. If an
object moves
across the background, and you send (object - background) unencrypted,
then, if I can guess one, I can straightforwardly determine the other.
So, in a "talking head" type situation, the background might be
indeterminate, but the person's face might be recoverable, and that
might be exactly what the encryptor was trying to obscure. This
also would allow for crab-wise type attacks (determine one moving
object, that gives you part of the background which gives you another
moving object which gives you...)

So my take here is that

- this cannot be regarded as truly secure without a lot of application
dependent analysis
- the security also (depending on the application) may be content dependent
- at best, this will foil simple attempts to copy a stream, but will
likely not withstand a
determined assault.
- the reader should be warned about this
- the "Security Considerations" should be substantially enhanced.

Regards
Marshall

On 12/22/06, Sunil Mahajan <[email-masked]> wrote:
>
> Hi All,
>
> We have submitted an ietf draft on support for selective encryption in SRTP,
> this draft is available at
>
> All of us know that selective encryption is a mechanism to improve the need
> of processing power at
> media confidentiality and integrity. Assuming that SRTP is the most popular
> transport mechanism of

---

From: Sunil Mahajan <[email-masked]>
Date: Tue, 26 Dec 2006 10:18:09 +0530

Hi Marshall,

We agree with your observations that the level of security depends a lot 
on application
level analysis and it will be application's responsibility to encrypt 
enough packets
to avoid security attacks.

The mention of I-frame level encryption is just an example and is not a 
recommendation
and as you rightly mentioned that it will depend on application level 
analysis and also on 
the security requirements of the application.

This draft is not discussing the methods of selective encryption as thats 
a well researched 
area and application developer will have to understand the security needs 
and method
used for selective encryption.

This draft only suggests a change in protocol sematics of SRTP so that 
selective encryption
can optionally be enabled on SRTP if so desired by application.

To give you a simple example - there are lots of free voip (or even video) 
services available
on the net and there will be many more coming in near future - now for 
these services, media
encryption (or security) is a requirement but level of security required 
is not the highest possible. 
The security provided needs to ensure that a casual evesdropper shall not 
be able to decipher
the contents (voice and video). So for these kinds of applications, 
application developer
can enable selective encryption and if media is carried over SRTP, it can 
use SRTP provided
mechanisms. Another example could be streaming service with mixed 
contents, some of the contents
may need highest security possible whereas others may not need. E.g. 
programme guide or even
programme promos may not need encryption whereas real programme may need 
to be encrypted.

Please let us know if we should add some of these details in the security 
consideration section
of the draft - we can update the draft and release next version with some 
of these details.

Regards,
Sunil Mahajan
AVP - Technology
ARICENT - INDIA

"Marshall Eubanks" <[email-masked]> 
12/22/2006 08:08 PM

To
Sunil Mahajan/HSS@HSS
cc
[email-masked], "Tom Taylor" <[email-masked]>
Subject
Re: [AVT] IETF Draft - Support for Selective Encryption in SRTP

Dear Suni Mahajan;

So my take here is that

- the security also (depending on the application) may be content 
dependent

Regards
Marshall

> We have submitted an ietf draft on support for selective encryption in 
SRTP,

> All of us know that selective encryption is a mechanism to improve the 
need
> media confidentiality and integrity. Assuming that SRTP is the most 
popular

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Dec 2006 09:41:32 -0800

Sunil,
   I am of two minds on this draft.  RFC 3711 leaves the structure  
and even the length of the MKI open so that different key management  
systems can make use of it as needed, e.g. one-way key management  
systems might choose to encode the MKI with context information  
specific to their needs whereas two-way systems might only need a  
short, positive index.  But for different key management systems to  
use SRTP selective encryption, the cipher definition needs to be  
rotated with the key and a change to the SRTP crypt context is  
necessary.  I think I understand the rationale of your I-D.

   On the other hand, there is the question of information security,  
specifically confidentiality.  Marshall pointed out that selective  
encryption can leak a lot of information and weaken security in ways  
that the users of this feature may not anticipate.  One can argue as  
you did that this is application-specific so that use of selective  
encryption must be analyzed for each application.  I don't agree that  
"encrypt enough packets to avoid security attacks" addresses this  
requirement:  If you're encrypting a particular encoding wrong, then  
more information is leaked as more packets are encrypted.  Also, what  
is "application" in this context?  Is it the particular payload type,  
signaling mechanisms, user-to-user purpose such as a phone  
conversation or video-on-demand?

   An alternative approach is to encrypt at the application level and  
not in SRTP, which might provide only message authentication.  That  
is, encrypt the semantic elements of the particular payload type in  
ways that are specialized to the particular encoding or compression  
technique and that provably do not lessen security (or lessen it by a  
known workload factor).  Application-level encryption is done by the  
MPEG-4 Encryption and Authentication (ISMAcryp) specification from  
the ISMA.  Even so, I never expected that selective encryption has  
wide application beyond entertainment scrambling and expected this to  
be of more use to broadcasters (viz. Sony Passage) than to  
individuals who want privacy in their conversations.

cheers, Mark

On Dec 25, 2006, at 8:48 PM, Sunil Mahajan wrote:

>
> Hi Marshall,
>
> We agree with your observations that the level of security depends  
> a lot on application
> level analysis and it will be application's responsibility to  
> encrypt enough packets
> The mention of I-frame level encryption is just an example and is  
> not a recommendation
> and as you rightly mentioned that it will depend on application  
> level analysis and also on
> This draft is not discussing the methods of selective encryption as  
> thats a well researched
> area and application developer will have to understand the security  
> needs and method
> This draft only suggests a change in protocol sematics of SRTP so  
> that selective encryption
> To give you a simple example - there are lots of free voip (or even  
> video) services available
> on the net and there will be many more coming in near future - now  
> for these services, media
> encryption (or security) is a requirement but level of security  
> required is not the highest possible.
> The security provided needs to ensure that a casual evesdropper  
> shall not be able to decipher
> can enable selective encryption and if media is carried over SRTP,  
> it can use SRTP provided
> may need highest security possible whereas others may not need.  
> E.g. programme guide or even
> programme promos may not need encryption whereas real programme may  
> need to be encrypted.
>
> Please let us know if we should add some of these details in the  
> security consideration section
> of the draft - we can update the draft and release next version  
> with some of these details.
>
> Regards,
> Sunil Mahajan
> AVP - Technology
> ARICENT - INDIA
>
>
>
>

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 27 Dec 2006 19:17:44 -0500

Dear Suni;

On 12/25/06, Sunil Mahajan <[email-masked]> wrote:
>
> Hi Marshall,
>
> We agree with your observations that the level of security depends a lot on
> application
> level analysis and it will be application's responsibility to encrypt enough
> packets

Of course. I was just trying to work through some specific cases.

>
> This draft is not discussing the methods of selective encryption as thats a
> well researched

That needs to be said in my opinion; if it is well-researched some
informative references should be given too.

> can optionally be enabled on SRTP if so desired by application.

It says in RFC 3711 that

              Note that the MKI SHALL NOT identify
              the SRTP cryptographic context, which is identified
              according to Section 3.2.3.

Which, if I am reading your draft correctly, is precisely what you are
proposing. I would
want to understand better why this was a "SHALL NOT" before I would
feel comfortable with overriding this.

Note that section 3.2.3 says that

   A cryptographic context SHALL be uniquely identified by the triplet
   context identifier:
   context id = <SSRC, destination network address, destination
   transport port number>

Why not have the encrypted stream and the unencrypted stream be
different ports or different SSRCs ? Is there a reason why the packet
has to carry this information in the MKI ?

> on the net and there will be many more coming in near future - now for these
> services, media
> encryption (or security) is a requirement but level of security required is
> not the highest possible.
> The security provided needs to ensure that a casual evesdropper shall not be
> able to decipher
> mechanisms. Another example could be streaming service with mixed contents,
> some of the contents
> programme promos may not need encryption whereas real programme may need to
> be encrypted.

> of the draft - we can update the draft and release next version with some of
> these details.

I would. I would assume that the reader doesn't necessarily know
anything about selective encryption; if there is something they need
to know, either provide it or point to it. Also, since you are trying
to protect mostly against "casual entertainment" attacks (i.e., you
don't want for me to see high quality video in something like real
time without paying), but not so much against "serious" attacks, I
would say explicitly that this technique SHOULD NOT be used to protect
against "serious" attacks.

(Note that I am neither a  Chair of this WG nor an AD; they may come
to other conclusions).

Regards
Marshall

> To Sunil Mahajan/HSS@HSS
> cc [email-masked], "Tom Taylor" <[email-masked]>
>
> Subject Re: [AVT] IETF Draft - Support for Selective Encryption in SRTP
>
>
>
>
>
> Dear Suni Mahajan;
>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Dec 2006 17:04:28 -0800

On Dec 27, 2006, at 4:17 PM, Marshall Eubanks wrote:
...
>> that
> proposing.

That's not how I read it.  The cipher is part of the crypto context  
and a set of keys with MKI are also part of it.  My reading is that  
they want to associate an additional parameter with the MKI beyond a  
master key to have a 3-tuple, <MKI, master key, cipher_spec>, where  
"cipher_spec" is a name I made up to describe the cipher that is  
associated with the master key.  A more restrictive definition would  
be that cipher_spec is a boolean and is cleared or set if a change is  
made to ESP_NULL.

> I would
>> for these
>> it can

I tend to agree and question whether the additional complexity is  
really worth the computational savings.

Mark

>>  > Method proposed in the draft is an optional mechanism and shall  
>> be used
>> by
>>  > endpoint if needed, in