ASA 5500: IKEv1 HASH payload length 4 during QM 3

armamsic_ · ‎08-02-2012

Hello,

I connecting to a Cisco ASA 5500 using a third party IKEv1 client. The initial connection and all rekey attempts that start on the client are successful. A tunnel is established, data cna be transferred between the client and the ASA's internal network etc.

However, when the ASA initiates rekeying of a Quick Mode SA this is rejected on the client. The rejection occurs due to QM3's HASH payloading having a length of 4, which is wrong.

ASA log:

ISAKMP Header

Initiator COOKIE: 48 81 9e 1b 80 94 41 a9

Responder COOKIE: fa ab 87 c7 a5 d9 8d 35

Next Payload: Hash

Version: 1.0

Exchange Type: Quick Mode

Flags: (none)

MessageID: DBF3EC48

Length: 469762048

Payload Hash

Next Payload: Security Association

Reserved: 00

Payload Length: 24

Data:

29 56 54 f6 d5 5a cb 5c e2 38 d0 92 90 5e 1c 70

45 c9 62 d6

Payload Security Association

Next Payload: Nonce

Reserved: 00

Payload Length: 64

DOI: IPsec

Situation:(SIT_IDENTITY_ONLY)

Payload Proposal

Next Payload: None

Reserved: 00

Payload Length: 52

Proposal #: 1

Protocol-Id: PROTO_IPSEC_ESP

SPI Size: 4

# of transforms: 1

SPI: b6 a2 d1 17

Payload Transform

Next Payload: None

Reserved: 00

Payload Length: 40

Transform #: 1

Transform-Id: ESP_3DES

Reserved2: 0000

Life Type: Seconds

Life Duration (Hex): e1 00

Life Type: Kilobytes

Life Duration (Hex): 00 01 86 a0

Encapsulation Mode: UDP Tunnel(NAT-T)

Authentication Algorithm: SHA1

Group Description: Group 1

Payload Nonce

Next Payload: Key Exchange

Reserved: 00

Payload Length: 24

Data:

80 07 36 76 1d 9f 13 1b 66 aa 31 b4 2d 5a 05 67

2e 62 0f 41

Payload Key Exchange

Next Payload: Identification

Reserved: 00

Payload Length: 100

Data:

2c 68 df d5 3b e1 84 f6 50 89 8d b2 d3 9b 68 61

57 a2 06 ad 4a 2e e7 de 80 bb a2 4b 64 86 90 af

23 4a 1a ca 76 e2 d5 9c d1 9b c1 aa f2 86 56 b9

41 af 1d b5 16 5f 8e 89 bf 88 0c 67 dd b5 51 30

09 b9 80 7c 9e 4c 3c 1f a8 a2 1d f2 76 9e 9f ff

2e 89 e2 8f e6 e3 6d 9c 08 24 53 05 dc d3 40 9d

Payload Identification

Next Payload: Identification

Reserved: 00

Payload Length: 16

ID Type: IPv4 Subnet (4)

Protocol ID (UDP/TCP, etc...): 0

Port: 0

ID Data: 0.0.0.0/0.0.0.0

Payload Identification

Next Payload: None

Reserved: 00

Payload Length: 12

ID Type: IPv4 Address (1)

Protocol ID (UDP/TCP, etc...): 0

Port: 0

ID Data: 172.22.71.92

RECV PACKET from <removed>

ISAKMP Header

Initiator COOKIE: 48 81 9e 1b 80 94 41 a9

Responder COOKIE: fa ab 87 c7 a5 d9 8d 35

Next Payload: Hash

Version: 1.0

Exchange Type: Quick Mode

Flags: (Encryption)

MessageID: 48ECF3DB

Length: 316

AFTER DECRYPTION

ISAKMP Header

Initiator COOKIE: 48 81 9e 1b 80 94 41 a9

Responder COOKIE: fa ab 87 c7 a5 d9 8d 35

Next Payload: Hash

Version: 1.0

Exchange Type: Quick Mode

Flags: (Encryption)

MessageID: 48ECF3DB

Length: 316

Payload Hash

Next Payload: Security Association

Reserved: 00

Payload Length: 24

Data:

df f7 08 28 81 71 51 4f d3 da 12 00 17 4b 8b e9

53 16 78 8b

Payload Security Association

Next Payload: Nonce

Reserved: 00

Payload Length: 64

DOI: IPsec

Situation:(SIT_IDENTITY_ONLY)

Payload Proposal

Next Payload: None

Reserved: 00

Payload Length: 52

Proposal #: 1

Protocol-Id: PROTO_IPSEC_ESP

SPI Size: 4

# of transforms: 1

SPI: af e4 f7 3e

Payload Transform

Next Payload: None

Reserved: 00

Payload Length: 40

Transform #: 1

Transform-Id: ESP_3DES

Reserved2: 0000

Life Type: Seconds

Life Duration (Hex): e1 00

Life Type: Kilobytes

Life Duration (Hex): 00 01 86 a0

Encapsulation Mode: UDP Tunnel(NAT-T)

Authentication Algorithm: SHA1

Group Description: Group 1

Payload Nonce

Next Payload: Key Exchange

Reserved: 00

Payload Length: 20

Data:

90 1c d7 5e ab 3f 0d 88 c4 2a 07 0a 0d 53 0b 34

Payload Key Exchange

Next Payload: Identification

Reserved: 00

Payload Length: 100

Data:

27 37 8c df a1 45 33 a2 5c 72 3b cb 9d 19 40 d8

60 dc 58 aa 65 8e df c4 56 4e 3c 25 23 a0 f9 b1

cb 67 b3 6f 59 c4 2f c7 c8 3b 20 74 81 e7 d7 23

03 3c 26 ab 60 03 04 92 b0 c7 32 c4 b5 98 4c f2

94 5e f0 c0 db dd fc 17 f6 47 82 8f 7e cb a4 08

76 d7 8c 3f 19 14 18 4a 49 cc 0d 0e dc 39 f9 de

Payload Identification

Next Payload: Identification

Reserved: 00

Payload Length: 16

ID Type: IPv4 Subnet (4)

Protocol ID (UDP/TCP, etc...): 0

Port: 0

ID Data: 0.0.0.0/0.0.0.0

Payload Identification

Next Payload: Notification

Reserved: 00

Payload Length: 12

ID Type: IPv4 Address (1)

Protocol ID (UDP/TCP, etc...): 0

Port: 0

ID Data: 172.22.71.92

Payload Notification

Next Payload: None

Reserved: 00

Payload Length: 48

DOI: IPsec

Protocol-ID: PROTO_ISAKMP

Spi Size: 16

Notify Type: STATUS_RESP_LIFETIME

SPI:

48 81 9e 1b 80 94 41 a9 fa ab 87 c7 a5 d9 8d 35

Data:

80 01 00 01 80 02 70 80 80 01 00 02 00 02 00 04

00 01 86 a0

Aug 02 06:18:34 [IKEv1]IP = <removed>, IKE_DECODE RECEIVED Message (msgid=48ecf3db) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 312

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing hash payload

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing SA payload

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing nonce payload

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing ke payload

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing ISA_KE for PFS in phase 2

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing ID payload

Aug 02 06:18:34 [IKEv1 DECODE]Group = <removed>, Username = <removed>, IP = <removed>, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing ID payload

Aug 02 06:18:34 [IKEv1 DECODE]Group = <removed>, Username = <removed>, IP = <removed>, ID_IPV4_ADDR ID received

172.22.71.92

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, processing notify payload

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, loading all IPSEC SAs

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, Generating Quick Mode Key!

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, NP encrypt rule look up for crypto map SYSTEM_DEFAULT_CRYPTO_MAP 65535 matching ACL Unknown: returned cs_id=ad80cbf8; rule=00000000

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, Generating Quick Mode Key!

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, NP encrypt rule look up for crypto map SYSTEM_DEFAULT_CRYPTO_MAP 65535 matching ACL Unknown: returned cs_id=ad80cbf8; rule=00000000

Aug 02 06:18:34 [IKEv1]Group = <removed>, Username = <removed>, IP = <removed>, Security negotiation complete for User (<removed>) Responder, Inbound SPI = 0xb6a2d117, Outbound SPI = 0xafe4f73e

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, oakley constructing final quick mode

Aug 02 06:18:34 [IKEv1 DECODE]Group = <removed>, Username = <removed>, IP = <removed>, IKE Initiator sending 3rd QM pkt: msg id = 48ecf3db

Aug 02 06:18:34 [IKEv1]IP = <removed>, IKE_DECODE SENDING Message (msgid=48ecf3db) with payloads : HDR + HASH (8) + NONE (0) total length : 56

BEFORE ENCRYPTION

RAW PACKET DUMP on SEND

48 81 9e 1b 80 94 41 a9 fa ab 87 c7 a5 d9 8d 35 | H.....A........5

08 10 20 00 db f3 ec 48 1c 00 00 00 00 00 00 04 | .. ....H........

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

00 00 00 00 00 00 00 00 | ........

ISAKMP Header

Initiator COOKIE: 48 81 9e 1b 80 94 41 a9

Responder COOKIE: fa ab 87 c7 a5 d9 8d 35

Next Payload: Hash

Version: 1.0

Exchange Type: Quick Mode

Flags: (none)

MessageID: DBF3EC48

Length: 469762048

Payload Hash

Next Payload: None

Reserved: 00

Payload Length: 4

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, IKE got a KEY_ADD msg for SA: SPI = 0xafe4f73e

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, Pitcher: received KEY_UPDATE, spi 0xb6a2d117

Aug 02 06:18:34 [IKEv1 DEBUG]Group = <removed>, Username = <removed>, IP = <removed>, Starting P2 rekey timer: 48960 seconds.

Aug 02 06:18:34 [IKEv1]Group = <removed>, Username = <removed>, IP = <removed>, PHASE 2 COMPLETED (msgid=48ecf3db)

What might be causing this issue?

The specific part in the log that seems to be wrong is the following:

ISAKMP Header

Initiator COOKIE: 48 81 9e 1b 80 94 41 a9

Responder COOKIE: fa ab 87 c7 a5 d9 8d 35

Next Payload: Hash

Version: 1.0

Exchange Type: Quick Mode

Flags: (none)

MessageID: DBF3EC48

Length: 469762048

Payload Hash

Next Payload: None

Reserved: 00

Payload Length: 4

Since the initial negotiations work, pre-shared key, IKE/IPsec settings etc should be correct; if they weren't the connections wouldn't work in the first place.

Patrick0711 · ‎08-02-2012

Looks normal to me

Where do you see an issue?

Why are you using a 3rd party client? Use the Cisco client...

armamsic_ · ‎08-03-2012

Thank you for your reply, Patrick0711.

My problem with this is that the Hash payload in QM 3 is wrong and goes against RFC 2409; causing the ASA not to be RFC compliant which is a problem for third-party vendors.

Quoting:

   Quick Mode is defined as follows:
        Initiator                        Responder
        -----------                      -----------
        HDR*, HASH(1), SA, Ni
          [, KE ] [, IDci, IDcr ] -->
                                  <--    HDR*, HASH(2), SA, Nr
                                               [, KE ] [, IDci, IDcr ]
        HDR*, HASH(3)             -->

HASH(3)-- for liveliness-- is the prf over the value zero represented as a single octet, followed by a concatenation of the message id and the two nonces-- the initiator's followed by the responder's-- minus the payload header.

HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

The above trace does not conform to this quote. Does the ASA implementation always send QM3 hash as a payload header with no content?

Marcin Latosiewicz · ‎08-03-2012

Hi there,

Interesting theory, let's verify.

If you're inetersted to look at the decoded packet you can get from ASA:

capture IKE type isakmp interface NAME_OF_INTERFACE

You can export that capture in pcap format and open it up in wireshark. You should see more info.

M.

armamsic_ · ‎08-03-2012

Hello Marcin, thank you for your reply.

I have just exported the capture to wireshark and I see a HASH payload with a length of 4 bytes and 24 octets being 0 at the end.

Marcin Latosiewicz · ‎08-03-2012

Open up a TAC case, attach the ISAKMP capture and debug and quote the RFC, it would need someone to look in depth at this.

armamsic_ · ‎08-03-2012

Hello Marcin,

Thank you for your input!