[Swan-dev] annoying AES_XCBC FIPS, er, quirk

[Paul Wouters]

On Tue, 27 Mar 2018, Andrew Cagney wrote:

> Up until now pluto hasn't had to deal with an algorithm that has both
> FIPS and non-FIPS implementations, and instead, code has been assuming
> that an algorithm marked as FIPS is so for both IKE and ESP/AH.
> Unfortunately AES_XCBC breaks that assumption - the kernel's AES_XCBC
> is assumed to be FIPS compliant, but Pluto's internal implementation
> is decidedly not.
>
> The consequence is that, in FIPS mode, AES_XCBC_96 gets listed as a
> valid IKE integrity algorithm vis:
>
> AES_XCBC_96         IKEv1:     ESP AH  IKEv2: IKE ESP AH  FIPS
> (aes_xcbc aes128_xcbc aes128_xcbc_96)
>
> Fortunately, because the underlying PRF (AES_XCBC) isn't valid (and
> isn't listed), the parser will reject attempts to use it.

Are you saying it is not fips compliant because of the truncation
oddness? If so, we could ask the FIPS people about that.

Or were you referring to the fact that we use a hash function to
implement a prf because nss has no native support for it?

Paul