Subject: [Sip] The TLS and IPSEC debate

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 31 Jan 2002 19:39:59 -0800

As the original author of the DIGEST specification I thought I should
explain what it exists for since it appears that there are some odd ideas on
this list concerning its use.

The objective of Digest was simply to define an interoperable mechanism that
had no patent encumberances that allowed client authentication that did not
cause passwords to go over the wire en-clair. Digest was not designed to
provide many of the features you would want in a full featured
authentication protocol such as a strong binding of the authentication data
to the message. These features were avoided on purpose because the primary
objective of DIGEST was to kill BASIC which had been released a week
earlier.

I seriously doubt that anyone could seriously asses the comparative
complexity of TLS and IPSEC in favor of IPSEC these days. IPSEC has grown at
least as large as TLS. A major reason for the explosion in IPSEC complexity
is that the original design punted on some hard design choices such as key
distribution. By the time the need for a key agreement mechanism was
understood the designs had grown to baroque proportions due to the need to
support multiple 'interim solutions' along the way.

IPSEC and TLS both share a broadly similar approach to packaging. IPSEC is
naturally packet oriented, TLS operates at the TCP level and is slightly
cleaner to implement. The only practical differences are that IPSEC provides
too many choices while TLS provides more choices than it needs to.

I would strongly disrecommend any approach that attempted to 'profile'
IPSEC. Either you support IPSEC or you do not. Attempting to define a subset
of IPSEC loses all the advantages of using an off the shelf specification.
It is not possible to use existing code. I also take exception to the
implication that the vast majority of the IPSEC specification is somehow
unnecessary and redundant, that RFC 2401 was sufficient on its own and the
rest of the spec was developed for reasons other than real world customers
needed the features in the real world.

The main source of complexity in implementing TLS is that it is based on PKI
and requires a PKI implementation. That need not be implemented at the
device end however, a PKI interface protocol such as the W3C XKMS protocol
can be used instead. 

From an architectural point of view TLS would appear to be better suited to
the design requirements. IPSEC is designed to provide ubiquitous security,
it is also designed to permit embedding at a very deep level in the network,
one which would normally be shielded from the application in a conventional
'protocol stack' model. TLS is designed to interact with the application
level. S/MIME would appear to be best suited of all since it is designed to
support end to end security in a store and forward environment.

I do not see how SIP could achieve any useful goals if the trust model was
limited to manual exchange of (presumably symmetric) keys. I can certainly
understand that giving the end user an incomplete solution saves development
time.

One cautionary tale of symmetric keys. Besides the published cryptographic
failures of the 802.11b WEP protocol there is a much greater failure in that
the 'Wired Equivalent Privacy' scheme failed to understand that in a
wireless environment unauthorized network access was at least as serious an
issue as confidentiality. So even before the crypto was discovered to be
broken people did not deploy WEP because everyone on the network used the
same shared secret for authentication and encryption.

The root cause of the problem was that at the start of the protocol someone
asserted that the protocol should be simple and this was accepted because
simple is often mistaken for secure.

Cryptographic protocols are not like a 'pick and mix' section in a candy
store. IPSEC was issued as a set of RFCs for a purpose. RFC 2401 through
2411 are all IPSEC related. It is pure sophistry to pull out the message
formats alone, as if ISAKMP and IKE were somehow optional extras added on as
an afterthought.

I have not had the time to perform a full security analysis of bis-6,
however the 'kitchen sink' approach (support all the IETF crypto protocols)
appears to be a pragmatic and reasonable response in this instance. The
market will soon decide if there are superfluous mechanisms defined. In
practice it is as Rohan suggests only really necessary to define
interoperability MUST support at the server to server level, people will use
servers that support their clients and choose clients that their servers
support, need will drive sensible choices.

I suspect that developers of lightweight clients would find XKMS more
relevant to their constraints than the debate on TLS vs IPSEC. Supporting
full blown PKI on constrained devices was a primary consideration in the
design of XKMS.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227