[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Position statement on IKE development



Okay, the first thing to do is **DON'T PANIC**.

The opinion in this document is not new. In fact, this moratorium on IKE
development has been in place for more than a year already, as I
specifically remember Ted talking about it at the Adelaide meeting. The fact
that the opinion of the ADs has suddenly been put in writing and posted to
the mailing list is no reason to get excited.

What does concern me is the effect that this moratorium has had on the WG.
Instead of encouraging work on simplifying IKE, it has merely stifled the
ongoing work on features that we simply must have. NAT traversal is clearly
not an optional feature. Development of a NAT traversal protocol will
continue with or without the IESG's blessing, as will user authentication
and dead peer detection.

If all development must stop until IKE is simplified, then how are we to add
these essential new features? Must there be an IKEv3 a year from now to add
all the features that have already been developed? I would also like to ask
why, if the enclosed opinion is in fact shared by all 3 authors, then how is
it that one of them recently co-authored a draft for adding SCTP support to
IKE?

---

In technical circles, just as in politics, the pendulum swings one way and
then it swings back again. No matter which way it is travelling, it
inevitably swings too far.

In our zeal to criticize IKE/Isakmp for its generic approach, we have
assumed there is some kind of magic pixie dust that we can sprinkle on IKE
to make it simpler. Rewriting the documents may make IKE easier to
understand, but it won't change the bits on the wire or the underlying
protocol. Designing related protocols to not share any code may reduce the
complexity of either protocol taken alone, but it will probably increase the
complexity of the system as a whole.

I agree with Mike that the separation of Main Mode from Quick Mode was a
good design decision for IKE. I also feel that the separation of ISAKMP from
IKE was a good decision. I would much rather see a rewritten IKE document
and a separate, simplified ISAKMP document (which only defines the payload
formats and such) than a new, fully merged IKE spec.

Counterintuitively, "simplicity" is a difficult concept to apply and
understand. A shorter RFC does not necessarily make a simpler protocol.
Simplicity can come from adding things as well as removing them. In
particular, adding restrictions can greatly simplify a protocol.

I am worried that if we try to make Son of IKE too terse then the lack of
restrictions will make the protocol vague. It has been my observation that
the single biggest problem area for IKEv1 has been rekeying. The IKE RFC
remains curiously silent on this topic, except to state the SAs are
"uncorrelated". The lack of sufficient rules for how to use the Certificate
Request payload has also been a source of trouble.

---

If you want to consider some real, bits-on-the-wire type simplifications to
IKE then take a look at our draft-improveike document. Also look at the
revised hash document and the IKE anti-replay document. These last two are
ideas for simplifying IKE by taking security properties which were formerly
solved individually for each mode, and defining a solution which solves the
problem for all modes, a simplification.

Not all of the things we suggest are simplifications; some of them are
merely suggestions to improve the protocol. But then again, not all of the
papers that Marcus cites are really commenting on complexity of IKE. The
paper by Simpson doesn't talk about the complexity of IKE at all. In fact,
all it says is that IKE is succeptible to a certain kind of DoS attack.

The paper by Ferguson/Schneier certainly talks about complexity, but I think
that many people are too star-struck by who the co-author is to consider
that he obviously isn't very familiar with the intimate details of IKE. In
fact, some of his comments are rather schitzophrenic, in the sense that he
interlaces suggestions for simplifying Main Mode with suggestions for
reducing the length of the exchange, a short-sighted idea which would almost
certainly introduce some new DoS attacks.

If we are going to redesign IKE then let us do so, but it would help if the
charter was defined so that people actually had an incentive to implement
the new, simplified IKE. Many of the proposed suggestions have been wild,
unsupported assertions such as: (A) let's have a contest and redesign
everything from scratch (clearly not from an implementer), (B) related
protocols X and Y shouldn't share code (great as long as you don't have to
implement both X and Y), (C) Merging all the documents together will somehow
automagically fix IKE (only if we agree on conventions for things like
rekeying).

I also wonder why IKE gets all the blame when the PKI-related protocols we
use with IKE are easily as complex, if not more complex.


My apologies for not replying earlier, but I have been on vacation until
today.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten
> Sent: Friday, August 03, 2001 2:50 AM
> To: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org;
> ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
>
> After just reading the papers by Meadows, Schneier/Ferguson and
> Simpson, I now have serious doubts that IPsec delivers the security
> required by the Internet community.
>
> This is a very serious issue.
>
> To make a mistake of this caliber when so many firms have committed
> large amounts of resources for software, board, ASIC and chip designs,
> implementations and manufactures is a terrible thing.
>
> I agree with Schneier & Ferguson. A security protocol/system cannot be
> designed by a large committee, unlike many other successful insecure
> protocols. Their suggestion to use a process like NIST's for selecting
> the AES standard is an excellent one. It's a pity they did not suggest
> it a decade ago. However it should be considered seriously not only
> for the replacement of IKE, but possibly also for the modification or
> simplification of the entire IPsec protocol suite. (I hesitate to say
> the replacement of IPSEC given the tremendous repercussions of doing
> so.)
>
> - Alex
>
>
> At 10:04 PM 8/2/2001 -0700, Alex Alten wrote:
> >
> >Dear Marcus, Jeff and Steve,
> >
> >May I make a suggestion given the seriousness of this?
> >
> >Let's hold an international design competition to select a key
> >management protocol for IPSec in a manner similar to how NIST did
> >the AES selection (although I hope it takes less than 5 years).
> >Once we get to a final 5, then let's cryptanalyze them and select
> >the best one.  In this manner hopefully we can avoid a 2nd debacle.
> >
> >Sincerely,
> >
> >- Alex Alten
> >
> >
> >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote:
> >>I'm sending the attached ASCII TEXT document on behalf of
> myself, Jeff
> >>Schiller, and
> >>  Steve Bellovin, to clarify our position with respect to IKE
> >>development. It is our hope
> >>  that it will clarify, to some extent, some fuzziness in
> this area that
> >>has evolved over
> >>  the last year or so.In the several years since the
> standardization of
> >the IPSEC protocols
> >>(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >>problems with the protocols, most notably the key-agreement
> protocol,
> >>IKE.  Formal and semi-formal analyses by Meadows, Schneier
> et al, and
> >>Simpson, have shown that the security problems in IKE stem directly
> >>from its complexity.  It seems only a matter of time before more
> >>analyses show more serious security issues in the protocol
> design that
> >>stem directly from its complexity.  It seems also, only a matter of
> >>time, before serious *implementation* problems become
> apparent, again
> >>due to the complex nature of the protocol, and the complex
> >>implementation that must surely follow.
> >
> >...
> >
> >>
> >>
> >>Marcus Leech   (IESG)
> >>Jeff Schiller  (IESG)
> >>Steve Bellovin (IAB)
> >>
> >--
> >
> >Alex Alten
> >
> >Alten@Home.Com
> >
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
>



Follow-Ups: References: