[vpn-devel] SHA2 Inteoperability issues?

Wed May 22 15:49:33 CDT 2013

Matthew was helpful enough to send me a pre-release image with the
up-to-date SHA2 truncation behavior following the RFC4868 standard. I can
confirm that I have tested all three variants of SHA2-256, SHA2-384, and
SHA2-512 and all three seem to be working against a WatchGuard firewall.

--Mark Larwill

On Wed, May 22, 2013 at 12:57 PM, Matthew Grooms <mgrooms at shrew.net> wrote:

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