[strongSwan] SHA2_256_128

[Eric_C_Johnson at Dell.com]

Just following up.

I am using a version of the kernel that supports both the 128 bit and 96 bit SHA_256 options.  You were 100% correct on the remote peer using the wrong key.  What appears to be happening is the P1\P2 SAs actually establish using SHA2_256_128 but the remote peer was actually using SHA2_256_96 to encrypt\decrypt the packets after the SAs were established.  To verify this I switched from SHA2_256_128 to SHA2_256_96 within wireshark.  As soon as I made that change the packets were interpreted correctly and proved that what was being used to encrypt\decrypt wasn't what was actually being negotiated.

Thank you for your help on this.

-----Original Message-----
From: Tobias Brunner [mailto:tobias at strongswan.org] 
Sent: Thursday, March 29, 2012 3:36 AM
To: Johnson, Eric C
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] SHA2_256_128

Hi Eric,

> I have a situation where ESP packets appear to be getting mangled on 
> the remote peer whenever I use SHA2-256-128 for Phase2 (ESP).  I can 
> establish the SAs from the Strongswan to the remote peer no problem.
> However, I get no packets returned after establishing the tunnel.

Not sure if this applies here as you didn't mention the kernel versions you are using, but Linux kernels before 2.6.33 incorrectly used a truncation of 96 bit for SHA-256.  With strongSwan 4.3.6 we introduced support for the configurable truncation length of newer kernels and the default changed to 128 bit.  For compatibility with older kernels we also added a new keyword (sha256_96) to negotiate the incorrect truncation (this uses algorithm identifiers from the private range in IKEv2, so it only works between two strongSwan hosts).  In your case the other host might be using the incorrect truncation while the strongSwan host expects a truncation of 128 bit.  By the way, Wireshark seems to support both truncations, so you should be able to verify this easily.

Regards,
Tobias