Subject: [Sip-security] Basic/digest over TLS

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 21:13:40 -0400

Folks,

One of the problems with the basic and digest mechanisms in SIP is that they
assume a very short lived relationship between the client and the server, as
was the case for HTTP in the beginning as well. In such a short lived
relationship, establishment of session keys between a UA and a proxy makes
little sense, and thats why that functionality was not initially provided.
It was our initial vision that proxies would be pure forwarding engines, and
thus most useful authentication would be primarily between UAC and UAS, not
between users and proxies. 

However, things have changed, and it seems people are very much interested
in more long lived relationships between clients and proxies, and
authentication/integrity/privacy in that relationship is important.

There is a very simple solution for this. A UA establishes a TLS connection
with its server, and this TLS connection is used for all communications, in
both directions, between the UA and the server. When the UA sends the first
request over that connection, the server challenges it, using basic or
digest, and therefore associates a user identity with messages arriving over
that connection. That initial message can be REGISTER, or it can be INVITE. 

From then on, the server need not challenge any requests. The TLS conenction
provides a persistent session key. If the connection breaks, the UA
re-establishes, and the same thing happens again.

This approach is not at all dis-similar to the way http has evolved, where
user ID is done primarily using passwords sent over TLS connections that use
server side certs only. 

The penalty, of course, is a whole lot of really long lived TCP connections
hanging off a proxy, and the requirement for client establishment of the
connection in order to secure identity. Persistent TCP is also probably
going to be problematic for devices, like wireless handsets, which are only
intermittently connected. However, that seems to be an issue of much
controversy.

This capability requires no extensions or changes to SIP, and would work
with pretty much any client that supports TLS. Its merely a server side
behavior - don't challenge requests over a TLS connection more than once. 

This mechanism provides quite a lot of whats needed - request and response
authentication between UAC/proxy and proxy/UAS, integrity for those
relationships, and privacy over those relationships.

Comments?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Oct 2001 00:30:59 -0400

I agree (having advocated TLS for years...). I'm not clear whether the
direction of the TCP connection has to be the same as that for TLS,
i.e., could the TCP client (SIP proxy) be the TLS server? There doesn't
seem to be an inherent coupling of the two roles. I vaguely remember
that the two TCP parties can negotiate their role at the TLS level.

This doesn't address the end-to-end protection case, but I suspect that
S/MIME for message/sip handles most of the interesting cases, in
addition to an improved version of Digest that includes headers in the
digest.

Can we go home now :-)?

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Tue, 23 Oct 2001 11:31:11 -0400

Hi,

This framework (TLS/certs for server auth + http basic or 
digest for client auth) seems to meet most requirements:

+ it can be used between clients and servers that are either
  inside (easy) or outside firewalls
+ it provides mutual authentication
+ TLS connection provides both message privacy and integrity

There seem to be a few remaining questions that we need to have
answers to:

Assuming TLS connections are long-lived, how scalable is this
solution?  Web servers have not had to deal with persistent
connections that last essentially forever, from huge numbers
of clients.  Scalability may not be an issue in the short
term, but we need to take a longer view.

Can TLS connections be initiated from server->client? (so we
don't need to keep them around forever).  If so, what is the
impact on session establishment delay?  

IMHO, there is real value to having a UDP based solution that
is equivalent to TLS in functionality.  IPSec could provide
this, if combined with an acceptable key management scheme
(not necessarily IKE) and if server implementations allow
adequate visibility into the security association that a 
packet arrived on.

Any comments on the scalability issue?

Not sure we should go home just yet :).

chuck

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 23 Oct 2001 15:49:17 -0400

"C. R. Kalmanek" wrote:

> term, but we need to take a longer view.

Would the session lifetimes be much longer than, say, for a web banking
or order application, where it's probably also on the order of minutes
to tens of minutes? 

> impact on session establishment delay?

I'm not sure, but according to Thomas, "SSL and TLS Essentials", the
(TCP, I assume) server can ask a client to restart the connection
(Section 4.5.1), using HelloRequest.

Also, this seems to be primarily a memory issue. Anybody know how much
state is consumed by a TLS connection, above and beyond TCP state? If we
assume 1 kB and 20,000 connections, which seems high for a single
server, that's 20 MB, which costs roughly $3.

> adequate visibility into the security association that a

In one of my network security exams, I asked students what it would take
to run TLS on top of UDP. We didn't do a careful analysis, but my
perception is that the record layer would have to be modified a bit, but
it wouldn't affect the rest of the protocol. However, I don't think this
is necessary, since the TCP state isn't that big a deal. 

> Any comments on the scalability issue?

See above.

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

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Tue, 23 Oct 2001 18:28:35 -0400

Responses below.

> or order application, where it's probably also on the order of minutes

To minimize post dial delay, sessions may need to be up for a very long
time.  

> (Section 4.5.1), using HelloRequest.

If this works (I'm not sure either), the ClientHello would presumably
include a Session ID to indicate that it wants to reuse a previously
existing connection.  This still involves TCP's 3-way handshake, but
is faster than initiating a TLS session from scratch.

One other concern is that TCP's congestion control algorithm is not
well matched with the performance requirements of signaling.  The
standard 500 ms retransmission timer is huge compared with post
dial delay budget, and even worse if multiple losses cause an
exponential timer backoff -- hidden in the kernel and invisible
to my signaling application... 

> server, that's 20 MB, which costs roughly $3.

True enough.  Although implementors seem to be very concerned about
large numbers of held TCP connections.

> is necessary, since the TCP state isn't that big a deal.

It's probably more complicated than that, message order issues would
need to be addressed, etc.  But it would be good to have a version of
TLS over UDP...