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

From: Sunil Mahajan <[email-masked]>
Date: Thu, 28 Dec 2006 12:42:56 +0530

Hi Mark,

Your understanding on the use of MKI to rotate the cipher context
along with cipher algorithm is correct.

Regarding other two observations, please see following comments

1) Application is the real application that's generating/consuming media
streams. E.g. voice calling, video calling, video on demand service etc.
What is suggested is an implementation level understanding between application
and SRTP stack where application suggests whether for a particular packet
encryption is needed or not.

So at implementation level, the analysis is actually done by the media

component of the application which determines requirement for encryption.

However this intelligence can also lie with higher level application, e.g. in case

single media stream is composed of multiple media contents separated by time.

Now when content type 1 is sent encryption is on and when content type-2 is

sent encryption is off.

Real logic to drive selective encryption will reside with application and will
be passed on to SRTP to select use of specific MKI value.

2) Encryption at application level is not recommended because it will require

additional  key exchange protocol and additional sematic exchange between

application over and above SRTP.

Selective encryption is useful to general telephony applications too, as

suggested in last mail, e,g, free voip or video calling service. Multimedia

applications within enterpise etc.

Regards,
Sunil Mahajan
AVP - Technology
ARICENT - INDIA

-----Mark Baugher <[email-masked]> wrote: -----

To: Sunil Mahajan/HSS@HSS
From: Mark Baugher <[email-masked]>
Date: 12/27/2006 11:11PM
cc: Marshall Eubanks <[email-masked]>, Shyam SBK Gupta Pallapothu/BLR/HSS@HSS, IETF AVT WG <[email-masked]>, Tom Taylor <[email-masked]>, David McGrew <[email-masked]>, "Mats Näslund (KI/EAB)" <[email-masked]>
Subject: Re: [AVT] IETF Draft - Support for Selective Encryption in SRTP

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
> 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"
> 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
> ***********************
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

*****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: Mark Baugher <[email-masked]>
Date: Thu, 28 Dec 2006 13:24:37 -0800

Sunil,

>    application over and above SRTP.

You already need an additional key exchange protocol or extensions to  
protocols.  Section 4 of http://www.ietf.org/internet-drafts/draft- 
smahajan-srtp-selective-encryption-00.txt sketches out where you're  
going, but RFC 4568 has some problems with signaling channels that  
don't do a 3-way handshake or even a round-trip exchange.  So your  
proposed mechanism would need to be defined for other key management  
systems as well.  Alternatively, you could define an application- 
layer key management library to support application-level encryption  
(i.e. an encrypted payload type definition as suggested by RFC 3550)  
and also provide a master key and salt to SRTP for message  
authentication.

I bring this up because I do think that selective encryption is  
payload-specific and not general to the transport.  It can be done at  
the transport level (SRTP) but at the cost of providing a mechanism  
that can be easily misused when applied to the wrong type of payload.

>    applications within enterpise etc.

I can't find citations for any of these applications in your I-D.  I  
know that selective encryption is used for conditional access, but  
this is the only application that I am aware of that uses selective  
encryption.  I'm sure that I'm missing a number of current or  
potential uses.  If you would point to some of the work that shows  
how generally useful selective encryption is, that would be helpful.

thanks, Mark
> cc: Marshall Eubanks <[email-masked]>, Shyam SBK Gupta  
> Pallapothu/BLR/HSS@HSS, IETF AVT WG <[email-masked]>, Tom Taylor  
> <[email-masked]>, David McGrew <[email-masked]>, "Mats Näslund  
> (KI/EAB)" <[email-masked]>
> "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."