[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
snipped...
> computer - or designing in the face of active hostile intent) will force us
> to correct this flaw in the long term. It would have been better if the
> choice had not been to expose us to such security embarassments.
> Unfortunately, we don't always have that luxury. Equally unfortunate is
> all the vendors who are about to be dumped on due to "cookie_crumb".
Concur with your reply. It is ironic that the ISAKMP protocol
specification, which is widely being deployed for IPSEC key management
has such a basic security flaw. It (helps) magnify Bruce's comments
in their IPSEC paper about how the IETF/IPSEC process does not work
(well) for security-centric developments.
Again, my gut feeling is that vendors will be driven to offer a special
version of ISAKMP using a proprietary (a more secure) transport
protocol as allowed in the ISAKMP RFC. As you will recall:
----------------------------------------------------------
>From RFC 2408: ISAKMP
----------------------------------------------------------
2.5.1 Transport Protocol
ISAKMP can be implemented over any transport protocol or over IP
itself. .....
----------------------------------------------------------
This was the original intent of my original post, to show how
a flaw in the specification plus a 'do it anyway you can get-out-
of-requirement-free card' for suppliers, will lead to interoperability
problems. Vendors will simply be forced to offer ISAKMP services
'securely' which is not an IETF standard, using their 'super-duper'
secure ISAKMP method.
BTW: My original post was not meant to be a TCP vs. UDP discussion
because we surely know that both protocols have vulnerabilities which
can be exploited during ISAKMP operations. TCP does 'raise the
bar just a little', IMHO, but not enough to be considered
a "compensating control" in risk-analysis jargon. However, the
straight UDP/500 approach is a large hole, IMHO.
One of my biggest concerns it the fact that organizations, both
large and very large, are under great pressure to field VPN
solutions by users who have no concept of the vulnerabilities
in the protocol specification. Organizations will field
systems, spending large dollars, thinking the are getting
'a secure system'; when in fact, the operational criteria
and specification, as currently being fielded, are far from
secure from an operational perspective.
-Neo
Follow-Ups:
References: