[vpn-devel] SHA2 Inteoperability issues?

Matthew Grooms mgrooms at shrew.net
Wed May 22 14:57:24 CDT 2013


Hi Mark,

Thanks for notifying me of this issue and helping me test the corrected 
SHA2 HMAC code.

For those who are curious, the VPN Client was tested primarily against 
the FreeBSD IPsec stack. Until recently (8.3/9.0), they used an HMAC 
value truncated to 96bits for all SHA2 variants. The VPN client worked 
when originally tested against that platform ( and at least one SHA2 
HMAC variant on a Linux distribution ), but now that everyone else is 
caching up with the standard, we need to as well.

 From now on, all Windows VPN client builds will adhere to the RFC4868 
standard. I am still researching what will need to be done on other 
platforms supported by the client, and Paul Wouters was kind enough to 
give me some helpful pointers for the Linux port.

Thanks again,

-Matthew

On 5/21/2013 2:11 PM, Matthew Grooms wrote:
> Hi Mark,
>
> I am the primary developer of the Shrew Soft VPN client. All of our
> compatibility testing for SHA2 was performed against Linux and FreeBSD
> kernel mode IPsec. I don't think any of the Cisco devices in my lab
> support SHA2. I will make sure my target gateways are up to date and
> perform some additional compatibility testing. If I can reproduce your
> failure test case, I will make sure this gets fixed for the upcoming
> 2.2.1 release and illicit your feedback for confirmation.
>
> Thanks,
>
> -Matthew
>
> On 5/20/2013 6:12 PM, Mark Larwill wrote:
>> This sounds like a good idea, but actually, I already knew the original
>> Linux handled SHA2-256 wrong, (incorrectly assuming a truncated length
>> of 96 bits). Our firewall is Linux based and I had run into the same
>> problem, and fixed it. There's an extra parameter we can pass to specify
>> the truncated length as 128 bits, which we do pass to Linux only in the
>> SHA2-256 case.
>>
>> In my case what I'm seeing is that all three SHA2 variants are failing
>> (negotiation works traffic doesn't pass), and in each case I'm seeing
>> the logs show up as an integrity check failing.
>>
>> I'm curious to know from any of the shrew developers or QA if they've
>> done any testing with Cisco boxes. We tested SHA2 for branch office VPN
>> from WatchGuard to a Cisco box and that worked. Since we already had the
>> Cisco box we also tested both mobile vpn with IPSec clients (Shrew
>> client, and NCP client) with the Cisco box, and we saw similar results,
>> NCP worked, Shrew did not. I have this log from the Cisco box from when
>> we tried to get it to work with Shrew:
>>
>> CRYPTO-4-RECVD_PKT_MAC_ERR: decrypt: mac verify failed for connection
>> id=179 local=16.0.0.200 remote=16.0.0.190 spi=030DA0F6 seqno=00000001
>>
>> --Mark Larwill
>>
>>
>>
>> On Mon, May 20, 2013 at 3:52 PM, Paul Wouters <paul at nohats.ca
>> <mailto:paul at nohats.ca>> wrote:
>>
>>     On Mon, 20 May 2013, Mark Larwill wrote:
>>
>>         I'm a developer at WatchGuard and I'm working on adding SHA2
>>         support for SHA2-256, SHA2-384, and SHA2-512 to our firewall.
>> I have
>>         noticed that when testing with NCP's mobile VPN client,
>>         everything works. When I test with Shrew's client it does not
>>         work. Here's
>>         what I know:
>>         1. Phase1 and Phase2 both complete successfully
>>         2. If I send ping traffic, Shrew does generate ESP packets
>>         3. ESP packets are dropped at the firewall and a log message is
>>         generated saying that "Integrity check failed"
>>
>>         May 20 20:45:30 2013 Firebox local0.warn kernel: [ 1553.257472]
>>         WG: Packet rejected. Gateways (src 4.4.4.1 dst 8.8.8.1) Selector
>>         (src
>>         77.0.0.1 dst 0.0.0.0) spi 0xb5d723ce proto 50 reason "Integrity
>>         check failed"
>>
>>         I understand that the problem could be on either side, so at
>>         this point it is not clear if the Shrew client is doing
>>         something wrong,
>>         or if the firewall is. However if I had to make an educated
>>         guess, I would speculate that maybe the shrew client is sending
>>         the full
>>         SHA2 hash, instead of the truncated value (per RFC4868). This
>>         could cause the integrity check to fail. For example if using
>>         SHA2-256
>>         and sending a 100 byte packet, with a full 32 bytes of hash, for
>>         a total of 132 bytes, the firewall might assume it's a 116 byte
>>         packet with 16 bytes of truncated hash.
>>
>>
>>     The Linux kernel implemented sha2_256 wrong. It used a draft
>> instead of
>>     the final RFC document. They then fixed it using a different
>> xfrm_algo
>>     struct in the kernel. So if your software uses the old method, it
>> will
>>     fail with RFC compliant devices. If your software uses the new
>> method,
>>     it will fail with older Linux kernels. Note that SHA2-384 and
>> SHA2-512
>>     were correctly implemented, so you can test with that see if this is
>>     indeed your problem (assuming you use shrew on linux)
>>
>>     For libreswan/openswan, we introduced the sha2_truncbug= option to be
>>     able to do both:
>>
>>             sha2_truncbug
>>                 The default hash truncation for sha2_256 is 128 bits.
>> Linux
>>                 implemented the draft version which stated 96 bits. This
>>     option
>>                 enables using the bad 96 bits version to interop with
>>     older linux
>>                 kernels (unpatched version 2.6.33 and older) and
>>     libreswan versions
>>                 before 2.6.38. Currently the accepted values are no,
>>     (the default)
>>                 signifying default IETF truncation of 128 bits, or yes,
>>     signifying
>>                 96 bits broken Linux kernel style truncation.
>>
>>     You can find the code in openswan/libreswan in
>>     programs/pluto/kernel_netlink.__c
>>
>>     Paul
>>
>>
>>
>>
>> _______________________________________________
>> vpn-devel mailing list
>> vpn-devel at lists.shrew.net
>> https://lists.shrew.net/mailman/listinfo/vpn-devel
>>
>
> _______________________________________________
> vpn-devel mailing list
> vpn-devel at lists.shrew.net
> https://lists.shrew.net/mailman/listinfo/vpn-devel



More information about the vpn-devel mailing list