Cisco's hybrid auth improvements

From: "F. Senault" <fred@lacave.net>

To: ipsec-tools-devel

Subject: Cisco's hybrid auth "improvements".

Hi all.

I'm still on my quest to help make a racoon fully interoperable with Cisco hard- and software.

This time, I'm hitting a new problem, with hybrid auth (discussed about this with Manu Dreyfus last evening, he has no idea either).

The hybrid auth IETF draft asserts that a client connecting to an edge device with hybrid auth will not need to authenticate himself during phase 1, but during xauth.

It seems that Cisco managed to add a little something that makes use of their group login and group password to authenticate.

The consequences of this are simple :

• When a cisco client talks to a racoon server, since we follow the draft to the letter, that PSK is utterly ignored, and the authentication succeeds, with any group password : good.
• When a racoon client talks to a cisco VPN 3k (for instance), we do not send that PSK, so the authentication automatically fails : bad.

I managed to reverse engineer the system, using the racoon server and a cisco vpn client. The last packet of the aggressive exchange goes like this :

• hash (validated with the usual method)
• notify - initial-contact
• notify - with the key
• vid - unknown (different each time ?)
• vid - cisco unity.

The notify message is recognised as a "HEARTBEAT notification", but, within the client's log, we can read "NOTIFY:PRESHARED_KEY_HASH".  There are also 20 more bytes after, which make it a very good candidate for a hash...

Strangely enough, the first VID seems to be random / encrypted / hashed, and even the Cisco doesn't identify it : it's logged as "VID(?)".

Of course, some research with Google and on Cisco's website didn't bring anything interesting (other than the certitude that ipsec-tools is currently the most advanced open-source ipsec solution around feature-wise... :-) ).

I've tried to muck a bit around to see if I could recognize the hash sent, but to no avail - I have no idea on the exact way to form or validate that hash, if the VID enters into the equation, etc.  It doesn't help that I'm not very good with cryptography.

Can anyone think of a solution ?  Is there a way to test some combinations of algorithms ?  I can provide packet dumps, verbose racoon logs, the root CA known by the client, the group password (toto, for my tests), the cisco client's logs...  With that much info, it should be possible to find what's going under the hood !

Either that, or someone here works for / has contacts with someone who works for Cisco, and is willing to disclose the technology.  Or it's posted somewhere in evidence, and I was very bad with my search... :-}

FYI, the detailed packet goes like this :

0) 61670801 35f13d0e 3cc44f6c 7056177f
1) 08100401 00000000 000000ac
2) 0b000018 a05a6562 a808ec0e 85c52349 1d813dca 404fce0d
3) 0b00001c 00000001 01106002 61670801 35f13d0e 3cc44f6c 7056177f
4) 0d000030 00000001 01109e37 61670801 35f13d0e 3cc44f6c 7056177f
=>                   d44f3179 23bd49ed 83500b81 1902aee4 64ba8bef
5) 0d000014 94a0af1c 35f03d0e 9cc39599 7fcd63c1
6) 00000014 12f5f28c 457168a9 702d9fe2 74cc0100
   00000000

0, 1, 2 are the SPI, the header, and the HASH.

3 is an the initial contact (0x6002) with the SPI again.

4 is that other notify, with the 0x9e37 ID and the 20 bytes of the supposed psk hash.

5 is the "vendor id", changing at each time, etc.

6 is the real cisco unity VID.

Cisco client"s log says :

129    03:15:27.072  03/30/05  Sev=Info/4       IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(
              HASH,
              NOTIFY:STATUS_INITIAL_CONTACT,
              NOTIFY:PRESHARED_KEY_HASH,
              VID(?),
              VID(Unity)
            ) to 192.168.1.19