[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

On Sun, Jan 30, 2000 at 09:55:47PM -0500, Mr. Anderson wrote:

	[...]

> 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.  

	I will agree with you and, respectfully, disagree with you.

	The idea that the process has failed for ISAKMP is in our face.
If any of the various security holes are valid (and cookie_crumb is an
unfortunate given at this point) then the fact that the process has failed
to prevent such problems is proven.  How, then, did we let this HAPPEN?

	Was the process designed to prevent such things?  No.  The
process was designed (and is evolving) to develop - NOT TO PREVENT.  That
is a CRITICAL distinction.  It's objectives is to develop protocols and
standards.  Lately, the IETF has the proviso that those standards should
be secure, as best we can accomplish given the state of the art, (remember
the stupidities that resulted in things like the FTP bounce attack that
still means you violate the standards to prohibit the attack).

	It is a false assumption, however, that the "IETF process does not
work".  The process does work!  It fulfills the objectives to which it is
presented!  We can't fault it for that.  We may fault the objectives or
the premises on which those objectives are based, but the process DOES work.  

	I would refer to you Heinlein's remarks (in a "A Time to
Love, the Diaries of Larzarus Long") of "An oligarcy assumes that the
minority knows more than the majority...  Who decides?  A democracy
assumes that the majority knows more than the minority...  Come again..."
His point, IMNSHO, is to look at the fundamental processes driving the
decision making, no whether it is one, many or majority who are making
the decision.

	Single sources have come up with ideas and have, time and time
again, have orphaned them to death.  Look at IBM and MCA.  Look at the
broohaha with DVD and the DeCSS debackle that is going on.  Is a focused
industry monopoly like the CSS consortium the answer?  I think NOT!  That
mess is a testimate to the fact that standards developed by a closed
industry consorium is going to result in an embarassment to all the guilty
parties involved!  As a cryptographer, I would hang my head in shame to
be associated with that debacle (other than its undoing).

> 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:

	In the "Brave New World" with open source nipping at their heels,
homogenous networks with single source vendors is going the way of the
dinosaurs.  Darwinism is taking its toll.  If you do not interoperate,
you will not flourish.  Note...  I did NOT say you would not survive.
Even those without the traits to dominate, do survive.  Darwinism
contrary to popular myth, is not an on/off switch - it's probabilites
over long periods of time.  Even those who do not have "survival
characteristists" do survive and do propagate, just not as well.  We
just haven't thrown an astroid at them yet!  :-)  WE DON'T WANT AN
ASTROID THROWN AS US!

	So...  We have a balance...  Vendors offering "proprietary"
solutions (which is a negative) against open standards with a potential
negative (the potential DoS problems noted).  Will there be sufficient
penetration of the open standard and the vulnerabilities to attract the
sort of attention that shut down Portal?  I hope not!  Or I hope we find
a solution to prevent it before it makes the headlines of CNN!

	[...]

> 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.

	Agreed here, somewhat.  Not sure on the details...

> 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.

	When we see one or more large organizations shut down due to things
like "cookie crumb" much like Portal was such down due to SYN flooding, then
we will see people wake up to some fundamental flaws.  Then, they are going
to be PISSED.  We need to have answers before they need to have scaples.

	But the process is not at fault.  The premise and the objectives,
maybe.  The open discussion process beats the closed committee and the,
even more closed, private enterprise/consorsium process hands down.  I
haven't seen a better PROCESS, even when the premise and the objectives
are misguided.  It makes little sense to attack the process when it's
the information and the goals that are really at fault.

	Understand this...  I'm the Senior Researcher and Fellow at
Internet Security Systems.  There are people who consider me "white hat".
There are people who consider me "grey hat".  I hope there aren't TOO many
people who consider me to be "black hat" (there are a few).  I don't think
my "hat" is as dark as Mudge or E-eye or a few others, but I AM THE DEVIL
IN THE DETAILS.  When protocols and implimenations screw up, I am the
asshole that makes life miserable on a lot of people.  I've got too much
to do now, as it is.  I'm currently tasked with looking at these potential
IKE problems.  I don't need more work!  I would seriously rather prevent
these problems BEFORE I write up security advisories on them!

	I'm in that rare occupation where it is more self satisfying to
fail (unable to find a security hole) and be unrecognized than it is to
succeed (rack some poor chump over the coals) and have CNN asking for
my interview.  My reputation does not require that I rape, piliage, or
burn.  But I have and I will....

> -Neo

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
References: