Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Jan 2002 15:20:20 -0600

Thanks for your comments, Mike. You always bring such a lively spirit of
debate to this otherwise dull standards process. Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 12:44 PM
> To: [email-masked]
> Subject: [Sip] TLS section
> 
> 
> 
> First of all, this section doesn't say what needs
> to be implemented. It's only of the form "if you
> use TLS, then you must do X."

Yes, we moved that part down the street to 22.3.1.

> 
> More comments on the actual text.
> 
>   "Transport or network layer security encrypts signaling traffic,
>    guaranteeing message confidentiality and integrity (note 
> however that
>    the originator and recipient of a session may be deducible by
>    observers performing a network traffic analysis). The certificates
>    used to encrypt traffic can also be used to provide a means of
>    authentication in many architectures."
> 
> Certificates do nothing of the sort. They are used
> as a means of proving identity, pure and simple;
> they encrypt nothing. Key exchange is accomplished
> by other means; authentication only answers the
> question "who". Also: you are overloading the word
> encryption; separate out confidentiality and
> message integrity.

Are you honestly suggesting that certificates cannot be used to provide a
means of authentication in many architectures? Distinguishing 'proving
identity' from 'authenticating' is perhaps a little more rigorous than I'm
accustomed to, I'm afraid.

It's true that 'encryption' isn't terribly precise here, though. Still, I
doubt anyone reading this would be at all confused by it.

> 
>   "IPSec is a  set of network-layer protocol tools that can 
> collectively
>    be used  as a secure replacement for traditional IP (Internet
>    Protocol). IPSec is most suited to architectures in which a set of
>    SIP hosts (mingled user agents and proxy servers) or bridged
>    administrative domains (possibly using security gateways) have an
>    existing trust relationship with one another, although 
> IPSec can also
>    be used on a per-hop basis."
> 
> The exact same thing can be said about TLS. You
> are not differentiating anything here, and if you
> think you are, you are mistaken. I suspect that
> there is some confusion about PKI's going on here.

TLS can be used as a replacement for traditional IP? Maybe using Mr.
Bradners IP-over-HTTP draft, if we run it over TLS.

TLS has security gateways and VPNs?

> 
>    IPSec is generally implemented at an operating-system 
> level within a
>    host, and in many architectures it does not require 
> integration with
>    SIP applications. Any deployment of IPSec for SIP would require an
>    IPSec profile describing the protocols tools that would be required
>    to secure SIP and the modes in which they would operate. No such
>    profile is given in this document.
> 
> Please, this doesn't have to be hard. ESP RFC 2406
> in transport mode with HMAC-MD-5-NULL should be
> all that needs to be supported to get
> interoperability.

I'm not sure this is sufficient; most of the other advocates of IPSec seem
to want some sort of security gateway solution. I think we should shake this
out somewhere other than bis.

> 
>   "TLS  provides transport-layer security over connection-oriented
>    protocols (for the purposes of this document, TCP); "tls" 
> (signifying
>    TLS over TCP) can be  specified as the desired transport protocol
>    within a Via header field or a SIP-URI. TLS is most suited to
>    architectures in which a chain of trust joins together a set of
>    hosts."
> 
> Nonsense. TLS is used as a point to point protocol
> primarily, and *anything* can be used to ignore
> transitive trust problems. Again, you haven't
> differentiated anything.

A spoon is more suitable for eating soup than a fork, but I'm sure that you
could make the fork work if you tried hard enough.

I believe that TLS is more suitable for certain architectures than IPSec,
and vice versa. 

> 
>    "For example, Alice trusts her local proxy server, which in
>     turn trust Bob's local proxy server, which Bob trusts, 
> hence Bob and
>     Alice can communicate securely."
> 
> This is a bug, not a feature.

The security solutions section, 22.3.2, suggests a way that this
transitivity might be used in a real-life deployment. Although it's
distasteful to you, I think it jibes with the core needs of SIP.

> 
>    TLS must be tightly coupled with a SIP application. Note that
>    transport mechanisms are specified on a hop-by-hop basis 
> in SIP, and
>    that in some deployments TLS might be used for only 
> certain portions
>    of the signaling path.
> 
> ...and useless on the most vulerable part of the
> signaling path.

Useless for UDP, it's true. The utility of UDP is also open for debate,
though.

> 
>    When TLS is used in a SIP application, implementers MUST minimally
>    support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. For 
> purposes of
>    backwards compatibility, proxy servers, redirect servers and
>    registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. 
> Implementers
>    MAY also support any other ciphersuite.
> 
> Just as a general note, I object to anything which
> makes RSA/PKI a requirement for a UA. 

Noted.

> 
> Also: this predictably ignores the real problem
> here which is UDP based UA's.

I believe TCP is now mandatory for UAs. Sorry to be so predictable.

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 14:31:30 -0800 (PST)

> Yes, we moved that part down the street to 22.3.1.

   I noticed that later. It's a bit odd to have
   two sections.

 > accustomed to, I'm afraid.

   That's not what the text says. The text says that
   certificates are used to encrypt traffic. That's
   incorrect.

 > doubt anyone reading this would be at all confused by it.

   I find it confusing because it's not correct
   in a pretty large way. That is, reading this
   tells me that the authors (maybe you! :) are 
   conflating message integrity/encryption with
   credentials.

 > Bradners IP-over-HTTP draft, if we run it over TLS.

   No. The paragraph implies that IPsec's applicability
   is limited to localized domains. TLS is just as limited
   insofar as the both imply PKI's. If you can build a
   large PKI at all, you could do it equally easy with
   IPsec as TLS. Thus this is not a differentiator.

   Frankly, I'd give up any other distinction than the
   two obvious ones: 

   o IPsec allows use of UDP
   o TLS currently has an API to access the
     credentials, while IPsec requires that
     API to be built.

 > out somewhere other than bis.

   Huh? Nothing prevents them from doing that;
   in fact, it's probably happening today for
   anybody with an IPsec VPN from work. Transport
   mode IPsec is a host-host protocol. I don't
   think we need to consider anything else.
 
 > I believe that TLS is more suitable for certain architectures than IPSec,

   You haven't enumerated why. Given the language in the
   previous paragraphs I think there's a
   disconnect about what the fundamental problem
   for large scale deployments of security is
   (aside from the accidental). That is,
   wide-scale authentication is hard. TLS does
   not help or hurt here. Nor IPsec. They are
   just transport mechanisms which use the same
   authentication technology.

 > distasteful to you, I think it jibes with the core needs of SIP.

   We all know how to ignore the transitive
   problem. That's as simple as ignoring it.
   The other problem with this paragraph is
   that it implies there's some quantifiable difference
   between TLS or IPsec here. There isn't;
   neither can help you, nor will they impede your
   memory cells from losing all knowledge of
   the transitive trust problem.

 > I believe TCP is now mandatory for UAs. Sorry to be so predictable.

   <predicatable>

   Nothing addresses security for UDP and thus the
   spec is incomplete.

   </predicatable>

		Mike