Issues in using OpenSAML 4.x in FIPS compliant applications

[Paul Henson]

On 8/15/2023 3:03 AM, Ritesh Kothari via dev wrote:

> Does not look like, Shibboleth wikis ensure any support on it in future 
 >
> - https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1159627167/FIPS 

Well, yes, as Scott made clear the project itself has no requirements 
for FIPS compatibility, and nobody with a paid consortium support 
contract has asked for it, so it's not a priority.

> - https://shibboleth.atlassian.net/browse/OSJ-339 

Although as demonstrated by this change Brent made, they will certainly 
try to help within the constraints they're working in.

It seems your options if you need this badly enough are either become a 
consortium member and submit an official feature request, implement it 
yourself and submit it for review, or get a third party shibboleth 
support company to do that for you:

	https://www.shibboleth.net/support/


 From just a quick look, these are the bouncycastle classes in use by 
the latest source of opensaml that aren't in the FIPs compliant jar:

org.bouncycastle.crypto.Digest
org.bouncycastle.crypto.agreement.kdf.ConcatenationKDFGenerator
org.bouncycastle.crypto.digests.RIPEMD160Digest
org.bouncycastle.crypto.digests.SHA1Digest
org.bouncycastle.crypto.digests.SHA224Digest
org.bouncycastle.crypto.digests.SHA256Digest
org.bouncycastle.crypto.digests.SHA384Digest
org.bouncycastle.crypto.digests.SHA512Digest
org.bouncycastle.crypto.params.KDFParameters
org.bouncycastle.jcajce.provider.asymmetric.util.EC5Util
org.bouncycastle.jce.ECNamedCurveTable
org.bouncycastle.jce.provider.BouncyCastleProvider
org.bouncycastle.jce.spec.ECNamedCurveParameterSpec

If the functionality provided is optional, you'd need a way to disable 
it; if it was required, you would need an alternative implementation 
that met your requirements. It appears the change from OSJ-339 takes 
care of the two KDF related classes, and 
org.bouncycastle.jce.provider.BouncyCastleProvider is only used by the 
testing framework. These ones:

org.bouncycastle.crypto.digests.RIPEMD160Digest
org.bouncycastle.crypto.digests.SHA1Digest
org.bouncycastle.crypto.digests.SHA224Digest
org.bouncycastle.crypto.digests.SHA256Digest
org.bouncycastle.crypto.digests.SHA384Digest
org.bouncycastle.crypto.digests.SHA512Digest

appear to have corresponding classes in the fips jar:

org.bouncycastle.crypto.general.RIPEMD160Digest
org.bouncycastle.crypto.fips.SHA1Digest
org.bouncycastle.crypto.fips.SHA224Digest
org.bouncycastle.crypto.fips.SHA256Digest
org.bouncycastle.crypto.fips.SHA384Digest
org.bouncycastle.crypto.fips.SHA512Digest


I think that only leaves the EC crypto support; it looks like the 
elastic search guys worked around that by just removing the file 
META-INF/services/org.opensaml.security.crypto.ec.NamedCurve from the jar:

	https://github.com/elastic/elasticsearch/pull/98199

Based on the discussion there, there are just a couple of classes that 
are eagerly loaded that pull in these dependencies, and it might just 
need a simple parameter created to avoid doing that in FIPs compliant mode.


-- 
Signet - The Art of Access
https://www.signet.id/