Subject: [Sip] Summary of TLS discussion

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

I'm afraid Mike's summary requires some small amount of clarification. There
are essentially three proposals under discussion for the lower-layer
security function. This lower-layer function should supply hop-by-hop data
integrity and confidentiality, and possibly authentication.

1) TLS: Doesn't support UDP. Has an innate key exchange system. Use of TLS
with an application like SIP is fairly straightforward. A minimum profile
for authentication/integrity/encryption is provided in bis06 today. Opinions
to the contrary notwithstanding, it can probably be implemented in less than
400K of code (a recent IEEE Comm's article claimed 100K).

Then two IPSec proposals (no IPSec minimum profile is proposed in bis06
today), both of which will support UDP.

2) IPSec transport mode: Is integrated into the 'operating system' (in hosts
that have one) and into applications - essentially, it plays a similar role
to TLS (however, since IPSec is modular, it may or not may not instantiate
any of TLS's functions), providing host by host security functions - which
functions, exactly, depends on the profile. Some of the details of
integrating this into applications may be complicated.
3) IPsec tunnel mode: Uses security gateways, and therefore is not
integrated with applications. Essentially uses a VPN to secure SIP clients.
This can be used opportunistically to secure any Internet applications
today.

Mike proposed a minimum profile for IPSec consisting of transport mode ESP
without a means of exchanging keys (manual key exchange required) or a means
of encrypting data, just a means of doing authentication and integrity. In
other words, Mike's proposal does not provide a story for confidentiality.
The ESP standard minimally requires support for DES. Mike asserts that his
profile can be implemented in 6K of code.

Brian Rosen then asked how many people liked Mike's profile. I posed the
parallel question of who preferred transport mode to tunnel mode IPSec. I
think both Brian and I are still interested to hear fresh opinions on these
matters.

Today, the normative text in bis06 strongly RECOMMENDS that UAs support TLS.
Proxies, registrars, and redirect servers MUST support TLS. All SIP entities
MAY support IPSec. UAs MUST support TCP and UDP.

This arguments made in favor of TLS versus IPSec, roughly, have been:

- Mike argues that TLS doesn't meet the requirements because it doesn't
support UDP. Advocates of TLS argue that the requirement is actually to
guarantee that every UA can speak securely to every proxy, not to mandate
that they be able to do so over every transport protocol they support. 

- Mike feels strongly that the lack of centralized public key infrastructure
in the real world means that key exchange is actually useless (in which case
TLS's must-implement key exchange would be a liability, whereas IPSec
modular approach would allow implementers to save some memory). TLS
advocates argue that TLS for SIP will replicate the web model, in which
clients verify the site certificates of servers (in the SIP world proxy
servers and so forth), and that this is in fact quite real and quite widely
deployed. 

- Another factor in the key exchange debacle is that IPSec key-exchange
mechanisms tend to require two-way key exchange, and both sides of this
argument agree that client-side certificates are an unsolved problem
(neither TLS mutual authentication with certificates nor any IPSec mutual
authentication is tractable). TLS advocates would argue that a client can
authenticate itself to a server with some non-TLS method, like Digest. 

- Mike also dislikes X.509 certificates. TLS advocates fall back on their
widespread use for e-commerce today.

- TLS has a good NAT traversal story. On several fronts (enumerated in a
draft by Bernand Aboba), IPSec does not.

- Finally, there has been some talk about whether or not the proposed
minimum profiles meet the requirements. Mike feels that an IPSec minimum
profile should not have to specify a data encryption mechanism or key
exchange mechanism. TLS advocates have argued that SIP requires these
capabilities, and that TLS provides such mechanisms.

That's pretty much it.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 9:56 AM
> To: Michael Thomas; [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> 
> Just to help everyone on the list that has not followed all 
> of this (Me if
> no one else :-) Could you briefly summarize the 6k and 400k solution?
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Michael
> > Thomas
> > Sent: Tuesday, January 29, 2002 8:41 AM
> > To: Rosen, Brian
> > Cc: 'Dean Willis'; Peterson, Jon; 'Michael Thomas'; [email-masked]
> > Subject: RE: [Sip] TLS section
> >
> >
> > Rosen, Brian writes:
> >  > I know this argument well; it's the "any security takes too much
> >  > cpu/memory".  I don't buy it.
> >
> >    In fact, the minimum requirement that I've been
> >    recommending can and has been implemented in 6000
> >    bytes of code. Anybody who can't afford that can't
> >    afford *any* crypto whatsoever since 5kb of that
> >    was just for the hash. This can be done at app layer,
> >    the kernel, or as a bump in the stack. There is just
> >    no excuse at all not to at least do this; it should
> >    be a MUST.
> >
> >    Yet, this very simple thing that could be done, widely
> >    implemented and deployed is being sent off into Siberia
> >    by the IESG in favor of something that requires 400kb
> >    of code, doesn't meet the basic requirements, and
> >    isn't even a MUST.
> >
> >    This is insane.
> >
> > 	   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
> >
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 21:55:49 +0200

> draft by Bernand Aboba), IPSec does not.

i forgot this one.  since nats are nowadays everywhere, the security
solution MUST have a good nat story.  otherwise sip will be dead on
arrival.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 12:03:09 -0800 (PST)

> solution MUST have a good nat story.  otherwise sip will be dead on

   IPsec working group is working on a standards track
   way of doing this. Basically, ESP over UDP.

	  Mike

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 29 Jan 2002 14:20:25 -0600

There are good products that support NAT.

Henry

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Juha
> Heinanen
> Sent: Tuesday, January 29, 2002 1:56 PM
> To: Peterson, Jon
> Cc: 'Cullen Jennings'; Michael Thomas; [email-masked]
> Subject: [Sip] Summary of TLS discussion
> 
> Peterson, Jon writes:
> 
>  > - TLS has a good NAT traversal story. On several fronts (enumerated
in
> a

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 12:21:07 -0800 (PST)

A few minor clarifications:

1) I don't think that PKI's etc are useless. I'm just
   extremely suspicious of any argument which starts 
   with "first we posit a global PKI..."

2) Confidentiality could obviously be included into
   my proposal. I'm pretty neutral here.

3) Making UDP a poor relation to TCP will guarantee
   that most if not all UDP-speaking UA's will be
   done in the clear. I don't find that acceptible.
   Security needs to be available for *all* available
   mechanisms, not just some. Either come up with a
   solution for UDP, or deprecate use of UDP altogether.
  
	Mike

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jan 2002 23:39:17 +0200

Hi,

>    solution for UDP, or deprecate use of UDP altogether.

I disagree with this statement. If you want to have a secure SIP
transaction, you will be willing to accept the TCP 3-way handshake plus
the 2 RTTs to establish a TLS connection. However, if you do not need
security for this particular transaction, you can avoid all these RTTs
by using UDP.

Therefore, you can see UDP as an optimization for systems that do not
want security at a certain point of time. And I believe that having UDP
in the protocol is a valuable optimization.

Regards,

Gonzalo

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 13:26:22 -0800 (PST)

> security for this particular transaction, you can avoid all these RTTs

   Why does it follow that I'd be willing to
   incure TCP overhead just because I want
   security? Secure DNS certainly doesn't 
   make any such assumption. What I really want is
   the fewest possible messages to get the job
   done.

 > want security at a certain point of time. 

   In other words, UDP is a poor relation.

	    Mike

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jan 2002 00:19:34 +0200

Hello,

Michael Thomas wrote:
>    What I really want is

We have two scenarios:

1) we want security for this SIP transaction
2) we do not want security for this SIP transaction

If we do not want security for a particular transaction, "the minimum
number of messages to get the job done" is achieved using UDP. That's
why I believe that deprecating UDP is out of the question.

If we want security, that's another story, and that's what we are
discussing in this thread.

Regards,

Gonzalo

---

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

>    way of doing this. Basically, ESP over UDP.

How does that help? UDP can still fragment, of course, and all
fragmentation is bad as far as a NAT is concerned.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 12:08:34 -0500

Michael Thomas wrote:
>    You can run TCP over IPsec too.

Of course. I was merely questioning your response to Juha that the nat
issues are being addressed by running ESP over UDP, and I was asking why
that helps. 

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Jan 2002 09:02:37 -0800 (PST)

Mike