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

[Martin Willi <martin@strongswan.org>]

Hi,

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

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

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

> 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