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

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:39:27 +0200

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

One of the drawback of this mechanism is that it mandates creating
multiple TCP connections between two proxies, this is:

                             P1               P2
Alice  --CONNECT---->------------------> ---------------------> Bob
Carol  --CONNECT---->------------------> ---------------------> Adam
Tomy  --CONNECT---->------------------> ---------------------> Mark

In a normal SIP scenario, if communication between P1 and P2 was TCP
or TLS, P1 would just mantain a single connection with P2. But using
CONNECT as stated in the draft, P1 needs to open 3 TCP connections
with P2 (as neither P1 or P2 can inspect the data transported).

I don't think this "limitation" is a showstopper, but just something
to take into account.

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?

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?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Sep 2011 11:08:43 -0500

> is based on the same mechanism for HTTP/CONNECT (widely deployed).

Thanks!

> certificate, which is uncommon, am I right?

Uncommon, yes.  However, self-signed certificates would work (as long
as the fingerprint was exchanged by some other means).

> but just TCP proxies. How does that fit with current SIP deployments?

It does not.  Understandably, the rub against this work back then,
and I presume now as well, will be that the value proposition of
turning all the intermediaries into simple byte forwarders is
hard to justify.

However, if you are Mick O'Malley [1], then you'd be happy if
such a scheme was provided :-)

[1] "Counting from Zero", Alan Johnston, 2011.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 18:11:40 +0200

> such a scheme was provided :-)

:)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Sep 2011 19:37:11 -0500

Thanks!

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

> 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