ipa_generate_password generates a really long password with at least one element from the upper, lower, special, and digit character class. This should be good enough for FIPS, too.

>>> from ipapython.ipautil import ipa_generate_password
>>> help(ipa_generate_password)
Help on function ipa_generate_password in module ipapython.ipautil:

ipa_generate_password(entropy_bits=256, uppercase=1, lowercase=1, digits=1, special=1, min_len=0)
    Generate token containing at least `entropy_bits` bits and with the given
    character restraints.
    
    :param entropy_bits:
        The minimal number of entropy bits attacker has to guess:
           128 bits entropy: secure
           256 bits of entropy: secure enough if you care about quantum
                                computers
    
    Integer values specify minimal number of characters from given
    character class and length.
    Value None prevents given character from appearing in the token.
    
    Example:
    TokenGenerator(uppercase=3, lowercase=3, digits=0, special=None)
    
    At least 3 upper and 3 lower case ASCII chars, may contain digits,
    no special chars.

>>> ipa_generate_password()
'0Fc*Cqs0k0deO)9WCT!{bPHg;f$Vrf|l/zx-N]BgE'
>>> ipa_generate_password()
'4Nq<*Ojx@8J/;oySW.}aphhM:x{VE.>liR<yw+-h.'
>>> ipa_generate_password()
'7Jo,gb26Lbm8J){Q:IGz);)[Nqj&<qvI>R&3O^xsO'
>>> ipa_generate_password()
'1Hc+T7p^U;<:o{zU&%5M}!6k7H|p&T@%Y)<*RcNKa'
>>> ipa_generate_password()
'7Fb>xFF!^!BK+NAT$yxOYi2jV}kpZX:j|.2z<H}]+'

Mark,

since https://pagure.io/389-ds-base/issue/49235, 389-ds defaults to PBKDF2_SHA256 for a password scheme. Was this tested to be FIPS compatible?

There is also this:

Clarify support of pbkdf2 for fips
https://bugzilla.redhat.com/show_bug.cgi?id=1513765

NIST SP 800-132 specifies PBKDF2 as approved when combined with HMAC as PRF with any FIPS approved hash function. NSS' FIPS Validation page https://wiki.mozilla.org/FIPS_Validation does list PBKDF2 explicitly.

What component is this failure coming from? Is that NSS? I would say then it is a bug in the component as there is nothing wrong with using PBKDF2-SHA256. Or you're calling the PBKDF2 implementation in NSS somehow incorrectly.

(In reply to Alexander Bokovoy from comment #3)
> Mark,
> 
> since https://pagure.io/389-ds-base/issue/49235, 389-ds defaults to
> PBKDF2_SHA256 for a password scheme. Was this tested to be FIPS compatible?

Hi Alexander,

At the time I recall it NOT working in FIPS mode, but "looks" like it is now supposed to work according to the comments in this bug.

Mark

(In reply to Tomas Mraz from comment #9)
> What component is this failure coming from? Is that NSS? I would say then it
> is a bug in the component as there is nothing wrong with using
> PBKDF2-SHA256. Or you're calling the PBKDF2 implementation in NSS somehow
> incorrectly.

For FreeIPA it is coming from 389-ds over LDAP protocol, so it is what happens in 389-ds. There, it is using password storage plugins to create hashes and store them. As reported by Thorsten, the failure is with PBKDF2_SHA256 storage scheme which fails. For PBKDF2_SHA256 hashing 389-ds uses NSS functions so it is most likely where it fails.

If password policy defines 'passwordstoragescheme: default', then 389-ds should detects it is running in FIPS mode (calling PK11_IsFIPS) and adopt a storage scheme SSHA512 (not PBKDF2_SHA256).

Is there a specific password policy with a specific passwordstoragescheme ?

There is no reason why the PBKDF2_SHA256 password hash should not work in the FIPS mode for password hashing. I probably understand why the function fails on NSS - it regards it as key derivation function and you need to export the key which NSS disallows because it used to be FIPS 140-2 level 2 validated. However this is no longer the case and the check is superfluous for level 1 validation and it unnecessarily prevents its use for password hashing.

upstream ticket https://pagure.io/389-ds-base/issue/50099

fix of upstream ticket https://pagure.io/389-ds-base/issue/50099 is pushed => POST

set back the needinfo flag

Build tested:
389-ds-base-1.4.0.20-5.module+el8+2685+6de0feb1.x86_64

Without FIPS mode passwordStorageScheme defaults to PBKDF2_SHA256:
[root@server ~]# cat /proc/sys/crypto/fips_enabled 
0
[root@server ~]# ldapsearch -LLL -D cn=directory\ manager -w password -b cn=config passwordStorageScheme | grep -i passwordStorageScheme
passwordStorageScheme: PBKDF2_SHA256

On FIPS machine passwordStorageScheme defaults to SSHA512
[root@server ~]# cat /proc/sys/crypto/fips_enabled 
1
[root@server ~]# ldapsearch -LLL -D cn=directory\ manager -w password -b cn=config passwordStorageScheme | grep -i passwordStorageScheme
passwordStorageScheme: SSHA512

Marking as VERIFIED.