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

From: Sunil Mahajan <[email-masked]>
Date: Tue, 2 Jan 2007 14:03:17 +0530

Hi Mark,

Mark Baugher <[email-masked]> 
12/29/2006 02:54 AM

To
Sunil Mahajan/HSS@HSS
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,

On Dec 27, 2006, at 11:12 PM, Sunil Mahajan wrote:

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

You already need an additional key exchange protocol or extensions to 
protocols. 

<SM> 
There is no additional key exhange protocol needed. Key exhange
protocol as needed for SRTP can be used and if required with some 
extensions
or change in protocol semantics. One of the examples of the extensions for
RFC 4568 is suggested in the draft. Again this is just a suggestion and
other extensions can be worked on.
<SM>

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. 

<SM> 
Yes, key exchange will have to work in sync with the security 
protocol as this requires establishment of MKI and other required 
parameters. 
<SM>

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.

<SM> 
The idea of the draft is to make SRTP aligned to selective encryption,
there can exist other mechanisms to achieve same result. However doing 
encryption at application level and authentication at SRTP split the
media security requirements and will be more complex to manage.

Draft is proposing a mechanism which can use existing protocol to achieve
this result and as suggested by draft, this mecahism is optional and will
be used by applications which are aware of its need.
<SM>

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.

<SM>
Again - the responsibility of selective encryption lies with applications
with serious security needs. The whole mechanism of SRTP and as suggested
by this draft is based on negotiation and if a particular application 
needs
more secured mechanism, it can choose not to use selective encryption.

I donot understand the misused part?

Another point is - selective encryption from one side does not force 
selective
encryption from other side as MKI value is to filled by both sides 
indepedently
in each packet from both directions.
<SM>

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

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.

<SM>
We will add these sample applications in the next revision of the draft.
We will add more examples of applications that would need selective 
encryption
to take advantage of its efficiency.

Selective encryption as we discussed depends on application and to some
extent on media type too. So its not a generic mechanism and hence would
be negotiated by applications for its use in communication.
<SM>

Regards,
Sunil Mahajan

thanks, Mark
> Regards,
> Sunil Mahajan
> AVP - Technology
> ARICENT - INDIA

***********************  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: Sunil Mahajan <[email-masked]>
Date: Tue, 2 Jan 2007 14:03:17 +0530

Hi Mark,

To
Sunil Mahajan/HSS@HSS
cc

Sunil,

<SM> 

<SM> 

<SM> 

<SM>

<SM>

Regards,
Sunil Mahajan

thanks, Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 2 Jan 2007 09:54:50 -0800

hi Sunil,

On Jan 2, 2007, at 12:33 AM, Sunil Mahajan wrote:
...
> by this draft is based on negotiation and if a particular  
> application needs

I meant that the user of the feature might misapply it to the wrong  
payload type and unexpectedly leak more information than the  
application can tolerate.  I think we agree that this feature is  
highly dependent on the particular payload type.

I'd like to hear what others in the WG think of putting this feature  
in the transport level.

Mark

>
> Another point is - selective encryption from one side does not  
> force selective
> "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."

---

From: Sunil Mahajan <[email-masked]>
Date: Wed, 3 Jan 2007 19:23:24 +0530

Hi Mark,

hi Sunil,

<SM>
Typically applications will come bundled with SRTP, so the intelligence
of selective encryption is not really into user's hand. Now if a user
writes a new application which uses selective encryption with SRTP and
does not implement it correctly then only this user's application is at 
risk and not other applications. This mechanism does not force both sides
to agree to selective encryption.

We will add this part into security considerations section in the next 
revision.
<SM>

<SM>
We would also like to request others on the mailing list and WG members to
comment on this feature and provide their feedback on the suggested 
mechanism.
<SM>

Regards,
Sunil Mahajan

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jan 2007 16:07:04 +0100

Mark Baugher skrev:
> I'd like to hear what others in the WG think of putting this feature in 
> the transport level.

AD hat off to be clear.

I can't see how selective encryption is worth the effort at all. It has 
clear security issues by making the security extremely dependent on the 
right application selection. It will require extra complexity in 
handling of context and in implementations. All for a small reduction in 
computational load. To my understanding the symmetric encryption 
algorithms used in SRTP today is not an particular high load compared to 
some of the media processing the peer maybe forced to do. And that 
include it comparing to todays voice codecs. If this is an issue in a 
lower powered device the right solution seems not to make the security 
less, but rather to provide the necessary hardware support to do it for 
less power.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Sunil Mahajan <[email-masked]>
Date: Fri, 19 Jan 2007 10:47:32 +0530

Hi Magnus, 

Thanks for sharing your feedback.

First of all let me clarify again that the mechanism suggested in the 
draft is optional - so if
a particular application is not interested in using it - there should be 
mechanism for it to 
communicate without using selective encryption and that will be supported 
even after this
draft is implemented.

Second point on security - Selective encryption depends on application 
intelligence and 
it will be application's responsibility to ensure that security is not 
compromised. Now again
requirement for security will vary with applications - some applications 
will have high security
needs and others may not - so application implementation can decide when 
to use selective
encryption and when not. Plus one endpoint can't force other endpoint to 
use selective 
encryption - its a negotiated feature and will be used only if both sides 
agree. The level of
security on both sides still could be different.

On efforts or computation saving - This again will be dependent on 
application - the mechanism
suggested is not suggesting any selective encryption mechanism but only 
suggesting how to 
transport the same on SRTP. So different applications may exploit 
selective encryption to 
different extend and hence exploit saving in computational expense. To 
give you an example
content based selective encryption (not based on individual frames) may 
save much more
on computation if different content types are mixed on same stream and one 
of them does not
require encryption. So overall computation saving will depend on 
application type and will be
proven in labs before such applications are launched.

Regards,
Sunil Mahajan

Magnus Westerlund <[email-masked]> 
01/18/2007 08:37 PM

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

AD hat off to be clear.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Jan 2007 09:28:56 +0100

Hi,

I do understand your points, however I am very hesitant against 
standardizing something that has very limited applicability and a large 
potential for misuse. That is why I at least would like to see some more 
explicit usecase where it is clear that selective encryption really is 
needed to make things work. And where this case isn't gone by the time 
we can ship a finished specification, in other words more than 2 years.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Sunil Mahajan <[email-masked]>
Date: Fri, 19 Jan 2007 15:28:38 +0530

Hi Magnus,

<MW>
potential for misuse.
<MW>

<SM>
Applicability of selective encryption is not limited. There are lots of 
media related applications 
which would need a mechanism to encrypt contents selectively. The real 
applications will come up 
over a period of time - these are the same set of applications that would 
need RTP or SRTP - so 
you can guess what all applications would need selective encryption too. 
Let me re-iterate that selective
encryption does not mean encryption based on frame type only, it can also 
be based on importance
of content in the media stream.

Let me try to list few examples
1) Free voice/video telephony clients - these applications will not have 
strict encryption need
2) IVR interactions with Contact Centers - these IVRs need not be 
encrypted - but real conversation
    with end user and operator may need encryption
3) IVR interactions with Voice Mail servers - these IVRs need not be 
encrypted - but real conversation
    with end user and mail server may need encryption
4) Broadcast services - where mixed contents are streamed. One content 
type (video album)
    would need encryption - but other content type lets say Ads would not 
need encryption.

There are many more such examples and I am sure that once this kind of 
service/mechanism is possible, 
more and more applications would use it. 
<SM>

<MW>
And where this case isn't gone by the time 
we can ship a finished specification, in other words more than 2 years.
<MW>

<SM>
You can see from the type of examples that this requirement is not a short 
term requirement and will
stay even beyond 2 years. Infact now is the time when people have started 
using VoIP/RTP/SRTP
for many many applications.

And I wonder why would it take 2 years to standardize such a mechanism - 
we are not looking at 
standardizing selective encryption methods but only the support of 
selective encryption in SRTP.
<SM>

Regards,
Sunil Mahajan

Hi,

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Jan 2007 11:42:52 +0100

> 1) Free voice/video telephony clients - these applications will not have 

this I find very disturbing, either you have security of some form or 
you don't. Even if it is free you can't claim that you have 
confidentiality and only encrypt some fraction of the packets. That 
would be fooling the users. Because it is only the users that actually 
know what is sensitive in the exchange.

>     with end user and operator may need encryption

Now you are coming to another situation. Now you start talking about 
security based on source. That is in my world something else than 
selective encryption. I find this argument more compelling than the 
normal selective encryption case. However the question still is raised. 
How do you clearly indicate to the user what is secured and what is not. 
 From that perspective it seems clearer to protect all interactions. In 
case you are doing a real switch between the IVR and a particular 
operator then you would also need to clarify this by doing a clear 
authentication of the session parties. If that change you also have a 
possibility to change the security level. But doing these changes 
without some type of signalling and handling of identities seems to me 
wrong.

>     would need encryption - but other content type lets say Ads would not 

3 and 4 is similar enough to 2 that my comments applies to them.

> selective encryption in SRTP.
Because very few things are done in less than 2 years within the IETF.

First a recharter to put that work onto a charter somewhere. Based on 
this being mostly security but with substantial relation to RTP and the 
payload it is important to get the right people present in that WG.

Cheers

Magnus Westerlund