[VOIPSEC] Using SRTP for University project

[Christian Stredicke]

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