[Swan-dev] annoying AES_XCBC FIPS, er, quirk
paul at nohats.ca
Wed Mar 28 09:26:22 UTC 2018
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?
More information about the Swan-dev