[VOIPSEC] Using SRTP for University project

[Hadriel Kaplan]

Hi Mark,
Comments inline...

> -----Original Message-----
> From: Mark Baugher [mailto:mbaugher at cisco.com]
> Sent: Monday, March 27, 2006 2:10 PM
> To: Hadriel Kaplan
> Cc: 'Cesc Santasusana'; Voipsec at voipsa.org; Christian.Stredicke at snom.de
> Subject: Re: [VOIPSEC] Using SRTP for University project
> 
> 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.  "

Those statements are only at SHOULD strength.  You said "required", which I
don't consider SHOULD to be. (that's why I put required in dquotes in my
original email response)

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

I didn't say sips offers "good" security.  I said it offers sufficient
security, given the constraints. (well... I implied that anyway)

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

Yup, of course.  An end system only knows its local tls hop, and has to
trust that the intermediate systems follow sips rules.  The rub is
definitely that they rely on transitive trust, and if the chain-of-trust is
broken they're in trouble.  My only point was if the chain is broken they're
in trouble anyway, because their signaling says a lot, and can be
manipulated, spoofed, rejected etc. (of course that's a generalization, but
I think you get my point)  If you don't want it going through intermediate
systems, don't send it through the first one you don't control.

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

Yup, I understood that.  Maybe it's just me, but I get and make a lot of
cell calls to new parties (conference calls especially), and I doubt my cell
has enough memory for a key ring the size of my speed-dial.  But I have the
cheap free cell phone. :) 
I was somewhat joking about the car thing, although I'm not joking about
changing basic user communication behavior being a bit unrealistic.  Zrtp
though has the advantage that at least it gives you some eavesdropping
protection if you don't care about authentication.  Although really a
middle-man could then do ZRTP back-to-back and you'd know no better (I
think?) - it's the key verbalizing that provides the real (authenticated)
security if I recall.  

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

Absolutely we agree on that.  If someone wants to make a secure call they
can feel free to use s/mime or better, plus zrtp, plus speak in pig-latin.
They can do whatever they wish.  Just don't expect the signaling to flow
through most service providers for s/mime, that's all. (and by that I mean
don't expect it to be sip-forwarded through all of their sip infrastructure
- it will probably work transparently through/across their IP network)  Zrtp
may work through it in some cases, some cases not.

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

All I meant was that you said you heard s/mime was not deployable - to which
I said if you want to get it through a service-provider's sip
infrastructure, it won't work.  Since the user has no power to change that,
other than not using service providers, their change of environment to
s/mime is not that useful. (Since it is probably the call through the
service-provider they're worried about the most)

But yes, I definitely think there are some parts of the environment that are
practically impossible to change, to meet the needs/wants of everyone.

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

There is no way to detect the proxies or control them (part of the point is
their owners don't want you to).  You have to trust the owner.  If you don't
trust them, then I don't know why you'd want to use them.

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

I don't think that's the only reason. Or at least I hope that's not the
reason. (otherwise there should only be one other mechanism, as opposed to
11 different ones)  Dan Wing's summary table slide at the IETF put it very
succinctly I think.  Each has pro's/con's. 

I was only referring to the one that in my opinion has the best chance of
widespread use. (which in my opinion is one that will work through the most
service-provider sip infrastructures - but other opinions will vary, and
some people would prefer it not work through service-providers at all)

-hadriel