Subject: RE: [Sip] TLS section

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jan 2002 11:13:00 -0500

I know this argument well; it's the "any security takes too much
cpu/memory".  I don't buy it.  

At this point, without designing an entirely new crypto package for
SIP, TLS and IPSec are the only viable candidates for hop-by-hop
security.  I don't thing the cpu/memory requirements are much
different for them.

The basic difference has been hashed out on this list for a while -
TLS is TCP only, applications level, with a set of conventions on
PKI that make the solution tractable for servers, and less so for
UAs.  IPSec is a transport layer, UDP or TCP, lacking the above
conventions, but with widely implemented mechanisms for the kind of
secure-tunnel-between-protected-enclave kind of hop-by-hop that 
we need.  For me, the (minor) win with IPSec is that you don't change
the app - you enable the IPsec stuff on the transport.

I don't think the threats that have confidentiality are the big ones;
the threats that need a reasonable degree of authentication (NOT
user authentication, server/device authentication) and integrity
protection are the ones I really worry about. YMMV

If 3G wants to ignore the must implement bit in the UA because they
have their own crypto in the handset-to-base-station link, fine.
We can't write the spec that way.  First hop can be important,
but it's rarely the weak point; you almost always have a proxy
server between the UA and the big-bad-world.  I'd actually like
the spec to say that first hop/last hop security is not mandatory
to implement, because I think that's the real world, but I'm
sanguine about trying to get that through the IESG.  The real
privacy advocates want to see tight confidentiality end to end,
and if you don't implement that in the UA, you don't get it.
The only reason we might be able to get away with HMAC-MD-5-NULL is
that there are quite a few RFCs that have that as the minimum.
I am actually okay with adding DES to the minimum set, but I don't
think we need it.  

The idea that the MINIMUM set includes AES is, to my way of thinking,
a problem, because there are very few implementations today.  Long
term, that is the way I'm heading, let there be no doubt, but do
we mandate that for an RFC releasing next month?

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 10:54 AM
> To: Peterson, Jon; 'Rosen, Brian'; 'Michael Thomas'; [email-masked]
> Subject: Re: [Sip] TLS section
> 
> 
> Jon asked:
> > I think it would be interesting first to learn who on this
> > distribution prefers to provide lower-layer security for SIP with
> > IPSec rather than TLS, and then moreover whether those that 
> do prefer
> > IPSec would rather use transport mode (host-by-host, integrated with
> > SIP applications) or tunnel mode (not integrated with SIP
> > applications, using security gateways).
> 
> Making either one a "MUST" is a BAD idea. It means that far too many 
> smaller systems, or systems with other security mechanisms, can never 
> comply with the specification. 
> 
> The implementors, forced to selectively ignore some 
> requirements of the 
> specification, are likely to ignore other parts of the spec as well.  
> It's kind of like "having shot the security gaurd, you might 
> as well go 
> ahead and rob the bank -- the penalty is not any worse".
> 
> Or those implementors may just demonstrate good sense and 
> switch to an 
> implementable protocol and ignore our further academic and 
> irrrelevant 
> ramblings.
> 
> Requirements which significantly impact applicability must be 
> carefully 
> bounded, with specific exemptions granted and alternatives allowed.
> 
> --
> Dean
>
*********This message is definately not confidential and it does not matter
in practice who sees it and whether or not it goes astray. No harm whatever
would come to anyone even if it were published in a national newspaper. I
apologise therefore for the unnecessary and irritating message that may or
may not follow (I don't know because it is invisible to me)!!!!******

This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 08:40:55 -0800 (PST)

> 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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 19:41:31 +0200

>  > 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.

-- juha

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 29 Jan 2002 09:56:24 -0800

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?

> 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:

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 10:20:47 -0800 (PST)

> username/password is the only thing that needs to be configured in the

   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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 10:18:06 -0800 (PST)

> no one else :-) Could you briefly summarize the 6k and 400k solution?

Sure. IPsec make a clear distinction between key
distribution and per-message crypto transforms.
The base IPsec is described in RFC 2401. It says
absolutely nothing about key distribution; it's
only requirement is that a symmetric key be bound
to a SPI in the IPsec security association
database. How that key gets in there is completely
out of scope, and one of the valid mechanisms is
sneakernet; ie, manual shared keys. While 2401
describes tunnel and transport modes, along with
AH and ESP, in the end it also describes how
security policy is transformed in security
associations. Since it is perfectly valid to have
policies which forbid tunnels and, say, AH, I do
not think it is too much of a stretch to say that
minimal implementations are within the spirit of
2401. In any case, this provably works; I have an
interoperable implementation with Freeswan and it
took me all of about a day and a half to write my
minimal IPsec from scratch. If I knew how to make
that public easily (I did this on Cisco's time),
I'd make it freely available. If enough people
are interested, I'll take on that effort.

TLS on the other hand is a package: it defines
both the per message transport crypto as well as
the key exchange and authentication piece. It does
not allow for manual keying at all. The openSSL
distribution I compiled required over 400kb of
code. While I do not doubt this could be reduced,
it is not possible to come anywhere near the small
footprint I achieved for minimal ipsec precisely
because it cannot be severed from key
distribution, PKI's and all the rest. Key
distribution code -- with its unfortunate use of
krufty ASN.1 -- is quite large. They all suck.
They bring things to the table that I think are
important (both for IPsec and TLS), but in the end
they are quite a large bite to chew for low end
widgets -- ie, the kinds of things we want to get
SIP into.

So for SIP, I think we should be mainly interested
in securing SIP messages instead of solving world
hunger through PKI navel gazing. A credible and
secure system could be built using manual keying
with the possible addition of digest where it's
not practical to access credentials in the kernel
(and this objection is *completely* bogus on most
embedded widgets which almost always have access
to their kernel or net drivers). We know this
model scales. In fact, it's the only model we know
for sure will scale. All the rest is conjecture.

Thus my proposal is simple, it meets requirements,
and it doesn't boil the ocean. The TLS proposal
doesn't meet requirements, is bloated, and
presupposes infrastructures that do not exist.
This really isn't rocket science.

	    Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 13:16:42 -0600

On Tuesday 29 January 2002 12:20 pm, Michael Thomas wrote:
> 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.
>  >
>  > 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.
>

Actually, this is a fairly clean approach, provided that the session 
key can be known to the first-hop porxy, The problem is, the key used 
for digest is generally known only to the UA and to the service point 
doing SIP authentication, and not to intermediate proxies including the 
first-hop proxy. So you need some key management.

For the 3GPP model, it seems like it might  be feasible to 
"dynamically" engage IPSEC between the mobile and the P-CSCF, using a 
session key derived from the key mechanism of the SIM card. 

Here's how it might work. Interproxy connections are covered by IPSEC 
ESP. The mobile-to-proxy connection is initially unprotected. The 
initial REGISTER is sent "in the clear". The authenticating node issues 
a 401, and attaches a session key and a nonce. This session key is 
protected back to the visited proxy by an IPSEC SA chain. The visited 
proxy strips the session key and hands it to the IPSEC layer. The 
mobile then uses the nonce and its smart card to generate a matching 
session key, which it then uses to set up an IPSEC SA with the visited 
proxy. So, we've now used the the AKA key mechanism to set up an SA to 
an intermediate proxy, without compromising any long-term secrets.

But even this usage doesn't address the one-way relationship model 
allowed by TLS, and I think we'll have many requirements for that as 
well.

I see no alternative besides allowing the systems implementor/operator 
to select from IPSEC, TLS, or something else as appropriate to the 
particular system's requirements.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Jan 2002 18:50:40 -0800 (PST)

Dean, 

I'm having a hard time believing that I'm actually
writing this, but you might also consider looking
at the mobile IP AAA keys drafts. Essentially they
have a similar problem but want to leverage AAA
based keys (eg, SIM based probably) to make a
mobile node/home agent/foreign agent security
associations. I'm not a huge fan of this work, but
the considerations you describe seem pretty
similar.

		   Mike