Subject: [MSEC] Position statement on IKE development

From: "Marcus Leech" <[email-masked]>
Date: Thu, 02 Aug 2001 21:33:47 -0400

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.

Despite the obviously complex nature of IKE, several proposals have
been put forward to extend ISAKMP/IKE in various ways, for various
purposes.  Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
others do nothing to improve the complexity situation with regard to
IKE as a whole.  While many of these proposals are, individually,
based on sound engineering and reasonably prudent practice, when cast
in the larger context of IKE, it seems clear that they can do nothing
to improve the complexity picture.

It is with that in mind that the Security Area directors in the IETF,
with the consultation of appropriate people on the IESG and IAB, hereby
place a temporary moratorium on the addition of new features to IKE.
It is fairly clear that work on IKE should focus on fixing identified
weaknesses in the protocol, rather than adding features that detract
from the goal of simplicity and correctness.

We are concerned that trying to reuse too much of the IKE
code base in new protocols -- PIC and GDOI come to mind --
will lead to more complex (and hence vulnerable) implementations.
We suggest that implementors resist this temptation, with the
obvious exception of common library functions that perform
functions such as large modular exponentiations.  Attempts
to share state or to optimize message exchanges are likely to
lead to disaster.

The Security Area Directors have asked the IPSEC working group to come
up with a replacement for IKE. This work is underway and is known in
the community as "Son of IKE".  This effort is at serious risk of
suffering the "second system effect", where all the features that were
left out of the first version, end up in the second.  For this to
happen would be a spectacular disaster, and very much detract from the
goal: to produce a more secure, simpler, and more robust version of IKE.

Arriving at this point has been exceedingly difficult and harrowing.
Understandably, egos have been bruised, and the "change not the IKE,
for it is subtle and quick to anger" position has been taken as a
personal afront by some members of the IPSEC community.  Nothing could
be further from the intent of either of the Security Area directors.
If IKE is vulnerable, we must all share a burden of responsibility for
allowing it to get to the state it is in and we must all work together
to correct the problems.

The IPSEC community must act prudently in moving forward with a
replacement for IKE.  The IPSEC auxillary groups (IPSRA, MSEC, IPSP)
must act with good judgment (chairs and members alike) in designing
protocols that don't interfere with the goal of security and
simplifying our IPSEC key-agreement protocol.

Marcus Leech   (IESG)
Jeff Schiller  (IESG)
Steve Bellovin (IAB)

---

From: Mark Baugher <[email-masked]>
Date: Fri, 03 Aug 2001 15:56:02 -0700

Ferguson and Schneier suggested the same thing as an alternative to 
design-by-committee, which they suggested was the source of problems with 
IPsec and IKE.  When I read this, I did not think it was a viable solution 
because the IPsec and IKE requirements were so much more complex than AES.

I don't think their criticisms of IKE were ever addressed on this list 
though the points about AH and ESP were as I recall.

Mark
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:
> >  the last year or so.In the several years since the standardization of
>the IPSEC protocols
>...
>--
>Alex Alten
>[email-masked]

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Alex Alten <[email-masked]>
Date: Thu, 02 Aug 2001 22:04:54 -0700

Sincerely,

- Alex Alten

the IPSEC protocols

...

--

Alex Alten

[email-masked]

---

From: Alex Alten <[email-masked]>
Date: Thu, 02 Aug 2001 23:49:51 -0700

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

--

Alex Alten

[email-masked]

---

From: Sandy Harris <[email-masked]>
Date: Fri, 03 Aug 2001 09:34:33 -0400

Marcus Leech wrote:

> from its complexity. ...

For anyone who has not seen those papers, there are links to them at:

http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#analysis

---

From: Henry Spencer <[email-masked]>
Date: Fri, 3 Aug 2001 10:21:49 -0400 (EDT)

On Thu, 2 Aug 2001, Alex Alten wrote:
> ...Their suggestion to use a process like NIST's for selecting
> simplification of the entire IPsec protocol suite...

I think this is throwing the baby out with the bathwater.

While the packet-level parts (ESP etc.) do have some flaws, most of those
can be fixed simply by taking a big black pen and crossing out superfluous
parts of the existing specs (e.g., all of RFC 2402).  While there is room
for some debate about exactly which parts should be crossed out (e.g.,
there are people who still think AH is useful), I think there would be
little or no support for redesigning the surviving parts.  So a design
competition does not seem very useful in this area.  Moreover, *this* is
the area where there is massive investment in silicon, solder traces, etc. 
Just deleting features does not, by and large, invalidate that investment.

IKE is the disaster area.  The rest of IPsec could use some judicious
featurectomies, but is not badly broken.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Alex Alten <[email-masked]>
Date: Fri, 03 Aug 2001 11:24:14 -0700

Several people have asked me for the urls of the paper's analyzing
IPsec and IKE.  These are the ones I found searching the web last
night.

A Cryptographic Evaluation of IPsec
by Niels Ferguson and Bruce Schneier
http://www.counterpane.com/ipsec.pdf

Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer
by Catherine Meadows
http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEE
E99.ps

IKE/ISAKMP Considered Dangerous
by William Simpson
draft-simpson-danger-isakmp-01.txt
http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html

BTW Henry,

The issue is not that parts of IPsec are superfluous.  

The question is if IKE is broken then is IPsec also broken?  

- Alex

--

Alex Alten

[email-masked]

---

From: Henry Spencer <[email-masked]>
Date: Fri, 3 Aug 2001 15:41:57 -0400 (EDT)

> The question is if IKE is broken then is IPsec also broken?  

That depends somewhat on exactly what you mean by "IPsec", which is why I
specifically referred to "the packet-level parts".  I don't think there is
much wrong with the packet-level stuff except for a few too many useless
options and alternatives.  The key-management ugliness doesn't seem to me
to have spilled over into the packet level (at least partly because the
packet-level work was nearly finished before key management came to the 
fore). 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Alex Alten <[email-masked]>
Date: Fri, 03 Aug 2001 13:20:27 -0700

Unfortunately what you and I think probably doesn't matter.  What matters
is that end user customers will hear that IPsec's IKE is broken, and they
will then ask themselves the question, is all of IPsec also broken?  It's 
anyone's guess as to how this will play out in the VPN markets, etc.

My own personal question is why the IPsec working group did not have a 
thorough cryptanalysis done by professionals, say by an outfit like ISSI,
before the standards were issued?

- Alex

--

Alex Alten

[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Aug 2001 17:45:05 -0400

> the best one.  In this manner hopefully we can avoid a 2nd debacle.

the worst of IKE's problems are not in the cryptography.

Besides the general complexity of encoding, there's also the matter of
robustness in the face of retransmissions, as well as loss of peer
state.  Not to mention flash crowds and flooding attacks..

---

From: Dan Harkins <[email-masked]>
Date: Fri, 03 Aug 2001 14:58:59 -0700

On Fri, 03 Aug 2001 11:24:14 PDT you wrote
> The question is if IKE is broken then is IPsec also broken?  

No, of course not. 

And you are assuming that IKE is broken. What has been noted by all the
analysis mentiond so far is that IKE is too complex to know whether it
is broken or not. The effort is to make it less complex, get rid of
unnecessary and unused options, get rid of the inconsistent and sometimes
contradictory verbage between the 3 RFCs, and make it a specification of 
a key management protocol for IPsec and IPsec only instead of the current 
instantiation (RFC2407) of a protocol framework (RFC2409) of a generic 
language (RFC2408). 

  Dan.

---

From: Rick Smith at Secure Computing <[email-masked]>
Date: Fri, 03 Aug 2001 16:58:09 -0500

>anyone's guess as to how this will play out in the VPN markets, etc.

It's not as if VPN customers have a well-recognized alternative with a less 
tarnished reputation. If anything, this simply illustrates how much 
pioneering work has gone into IKE.

>before the standards were issued?

Some weaknesses emerge only after you've actually built and deployed a 
protocol. Such flaws may be in the implementation, but some may be faulty 
assumptions about how the protocol will work in a practical deployment. 
It's especially hard to predict problems when the protocol is the 
foundation of a fairly new class of products, like VPN gateways, since 
there's not enough well-known prior art to base the analytical models on.

Rick.
[email-masked]

---

From: Alex Alten <[email-masked]>
Date: Fri, 03 Aug 2001 15:29:24 -0700

Quoting Marcus, Jeff and Steve:

"The Security Area Directors have asked the IPSEC working group to come
up with a replacement for IKE. This work is underway and is known in
the community as "Son of IKE". "

"If IKE is vulnerable, we must all share a burden of responsibility for
allowing it to get to the state it is in and we must all work together
to correct the problems."

OK. IKE is not technically broken. But it sure sounds like someone
is worried.  Otherwise why bother with a replacement for IKE?

It's rather ironic that the 802.11 wireless key management was broken
just recently as well.

- Alex

--

Alex Alten

[email-masked]

---

From: [email-masked]
Date: Sat, 04 Aug 2001 10:03:20 +0900

(stripped off some of the explicit cc:s)

	just checking: does "ongoing work on Son of IKE" mean this draft,
	or something else?
	draft-ietf-ipsec-improveike-00.txt

itojun

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 3 Aug 2001 23:01:44 -0700 (PDT)

> the best one.  In this manner hopefully we can avoid a 2nd debacle.

In practice, such a competition is being held every day in the offices of
customers. The problem is that the contenders are proprietary versions of
IKE (IKE's evil sisters), that there is no cryptanalysis available, and
that the decision criteria and selection are not openly discussed. 

I can state from experience that the "Cinderella IKE" that we now seek to
shelter rarely wins these private beauty contests against the evil
sisters. This is in part, because it is not a good match to customer
requirements such as the need for NAT friendliness and a viable
shared-secret authentication mode. 

It seems to me that unless we can find a "glass slipper" for Cinderella
IKE, that it will languish as the evil sisters grow stronger and more
popular. While we might not like this outcome, or feel that it is "right",
the evidence is to strong to ignore. Cinderella IKE just isn't being
invited to the ball.