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

Re: How IKE is sometimes (mis-)used in the real world.



On Fri, Dec 12, 2003 at 06:36:45PM -0500, Thor Lancelot Simon wrote:
> This is a copy of a message I sent to BUGTRAQ earlier today.  It is
> written for a significantly less technical and less IPsec-savvy
> audience than the usual suspects on this list but a few people sugested
> I should send it here anyway; so that's what I'm doing.

Just to provide another example of just how badly some vendors -- or,
at least, their sales/marketing folks -- Don't Get It, and just how
they're likely to try to wiggle through holes in even the most carefully
constructed protocols to inflict dangerous "solutions" on their customers
while claiming to have implemented what the IETF specified: here's Cisco's
response to my raising the XAUTH issue on Bugtraq, followed by my response
to it.

In fairness to Cisco, it turns out that between my originally pointing out
the "authenticate the DN, not the CA!" issue to them and the present time,
they did eventually fix that problem, and make a note of it in the 
appropriate places.  But the lengths of rationalization to which some folks
will go in order to justify dangerous use of protocol "extensions" that
weren't accepted is pretty scary.

Perhaps the next time something like XAUTH is proposed, the standard it
impacts should be explicitly revised to MUST NOT some of the dangerous
things it does.  At least that way the implementations in question could
not claim to conform to the standard.

On Fri, Dec 12, 2003 at 09:10:50PM -0800, Sharad Ahlawat wrote:
> 
> Issue #2: This is a widely known common aspect of the Pre Shared Keys (PSK) 
> authentication mechanism since 1999. With PSK, there is no way for a client 
> to identify what is on the other side of the connection except that the other 
> side has the same PSK.

Sharad's (Cisco's?) highly disingenuous claim is completely false.

In fact, the security vulnerability in question is caused by Cisco's 
decision to deliberately *misuse* the preshared key authentication method 
of IKE, in combination with the very dangerous XAUTH extension to IKE which 
was not accepted by the IETF IPsec wworking group.

As is specified by the relevant standards and as was pointed out in the
working group while XAUTH was under discussion, the entire security of
the PSK authentication method relies upon the fact that these keys are,
in fact, a shared secret between the two IPsec peers -- *not* a "VPN
server" and an arbitrary number of "clients".  In combination with the
rejected XAUTH extension, the misuse of PSK that Cisco advocates and
supports is particularly dangerous because it leads to the disclosure of
persistent authentication information such as user passwords.

Indeed, with preshared key authentication, there is no way for a client
to identify what is on the other side of the connection except that the
other side has the same preshared key.  That much is intrinsic to the
design of the protocol *and is why only two parties must ever have
knowledge of any single preshared key*.  

Yet Cisco deliberately chooses to *recommend* to its customers an IKE
configuration in which many parties use the same preshared key, and,
even worse, use that key to "protect" the dangerous and nonstandard
XAUTH exchange in which the client will give password or other legacy
authentication information to the other end with no guarantee of what,
exactly, that other end might be.

In other words, Sharad confirms that Cisco knows just how dangerous
this is, while glossing over the fact that Cisco sales engineers and
other field personnel continue to *recommend* this configuration to
customers.  Indeed, if this configuration is so widely understood to
be dangerous, why does the Cisco client software even support it,
even going so far as to gloss over the fact that a preshared key is
being used by more than two parties by calling it a "group password"?

Thor