[18951] in cryptography@c2.net mail archive
Re: "ISAKMP" flaws?
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Tue Nov 15 15:11:44 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: cryptography@metzdowd.com
In-Reply-To: Your message of "Tue, 15 Nov 2005 09:46:16 PST."
<p0623095bbf9fcc37f2d1@[10.20.30.249]>
Date: Tue, 15 Nov 2005 14:29:21 -0500
In message <p0623095bbf9fcc37f2d1@[10.20.30.249]>, Paul Hoffman writes:
>At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote:
>>Some articles have been appearing in various web sites about flaws in
>>IPSec key negotiation protocols, such as this one:
>>
>>http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.h
>tml
>>
>>I haven't been following the IPSec mailing lists of late -- can anyone
>>who knows details explain what the issue is?
>
>The advisory itself is at
><http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en>.
>Note that the abstract is "Multiple Vulnerability Issues in
>Implementation of ISAKMP Protocol", with emphasis on "Implementation
>of". It appears that this is *not* a problem with ISAKMP or IKE, but
>instead only a problem with some implementations. A summary would be
>"when some IKEv1 implementations are sent certain malformed messages,
>they stop, reboot, or possibly do other bad things".
>
>Given that they started this research with sending malformed SNMP
>packets to SNMP-aware systems (with similar results), it is safe to
>extrapolate the results to implementations of nearly any protocol to
>varying extents. It is likely that this applies to IKEv2 as well, but
>using differently-malformed packets. It is also likely that it
>applies to some SSL/TLS implementations, of course using very
>different malformed packets.
>
I mostly agree with you, with one caveat: the complexity of a spec can
lead to buggier implementations. Sure, even relatively simple
protocols can be implemented poorly, but complex ones have more places
to go wrong. (It's instructive, I might add, to read RFC 1025,
especially the part about "dirty blows".)
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
