bugtraq - Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 13 Dec 2003 00:35:14 -0500
From: Thor Lancelot Simon <tls@....tjls.com>
To: bugtraq@...urityfocus.com
Cc: psirt@...co.com, sha@...co.com
Subject: Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,

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"?

Cisco customers: take note: Sharad -- Cisco's de-facto representative
on Bugtraq -- has just told you not to use the configuration in question 
because it's unsafe, and says that Cisco's known that for a long time.  
I suggest that you ask your sales engineers why they recommended it to 
you.

Thor