Re: [sipcore] About draft-gurbani-sip-sipsec

[Dean Willis <[e-mail]>]

On 9/16/11 9:39 AM, Iñaki Baz Castillo wrote:
> Hi all,
>
> I would like to comment about draft-gurbani-sip-sipsec "The SIPSEC
> Uniform Resource Identifier (URI)".
> I like the idea proposed there. Even more taking into account that it
> is based on the same mechanism for HTTP/CONNECT (widely deployed).
>

Thanks!

>
> Another "issue": The draft requires that the TLS negotiation is made
> by both endpoints (let's say two phones), so the UAS MUST have a TLS
> certificate, which is uncommon, am I right?

I understand that comodohacker has made certs widely available. You 
wanna be gmail for a day?

Seriously, yes, you're right. And this is a major "design feature", not 
unintended. It gives us real "end to end" authentication and privacy, 
subject to the strength of the certificate issuance process (see: 
comodohacker).

As Vijay pointed out, you can issue your own certificates if you and 
your partner work out the trust relationships outside of the usual CA 
process. The certificate used can also be dynamically varied with the 
target identity.

This works nicely in the enterprise space, for example.

Let's say as a consultant working for many clients, each gives me a cert 
to use when talking with them. My UA can key off the remote domain 
identifier in order to know which cert to present during handshake.

However, nothing about the protocol really demands mutual cert-auth. It 
should be possible to use HTTP-style cert-auth of the UAS and digest 
auth of the UAC.

On the other hand, you're going to need a cert to answer the phone, so 
you might as well use it when making calls, too.


> And the last comment: proxies in the path cannot inspect the SIP
> traffic through the established connection so they know nothing about
> what's happening in the call or transactions. Proxies cannot do
> accounting or whatever other action as they are not SIP proxies now,
> but just TCP proxies. How does that fit with current SIP deployments?

That's another feature, not a bug. Current SIP deployments are mostly 
MITM attacks waiting to happen.

Where this becomes incredibly important is P2PSIP (aka SIP/RELOAD). When 
some other bozo's box is acting as your proxy, do you really want it 
doing "accounting or whatever other action" on your SIP messages?

Further, the processing load on the proxies is hugely decreased. Not 
only can they stop worrying about wiretapping every SIP message (as such 
would be pointless), they no longer require the overhead of having to 
decrypt each message before logging it and then re-encrypting it before 
resending it. This makes them hundreds of times more scalable.

It's a win-win for everybody who matters.

Of course, this also works well for criminal conspiracies that have a 
good IT department and can mint and share their own certs out-of-band. 
I'm OK with that. Note that the presence of a communication between the 
two endpoints is still revealed; it's just the text of the signaling 
between them that is protected by the protocol, so snoops could still 
get a "pen register", which in the US is typically a warrantless request 
anyhow. True anonymity is much harder; what is needed is a TOR-ified 
version of the protocol, and that still reveals two half-calls.

--
Dean




--
Dean


--
Dean