I can answer part of this myself (after happy hours with windows debugger)


Windows does (a) because it thinks that the linux box is another Windows box

Why it thinks that is a different story - I will post that later, its due to a fix for a different problem


However (b) is still wrong , isakmp_inf.c cannot blindly assume that the second payload is the n/d


From: Paul Moore [mailto:paul.moore@centrify.com]
Sent: Thursday, January 29, 2009 5:10 PM
To: ipsec-tools-devel@lists.sourceforge.net
Subject: [Ipsec-tools-devel] informational hashing bugs


0.7.1 talking to Windows (xp and Vista)


Sometimes windows sends an informational delete that look like this




585853ee 6a24e2d6 0a6de100 1c147ffb 08100501 08cc355b 0000005c 0a000018

d7631b7a 6409c676 f5b24ab6 79533902 55079991 0cf40018 6049df4d 3c1c37dd

77e2ec26 b5a82ff2 809bb074 00000010 00000001 03040001 609626d3


I dont know why it does this but several bad things then happen


a) windows generated the hash like this

prf(skeyida, msgid | nonce | D)

ie it hashed everything starting from the 0cf40018 to the end of the packet

this is not right (at least not according to my reading of thr rfcs)


b) isakmp_inf.c assumes that the second payload in the messages is the delete message

so it did a hash check on this



2009-01-29 16:24:17: DEBUG: HASH with:

2009-01-29 16:24:17: DEBUG:

08cc355b 0cf40018 6049df4d 3c1c37dd 77e2ec26 b5a82ff2 809bb074


which is msgid|nonce


so we get


2009-01-29 16:24:17: ERROR: ignore information due to hash mismatch


isakmp_parse correctly recognized the payloads


2009-01-29 16:24:17: DEBUG: seen nptype=8(hash)

2009-01-29 16:24:17: DEBUG: seen nptype=10(nonce)

2009-01-29 16:24:17: DEBUG: seen nptype=12(delete)


but this is after the hash check that is hardwire to payload 2 (I commented out the hash memcmp check to get this far)


I can obviously add a bunch of code to workaround a and fix b but I just wondered if this was a known behavior