Hello Benoit, RFC 3947 "Negotiation of NAT-Traversal in the IKE" does not specify explicitly whether the additional NAT-OA payloads must be part of the hash:
>---------------------------------------------------------------------- The following example is of Quick Mode using NAT-OA payloads: Initiator Responder ------------ ------------ HDR*, HASH(1), SA, Ni, [, KE] [, IDci, IDcr ] [, NAT-OAi, NAT-OAr] --> <-- HDR*, HASH(2), SA, Nr, [, KE] [, IDci, IDcr ] [, NAT-OAi, NAT-OAr] HDR*, HASH(3) --> ----------------------------------------------------------------------< but the IKEv1 RFC 2409 specifies in section 5.5 "Phase 2 - Quick Mode": >---------------------------------------------------------------------- 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) --> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP header concatenated with the entire message that follows the hash including !! ^^^^^^^^^^^^^^^^^ all payload headers, but excluding any padding added for encryption. HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, minus the payload header-- is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for a liveliness proof. 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. In other words, the hashes for the above exchange are: HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ) HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of !! ^^^^^^^^^^ payloads in the message differs from the illustrative example or if any optional payloads, for example a notify payload, have been !! ^^^^^^^^^^^^^^^^^^^^^ chained to the message. ----------------------------------------------------------------------< Thus in my opinion strongSwan is correct in including the optional NAT-OA payloads in the HASH and racoon is wrong in not doing so. Best regards Andreas On 14.12.2010 10:04, Benoit Foucher wrote: > Hi Victor, > > I found a workaround for this INVALID_HASH_INFORMATION error by > hacking strongSwan's code but I doubt it's really correct (and I'm > running into another issue after :(). The problem is that raccoon and > strongSwan don't compute the HASH on the same data (raccoon doesn't > includes NAT-OA in the hash computation whereas strongSwan does). > > See: > > https://lists.strongswan.org/pipermail/users/2010-December/005712.html > > It would be good to figure out whether or not this is a strongSwan > or raccoon issue. If it's the later I'll submit a bug where > appropriate. > > Cheers, Benoit > ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users