Thanks for the reply, Ulrich. What I'm trying to do is meet a customer requirement :-)

We are using {SSHA} (SHA-1) in OpenLDAP now. The customer wants SHA-512. And they require a FIPS-validated implementation, which I think narrows our options to using either OpenSSL or NSS in FIPS mode. I cannot see a better way to meet the customer's two requirements than gutting pw-sha2 and using that as a thin wrapper for the raw crypto functions in either openssl or nss.

I'm hoping somebody can suggest a better solution.

Steve

-----Original Message----- From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de] Sent: Friday, October 25, 2013 1:02 AM To: Steve Eckmann; openldap-technical@openldap.org Subject: Antw: use openssl or moznss for more than TLS?

...

...

Steve Eckmann steve.eckmann@issinc.com schrieb am 25.10.2013 um 04:08 in

Nachricht 1cc760ef909d438ab78baff3ff7547b1@CO1PR04MB442.namprd04.prod.outlook.com:

We need a FIPS-validated SHA512 for password storage. The pw-sha2 module provides SHA512 but isn't FIPS-validated. I see that I can use openssl or moznss in FIPS mode to get TLS, but I don't see how to get to either of those library's crypto functions from openldap. Is it possible?

Hi!

I don't know what you wnat to do, but user's passwords will be significantly weaker than SHA-1 I guess. The only thing is that some algorithms use more random bits for the salt, so the new security actually comes from mor salt, not from longer hashes. Still common passwords (from a dictionary) are problematic...

Like this (both passwords are identical): mOH0vXSTP9b9c (DES, UNIX standard) $6$rF2.bjfmxyctx3d2$7pJwHFCgsJPD/nwoA4kUm2aykwpWs3VUO5zZrQzEVWEqgGM0.qSvzkP3fsaJXrDCgjQvw454DkPYAh6Z/BD/p1 (SHA-512)

Regards, Ulrich

Thanks.

Steve

Thanks, Michael. I will follow up on your suggestion to ask about feasibility on openssl-users. And I agree about the validity of the requirement. We are trying to make it go away or identify workarounds.

Regards, Steve

-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Friday, October 25, 2013 12:00 PM To: Steve Eckmann; openldap-technical@openldap.org Subject: Re: Antw: use openssl or moznss for more than TLS?

Steve Eckmann wrote:

We are using {SSHA} (SHA-1) in OpenLDAP now. The customer wants SHA-512. And they require a FIPS-validated implementation, which I think narrows our options to using either OpenSSL or NSS in FIPS mode. I cannot see a better way to meet the customer's two requirements than gutting pw-sha2 and using that as a thin wrapper for the raw crypto functions in either openssl or nss.

You probably should first ask on the openssl-users mailing list under which conditions you get some "FIPS-validated" code regarding the whole OpenLDAP "application". Likely it's not feasible.

I'm pretty sure that your customer FIPS requirement is plain nonsense and you might work around this by some other strange policy text. ;-}

Ciao, Michael.

devzero2000 wrote:

On Fri, Oct 25, 2013 at 7:59 PM, Michael Ströder michael@stroeder.com wrote:

...

Steve Eckmann wrote:

...

We are using {SSHA} (SHA-1) in OpenLDAP now. The customer wants SHA-512. And they require a FIPS-validated implementation, which I think narrows our options to using either OpenSSL or NSS in FIPS mode. I cannot see a better way to meet the customer's two requirements than gutting pw-sha2 and using that as a thin wrapper for the raw crypto functions in either openssl or nss.

You probably should first ask on the openssl-users mailing list under which conditions you get some "FIPS-validated" code regarding the whole OpenLDAP "application". Likely it's not feasible.

I'm pretty sure that your customer FIPS requirement is plain nonsense and you might work around this by some other strange policy text. ;-}

I am not sure "nonsense" if some distro are doing something in this area. Right or, perhaps, sometime wrong (o perhaps sometime break). http://fedoraproject.org/wiki/FedoraCryptoConsolidation

FIPS validation is pretty strict. AFAIK you must not link any other crypto library into the same software which would IMHO require to hunk out all of OpenLDAP's built-in hash algorithm implementations and replace them with calls into the FIPS validated library.

AFAICS you would not gain anything by doing this regarding real security.

So I'd ask the customer where this FIPS validation requirement really comes from. Most times there's a policy way around it.

Ciao, Michael.

Interesting link : http://en.wikipedia.org/wiki/Dual_EC_DRBG

It talks about the pros and cons of Dual_EC_DRBG which seems at best to be not very good random, at worst picked because it makes the sequence surface predictable, especially with a known secret key.. "possibility of the existence of a known secret key, which facilitates solution of the problem" and especially in light of : http://en.wikipedia.org/wiki/Key_disclosure_law which by law requires people in the USA to give up said secret keys.

I guess it's fair enough in the USA where cryptographic freedom is given up to the government by federal legislation, but in other parts of the world this standard looks pretty terrible, as it is including this as a known or at least suspected attack vector. In other countries you need to hand over encryption keys, it usually needs a court order or some sort of evidence.. and in another country it seems silly to potentially facilitate another country's inspection of your secure traffic.

On Sun, Oct 27, 2013 at 4:45 AM, Howard Chu hyc@symas.com wrote:

devzero2000 wrote:

...

On Fri, Oct 25, 2013 at 7:59 PM, Michael Ströder michael@stroeder.com wrote:

...

Steve Eckmann wrote:

...

We are using {SSHA} (SHA-1) in OpenLDAP now. The customer wants SHA-512. And they require a FIPS-validated implementation, which I think narrows our options to using either OpenSSL or NSS in FIPS mode. I cannot see a better way to meet the customer's two requirements than gutting pw-sha2 and using that as a thin wrapper for the raw crypto functions in either openssl or nss.

You probably should first ask on the openssl-users mailing list under which conditions you get some "FIPS-validated" code regarding the whole OpenLDAP "application". Likely it's not feasible.

I'm pretty sure that your customer FIPS requirement is plain nonsense and you might work around this by some other strange policy text. ;-}

I am not sure "nonsense" if some distro are doing something in this area. Right or, perhaps, sometime wrong (o perhaps sometime break). http://fedoraproject.org/wiki/**FedoraCryptoConsolidationhttp://fedoraproject.org/wiki/FedoraCryptoConsolidation

FIPS spec is clearly nonsense, from a technical perspective. E.g. it required support of Dual_EC_DRBG random number generator which was proven to be inferior and almost certainly has an NSA backdoor.

The Fedora crypto consolidation rationale is completely bogus; in unifying the crypto database across the entire machine it fails to recognize that different services (and different clients) will have completely different security policies and requirements. Of course this is common knowledge for actual security practitioners - servers generally should only recognize and trust client certificates issued by a single CA, while clients generally need to be able to trust many different CAs for a wide range of services. HTTP servers have much different certificate requirements from LDAP/FTP/SMTP servers; almost nobody uses client certificates with HTTP but they are commonplace for many other authenticated services.

Of course, the Fedora crypto scene is dictated more by political concerns than technical. https://bugzilla.redhat.com/**show_bug.cgi?id=319901https://bugzilla.redhat.com/show_bug.cgi?id=319901

-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/**project/http://www.openldap.org/project/