[vpn-devel] SHA2 Inteoperability issues?

[Matthew Grooms]

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
>