[vpn-devel] SHA2 Inteoperability issues?

[Mark Larwill]

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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-devel/attachments/20130520/eef0a9c0/attachment.html>