Subject: Network authentication

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 01 Nov 1999 13:16:44 +0200

Hi,

I've seen in a couple of drafts a UAC authenticating itself to the edge
proxy of a certain network (let's say, MCI network).

What about network authentication?

I think it is also important from the user point of view to be sure that
we are "talking" to the real MCI SIP server. This is not addressed in
the drafts released by MCI.

Any ideas?

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Nov 1999 09:57:09 -0500

Hop by hop authentication and encryption (i.e., I am talking to the
proxy I think I'm talking to) does not need to be done within SIP.
Transport level security or IPsec are sufficient for this purpose. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 210 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 01 Nov 1999 17:20:49 +0200

Hi,

> Transport level security or IPsec are sufficient for this purpose.

But if I use IPsec from my client to the proxy the SIP-digest will be
never used, right?

What I mean is that if we use transport level security or IPsec to
assure that the proxy I'm talking to is the "good" one, why do we have
to use the proxy-authorization SIP header? 

Regards,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Nov 1999 09:21:42 -0600

If I understand your qustion, you're asking how does a UAC validate the
authenticity of a network element which has challenged the UAC?

I am currently unaware of any explicitly defined SIP-way to do this. Two
options come to mind:

1) With a PKI, have the network element attach a signature to its 401 or 407

2) As DCS suggests, use IPSEC and push the network security problem to the
network layer.

As we have neither a widely deployed PKI nor widely available working IPSEC,
neither option made it into the examples. The suggestion box is open . . .

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Nov 1999 11:10:46 -0500

> neither option made it into the examples. The suggestion box is open . . .

I assume the reason you worry about this is because somebody might trick
you into registering with the wrong server and thus gain access to
location information, for example. Any other vulnerabilities?

SSL seems like the right solution. Widely available and can re-use
existing keys.

It wouldn't be too hard to "reverse" digest authentication. One could
ask for a signed response for an OPTIONS and then use the same TCP
connection to register.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Nov 1999 09:25:56 -0500

Michael Thomas wrote:
> 
> If I am not mistaken, SSL only runs on a stream
> transport (read: TCP). For ALF based SIP's, that's
> a problem.

Many SIP implementations can use either UDP or TCP. Indeed, one reason
for supporting TCP (besides signaling trunks) is the ability to use SSL.
Use of SSL over UDP hasn't been done yet, although I don't see this as
requiring more than dealing with mapping SSL messages to UDP datagrams.

Another possibility for security, largely unexplored, is the use of
shttp-like techniques (RFC 2660). My impression is that this isn't
widely used, though.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Nov 1999 06:06:36 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Nov 1999 15:28:57 -0800 (PST)

> requiring more than dealing with mapping SSL messages to UDP datagrams.

   This strikes me as the tail wagging the dog. 
   A deployment should choose a transport and then
   figure out how to secure it rather than the
   other way around. 

	     Mike

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 05 Nov 1999 10:13:44 +0200

Hi,

> location information, for example. Any other vulnerabilities?

If we assume that the user is authenticated by the network, and we trust
everything coming from the network (the SIP proxy), the "bad" SIP proxy
would make you think that the other party is busy, or that the
other-party is not willing to join the session (denial of service).

It could also make you think that you are having a session with your
bank and this way get some confidential information. (If the SIP proxy
tells me that I am talking to my bank, I will trust it).

I will negociate end to end user plane encryption with a "bad" end user.
They could record the voice mail that I think I am leaving in my
friend's answering machine...

I believe we need to use end-to-end authentication and network-to-end
user also. Not just end user-to-network.

Regards,

Gonzalo

---

From: "Stephen Thomas" <[email-masked]>
Date: Fri, 5 Nov 1999 06:27:29 -0500

|  > Many SIP implementations can use either UDP or TCP. Indeed, one reason
|  > for supporting TCP (besides signaling trunks) is the ability to use
SSL.
|  > Use of SSL over UDP hasn't been done yet, although I don't see this as
|  > requiring more than dealing with mapping SSL messages to UDP datagrams.
|
|    This strikes me as the tail wagging the dog.
|    A deployment should choose a transport and then
|    figure out how to secure it rather than the
|    other way around.

A couple of thoughts on this thread:

1) Actually, there is a variation of TLS defined for UDP. It's the
   Wireless TLS standard developed by the Wireless Application
   Forum (www.wapforum.org). I don't know if anyone has actually
   implemented it.

2) I could make the argument that any real commercial deployment
   should first figure out its security requirements, then
   decide the security infrastructure, and, only then, determine
   the transport approach that fits within that security
   infrastructure. Leaving security as an afterthought has
   gotten a lot of people in trouble in the past. In this
   context it's worth noting that 40+ years of practical
   experience has unequivocally shown that there is a strong
   incentive for folks to try to get "free phone calls."

Stephen