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)             -->

   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


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)

Users mailing list

Reply via email to