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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Nov 2001 15:39:03 -0500

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 1:04 AM
> To: Jonathan Rosenberg; 'Henning G. Schulzrinne'; C. R. Kalmanek
> Cc: [email-masked]
> Subject: Re: [Sip-security] Basic/digest over TLS
> 
> 
> 
> > I suspect you are going to need to keep them open 
> indefinitely to support
> > quick call setups.
> 
> Keeping the session open indefinitely would cause an 
> interesting situation
> in the mobile networks where local proxies are contacted by roaming
> terminals: the proxies would be keeping state not just with 
> everyone who
> is on the area but also those who have been on the area. Does your OS
> support a billion open TCP sessions?  ;-)

I agree its a problem. I am merely suggesting that Basic/Digest over TLS can
help us solve some cases.

> * Unnecessary reliance on public key crypto. There's never enough CPU
>   and power on small mobile devices (if there was, the 
> manufacturer would
>   make the device smaller and the battery to last longer). 
> Are we taking
>   public key crypto because we need it, or because our symmetric key
>   protocols aren't good enough?

TLS only uses PKI for the initial authentication; it causes the exchange of
a symmetric session key thats used for all actual data exchange. So, I don't
see the issue here.

> 
> * Bandwidth. How much extra bandwidth is going to be consumed 
> by sending
>   certificates etc?

Its just at setup, so I don't think its too bad, but I don't have any
figures.

> 
> * Roundtrips. I don't know how many additional roundtrips TLS 
> introduces, but
>    it is essential to minimize them, in order to get the call 
> setup and/or registration
>    delays small. IKE at least introduces currently too many 
> roundtrips for this
>    application (in the order of 9 messages). RTT is *long* in 
> cellular networks.

Right; I would not propose establishing a TLS connection every time you want
to make a call. You more or less need to leave one nailed up for reasonable
performance. That has challenges too, of course.

> * Can we reuse legacy authentication schemes in TLS? This would be
>    important for e.g. 3g folks who would like to reuse 
> existing infra (smart
>    cards, procedures to hand out them, slots in devices, etc.).

SSL does support negotiatble crypto techniques. However, everything you list
above is for client authentication to the server. I am NOT proposing that we
use TLS for that. I am only proposing TLS for the server authentication to
the client. Client authentication to the server follows using SIP basic,
digest, or something else, over that connection.

> 
> * Even if we were able to make TLS perfect in this 
> environment, we still
>    face the problem that it is hop-by-hop. In many cases I see that an
>    end-to-end solution is needed as well, so wouldn't we 
> prefer a solution that
>    can handle both the hop-by-hop and end-to-end protection cases?

TLS + Basic/Digest does not solve the end-to-end problems, but it does
provide some low hanging fruit to solve a few of them. I would NOT advocate
a single mechanism that is the one and only security mechanism for sip,
which is the same for all use cases.

> That being said, I think both TLS and IPsec/IKE are clearly 
> the preferred
> solutions in many cases, e.g. protecting traffic between 
> proxies or within
> a corporate LAN.

Well, I have little faith in IKE, but thats a separate issue.

-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 G. Schulzrinne" <[email-masked]>
Date: Mon, 05 Nov 2001 16:10:21 -0500

> help us solve some cases.

Note that this is a common problem for any state, not just TCP. My
interpretation is that TCP state is no larger than typical secured
connection state, be it IPsec or TLS or anything else. 

> Its just at setup, so I don't think its too bad, but I don't have any

Would be nice if somebody could do a tcpdump to make some measurements.

> performance. That has challenges too, of course.

And this is common to most any protocol that establishes a security
association. Do you want to run IKE for every phone call?

> which is the same for all use cases.

Agreed; if we were to to try to do this, we would 

- have to invent a fairly complicated new security mechanisms, with all
the inherent dangers;

- never get done, given the amount (or lack thereof) of progress we've
so far.

> Well, I have little faith in IKE, but thats a separate issue.

From all that I've heard, IKE is an interoperability nightmare and
recognized as a poorly specified protocol. There's a reason people in
the IETF are talking about son-of-IKE or alternatives for key
establishment.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs