[strongSwan] Confusing SHA256 truncation
Ruel, Ryan
rruel at akamai.com
Thu Jun 9 15:18:11 CEST 2016
I’ve run into this issue before.
There is a thread I had found (shown below) that describes what the exact issue is.
It’s indeed a bit odd it’s still present in the ARM 3.10 Kernel.
/Ryan
https://groups.google.com/forum/#!msg/fa.linux.kernel/RMS91WQXlUQ/MnNlkbzqJq0J
Currently the sha256 icv truncation length is set to 96bit
while the length is defined as 128bit in RFC4868.
This may result in some errors when working with other IPsec devices
with the standard truncation length.
Thus, change the sha256 truncation length from 96bit to 128bit.
Signed-off-by: Lei Xu <Lei... at freescale.com>
Signed-off-by: Horia Geanta <horia.... at freescale.com>
---
net/xfrm/xfrm_algo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index debe733386f8..ca21ba7a0716 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -220,7 +220,7 @@ static struct xfrm_algo_desc aalg_list[] = {
.uinfo = {
.auth = {
- .icv_truncbits = 96,
+ .icv_truncbits = 128,
.icv_fullbits = 256,
On 6/8/16, 4:23 PM, "Andreas Steffen" <andreas.steffen at strongswan.org> wrote:
>Hi Harald,
>
>before the 2.6.33 kernel, Linux used a non-compliant truncation of the
>SHA256 HMAC to 96 bits. RFC 4868 requires truncation to be exactly n/2
>bits where n is the size of the hash value.
>
> https://tools.ietf.org/html/rfc4868#section-2.3
>
>In the case of SHA256 this must be 128 bits. Why 96 bit truncation is
>still occurring in an ARM 3.10 kernel is really weird. It might be
>that the extra xfrm_algo_auth struct needed to configure SHA256_128
>truncation in the kernel is missing.
>
>Best regards
>
>Andreas
>
>On 06/08/2016 09:54 PM, Harald Krammer wrote:
>>
>> Hi all,
>> Currently I use Strongswan 5.2.2 (Debian 8). So far, everything is fine.
>> Only with SHA256 there are weird things.
>>
>> On my PC with Kernel 3.16 I got a length of 128 bits for SHA256 and the
>> same version on my ARM board with Kernel 3.10 I got a length pf 96 bits.
>>
>> Why does this happen?
>>
>> Any notes are welcome. Below is the output of ip xfrm state and the
>> configuration.
>>
>> Nice greetings
>> Harald
>>
>>
>>
>> Setup:
>> ######
>> PC with Debian 8 x86_64 with Kernel 3.16
>> <----->
>> ARM Board imX28 Kernel 3.10 also Strongswan 5.2.2
>>
>>
>> ARM Board imX28 Kernel 3.10 also Strongswan 5.2.2:
>> / # ip xfrm state
>> src 10.1.8.241 dst 10.1.8.240
>> proto esp spi 0xc86e8c86 reqid 1 mode tunnel
>> replay-window 32
>> auth-trunc hmac(sha256)
>> 0x9954ce2e14cbf9c68ec72178859d377da19899688df13783fd728ddd9648bcb7 96
>> enc ecb(cipher_null)
>> sel src 0.0.0.0/0 dst 0.0.0.0/0
>> src 10.1.8.240 dst 10.1.8.241
>> proto esp spi 0xc31d24ed reqid 1 mode tunnel
>> replay-window 32
>> auth-trunc hmac(sha256)
>> 0x0549596a5249d0ae333b9f2e56db47923aedc69252289d27796167d64db151de 96
>> enc ecb(cipher_null)
>> sel src 0.0.0.0/0 dst 0.0.0.0/0
>>
>> PC with Debian 8 x86_64 with Kernel 3.16:
>> root at saturn:/home/hk# ip xfrm state
>> src 10.1.8.240 dst 10.1.8.241
>> proto esp spi 0xc31d24ed reqid 10 mode tunnel
>> replay-window 32 flag af-unspec
>> auth-trunc hmac(sha256)
>> 0x0549596a5249d0ae333b9f2e56db47923aedc69252289d27796167d64db151de 128
>> enc ecb(cipher_null)
>> src 10.1.8.241 dst 10.1.8.240
>> proto esp spi 0xc86e8c86 reqid 10 mode tunnel
>> replay-window 32 flag af-unspec
>> auth-trunc hmac(sha256)
>> 0x9954ce2e14cbf9c68ec72178859d377da19899688df13783fd728ddd9648bcb7 128
>> enc ecb(cipher_null)
>>
>>
>>
>> Config: (is working without SHA256)
>> #######
>> conn %default
>> ikelifetime=28800
>> keylife=60m
>> rekeymargin=3m
>> keyingtries=1
>> keyexchange=ikev2
>> authby=secret
>>
>> conn test
>> left=10.1.8.240
>> leftsubnet=10.1.0.0/8
>> leftid=10.1.8.240
>> leftfirewall=yes
>> leftsourceip=%config
>> right=10.1.8.241
>> rightsubnet=10.1.8.241/32
>> rightid=10.1.8.241
>> auto=add
>> type=tunnel
>> ike=null-sha256-modp2048! # null for wireshark
>> esp=null-sha256-modp2048! # null for wireshark
>> dpdaction=restart
>> dpddelay=20s
>> dpdtimeout=10s
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>--
>======================================================================
>Andreas Steffen andreas.steffen at strongswan.org
>strongSwan - the Open Source VPN Solution! www.strongswan.org
>Institute for Internet Technologies and Applications
>University of Applied Sciences Rapperswil
>CH-8640 Rapperswil (Switzerland)
>===========================================================[ITA-HSR]==
>
More information about the Users
mailing list