[VOIPSEC] Using SRTP for University project

[Mark Baugher]

Christian,
   I agree with you.  The issues related to the integrity and privacy  
of at least parts of the signaling message are important voip  
security concerns.  Without some secure multiparts solution such as S/ 
MIME or PGP/MIME, I don't think this issue can be addressed.

Mark


On Mar 27, 2006, at 11:55 AM, Christian Stredicke wrote:

> Well one good reason for using sdes is actually that there might be
> other sensitive information like ICE passwords and IP addresses  
> that are
> also security-sensitive. The SRTP key is not the only thing that needs
> protection!
>
> And using S/MIME is just a consequent answer. There is a need to  
> protect
> the whole SDP body, not only parts of it.
>
> CS
>
>> -----Original Message-----
>> From: Mark Baugher [mailto:mbaugher at cisco.com]
>> Sent: Monday, March 27, 2006 2:16 PM
>> To: Hadriel Kaplan
>> Cc: 'Cesc Santasusana'; Voipsec at voipsa.org; Christian Stredicke
>> Subject: Re: [VOIPSEC] Using SRTP for University project
>>
>>
>> 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
>>
>>
>>