Subject: [MMUSIC] Optional SRTP?

From: "Rick Porter" <[email-masked]>
Date: Thu, 30 Mar 2006 11:14:40 -0500

How do you make a call and optionally do SRTP? I'd like to have a single
media stream that may do encryption, if the other end supports it.

Thank you,
Rick

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Alan Johnston <[email-masked]>
Date: Thu, 30 Mar 2006 11:23:23 -0600

Rick,

This is an important requirement that I call opportunistic media 
encryption.

Unfortunately, all the current solutions today require a separate RTP 
profile for secure vs. non-secure media.  As a result, a single media 
stream (m= line) must be either secure or non-secure.  The only solution 
today is to offer two separate SDP offers - one with a secure media 
stream, the other insecure, and send them as multipart alternative in 
SIP.  Unfortunately, support of mulitpart alternative is optional in SIP 
and causes many current UAs to crash and often doesn't even generate the 
correct error response.

Another bad alternative is to offer a secure SDP offer first, and then 
if it fails, send a second insecure SDP offer.

ZRTP (draft-zimmermann-avt-zrtp-01.txt) supports opportunistic media 
encryption because it is an extension to RTP and uses a normal m= line 
in the SDP.  If both endpoints support ZRTP, the session switches to 
SRTP.  If one side does not, the call continues as RTP.

Opportunistic encryption could be supported by other approaches as well 
if the a=crypto and a=key-mgt attributes could be used with a normal 
non-secure m= line.  As an optional attribute, the keying material would 
simply be ignored if the other UA does not support SRTP.

All devices that support opportunistic encryption also require a user 
interface to let the user know if the media is secure or insecure.  For 
example, audio tones or graphics can be used for this.

Thanks,
Alan

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Mar 2006 18:56:25 +0100

Rick,

It's important to note that there was a lot of discussion on this  
subject in the MMUSIC and AVT working groups, and the RAI area  
meeting, at the IETF last week. The zrtp draft is one of many  
proposals, and it is by no means clear that there is consensus on any  
single approach.

Colin

On 30 Mar 2006, at 18:23, Alan Johnston wrote:

> Unfortunately, all the current solutions today require a separate  
> RTP profile for secure vs. non-secure media.  As a result, a single  
> media stream (m= line) must be either secure or non-secure.  The  
> only solution today is to offer two separate SDP offers - one with  
> a secure media stream, the other insecure, and send them as  
> multipart alternative in SIP.  Unfortunately, support of mulitpart  
> alternative is optional in SIP and causes many current UAs to crash  
> and often doesn't even generate the correct error response.
>
> Another bad alternative is to offer a secure SDP offer first, and  
> then if it fails, send a second insecure SDP offer.
>
> ZRTP (draft-zimmermann-avt-zrtp-01.txt) supports opportunistic  
> media encryption because it is an extension to RTP and uses a  
> normal m= line in the SDP.  If both endpoints support ZRTP, the  
> session switches to SRTP.  If one side does not, the call continues  
> as RTP.
>
> Opportunistic encryption could be supported by other approaches as  
> well if the a=crypto and a=key-mgt attributes could be used with a  
> normal non-secure m= line.  As an optional attribute, the keying  
> material would simply be ignored if the other UA does not support  
> SRTP.
>
> All devices that support opportunistic encryption also require a  
> user interface to let the user know if the media is secure or  
> insecure.  For example, audio tones or graphics can be used for this.
>
> Thanks,
> Alan
>
> Rick Porter wrote:
>

---

From: Mark Baugher <[email-masked]>
Date: Thu, 30 Mar 2006 10:14:50 -0800

hi,

On Mar 30, 2006, at 9:56 AM, Colin Perkins wrote:

> proposals, and it is by no means clear that there is consensus on  
> any single approach.

The issue that Rick mentions below is common to all potential  
solutions.  RAI needs to explore the problem of how to securely  
identify whether a remote endpoint supports SRTP under the threat of  
a potential bid-down attack and the problems of legacy  
infrastructure.  Cullen Jennings and Dan Wing have authored a draft  
on this topic, which is a place to start.  It's a hard problem.   
There is supposed to be a mailing list established under the auspices  
of the RAI to discuss SIP key management and this topic probably can  
best be considered on that list.

One more thing:  The term "opportunistic encryption" is already being  
used to mean something unrelated to negotiating an SRTP session.  I  
recommend that we find a different term or else we're condemned to  
always have to explain the distinction.

Mark
>> RTP profile for secure vs. non-secure media.  As a result, a  
>> single media stream (m= line) must be either secure or non- 
>> secure.  The only solution today is to offer two separate SDP  
>> offers - one with a secure media stream, the other insecure, and  
>> send them as multipart alternative in SIP.  Unfortunately, support  
>> of mulitpart alternative is optional in SIP and causes many  
>> current UAs to crash and often doesn't even generate the correct  
>> error response.
>>
>> session switches to SRTP.  If one side does not, the call  
>> continues as RTP.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Mar 2006 15:36:37 -0500

At the risk of diving into a topic where I am a novice or less...

I suspect that the desired behavior can't be distinguished from a bid 
down attack. In many cases being potentially subject to bid down is ok. 
As long as the user knows whether a secure session is or is not 
available he can moderate behavior appropriately. And often the user 
will be able to decide whether the absence of a secure session is "odd".

So, the lack of a way to formally detect a bid down attack is not a big 
problem to me.

	Paul

Mark Baugher wrote:
> identify whether a remote endpoint supports SRTP under the threat of  a 
> potential bid-down attack and the problems of legacy  infrastructure.  
> Cullen Jennings and Dan Wing have authored a draft  on this topic, which 
> is a place to start.  It's a hard problem.   There is supposed to be a 
> mailing list established under the auspices  of the RAI to discuss SIP 
> key management and this topic probably can  best be considered on that 
> list.
> 
>>> media stream (m= line) must be either secure or non- secure.  The 
>>> only solution today is to offer two separate SDP  offers - one with a 
>>> secure media stream, the other insecure, and  send them as multipart 
>>> alternative in SIP.  Unfortunately, support  of mulitpart alternative 
>>> is optional in SIP and causes many  current UAs to crash and often 
>>> doesn't even generate the correct  error response.
>>>
>>> encryption because it is an extension to RTP and uses a  normal m= 
>>> line in the SDP.  If both endpoints support ZRTP, the  session 
>>> switches to SRTP.  If one side does not, the call  continues as RTP.
>>>
>>> material would simply be ignored if the other UA does not support  SRTP.
>>>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 30 Mar 2006 15:37:35 -0600

I agree completely with Paul.  A requirement is that the human user be 
informed whether the session is secure or not.

We must develop a truely deployable security solution or else we have 
failed.  What we have today is not deployable - talk to any implementer.

Thanks,
Alan

Paul Kyzivat wrote:

> down attack. In many cases being potentially subject to bid down is 
> ok. As long as the user knows whether a secure session is or is not 
> So, the lack of a way to formally detect a bid down attack is not a 
> big problem to me.
>
>     Paul
>
> Mark Baugher wrote:
>
>> hi,
>>
>> There is supposed to be a mailing list established under the 
>> auspices  of the RAI to discuss SIP key management and this topic 
>> probably can  best be considered on that list.
>>
>> One more thing:  The term "opportunistic encryption" is already 
>> being  used to mean something unrelated to negotiating an SRTP 
>> session.  I  recommend that we find a different term or else we're 
>> condemned to  always have to explain the distinction.
>>
>> Mark
>>
>>>
>>> Colin
>>>
>>>
>>>