PBKDF2 hashing does not work in FIPS mode

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50528

Created at 2019-08-02 13:09:35 by mhonek (@kenoh)
Assigned to mhonek (@kenoh)

Issue Description

When NSS is run in FIPS mode (either Level 1 - the internal token is FIPS, or Level 2 - the NSS database is set to FIPS mode), it is not possible to extract the produced hash using PK11_ExtractKeyValue().

Package Version and Platform

1.4

Steps to reproduce

Run in FIPS mode.
Trigger the pbkdf2_sha256_hash function, e.g. by trying to bind with a password that's stored with PBKDF2.
The code trips over PK11_ExtractKeyValue call.

Actual results

The function fails.

Expected results

The hash (i.e. key value) is correctly extracted.

389-ds-bot commented 4 years ago

Comment from mhonek (@kenoh) at 2020-03-04 16:30:03

Metadata Update from @kenoh:

Custom field origin adjusted to None
Custom field reviewstatus adjusted to None
Issue set to the milestone: 1.4.3 (was: 1.4.2)

droideck commented 4 years ago

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1779685

Firstyear commented 4 years ago

This sounds like an NSS problem, not a 389 one. In FIPS mode NSS limits what can/can't be done, and if NSS is limiting the use of PBKDF2 in FIPS mode, that's not something we can do a lot about.

droideck commented 4 years ago

This sounds like an NSS problem, not a 389 one. In FIPS mode NSS limits what can/can't be done, and if NSS is limiting the use of PBKDF2 in FIPS mode, that's not something we can do a lot about.

We can, there is something similar that @kenoh found - https://github.com/ethernitynet/libreswan/blob/dfd3e6a775952209721fbb182ee3d15cde609691/programs/pluto/crypt_symkey.c#L283

Basically, we can extract the key value by wrapping(encrypting) and then decrypting. As a side-effect, we get the key value.

Firstyear commented 4 years ago

That sounds like a hack to work around a flaw in NSS then .... In FIPS NSS should just let us see the derived key.

kenoh commented 4 years ago

It is a hack which is however accepted in FIPS since it does not extract secrets. Bob Relyea admitted that NSS should provide a way for a simple extraction of hashes; I guess they welcome patches. :)

Firstyear commented 4 years ago

Bob Relyea admitted that NSS should provide a way for a simple extraction of hashes; I guess they welcome patches. :)

I don't think it's up to us to implement this, and we should request it from NSS to implement this functionality that will benefit all nss linking FIPS programs, rather than everyone creating bespoke "hacks" to make up for it.

droideck commented 4 years ago

I've reported the bug to NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1670235

Also, I think we should work around it until the issue is fixed. And then we should fix the workaround back to the original state when PBKDF2 will start to work in FIPS.

droideck commented 4 years ago

The upstream NSS issue got an update:

"This is expected behavior. You can't extract keys from FIPS mode. (PBKDF2 works in FIPS mode, getting PBKDF2 result as data does not).

I'll see if we can create a new mechanism for this that produces data rather than a key. There are people who are using PBKDF2 as hashes rather than a key derive function.

For now this is not a bug, but it probably implies a feature request (data access to PBKDF2). This is not the only user that has run into this problem. You an see ldap's work around.

I've updated the title too reflect the real issue and changes this to an enhancement."

Firstyear commented 3 years ago

@droideck This may not be an issue soon since the openldap password hashers I just submitted link to openssl rather than nss, which actually resolves a security issue in the NSS version. So perhaps we could default to the rust version of pbkdf2 in 2.0.1?

mreynolds389 commented 3 years ago

droideck commented 3 years ago

aa0564647..1b3c54bd4 389-ds-base-1.4.3 -> 389-ds-base-1.4.3 6b8b98a37..e3dff55fb 389-ds-base-1.4.4 -> 389-ds-base-1.4.4 6467ea5cb..b0d06615e 389-ds-base-2.0 -> 389-ds-base-2.0

vashirov commented 3 years ago

Reopening, as this breaks non-Rust builds, see https://github.com/389ds/389-ds-base/pull/4985#issuecomment-961888266 pwdhash fails:

The plugin entry [cn=PBKDF2,cn=Password Storage Schemes,cn=plugins,cn=config] in the configfile /usr/share/dirsrv/data/template-dse.ldif was invalid.  Failed to load plugin's init function.

Entries added to template-dse.ldif use pwdchan plugin written in Rust, but it's not available on non-Rust builds.

mreynolds389 commented 3 years ago

Perhaps instead of adding it to template-dse we can add it via the upgrade() function in ldap/servers/slapd/upgrade.c, like what we do with entryuuid plugin?

droideck commented 3 years ago

Perhaps instead of adding it to template-dse we can add it via the upgrade() function in ldap/servers/slapd/upgrade.c, like what we do with entryuuid plugin?

Sounds good! I'll work on that next week. :) Easy to do, but I need to test it here and there.

droideck commented 2 years ago

As discussed, Rust is a core part of the new versions of 389 DS, so it should be built with it. Hence, https://github.com/389ds/389-ds-base/issues/3584#issuecomment-962143494 won't be implemented for now.

mreynolds389 commented 2 years ago

Should this test also be cherry-picked down to 1.4.3?

droideck commented 2 years ago

33ea3c176..7a351d036 389-ds-base-1.4.3 -> 389-ds-base-1.4.3 6444e45be..3ab042db6 389-ds-base-1.4.4 -> 389-ds-base-1.4.4 97b3c32d2..c2f6c23ba 389-ds-base-2.0 -> 389-ds-base-2.0

389ds / 389-ds-base