Re: [PATCH] [IPSEC]: Change the ICV length of sha256 to 128 bits

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

On Wed, Dec 24, 2008 at 07:59:40PM +1100, Herbert Xu wrote:
> On Tue, Dec 23, 2008 at 11:02:25PM -0700, Jason Gunthorpe wrote:
> > 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 <jgunthorpe@obsidianresearch.com>
 
> 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?

> 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.

> 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.

> 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