<div dir="ltr">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.<div>
<br></div><div style>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.</div>
<div style><br></div><div style>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:</div>
<div style><br></div><div style>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<br></div><div style><br></div><div style>--Mark Larwill</div><div style><p class=""></p></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 20, 2013 at 3:52 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 20 May 2013, Mark Larwill wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
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<br>
what I know:<br>
1. Phase1 and Phase2 both complete successfully<br>
2. If I send ping traffic, Shrew does generate ESP packets<br>
3. ESP packets are dropped at the firewall and a log message is generated saying that "Integrity check failed"<br>
<br>
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<br>
77.0.0.1 dst 0.0.0.0) spi 0xb5d723ce proto 50 reason "Integrity check failed"<br>
<br>
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,<br>
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<br>
SHA2 hash, instead of the truncated value (per RFC4868). This could cause the integrity check to fail. For example if using SHA2-256<br>
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<br>
packet with 16 bytes of truncated hash.<br>
</blockquote>
<br></div>
The Linux kernel implemented sha2_256 wrong. It used a draft instead of<br>
the final RFC document. They then fixed it using a different xfrm_algo<br>
struct in the kernel. So if your software uses the old method, it will<br>
fail with RFC compliant devices. If your software uses the new method,<br>
it will fail with older Linux kernels. Note that SHA2-384 and SHA2-512<br>
were correctly implemented, so you can test with that see if this is<br>
indeed your problem (assuming you use shrew on linux)<br>
<br>
For libreswan/openswan, we introduced the sha2_truncbug= option to be<br>
able to do both:<br>
<br>
sha2_truncbug<br>
The default hash truncation for sha2_256 is 128 bits. Linux<br>
implemented the draft version which stated 96 bits. This option<br>
enables using the bad 96 bits version to interop with older linux<br>
kernels (unpatched version 2.6.33 and older) and libreswan versions<br>
before 2.6.38. Currently the accepted values are no, (the default)<br>
signifying default IETF truncation of 128 bits, or yes, signifying<br>
96 bits broken Linux kernel style truncation.<br>
<br>
You can find the code in openswan/libreswan in programs/pluto/kernel_netlink.<u></u>c<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>