Yes, this is exactly what we want. Behave like PK11_MD5_DISABLE is
defined on FIPS enabled system. Behave like it was not defined by
default. I will try to prepare patch doing just that.
On 01/18/2018 03:27 PM, Ondrej Sury via RT wrote:
> So, if I am reading this correctly.
>
> If we were to change PK11_MD5_DISABLE logic into a global flag (e.g. runtime detection) instead of configure time option that would basically satisfy your needs as it would make BIND not fail when MD5 would be used, and same binary could be used.
>
> The ABI would stay stable for maintenance releases and it would be easier to backport than the originally proposed patch.
>
> Do I understand the situation from RedHat point of view correctly?
>
> Ondrej
>
> On Thu Jan 18 12:14:29 2018, pemensik@redhat.com wrote:
>>
>>
>> On 01/18/2018 01:55 AM, Francis Dupont via RT wrote:
>>> On Wed Jan 17 20:37:01 2018, pemensik@redhat.com wrote:
>>>> Thank you Ondrej. Hello Francis, Hello Evan.
>>>>
>>>> Unfortunately I am not happy with this fix at all. It completely
>>>> missed
>>>> our intention and actually moved us even farther from solving our
>>>> issue.
>>>
>>> => my interpretation of the FIPS mode according to the Guidance
>>> document is that in FIPS mode not-approved crypto must not be
>>> used and this applies to applications ("user" in FIPS terms) too.
>>>
>>> So I can see 3 different solutions, none perfect of course:
>>>
>>> 1- build one bind package with MD5, DSA and DH disabled
>>> (DSA because it uses old and unsafe parameters, DH for
>>> the same reason and because its only usage implies MD5).
>>> It should work well in both FIPS mode enabled or disabled,
>>> the only obvious drawback is it does not work (in fact it
>>> impossible to configure) with TSIG HMAC-MD5.
>>> Note command usages are updated too so attempts
>>> to use MD5 raise understandable errors.
>>> I don't consider old rndc versions because rndc should
>>> come with named and do not accept old configs
>>> using MD5 at both sides is IMHO a good thing as
>>> soon as error messages are clear about the problem.
>> Default algorithm used for automatically generated RNDC key were changed
>> 3 months ago [1]. Automatic removal and regeneration of existing keys
>> are not preferred operation. Just for this reason default build without
>> HMAC-MD5 support at all is not desired. FIPS users are important but
>> majority of users should be able to use MD5 based operations, if they wish.
>>>
>>> 2- build two packages.
>> That means more burden on maintenance efforts. We already build two
>> variants bind and bind-pkcs11. We would have to change dependencies that
>> use it, especially bind-dyndb-ldap. We want to avoid this if different
>> solution is at hand.
>>>
>>> 3- Disable FIPS mode when MD5 is enabled at initialization time,
>>> or build bind with internal MD5 code. In both case they make
>>> bind behaves as without FIPS but I am not a big fan of them
>>> because they clearly defeat the FIPS mode idea.
>> I think way how FIPS is enabled is not clear here. FIPS mode is enabled
>> for whole machine. It is not enabled by application, but at boot of the
>> system. You cannot just disable it from the application. System
>> libraries are just different. MD5 code should not be internal, but
>> trusted and certified library calls should be used for any MD5
>> operations. This way, once FIPS is active, whole application cannot do a
>> single MD5 checksum. That is the way we archieve MD5 as disabled, while
>> BIND still has references to MD5 in code.
>>
>> 4- Use either --with-openssl-hash or --enable-native-pkcs11. Build BIND
>> in a way all crypto operations are forwarded to trusted crypto
>> libraries. They should be as fast as any internal implementation, only
>> some indirect calls are included. If these calls are known to fail,
>> behave the same way like in point 1. Refuse any request to do MD5
>> operation in FIPS mode. Refuse to start if MD5 or DH key is used in
>> configuration. Make different default algorithm in ddns-confgen, so no
>> MD5 keys are generated, refuse if requested. If any MD5 operation
>> requested, respond with unknown algorithm or just refused, failed etc.
>>
>> We want number 4 in RHEL. This is what my original patch solved somehow.
>> It was invasive, sure. Because it took into account MD5 can fail. It
>> allowed such failure to be reported and continue to run. There can be
>> different ways to accomplish the same goal. With less changes to the
>> basic API, if that is not desired. I had no such feedback however.
>>>
>>>> Once FIPS mode is enabled in target system, crypto library disables
>>>> support for MD5. Any try to use md5 will result in error.
>>>
>>> => it does not make sense: either MD5 is supported or it is not.
>>>
>> Let's try a simple test, generate md5 checksum.
>>
>> On FIPS enabled machine:
>> $ echo test | openssl md5
>> Error setting digest md5
>> 140187769722784:error:060800A3:digital envelope
>> routines:EVP_DigestInit_ex:disabled for fips:digest.c:251:
>>
>> On different machine with FIPS disabled:
>> # echo test | openssl md5
>> (stdin)= d8e8fca2dc0f896fd7cb4cb0031ba249
>>
>> MD5 calls are not removed from openssl library. They just fail in FIPS
>> mode. Always. They will never give you any digest you can use. I would
>> say that means MD5 is not supported.
>>
>>>> Only difference we would like archieve behavior similar to defined
>>>> PK11_MD5_DISABLE in pk11/site.h.
>>>
>>> => the PK11_MD5_DISABLE feature comes from an old (2008)
>>> ticket opened by Adam Tkac from Red Hat about FIPS mode
>>> support. At that time the FIPS code was the OpenSSL FIPS
>>> object module and it was clear that a bind using it should
>>> not have MD5 support. It was never released but it leads
>>> to remove first MD5 dependencies and after defaults.
>>> When HSMs without MD5 support appeared the site.h
>>> file was added to allows them to be used.
>> RHEL 6 does not have pkcs11 variant build. Default version uses only
>> internal implementation. Such build is not clearly FIPS compatible.
>>
>> Request for FIPS compatibility came to FreeIPA team. Because RHEL 7 has
>> bind-pkcs11 variant and FreeIPA use it, we thought we can make it FIPS
>> compatible. We failed to test it properly however. BIND is just one part
>> of more complex FreeIPA Identity Management project.
>>
>>> For different reasons, for instance recommendations
>>> of early OpenSSL FIPS guides, it was chosen to disable
>>> MD5 by an option at build time. BTW it provides a strong
>>> guarantee that MD5 code cannot be called: as it is not
>>> in the binary it is not reachable. Of course you can object
>>> that it is to make security before usability...
>>> If you have an usage for it the -P flag was reserved in
>>> all command arguments at that time for switching
>>> to FIPS mode per application.
>> Different build for FIPS mode will not help. Red Hat require FIPS
>> enabled on whole machine, not per application. We do not want to support
>> separate repository for FIPS builds. We managed to make OpenSSL work. We
>> just want to use it, but handle errors without fatal error.
>>>
>>>> That means any request to use MD5 will fail like it was
>>>> not supported at all
>>>
>>> => note this applies to configuration / command line
>>> arguments, etc, not to the MD5 low level crypto.
>>> Or with other words the PK11_MD5_DISABLE approach is
>>> the right one and your concern is it is a built time vs.
>>> run time.
>> Yes. We require just runtime switch to disable MD5 by runtime library
>> call. If commands offer HMAC-MD5 algorithm in help or manual page, that
>> is ok. They just have to fail. We can document that in an article with
>> details on FIPS support of BIND.
>>>
>>>> Because we support older version 9.9 which does not contain different
>>>> than HMAC-MD5 rndc key support, we cannot remove whole support from
>>>> the build.
>>>
>>> => argh! Partially my fault as I was late to convince my
>>> colleagues to go far from MD5. As far as I know 9.9 is EOL in June.
>>>
>> We could do much better much earlier. I did not realize RNDC has
>> alternative to disable-algorithms too late. And modification of
>> autogeneration script to choose different algorithm by default was
>> simple as well. I am not blaming anyone for this. I could do more as well.
>>
>>>> Current RT #46764 patch committed with id
>>>> 614d838acf4e4b61523a044fde014d8ee7f60e70 would not help us. In fact,
>>>> we
>>>> would have to revert that in our code to support FIPS mode.
>>>
>>> => it is in #ifndef PK11_MD5_DISABLE code so anyway
>>> you have to address it. IMHO you should keep it downgrading
>>> to a sanity check: if it is reached something went really wrong
>>> before. And it includes better error messages.
>>>
>> Sure, sanity check might be good. It would save us trouble if it were
>> there before. We would notice sooner. Sanity check is good. But we do
>> not want to prevent start in FIPS mode.
>>>> I am sorry I was not clear enough from the start. This patch would
>>>> prevent us starting named in FIPS mode.
>>>
>>> => prevent to start a named (or any command using crypto)
>>> which wants to freely use MD5.
>>>
>> That is the point. I want it to only forbid or just fail use of MD5.
>>>> We would like to use --with-openssl-hash in the future.
>>>
>>> => BTW another heritage of the old FIPS mode work with
>>> in addition the fact that OpenSSL is clearly faster
>>> (visible different with NSEC3 iterated hash).
>>> It was recently made the default when bind is built
>>> with OpenSSL.
>> Sure. But if it were the default, we would not be able to start any
>> named in FIPS mode. Now only named-pkcs11 has problems and named is not
>> compliant. Not good, we want both fixed. That was the reason I did
>> propose digest functions to return result code indicating success. There
>> might be different reasons for OpenSSL to fail. It is not under our
>> control to support all of them.
>>>
>>>> Our current
>>>> problem is with --enable-native-pkcs11 variant.
>>>
>>> => as no HSM implements a consistent subset of PKCS#11
>>> I am afraid the idea of to provide a bind package with native
>>> PKCS#11 will never work. BTW only SoftHSMv2 with OpenSSL
>>> backend (and not in FIPS mode) can run all the system tests...
>>>
>> Can you try it on a system in FIPS mode? Can you make it pass somehow? :)
>>
>> [1]
https://bugzilla.redhat.com/show_bug.cgi?id=1508003
>>
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik@redhat.com PGP: 65C6C973