[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Position statement on IKE development
At 12:00 AM 8/5/2001 +0100, Steven M. Bellovin wrote:
>In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes:
>
>
>>>
>>>Agreed. And large parts of the Schneier/Ferguson analysis of the
>>>packet-level parts are just plain wrong.
>>>
>>
>>
>>Steve, with all due respect, you, Jeff and Marcus stated the following.
>>
>>"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."
>>
>>If IKE is no longer considered viable because of it's complexity, then
>>I am concerned that the other protocols of IPsec are also at risk. This
>>is not my concern alone, others have expressed it to me as well.
>>
>>At this point, to restore confidence in the security of the design I
>>would hope that the IETF will retain the services of a quality
>>cryptanalysis consulting firm and publish the results. To do otherwise
>>will be to risk the discrediting of the entire IPsec standard.
>
>Frankly, a lot of very competent folks did look at the cryptography.
>WIth all due modesty, I published two papers on the subject myself, and
>I wasn't the only one. In fact, that's one of the reasons why IPsec
>took so long -- the result of those analyses is why RFCs 1825-29 were
>replaced by 2401 et al. -- because we found and fixed a fair number of
>problems. The flaws in the Schneier/Ferguson analysis are
>because they don't understand the networking context. I sent Bruce a
>long, detailed note about that before he ever published the analysis.
>
>You say "retain the services of a quality cryptanalysis consulting firm".
>Apart from the point that there aren't that many -- and I and others
>know most of the likely players in the field -- the question is whether
>or not they understand the networking context. I have no particular
>reason to think that the results would be any better than what we have
>now.
>
>Is IPsec perfect? No, of course not. I'd like to get rid of AH, for
>example, not because it doesn't work -- it does -- but because it adds
>complexity to implementations without (to me) doing anything useful.
>There are a few other minor things I'd have done differently. But I
>have a great deal of confidence in the correctness of the packet-level
>transforms.
>
Dr. Steven Bellovin,
I have the greatest respect for your design and analysis capabilities
in both networking and cryptography. However at this point in time,
besides the Ferguson & Schneier analysis, and in a sense older papers
by yourself, Dr. Rogaway and possibly others, I have yet to come across
a comprehensive, thorough analysis of the 2401 set of RFCs. I don't
think that this is something that can be done properly through academia,
at least not as a free, unfocused effort. It really requires a focused
effort, with clear, practical analysis objectives laid out. That is why
I suggest using a good consulting firm, preferably one that does similar
type of work on a regular basis.
I appreciate your personal assurances that it is a sound design. However
I think it is critical that an unbiased, reputable third party report
on the core suite of protocols. I understand your concern that they
might not understand the underlying network context. But I would expect
that you and others would be appropriate guides for the analysis. As you
should well know, unbiased peer review is critical in the design of any
security system. We, as designers, tend to be blind to our own mistakes.
It is a rather humbling profession for any security system designer.
Therefore I ask the IAB/IETF to strongly consider sponsering a thorough
analysis of the 2401 set of RFC's. As a member of the Internet Society
I feel it is our responsibility and duty to the Internet community to
ensure, as best as we can, the integrity and soundness of the design.
At the same time, I would hope that the IAB/IETF will come up with a
criteria for selecting the replacement for IKE, rather than trying to
do it all in-house again. While understanding the misgivings others
have expressed, I still feel that a competition along the same lines
that NIST used for AES selection, would be the best approach. The
internal workings of a block cipher are probably just as complex as
the external workings of a key management protocol. Arguements
against a NIST-like selection approach using complexity as a reason
seem to be fallacious to me.
Sincerely,
Alex Alten
--
Alex Alten
Alten@Home.Com
References: