Subject: [Sip] Bis-5: TLS as secure transport for SIP

From: "Shieh, Hugh" <[email-masked]>
Date: Fri, 2 Nov 2001 16:19:53 -0800

line: 2977. It was recommended that TLS as a secure transport for SIP.

This is different from what's in bis04, has this been discussed and agreed
on the list?

Since TLS relies on some reliable transport protocol (e.g., TCP) at lower
layer, TLS will not work directly on top of UDP.

I am also confused by the sentence in 2970-2973. TLS is NOT a transport
protocol like TCP or UDP, the primary goal of the TLS Protocol is to provide
privacy and data integrity for an underline reliable transport protocol like
TCP.

Regards,

-Hugh

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 3 Nov 2001 09:07:16 +0200

[Sip] Bis-5: TLS as secure transport for SIP
I have been wondering about this too, and have the same questions as Hugh
did. Furthermore, I have trouble understanding the trust model explanations in
lines 2967-2973. TLS and IPsec are both hop-by-hop models, so they're both
suited to environments where either one hop is sufficient protection, or where
you have some chain of trust. (One true difference the text neglects to mention
that TLS could be run in a one-sided manner with certs only the server side and
HTTP authentication to the other direction, which eases its deployment in
situations where you have a large number of clients towards a small number of
servers.)

Trouble is, I'm not very happy about either TLS or IPsec/IKE on the client
side, if we are talking about the wireless environment. Delays, need to
do public key cryptography, etc seem hard issues and I'm not sure we
really need them.

As for the communication between servers and proxies there's also a couple
of hard requirements to handle. For instance, as [1 sec 6.24] points out, there
is a need to make it scalable to a large number of nodes. IPsec generally
can deal with this better given that it is typically placed on security gateways,
possibly hiding many proxies of an operator behind it. Plus, you can tackle
other important traffic within the same tunnels.

In the third generation mobile networks, IPsec is going to be used as
a protection to get the network elements talk to each other securely.
For the communication to the 3g terminals, I think we need something
more lightweight than TLS or IPsec/IKE. Perhaps improved versions of
HTTP Digest could do the job. How are we by the way progressing on 
the Undery draft and other proposals in this direction? Are they going to be
integrated to RFC 2543 BIS or not?

Finally, I think all of this h2h is necessary but I wish we could be making
some progress in end-to-end security for SIP as well. I don't always see
myself trusting those proxy chains...

Jari
[1] http://www.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-00.txt

_______________________________________________
Sip mailing list  http://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: Sat, 3 Nov 2001 09:42:48 +0200

Jari Arkko writes:

 > more lightweight than TLS or IPsec/IKE.

how about hip?

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Nov 2001 10:55:31 -0800 (PST)

>  > more lightweight than TLS or IPsec/IKE.

   At a fundamental level these things all have
   to do similar things. If you want encryption,
   you need to have an encryption algorithm. If
   want the ability to create a secret out of 
   nothing, you need public key cryptography,
   and so on. I've compared the sizes of TLS 
   and IPsec on my Linux box and not surprisingly,
   they're almost exactly the same.

   I, like Jari, am concerned about this for small
   widgets but am afraid that there's no silver
   bullet. Beyond outlawing ASN.1, I think the
   most likely avenue is to profile existing
   protocols to their bare bones (minimal
   # algorithms, specialized ASN.1 parsers, 
   etc, etc) rather than trying to create a
   "lightweight" protocol which invariably isn't
   lightweight after it's been in the standards
   body feeding lot for a few years. Oh, and pray
   for Moore's Law :-)

	      Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 4 Nov 2001 18:05:13 +0200

>    and so on. 

You need something, but I'm not sure it has to
be public key cryptography. As an example,
the folks who want to build the 3g multimedia
system have recently built successfully a distributed
network with 500 million clients (gsm) using symmetric
cryptography. I really don't want to go and explain
to them that we need public cryptography because
the multimedia network is so big!

Yes, public key cryptography is very useful in
many cases. However, I think we should allow
also simpler, symmetric methods to be used
because there doesn't seem to be any reason
why they couldn't work in the domains they are
suited for. For instance, given something like
Undery's draft on improving digest, we could
integrity protect SIP signaling h2h and e2e
with simple passwords. Yes, there's a lot of
things to fix but...

Jari

---

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Nov 2001 10:46:44 -0800 (PST)

> the multimedia network is so big!

   Note my "if" above. Public key cryptography
   is useful in many cases, but it's got a whole
   list of drawbacks as well. Part of why I like
   Kerberos is that it doesn't force you to use
   public key cryptography.

	      Mike

---

From: "James Undery" <[email-masked]>
Date: Mon, 5 Nov 2001 13:01:29 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jari Arkko

[sniped]

> integrated to RFC 2543 BIS or not?

Obviously I'd be glad to see it integrated :-), however, there appears
to be little interest in the draft even as a short term solution.
There are a number of changes I've thought about since to prevent step
down attacks although. i.e. including the available methods in
plaintext in the nonce so "SIP Digest" aware browsers would be able to
check, yet still allow Digest to work on older clients. (Obviously the
rest of the nonce should be unguessable.)

James