[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Position statement on IKE development
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)
Follow-Ups: