IPSECv2 Was: Thoughts on identity attacks

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> I think the passive attack is the most important. Against an active
attack,
> it would be nice for the initiator's id to be protected in in
road-warrior
> cases and the responder's id to be protected otherwise.

I think I disagree with this charaterisation. There are some active
attacksthat is hard, others is not.

For example the class of active man in the middle attacks in which the
attacker intercepts all messages and replaces them somehow is very
challenging.

The class of active attack in which the attacker observes some information
on the network and then introduces packets based on that data is not at all
challenging.

I absolutely agree that a security protocol that does not protect against
active man-in-the-middle can add a lot of value. I don't think there is any
value in a protocol that protects against passive attack but leaves all
types of active attack out of scope.


The other issue I think has been lost in this thread is that the
requirements of VPN manufacturers are not necessarily the most relevant
issue for IPSEC. IPSEC is meant to be a heck of a lot more than a VPN
protocol.

I think it is essential that IPSEC meet the requirements set by VPN
marketing depts, but that is a necessary not a sufficient condition. Equally
I think it is important that the requirement for identity concealment be
justified by a requirement from some group of end users somewhere and for
reasons that are grounded in a genuine security threat for which the
proposed feature provides an effective control.


The discussion is relevant in the context of son-of-IKE. The issue of
whether identity concealment is actually required and and whether achieved
in practice has a practical impact, it decides if you require 1 round trip
plus a possible additional for DoS protection or require 2 in every case.
The complexity of IKE is irrelevant to these discussions.

Moreover the structure of IETF is not that of an industry consortium. The
IETF structure is encourages proliferation of features and definition of six
different ways to skin a cat.


What we are really discussing here is IPSECv2, which will hopefully allow
IPSEC to meet the original goal of A SECURE INTERNET PROTOCOL. It is good
that IPSECv1 has found a useful niche in providing VPN support, but we are
still travelling hopefully, we have not arrived.

To achieve the goals of IPSECv2 it is essential that the complexity of the
protocol be managed more effectively. Eliminating ESP mode and employing
son-of-IKE reduce the complexity of the client, putting IPSEC within the
reach of 802.11* NICs, handheld devices, media jukeboxes etc.

It is also essential to address the complexity of the trust relationships. I
disagree with the assertion that 90% of the complexity of PKI is in the I.
In the case of IPSEC the main source of complexity is the fact that the PKI
support in current products is simply insufficient to address applications
beyond the closed VPN model.

Nor is it the case that inserting the full PKIX stack into every client is
going to solve this problem, in the first place the stack is too big to fit,
in the second real world trust relationships are typically more subtle than
can be expressed in a fixed certificate format such as X.509 that is limited
to private keys.


One approach is to take the complexity out of the IPSEC end points and put
it in a trust service that is a specialist in that role. This is essentially
what KINK attempts to do. The fundamental flaw of KINK is that attempting to
scale symmetric key protocols up to Internet scale is hard, even if leavened
with a smattering of post-facto public key features.

Another approach is to use DNSSEC in some form, provided the working group
agrees that the ability to deploy DNSSEC in the largest zones should be a
requirement. This has promise but is only applicable for entities that have
DNS names which is insufficient to address the full range of the potential
of IPSEC.

The approach I have been advocating for some time now is delegate the PKI
processing functions from the IPSEC applications to a specialist trust
service. We are currently working on an XML based protocol to do this in the
W3C XKMS working group http://www.w3.org/2001/XKMS/. An XKMS trust service
may be used to access keys from any underlying PKI, including PKIX, DNSSEC.


The point about XKMS is not that it is necessarily the solution to every
problem. I would be very happy if vendors said that they will implement a
full PKIX stack in their product instead! What XKMS does do however is it
removes the excuse that PKI is too complex so we either won't do it at all
or do only a minimal wimpy version that is only useful in a very small
application area.

This stuff should be simple. IPSEC deployment should be made so simple that
it can be done by consumers and network operators without even having to
know how the thing works. What is more, it CAN be made simple. Cryptographic
Plug and Play is well within the capabilities of the specifications out
there already. All we have to do is come to an agreement about how they fit
together.

	Phill