Skip to contentSkip to conversation

: Change the ICV length of sha256 to 128 bits

PATCH In review Jason Gunthorpe 3 participants 6 messages Dec 24, 2008 – Dec 29, 2008

Subsystems (3)
Networking Network drivers Networking IPsec
lore
Share & tools
lore

Jason Gunthorpe

author
#0 lore raw

PATCH 1/1 : Change the ICV length of sha256 to 128 bits

The existing setting is 96 bits which does not match the RFCs and is not negotiable via IKEv2. RFC 4868 says the ICV should be 128 bits, and IKEv2 uses AUTH_HMAC_SHA2_256_128 = 12 to identify it.

git blame says this setting was made before RFC 4868 was published, so I'm not sure that it was chosen with any standard in mind.

NOTE: This 'breaks' the user space API, however at least StrongSwan 4.2.9's charon already associates AUTH_HMAC_SHA2_256_128 with the transform name 'sha256'.

Signed-off-by Jason Gunthorpe <[email protected]>
---
 net/xfrm/xfrm_algo.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
net/xfrm/xfrm_algo.c +1 -1
index 4141376..d136b72 100644
@@ -187,7 +187,7 @@ static struct xfrm_algo_desc aalg_list[] = {
 
 	.uinfo = {
 		.auth = {
-			.icv_truncbits = 96,
+			.icv_truncbits = 128,
 			.icv_fullbits = 256,
 		}
 	},
Signature · 1 line
1.5.4.2
maintainer
#1 lore raw
Quoted 4 lines · Jason Gunthorpe

The existing setting is 96 bits which does not match the RFCs and is not negotiable via IKEv2. RFC 4868 says the ICV should be 128 bits, and IKEv2 uses AUTH_HMAC_SHA2_256_128 = 12 to identify it.

Quoted 8 lines

git blame says this setting was made before RFC 4868 was published, so I'm not sure that it was chosen with any standard in mind.

NOTE: This 'breaks' the user space API, however at least StrongSwan 4.2.9's charon already associates AUTH_HMAC_SHA2_256_128 with the transform name 'sha256'.

Signed-off-by Jason Gunthorpe <[email protected]>

The 96 bits is actually still correct for the auth algorithm IDs 5, 6, and 7. The parameters in 4868 have been assigned new IDs starting from 12.

So what we should do is support both.

This is easy to do for af_key as it uses IDs to identify the algorithms. To make this work for xfrm, we need to extend the auth algorithm specification to include the truncation length, just like AEAD.

So if you feel adventurous, please prepare a patch to create a new xfrm attribute XFRMA_AUTH2 that uses xfrm_algo_aead instead of xfrm_algo, and allow that in place of XFRMA_AUTH.

After that we can restructure the auth algorithm list to be like AEAD and then you can add a new set of SHA algorithms for RFC 4868.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author
#2 lore raw
Quoted 12 lines · Herbert Xu
Quoted 11 lines · Jason Gunthorpe

The existing setting is 96 bits which does not match the RFCs and is not negotiable via IKEv2. RFC 4868 says the ICV should be 128 bits, and IKEv2 uses AUTH_HMAC_SHA2_256_128 = 12 to identify it.

git blame says this setting was made before RFC 4868 was published, so I'm not sure that it was chosen with any standard in mind.

NOTE: This 'breaks' the user space API, however at least StrongSwan 4.2.9's charon already associates AUTH_HMAC_SHA2_256_128 with the transform name 'sha256'.

Quoted 5 lines
Quoted 1 line
Signed-off-by Jason Gunthorpe <[email protected]>

The 96 bits is actually still correct for the auth algorithm IDs 5, 6, and 7. The parameters in 4868 have been assigned new IDs starting from 12.

Oh? Ok, I didn't realize there was something that defined those usages on PF_KEY. They are not defined for use with IKEv2 at all..

BTW, is there some reason why SADB_X_AALG_SHA2_384HMAC and SADB_X_AALG_SHA2_512HMAC are absent from the table in xfrm_algos?

Quoted 4 lines

This is easy to do for af_key as it uses IDs to identify the algorithms. To make this work for xfrm, we need to extend the auth algorithm specification to include the truncation length, just like AEAD.

Yes, I was already thinking this was the best way to support the 128/160 bit ICV lens for MD5/SHA1 that are now defined.

Quoted 3 lines

So if you feel adventurous, please prepare a patch to create a new xfrm attribute XFRMA_AUTH2 that uses xfrm_algo_aead instead of xfrm_algo, and allow that in place of XFRMA_AUTH.

Thats not too hard, I might have a little time to do that over the break.

Quoted 2 lines

After that we can restructure the auth algorithm list to be like AEAD and then you can add a new set of SHA algorithms for RFC 4868.

It seems like those can be added today, they already have unique
names: hmac(sha384), hmac(sha512)

BTW, Herbert, if this is the way to go can you fix StrongSwan? Mapping AUTH_HMAC_SHA2_256_128 to 'sha256' in src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c is not correct based on this discussion. It needs to be 'hmac(sha256)' and use this XFRMA_AUTH2 idea. Similarly for all the SHA-2 family of functions I guess.

Thanks,
Jason

maintainer
#3 lore raw
Quoted 2 lines · Jason Gunthorpe

BTW, Herbert, if this is the way to go can you fix StrongSwan?

No I can't since I'm not a Strongswan developer :)

I've cced the people who can though.

Quoted 5 lines

Mapping AUTH_HMAC_SHA2_256_128 to 'sha256' in src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c is not correct based on this discussion. It needs to be 'hmac(sha256)' and use this XFRMA_AUTH2 idea. Similarly for all the SHA-2 family of functions I guess.

Strongswan needs to drop SHA2-256-128 for now since we don't support it currently. Once we have XFRMA_AUTH2 it can be restored of course.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#4 lore raw
In reply to Jason Gunthorpe

Hi,

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines

git blame says this setting was made before RFC 4868 was published, so I'm not sure that it was chosen with any standard in mind.

NOTE: This 'breaks' the user space API, however at least StrongSwan 4.2.9's charon already associates AUTH_HMAC_SHA2_256_128 with the transform name 'sha256'.

We already discussed this in
http://kerneltrap.org/mailarchive/linux-kernel/2008/6/5/2039114 , but it was too much effort for me to fix this properly then.

Quoted 6 lines
Quoted 3 lines

The 96 bits is actually still correct for the auth algorithm IDs 5, 6, and 7. The parameters in 4868 have been assigned new IDs starting from 12.

Oh? Ok, I didn't realize there was something that defined those usages on PF_KEY. They are not defined for use with IKEv2 at all..

In PF_KEY, SADB_X_AALG_SHA2_256HMAC (5) was defined in draft-ietf-ipsec-ciph-sha-256-00 to 96 bit truncation (what is currently implemented). draft-ietf-ipsec-ciph-sha-256-01 defined it to 128 bit truncation (what is now RFC 4868).
Those numbers starting from 12 are IKEv2 algorithm identifiers and are never passed to the kernel.

Quoted 2 lines

BTW, is there some reason why SADB_X_AALG_SHA2_384HMAC and SADB_X_AALG_SHA2_512HMAC are absent from the table in xfrm_algos?

Yes, it was not specified in draft-ietf-ipsec-ciph-sha-256-00, but is defined in RFC 4868.

Quoted 6 lines

BTW, Herbert, if this is the way to go can you fix StrongSwan? Mapping AUTH_HMAC_SHA2_256_128 to 'sha256' in src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c is not correct based on this discussion. It needs to be 'hmac(sha256)' and use this XFRMA_AUTH2 idea. Similarly for all the SHA-2 family of functions I guess.

Yes I'm aware of that. I'll fix it a soon as it is available in the kernel.

Regards
Martin

maintainer
#5 lore raw
Quoted 7 lines · Martin Willi

In PF_KEY, SADB_X_AALG_SHA2_256HMAC (5) was defined in draft-ietf-ipsec-ciph-sha-256-00 to 96 bit truncation (what is currently implemented). draft-ietf-ipsec-ciph-sha-256-01 defined it to 128 bit truncation (what is now RFC 4868).
Those numbers starting from 12 are IKEv2 algorithm identifiers and are never passed to the kernel.

What are you talking about? Neither of those two drafts talks about the ID used between the KM and the kernel. So the PF_KEY ID is simply irrelevant.

What is important though is what's deployed in the field with respect to IKE. All the BSDs support 96-bit truncation so we should continue to do that as well.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt