[VOIPSEC] Using SRTP for University project

[Mark Baugher]

On Mar 27, 2006, at 10:20 AM, Hadriel Kaplan wrote:

>
>
>> -----Original Message-----
>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec- 
>> bounces at voipsa.org] On
>> Behalf Of Mark Baugher
>> Sent: Monday, March 27, 2006 12:16 PM
>> To: Cesc Santasusana
>> Cc: Voipsec at voipsa.org; Christian.Stredicke at snom.de
>> Subject: Re: [VOIPSEC] Using SRTP for University project
>>
>> I expect that we are still a long way off from the final key
>> establishment and key management solutions for IP telephony.  Whether
>> or not sdesc is the final answer is far from certain.  Regarding
>> security, those who have read the latest sdescriptions draft should
>> recognize that S/MIME is required for end-to-end security through
>> intermediate systems, even S/MIME with self-signed certificates and a
>> user-to-user authentication procedure (e.g. reading the fingerprint
>> of the public key over the phone) offers good security.  Why don't we
>> use this as the interim solution for those implementations that are
>> using sdesc?
>
> S/MIME is only "required" if you don't trust the intermediate  
> systems to
> follow sips rules.

I'm not sure why you say this but it is not based on draft-ietf- 
mmusic-sdescriptions-12.txt.  It's true that the applicability  
section recommends either sips or s/mime.  But I don't find your  
interpretation in this document.  This is what the document says on  
the topic:

"When the communication path of the SDP message is routed through
intermediate systems that inspect parts of the SDP message, security
protocols such as IPsec or TLS SHOULD NOT be used for encrypting
and/or authenticating the security description.  In the case of
intermediate-system processing of a message containing SDP security
descriptions, the "a=crypto" attributes SHOULD be protected end-to-
end so that the intermediate system can neither modify the security
description nor access the keying material.  Network or transport
security protocols that terminate at each intermediate system,
therefore, SHOULD NOT be used for protecting SDP security
descriptions.  A security protocol SHOULD allow the security
descriptions to be encrypted and authenticated end-to-end
independently of the portions of the SDP message that any
intermediate system modifies or inspects:  MIME secure multiparts
are RECOMMENDED for the protection of SDP messages that are
processed by intermediate systems.  "

It might be that this is not realistic owing to the changes that are  
required in the infrastructure.  Saying this is much different than  
saying that sips offers good security.

> If that's true, you're probably in a world of hurt
> anyway.

An end system has no way of knowing what devices are handling the  
call message.  So you are in fact in a world of hurt if you want a  
secure end-to-end phone call when the message is routed through  
unknown and unknowable intermediate systems.

> And you don't seriously expect people to read out hex values over
> the phone before talking, do you?  Somehow I think that will make  
> for a lot
> more car accidents due to cell phones.  :)

You misunderstand the process.  One does not do this for each phone  
call or even necessarily for the initial phone call, although that's  
an obviously good time to establish a secure association with a user  
who calls you or whom you are calling.  As has been pointed out on  
this list before, the procedure is done once, the key is admitted to  
a key ring or something like that, and then subsequent (even future)  
calls can be authenticated end to end.

>
> (note I'm talking about the 99.9% population, not the DoD)

Most people won't do this, just as most people do not use secure  
email.  But we need to have these things for people who do want to  
use it and at least some means to determine if a secure call is being  
spoofed.  The good alternatives involve third-party or device (e.g.  
sim card) infrastructure such as SIP Identity. In the absence of such  
infrastructure, it is a poor security solution in which a user cannot  
even tell if their call security has been subverted.
>
>> I have heard from a few persons that S/MIME is not deployable, but I
>> have not yet heard from anyone who has tried to deploy it.  I'd be
>> interested in hearing about those experience.
>
> It depends on your application.  If you want your sip call to work  
> through
> most service providers (and my guess is enterprises) today, and in the
> foreseeable future, then s/mime won't work. So why would you use a  
> mechanism
> which only works inside your own environment?

SRTP will only work inside an environment in which all the phones are  
changed to use SRTP.  Obviously, some parts of the environment must  
be changed.  Perhaps your point is that there are some parts of the  
environment that are too hard to change.  Why not say that?

>
>> But if you're sending the keys in the clear through multiple proxies,
>> this is not a secure solution.  I agree with that.
>
> Agreed.  Hence SIPS, i.e. TLS, or stronger is mandated.

If you are going to rely on sips for security, then you need to  
explain how one can control or even detect which proxies handle the  
calls, at minimum.  I haven't heard such an explanation.  The reason  
that we have several new proposals for voip key management is because  
sips alone is not considered to be good enough security for  
establishing secure voice calls.

Mark

>
> -hadriel