[strongSwan] SHA1 vs SHA256

[Noel Kuntze]

Hi,

If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default truncation length.
It is not possible to choose the truncation length using pfkey.
If XFRM over netlink socket is used to configure XFRM, one can choose the truncation length. strongSwan uses the 128 bit truncation length for HMAC-SHa256.

Since 5.5.3, one can choose the truncation length on a per-conn basis.
From the roadmap[3]:

With the sha256_96 compatibility option it's possible to locally configure 96-bit truncation
for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the official
algorithm identifier (12). This is only useful for compatibility with peers that incorrectly
use this shorter truncation as the actual truncation length is not negotiated.

So the solution is to try using kernel-netlink instead of kernel-pfkey with strongSwan in an attempt to force the kernel to
use the 128 bit truncation length, which strongSwan chooses by default.

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2301
[2] https://wiki.strongswan.org/issues/2391
[3] https://wiki.strongswan.org/versions/65
On 04.08.2017 20:50, Andreas Steffen wrote:
> Hi Dusan,
> 
> the only workaround I see is to either upgrade your Linux 2.6
> kernel or fall back to a SHA-1 based ESP HMAC.
> 
> Regards
> 
> Andreas
> 
> On 04.08.2017 20:46, Dusan Ilic wrote:
>> Hi,
>>
>> Unfortunately, I'm not following you guys :)
>> Could someone please clarify?
>>
>>
>> Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
>>> Hi,
>>>
>>> IIRC pfkey still uses the old truncation (It's mentioned in some
>>> relatively recent ticket).
>>> Try using kernel-netlink instead.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>>
>>> On 04.08.2017 19:02, Andreas Steffen wrote:
>>>> Hi Dusan,
>>>>
>>>> hmmm, our documentation says that the correct ESP SHA256_128 HMAC
>>>> truncation was introduced with the 2.6.33 kernel but your kernel
>>>> might not be a vanilla 2.6.36 kernel:
>>>>
>>>>   https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>>>
>>>>   (ESP integrity algorithm footnote n)
>>>>
>>>> Regards
>>>>
>>>> Andreas
>>>>
>>>> On 04.08.2017 16:41, Dusan Ilic wrote:
>>>>> Hi Andreas
>>>>>
>>>>> One side is 2.6.36 and the other 3.10.20
>>>>>
>>>>>
>>>>> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>>>>>> Hi Dusan,
>>>>>>
>>>>>> this is a Linux kernel issue. Which kernel versions are you running
>>>>>> on the two endpoints?.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> On 04.08.2017 12:41, Dusan Ilic wrote:
>>>>>>> Hi Noel,
>>>>>>>
>>>>>>> One side is Strongswan 5.2.2 and the other is 5.5.2.
>>>>>>> How do I switch?
>>>>>>>
>>>>>>>
>>>>>>> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
>>>>>>>> the remote peer probably uses the DRAFT variant of sha2-256, which
>>>>>>>> uses 96 bit truncation. strongSwan uses the actual standardized
>>>>>>>> variant that truncates to 128 bit.
>>>>>>>> You can switch between the two in the newest version of strongSwan
>>>>>>>>
>>>>>>>> On 04.08.2017 12:23, Dusan Ilic wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> I have a strange issue, with both settings below the tunnel goes up
>>>>>>>>> as it should, but only with SHA1 in ESP traffic goes through.
>>>>>>>>> When I
>>>>>>>>> ping the remote client with ESP SHA256 it times out, even though
>>>>>>>>> the
>>>>>>>>> tunnel reports as being up by Strongswan.
>>>>>>>>>
>>>>>>>>> Traffic working:
>>>>>>>>>
>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>> esp=aes128-sha1-modp2048!
>>>>>>>>>
>>>>>>>>> Traffic not working:
>>>>>>>>>
>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>> esp=aes256-sha256-modp2048!
>>>>>>>>>
>>>>>>>>> Below combo doesn't work either:
>>>>>>>>>
>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>> esp=aes128-sha256-modp2048!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, are above settings good? I'm having AES128 on ESP because
>>>>>>>>> with
>>>>>>>>> AES256 I loose too much througput. Do you have any suggestions for
>>>>>>>>> change?
>>>>>>>>>
>>>>>>>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170804/df316935/attachment.sig>