Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 29 Jan 2002 13:19:13 -0600

Or maybe Juha would like TLS, because you don't have to do any manually
keying. 

Note that e-commerce requires a global PKI, but only so servers can
authenticate themselves to clients (via TLS). When a client authenticates
itself to a server in the web, it uses HTTP Auth (i.e. Digest) to
communicate a username and password to the server. This assymetry is exactly
what we're proposing for SIP. Distributing keys to servers, and passwords to
users, is not a fantasy - it is a hard reality, and we can re-use this for
SIP.

When you give up that global server-side PKI, you give up the ability for
SIP to be used in arbitrary interdomain contexts, where clients speak
securely to servers they've never addressed before. I think this would be a
great loss for SIP, and I think we need it regardless of whether we choose
TLS or IPSec.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 10:21 AM
> To: Juha Heinanen
> Cc: Michael Thomas; Rosen, Brian; 'Dean Willis'; Peterson, Jon;
> [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> Juha Heinanen writes:
>  > Michael Thomas writes:
>  > 
>  >  >  > I know this argument well; it's the "any security 
> takes too much
>  >  >  > cpu/memory".  I don't buy it.  
>  > 
>  > i don't care of cpu/memory, but i get mad if security makes
>  > configuration of the ua more difficult than what it is w/o 
> security or
>  > if sip phones can't be used without a global pki.  so 
> whatever security
>  > technology is chosen, it MUST be based on self generated 
> keys so that
>  > username/password is the only thing that needs to be 
> configured in the
>  > ua for security.
> 
>    Then you should like my proposal. In fact, you could
>    use the exact same key that you use for digest, as well
>    as share the code for MD5.
> 
> 	    Mike
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 02:17:02 -0500

Let me put my 2 cents in here.

I think this whole debate is silly.

First off, I did not think we indicated that either tls or ipsec was
mandatory for UA; I think both are going to be equally inpalatable or
not useful; we will need to handle that hop other ways. I thought we
were talking between proxies.

I like IPSec; we use it in some places in our architectures where I
don't care that the proxy knows about the identity of the other side,
and I want somehting I can slide in without affecting the proxy
application itself. I also like TLS; I need it in some cases where I
need to know the identity of the peer (inter-provider business
relationships, in particular). There are roles for both TLS and IPSec.
SIP allows both IPSec and TLS. Debating their merits is futile. You use
when when its benefits are more important than its costs for that
particular problem. The issue at hand is which is MUST, and which is
MAY, in terms of implementation.

Arguably, given that there are cases where IPSec is right and where TLS
is right, you should make both of them MUST to provide interoperability.
However, I think I would be visciously beaten by many folks for
proposing that. Instead, a reasonable criteria for deciding might be:
given the set of situations in which a hBh mechanism is needed, under
what conditions would you run into a cross-provider interop situation,
and in that situation, which would be the more appropriate choice for a
mechanism, so that that particular mechanism would be available on both
sides.

Within a single provider network, you can always select products that
support whichever protocol you prefer, so I don't think there is a real
issue there. The main issue will arise cross-domain. In those cases, I
would probably select TLS over IPSec, primarily because I would expect
the proxy application would need to know who it was talking with. I
would also expect that mutual auth based on PKI would be feasible and
desirable here. Whilst that doesn't rule out IPSec, TLS is arguably
easier to do for those things. 

-Jonathan R.

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