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

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 3 Nov 2001 14:59:03 -0600

The proposed RECOMMENDED for TLS is not without controversy - there are a
number of diverse architectures in which SIP will undoubtedly be deployed,
and it is tough to say whether any recommendation should be made at all
since nothing will satisfy the requirements of every architecture. 

So why recommend TLS for SIP (as opposed to IPSec)? Three reasons come to
mind that, while they are necessarily somewhat general, apply to the most
common architectures in which TLS and IPSec are used:

- Because TLS secures just a single SIP connection. rfc2543bis should
provide a means of securing SIP that is independent of securing other
services or connections. In some architectures it would be a serious flaw if
the security association that allows you to authenticate SIP messages sent
to a proxy were also used to authenticate, say, telnet sessions to a proxy -
but this is often desirable for architectures in which IPSec is used.

- Because use of TLS is reflected in the SIP protocol. The application
therefore has direct knowledge of the use of a secure transmission
mechanism, and uses this knowledge to populate the 'sent-protocol' in Via
headers or the 'transport-param' in various URI. In fact, an application
could even inspect the trail of Via headers to determine how many hops of a
signaling chain went over TLS. In many IPSec VPN architectures,
authentication and encryption are performed outside the context of the
application (at an operating system level, or even on a separate network
host) - precluding any application-layer visibility into security
associations.

- Because a proxy server or user agent might not just want to know THAT a
message was authenticated, but WHAT identity that authentication proved.
Again, in many IPSec architectures when authentication is performed outside
the context of the SIP application, the application has no way to gain
access to this identity. A proxy server or user agent may want to make
behavioral decisions based on policies that apply to the identity of
requestors. This isn't to say that TLS doesn't admit of architectures in
which streams are aggregated or the identity of the originating party is not
passed to applications that want to view them for whatever reason, but it
seems easier for a TLS proxy to introduce some token into SIP signaling
identifying the originator of the request than it would be for, say, a
router implementing an IPSec VPN.

I understand why 3G mobile networks (which have something in common with
large VPNs) might want to use IPSec for security - it is perfectly valid for
a great number of architectures. The reasons given above are necessarily
generalizations, and nothing in rfc2543bis05 is intended to discourage the
use of IPSec when appropriate. Some parties working on the SIP standard just
felt that SIP should have a 'story' about non-HTTP-based security that went
beyond some hand-waving about lower layers taking care of it. Of course,
that's why it isn't a MUST, or even a SHOULD - just a RECOMMENDED.

I'd be interested to hear how others feel about the use of RECOMMENDED for
TLS, or indeed the whole discussion of TLS and IPSec (given that the text
always could use some improvements and tweaking). Is it useful to have any
recommendation here? Or even a discussion of these two popular alternatives?

As for e2e security, there is now a mention in 20.3 of secure MIME types,
which are probably as close as we'll get to e2e signaling security. The
problem of header transparency in useful SIP architectures really precludes
encrypting most of the headers - although secure MIME types might be able to
assist this in some fashion.

Jon Peterson
NeuStar, Inc

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 11:07 PM
> To: Shieh, Hugh; [email-masked]
> Subject: Re: [Sip] Bis-5: TLS as secure transport for SIP
> 
> 
> [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

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Mon, 5 Nov 2001 09:42:35 -0800 (PST)

I frankly think that TLS is a non-starter since it
doesn't work with UDP. Henning disagrees, but I've
yet to hear what should be RECOMMENDED for UDP.
IPsec at least meets the UDP requirement, but
there seems to be a fair amount of concern that
it's too heavy weight. The other alternative is
doing something at application level for
hop-by-hop. Before we went there, I'd want to be
convinced that base transport mode IPsec minus key
distribution, tunnels, minimal crypto support etc,
is in fact significantly smaller than a customized
application layer crypto solution. While I'm
willing to believe the "smaller" part, I'm pretty
dubious about the "significant" part.

Also: KINK gives IPsec the ability to create SA's
in two messages (as opposed to 8-9 for IKE and,
what, 4-5 for TLS?) without *any* public key
cryptography. Manual keying is also possible,
and I'm sure that somebody is going to eventually
start keying up SA's with AAA (which I would be
a lot more receptive to if they actually
confronted the general problem rather than the
one-off hacks they're doing for, say, MIP).

	      Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 5 Nov 2001 10:46:36 -0800 (PST)

Michael Thomas writes:
 > Before we went there, I'd want to be

   Argh. *Larger*.

		Mike