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

[Andrew Cagney]

The latter, I'd assume our custom implementation is not FIPS compliant.
In FIPS mode it is disabled (it just doesn't look like it is).


On 28 March 2018 at 05:26, Paul Wouters <paul at nohats.ca> wrote:
> 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