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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
