[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
Joern:
Question is, why wasn't this build into ISAKMP? The normal ISAKMP
cookies could have been exchanged before sending the SA payload.
Would have taken an extra round-trip, of course.
Andrew:
I don't know. Maybe we need to go back and scavenge a few ideas from
Photuris. Although Photuris does seem to be vulnerable to modular
exponentiation attacks (which is typical of identity protection exchanges),
the cookie request exchange is similar to what you proposed.
Ari's comment about using public-key crypto to sign the info seems like
overkill. Cookies can be encrypted based on local secret info using a fast
algorithm. (Why sacrifice CPU consumption to save memory consumption?)
The other interesting aspect of Photuris' design is the technique by which
the state is stored exclusively by the initiator. This makes it more
resistant to cookie crumb attacks.
For example, in all the current ISAKMP exchanges, the SA proposal list is
generated by the initiator and the responder must choose and remember one.
This means that the responder must create a state (for the SA proposal AND
for the cookie).
In Photuris, the responder generates the SA proposal list. Therefore, he
does not need to keep a state (since the proposal list is presumably static
or, at the very least, easy to regenerate from policy). Also, all the
information needed to generate the keys is sent simultaneously, allowing the
responder to make a sudden transition from entirely stateless to fully
stateful.
Note that we could accomplish the same thing in IKE (a bit less elegantly)
by having the initiator resend the selected SA proposal later in the
exchange. The same could presumably be done with all the other fields,
allowing the responder to make a transition from stateless to stateful
immediately after authenticating the peer.
Of course, because of the "tragedy of the commons" principle, none of us are
going to do anything about DoS until our customers ask for it, and our
customers aren't going to ask for it until there are highly-publicized
attacks.
<Begin Rant>
I mean, mathematicians have been publishing reports for years saying that
DES can be cracked. They will usually state that it will take X amount of
CPU power (which is equivalent to Y PCs working in parallel for Z hours).
It's not really even a debatable analysis, but the mainstream media ignores
the result until someone actually goes and does it.
Some day they'll publish a newspaper story... "Mathematicians have long
suspected that two to the power of a googaplex was even, but now John Doe
has given them conclusive proof. An array of 10000 Cray supercomputers, the
largest ever chained worked tirelessly to compute the exponent..."
<End Rant>
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
-----Original Message-----
From: Joern Sierwald [mailto:joern.sierwald@f-secure.com]
Sent: Monday, January 31, 2000 10:15 AM
To: ipsec@lists.tislabs.com
Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs
Addressing
At 14:51 30.1.2000 -0500, you wrote:
>
>WG Members:
>
>We are hearing more and more concerns in the enterprise community
>that ISAKMP will be vulnerable to UDP denial of service attacks
>in the future. This is a widely known and serious flaw, IMHO.
>
>----------------------------------------------------------
>FYI Review of RFC 2408: ISAKMP
>----------------------------------------------------------
>
>2.5.1 Transport Protocol
>
>ISAKMP can be implemented over any transport protocol or over IP
>itself. Implementations MUST include send and receive capability for
>ISAKMP using the User Datagram Protocol (UDP) on port 500.
>----------------------------------------------------------
>
>The specification above means that most vendors who read this
>will build ISAKMP on 500/UDP; which means that any malicious
>person with a clue as to how UDP DoS attacks can be done will
>be able to create chaos with the ISAKMP process during SA
>setup, etc.
>
>Vendors with a clue will build an alternate mechanism which allows
>ISAKMP to play using a more robust transport mechanism, at least
>TCP based, which raises the bar against simple UDP DoS attacks.
>
>I suggest the ISAKMP RFC address this vulnerability more directly because
>IPSEC and ISAKMP security issues such as this could be treated more
>openly in the RFC, perhaps even an ISAKMP protocol risk-analysis should be
>documented in the IETF process.
>
>Finest Regards,
>Neo
>
Folks, let me rephrase the problem to check if we're talking
about the same problem here:
The problem is that ISAKMP implementation do policy lookups, create state
and even do RSA or DH before the IP address of the sender is verified.
An attacker could send packets with random source IP address and
keep the ISAKMP machine very busy.
This could be solved by using another transport layer. For instance, here's
my
antispoofing protocol:
- use UDP port 55555 instead of 500.
- a header with a ticket field is used (var length), after that a normal
ISAKMP packet. Compare that ticket with Ari Huttunen's state payload.
- before doing phase 1 ISAKMP exchange, the initiator requests a ticket
from the
responder. Like, Initiator sends empty packet, Responder returns ticket
(some array of bytes, opaque for the initiator, very much like ISAKMP
cookies).
If the sender uses wrong source addresses, he never gets my ticket
and can't attack my ISAKMP engine.
That antispoofing protocol looks too simple. Can somebody check whether this
would work?
Question is, why wasn't this build into ISAKMP? The normal ISAKMP
cookies could have been exchanged before sending the SA payload.
Would have taken an extra round-trip, of course.
Jörn Sierwald