security_wrappers.c

PRBool
slapd_pk11_isFIPS()
{
    return PK11_IsFIPS();
}

This should work.

Thanks mate. I'll keep this in mind :)

I'm not sure if this can be addressed, but when you enable fips the root DN password no longer works.

[1] Setup DS
[2] Setup SSL
[3] Enable FIPS
[4] Try and use Directory Manager, or any user that already has a PBKDF2_SHA256 password.

ldapsearch -D "cn=directory manager" -w password -b "" -h localhost -p 389 -s base objectclass=top
ldap_bind: Invalid credentials (49)

[14/Nov/2017:10:09:10.730134567 -0500] - ERR - PBKDF2_SHA256 - Unable to extract hash output.
[14/Nov/2017:10:09:10.738541260 -0500] - ERR - PBKDF2_SHA256 - Unable to hash userpwd value

So the only way to fix it is to manually reset the password in dse.ldif. The same situation would apply to all users in the database. Once you goto FIPS everyone gets locked out, perhaps PBKDF2_SHA256 should not be the default storage scheme?

If we follow fips by default, we are essentially telling our consumers "lets stay 10 year behind the world cryptographically". I don't think that's responsible behaviour for us, and I don't want to hinder "secure by default" for the majority of the world that can follow reasonable cryptographic standards.

If you turn on fips, you need to reset your passwords, easy as that. Fips are a minority of our deployments, and in those cases, their admins tend to be highly informed and will be managing these settings anyway.

If you do fips first, then make the instance, that would have less issues I expect.

ALso, you can "pre-provide" root password hashs with both setup-ds.pl, and ds-create that can be any scheme you want,

Ohh by the way,

PBKDF2 is just multiround SHA, which is fips approved. According to this, it's allowed at l1

https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2261.pdf

This doc indicates likelihood that PBKDF2_SHA256 is fips allowed,

https://godoc.org/golang.org/x/crypto/pbkdf2

And openssl are supporting pbkdf2 in their fips module.

https://wiki.openssl.org/index.php/FIPS_module_3.0

So perhaps this is actually a bug in NSS, that they have not got the correct fips definitions sorted for their algos?

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf

Yep, here it is. NIST recommends PBKDF2 and if I interpret section 5.3 correctly, they approve it for fips provided the hmac is approved (sha256 is approved).

We need to release note this behaviour so customers don't flip out after then enable fips and everything breaks.

Okay, I'll get this documented correctly in the fips section. I have also opened https://bugzilla.redhat.com/show_bug.cgi?id=1513765 for NSS to clarify/correct their fips support.

If we are happy with those two outcomes, is the code okay? :)

Yeah, sorry, ack.

commit 90e1cf958d9921f18f1a77e21061ef5cd045a7f8
To ssh://git@pagure.io/389-ds-base.git
d40d919..25e62b6 master -> master

Issue linked to Bugzilla: Bug 1514297

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2507

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.