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

From: Sunil Mahajan <[email-masked]>
Date: Tue, 2 Jan 2007 11:45:20 +0530

Resending the message as it bounced back from the list.

----- Forwarded by Sunil Mahajan/HSS on 01/02/2007 11:39 AM -----

Sunil Mahajan/HSS
12/28/2006 01:07 PM

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

Hi Marshall,

>Dear Suni;
>On 12/25/06, 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
>> 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.

>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
>> area and application developer will have to understand the security 
needs
>> and method
>> used for selective encryption.
>>
>That needs to be said in my opinion; if it is well-researched some
>informative references should be given too.

<SM> This will be added in next revision of the draft.

>> 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.
>>
>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 =   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 ?

<SM> Proposed mechanism in the draft still not make MKI identifying 
cyptographic
context which will still be identified by the tripplet as suggested in 
section
3.2.3. However it proposes that cryptographic context shall carry cipher 
alogorithm
at MKI level and not single algorithm per context. So that change in MKI 
value can
also indicate change in cipher algorithm along with change of keys if 
applicable
 
>> 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.
>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.
 
<SM> We will add pointers for the selective encryption reading. However 
this
mechanism can be used for both casual attacks and serious attacks. As 
discussed
in previous mail, serious attacks can also be prevented but that will 
require 
application level intelligence to decide what to encrypt and what not. So 
if application
is intelligent enough it can use selective encryption even for serious 
communications,
else if application is very intelligent it can avoid it.
 
>(Note that I am neither a  Chair of this WG nor an AD; they may come
>to other conclusions).
 
<SM> We would request the chair of WG to evaluate this.
Regards,
Sunil Mahajan

> "Marshall Eubanks" 
>
> 12/22/2006 08:08 PM
>
>
> To Sunil Mahajan/HSS@HSS
>
> cc [email-masked], "Tom Taylor" 
>
> Subject Re: [AVT] IETF Draft - Support for Selective Encryption in SRTP
>
>
>
>
>
> 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 wrote:
>  >
>  > 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
>  >
>  >
>  >
>
>
>
>  ***********************  Aricent-Unclassified   ***********************

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

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Jan 2007 12:01:32 +0000

On 2 Jan 2007, at 06:15, Sunil Mahajan wrote:
...
> >> 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
> >> 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
> >> 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.
> <SM> We will add pointers for the selective encryption reading.  
> However this
> mechanism can be used for both casual attacks and serious attacks.  
> As discussed
> in previous mail, serious attacks can also be prevented but that  
> will require
> application level intelligence to decide what to encrypt and what  
> not. So if application
> is intelligent enough it can use selective encryption even for  
> serious communications,

This chair agrees with Marshall - the security considerations section  
should standalone.

Colin

---

From: Sunil Mahajan <[email-masked]>
Date: Tue, 2 Jan 2007 18:41:48 +0530

Hi Colin,

We have already accepted the comment to enhance the security consideration 
section
in the next revision - will do that after we collect some more feedback 
from the list.

The reqeust to chair was to evaluate the draft for inclusion in SRTP 
protocol definition.

Regards,
Sunil Mahajan

Colin Perkins <[email-masked]> 
01/02/2007 05:31 PM

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

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Jan 2007 13:16:57 +0000

> We have already accepted the comment to enhance the security  
> consideration section in the next revision - will do that after we  
> collect some more feedback from the list.
>
> The reqeust to chair was to evaluate the draft for inclusion in  
> SRTP protocol definition.

That depends on feedback from the working group. I think it much too  
early to judge the consensus yet.

Colin