[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Position statement on IKE development
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
At 10:21 AM 8/3/2001 -0400, Henry Spencer wrote:
>On Thu, 2 Aug 2001, Alex Alten wrote:
>> ...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 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
> henry@spsystems.net
>
>
>
--
Alex Alten
Alten@Home.Com
Follow-Ups:
References: