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

From: Sunil Mahajan <[email-masked]>
Date: Wed, 24 Jan 2007 12:45:37 +0530

Resending as the mail bounced back.

----- Forwarded by Sunil Mahajan/HSS on 01/24/2007 12:40 PM -----

Sunil Mahajan/HSS
01/24/2007 12:40 PM
Aricent-Unclassified

To
Mark Baugher <[email-masked]>
cc
IETF AVT WG <[email-masked]>, "Kalleitner, Franz" 
<[email-masked]>, Magnus Westerlund 
<[email-masked]>, Shyam SBK Gupta Pallapothu/BLR/HSS@HSS, 
Sunil Mahajan/HSS@HSS
Subject
Re: AW: [AVT] IETF Draft - Support for Selective Encryption in SRTP

Hi Mark,

Nice to see that you believed in "Selective Encryption" in 2005 itself and 
we can count 
on you for any support for selective encryption to promote our draft.

We understand that there are 2 ways to do selective encryption or 
encryption in general
one at lower layers (e.g. transport layer) or at higher layers (e.g. 
Application layer). And
both have their own advantages and disadvantages.

The motivation for purposing selective encryption at SRTP level was to use 
SRTP defined
encryption as this is one standard which most of the people are going to 
follow for media 
level security and second reason is the change proposed was too small (no 
change in syntax 
and a minor change in semantics). This is also to promote SRTP more and 
not define more
layers to support features.

Now we have seen traditionally that mechanisms that become common across 
multiple applications
are pushed to lower layers and it definitely has its own advantages e.g. 
link redundancy (multihoming)
support in SCTP compared to multiple TCP connections.

Now I would leave it to WG and WG Chairs to evaluate whether we need 
selective encryption
mechanism support at application level or at transport level.

We will be submitting revised draft by end of month.

Regards,
Sunil Mahajan

Mark Baugher <[email-masked]> 
01/23/2007 09:20 PM

To
"Kalleitner, Franz" <[email-masked]>
cc
Sunil Mahajan/HSS@HSS, Magnus Westerlund <[email-masked]>, 
Shyam SBK Gupta Pallapothu/BLR/HSS@HSS, IETF AVT WG <[email-masked]>
Subject
Re: AW: [AVT] IETF Draft - Support for Selective Encryption in SRTP

As I understand what you're saying, application-level encryption is 
potentially a better way to do selective encryption for scalable 
media.  I think if selective encryption has any secure use at all, it 
is at the application level rather than at the transport level.  This 
could be done using encrypted payload types.  A few years ago, I 
wrote a first draft document that described a framework for encrypted 
payload types that encrypts at the application-level, authenticates 
at the packet level, and supports selective encryption,
http://www.rdrop.com/users/mbaugher/I-D/draft-baugher-avt-enc-PT-00.txt.
I did not complete this work because there did not seem to be much 
interest in it at the time.

Mark
On Jan 19, 2007, at 4:50 AM, Kalleitner, Franz wrote:

>
> beside the ongoing discussion, another thought:
>
> as far as I know, available encryption concepts do not consider 
> adaptive or scalable media payload generated by media source 
> encoders. hence, the entire media payload is considered as 
> "portion" to be encrypted. other methods i.e. IPSEC may protect the 
> headers in addition to the media payload. however, a method to 
> protect data transferred over a packet based transport network 
> (i.e. IP) is working perfectly as long as no truncation/chopping of 
> the media payload is intended. doing so, the receiver must assume 
> the content of an encrypted payload has been changed on the way 
> from sender to receiver and it wouldn't be possible to decrypt the 
> packet successfully.  In the following, the packet will be discarded
> most media decoders are somewhat robust against packet loss or 
> packet truncation, exploited for rate adaptation purposes to 
> resolve local congestions.
>
> in the context of rate adaptation , and in particular to scaling 
> nodes that are not in the security context, this idea seem to be 
> helpful. the media payload can be chopped but decryption of media 
> payload still works at the receiver, because each frames is 
> encrypted separately. stream ciphers are able to seek to arbitrary 
> locations in their key-stream, thus encryption or decryption of 
> media frame does not depend on preceding once. in sum, independency 
> between encrypted frames would allow to chop/drop one or more less 
> significant/important (encypted) frames
>
> cheers,
> franz
>

***********************  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: Wed, 24 Jan 2007 11:58:23 -0800

hi Sunil
   I meant to say that if selective encryption is of any value at all,  
it's at the application layer and not the transport layer.  The I-D  
that I referenced is based upon the MPEG-4 Authentication and  
Encryption (ISMAcrypt) draft.  I was the editor of ISMAcrypt v.1 and  
not the sole author.  Members of the group from conditional access  
companies wanted selective encryption functionality, they understand  
the application and the requirements, particularly what elements need  
to be encrypted or can be left in the clear.  Selective encryption has  
been used in this particular application; Sony Passage got a lot of  
press a few years ago for their DVB Multicrypt technique.  This is  
probably an example of where selective encryption can be used; but I  
don't consider conditional access to be a security application per se.

   I checked the archive and see that I've already enumerated why I  
think the transport is the wrong place to do selective encryption and  
would repeat myself.

Mark

On Jan 23, 2007, at 11:10 PM, Sunil Mahajan wrote:

>
> Hi Mark,
>
> Nice to see that you believed in "Selective Encryption" in 2005 itself  
> and we can count
> The motivation for purposing selective encryption at SRTP level was to  
> use SRTP defined
> encryption as this is one standard which most of the people are going  
> to follow for media
> level security and second reason is the change proposed was too small  
> (no change in syntax
> and a minor change in semantics). This is also to promote SRTP more  
> and not define more
> Now we have seen traditionally that mechanisms that become common  
> across multiple applications
> are pushed to lower layers and it definitely has its own advantages  
> e.g. link redundancy (multihoming)
> Sunil Mahajan/HSS@HSS, Magnus Westerlund  
> <[email-masked]>, Shyam SBK Gupta  
> Pallapothu/BLR/HSS@HSS, IETF AVT WG <[email-masked]>
> Subject
>  > ________________________________
>  >
>  > Von: Sunil Mahajan [mailto:[email-masked]]
>  > Gesendet: Fr 19.01.2007 13:08
>  > An: Magnus Westerlund
>  > Cc: Shyam SBK Gupta Pallapothu; IETF AVT WG; Mark Baugher
>  > Betreff: Fw: [AVT] IETF Draft - Support for Selective Encryption in  
>  
>  > SRTP
>  >
>  >
>  >
>  > resending the message as it bounced back.
>  >
>  >
>  > Hi Magnus,
>  >
>  > Please see my comments below.
>  >
>  > Regards,
>  > Sunil Mahajan
>  >
>  >
>  >
>  >
>  > Sunil Mahajan skrev:
>  >
>  >> Let me try to list few examples
>  >> 1) Free voice/video telephony clients - these applications will  
>  >> not have
>  >> strict encryption need
>  >
>  > <MW>
>  > 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.
>  > <MW>
>  >
>  > <SM>
>  > I am not suggesting that encryption will be done randonmly - it  
>  > will based
>  > on some application intelligence - simplest is based on frame type.  
>  
>  > And
>  > I assume that method of selective encryptions are secure. Now even  
>  > if they
>  > are fully secured from all possible attacks by supercomputers -  
>  > that is
>  > probably not the requirement of a free telephony service. Another  
>  > similar
>  > example is enterprise (IP-PBX) voice/video service.
>  > <SM>
>  >
>  >
>  >> 2) IVR interactions with Contact Centers - these IVRs need not be
>  >> encrypted - but real conversation
>  >>     with end user and operator may need encryption
>  >
>  > <MW>
>  > 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.
>  > <MW>
>  >
>  > <SM>
>  > As per my understanding this is also selective encryption, where  
>  > contents
>  > are selectively encrypted. And the proposed draft will cover both  
>  > types
>  > of selective encryption.
>  > <SM>
>  >
>  > <MW>
>  > 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.
>  > <MW>
>  >
>  > <SM>
>  > The decision is taken by application and not by user and we donot  
>  > need to
>  > inform users on these scenarios. We are trying to save computation  
>  > at servers
>  > (IVR servers based on VoIP) for some contents to encrypted and some  
>  
>  > not.
>  > <SM>
>  >
>  > <MW>
>  > 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.
>  > <MW>
>  >
>  > <SM>
>  > As per my understanding of the scenario, the voice session is  
>  > established
>  > based on SRTP and as suggested by draft it will have two keys  
>  > exchanged, one
>  > for security and other for null encryption - during IVR SRTP packet  
>  
>  > shall carry
>  > MKI pointing to NULL Key and during conversation MKI points to real  
>  
>  > encryption
>  > key. Now this intelligence is with application and not communicated  
>  
>  > or triggered
>  > by user and as part of implementation application triggers SRTP on  
>  > switching
>  > MKI (this is just a suggestion and I am not suggesting any real  
>  > implementation).
>  > <SM>
>  >
>  >> <SM>
>  >> 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>
>  >>
>  >
>  > <MW>
>  > 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.
>  > <MW>
>  >
>  > <SM>
>  > OK. I understand now that this might take time to standardize.
>  > <SM>
>  >
>  >
>  >
>  >
>  > 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."
>
>
>
> 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