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

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

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>

***********************  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: "Marshall Eubanks" <[email-masked]>
Date: Fri, 19 Jan 2007 07:44:56 -0500

Hello;

To me the big issue here is to find some way to indicate in the draft
(or by normative reference) how this could be used safely.

In my opinion, just saying that the application writer / user should
know what they are doing is not sufficient. If this is to be a
standard, it needs to stand alone.

If someone comes to us and says, "I implemented everything in your
RFC, I followed all of your suggestions, and my implementation was
immediately broken and hacked because of problems you knew about,"
then we have not done our job.

If this cannot be done, then I do not think that this is suitable to
be a standard.
I actually think, however, that it could be, maybe by including a set
of use cases which illustate the problems and provide solutions.

Regards
Marshall

On 1/19/07, Sunil Mahajan <[email-masked]> wrote:
> based on SRTP and as suggested by draft it will have two keys exchanged, one
> by user and as part of implementation application triggers SRTP on switching
> the individual to whom it is addressed. It may contain privileged or
> confidential information and should not be
> 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

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Fri, 19 Jan 2007 13:50:57 +0100

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
 
________________________________

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

Hi Magnus, 

Regards, 
Sunil Mahajan 

<MW>

<SM> 

<MW>

<SM> 

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

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

<MW> 

<SM>

---

From: Sunil Mahajan <[email-masked]>
Date: Fri, 19 Jan 2007 18:29:57 +0530

Hi Marshall,

We have already accepted this comment and will include following in the 
next revision of this
draft

1) More details on what we mean by selective encryption (some references 
too)
2) Example (sample only) applications that can use selective encryption 
and hence selective encryption 
    using this draft and SRTP
3) Security Considerations - warning to user on possible security issues 
with selective encryption if 
    not implemented with proper analysis

We are still waiting for some more feedback on the basic concept of draft 
and will update next version
by end of this month.

Regards,
Sunil Mahajan

"Marshall Eubanks" <[email-masked]> 
01/19/2007 06:14 PM

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

Hello;

Regards
Marshall

---

From: Mark Baugher <[email-masked]>
Date: Tue, 23 Jan 2007 07:50:31 -0800

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:

> 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
>
> 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: "Kalleitner, Franz" <[email-masked]>
Date: Wed, 24 Jan 2007 09:16:50 +0100

hi, mark!

exactly that was my point. Beside payload types MPEG, MPEG-4, MP3, H.264/AVC and VC-1 another media codec that 
may gain from could be H.264/SVC (http://www.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt)
SVC provides scalable video bitstreams. In SVC, a scalable video bitstream contains a base layer 
and one or more enhancement layers. for congestion control a bit-rate adapation could be simple done by
e.g.  removing the packet (NAL Unit) belonging to hierarchically highest enhancement layer 
or set of enhancement layers from an RTP or removing some or all bits of a given Fine Grain Scalability 
enhancement layer. This type of scalability is applicable for several speech/audio codecs too.

In the context of RTP level security and to gain from the scalability, media packets need to be  cryptographically-independent as indicated in your draft. I'm not sure if this can be seen independent to
SRTP, but it may.

Of course, the scalability of media packets must be take into account before encrypting. Aforementioned, some
media packets may be dropable other may truncatable. The similar utilization has been outlined at ch. 2.3.2.  Delta_IV.

cheers,
franz

-----Ursprüngliche Nachricht-----
Von: Mark Baugher [mailto:[email-masked]] 
Gesendet: Dienstag, 23. Jänner 2007 16:51
An: Kalleitner, Franz
Cc: Sunil Mahajan; Magnus Westerlund; Shyam SBK Gupta Pallapothu; IETF AVT WG
Betreff: Re: AW: [AVT] IETF Draft - Support for Selective Encryption in SRTP

Mark

---

From: Sunil Mahajan <[email-masked]>
Date: Wed, 24 Jan 2007 15:07:59 +0530

Hi Franz,

Sorry I could not relate your description to selective encryption proposal 
on SRTP - 
can you please elaborate whether you are proposing an alternate mechanism 
for selective
encryption at application level or general encryption scheme at 
application level and suggesting
removal of encryption from SRTP? Please can you help me understand your 
point.

Regards,
Sunil Mahajan

"Kalleitner, Franz" <[email-masked]> 
01/24/2007 01:46 PM

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

hi, mark!

exactly that was my point. Beside payload types MPEG, MPEG-4, MP3, 
H.264/AVC and VC-1 another media codec that 
may gain from could be H.264/SVC (
http://www.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt)
SVC provides scalable video bitstreams. In SVC, a scalable video bitstream 
contains a base layer 
and one or more enhancement layers. for congestion control a bit-rate 
adapation could be simple done by
e.g.  removing the packet (NAL Unit) belonging to hierarchically highest 
enhancement layer 
or set of enhancement layers from an RTP or removing some or all bits of a 
given Fine Grain Scalability 
enhancement layer. This type of scalability is applicable for several 
speech/audio codecs too.

In the context of RTP level security and to gain from the scalability, 
media packets need to be  cryptographically-independent as indicated in 
your draft. I'm not sure if this can be seen independent to
SRTP, but it may.

Of course, the scalability of media packets must be take into account 
before encrypting. Aforementioned, some
media packets may be dropable other may truncatable. The similar 
utilization has been outlined at ch. 2.3.2.  Delta_IV.

cheers,
franz

-----Ursprüngliche Nachricht-----
Von: Mark Baugher [mailto:[email-masked]] 
Gesendet: Dienstag, 23. Jänner 2007 16:51
An: Kalleitner, Franz
Cc: Sunil Mahajan; Magnus Westerlund; Shyam SBK Gupta Pallapothu; IETF AVT 
WG
Betreff: Re: AW: [AVT] IETF Draft - Support for Selective Encryption in 
SRTP

Mark

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 24 Jan 2007 11:00:44 +0100 (CET)

Dear Franz, all,

The newest version of the SVC RTP payload draft can be found here:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-00.txt

Thomas

On Jan 24, 2007 09:16 AM, "Kalleitner, Franz"
<[email-masked]> wrote:

>may gain from could be H.264/SVC
>(http://www.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt)

>>significant/important (encypted) frames

__________________________
Thomas Schierl, Dipl.-Ing.
Fraunhofer HHI
Einsteinufer 37, 10587 Berlin, Germany
PHONE: +49 30 31002 227,FAX: +49 30 392 7200
EMAIL: [email-masked],WEB: ip.hhi.de

---

From: Mark Baugher <[email-masked]>
Date: Wed, 24 Jan 2007 12:10:21 -0800

hi Franz,

On Jan 24, 2007, at 12:16 AM, Kalleitner, Franz wrote:

> H.264/AVC and VC-1 another media codec that may gain from could be  
> H.264/SVC  
> SVC provides scalable video bitstreams.

My draft was written before we had RTP payload definitions for SVC.  I  
think it's an important codec to include and would benefit from  
application-layer encryption.

> In SVC, a scalable video bitstream contains a base layer and one or  
> more enhancement layers. for congestion control a bit-rate adapation  
> could be simple done by e.g.  removing the packet (NAL Unit) belonging  
> to hierarchically highest enhancement layer or set of enhancement  
> layers from an RTP or removing some or all bits of a given Fine Grain  
> Scalability enhancement layer. This type of scalability is applicable  
> for several speech/audio codecs too.
>
> media packets need to be  cryptographically-independent as indicated  
> in your draft. I'm not sure if this can be seen independent to SRTP,  
> but it may.

There is currently application-level encryption but not  
application-level authentication in the draft.  SRTP is used for  
message authentication.  At minimum, we would want to authenticate  
packets from the source of the stream and SRTP can do that.

Mark
> before encrypting. Aforementioned, some media packets may be dropable  
> other may truncatable. The similar utilization has been outlined at  
> ch. 2.3.2.  Delta_IV.
>
> cheers,
> franz
>
>
>
>
>