<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <tt> </tt><tt> </tt> <div class="moz-cite-prefix"><tt>On 01/13/2017 05:44 PM, Petr Vobornik wrote:</tt><tt> </tt></div> <blockquote cite="mid:2d4f4629-27f0-86e2-abc9-5455a009cf0c@redhat.com" type="cite"> <pre wrap="">On 01/13/2017 03:49 PM, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Tomas Krizek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 01/12/2017 04:17 PM, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Tomas Krizek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 12/19/2016 04:41 PM, Standa Laznicka wrote: </pre> <blockquote type="cite"> <pre wrap="">On 12/19/2016 03:07 PM, John Dennis wrote: </pre> <blockquote type="cite"> <pre wrap="">On 12/19/2016 03:12 AM, Standa Laznicka wrote: </pre> <blockquote type="cite"> <pre wrap="">On 12/16/2016 03:23 PM, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Standa Laznicka wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello, I started a design page for FreeIPA on FIPS-enabled systems: <a class="moz-txt-link-freetext" href="https://www.freeipa.org/page/V4/FreeIPA-on-FIPS">https://www.freeipa.org/page/V4/FreeIPA-on-FIPS</a> Me and Tomáš are still investigating what of all things will need to change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed to install and run patched FreeIPA server and client and connect them together. There are some issues with NSS when trying to create an HTTPS request (apparently, NSS requires an NSS database password to set up an SSL connection). I am actually thinking of removing NSSConnection from the client altogether. </pre> </blockquote> <pre wrap="">Can you expand on this a bit? NSS should only need a pin when it needs access to a private key. What connection(s) are you talking about, and what would you replace NSSConnection with? rob </pre> </blockquote> <pre wrap="">Hello Rob, Thank you for this excellent question, in order to cut the email short I seem to have omitted quite a few information. One of the very first problems I had with FreeIPA with FIPS was that NSS was always asking for password/pin. I was discussing this with the NSS guys on their IRC chat last week and it turns out that NSS tries to create a private key every time you want to use it as a backend for an SSL connection on FIPS. I still don't think this is quite right so I may open a bugzilla for that. </pre> </blockquote> <pre wrap="">I don't understand, I thought the case you were having problems with was the FreeIPA client, not the server. I assume when you use the term "backend" you mean server, and yes when NSS is in server mode it will access to keys. So isn't the problem NSS is not being initialized correctly so that it recognizes it is in client mode and not server mode? </pre> </blockquote> <pre wrap="">What I meant was "a client backend for an SSL connection" - we're using NSS implementation of SSL (via python-nss) for HTTPS connections from client to server during which we're getting a CA cert from an NSS database but this eventually leads to a password prompt. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Anyway, the guys suggested me that we could try to create the database with an empty password and everything will work. I don't quite like that, too, but it's at least something if you don't want the `ipa` command to always bug you for password you have no way knowing if you're just a regular user. What I think would be a better way to go is to use httplib.HTTPSConnection. We have the needed certificates in /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion with Honza this morning and it seems that with this approach we may get rid of the NSSConnection class altogether (although I still need to check a few spots) and start the process of moving away from NSS which was discussed some year ago in an internal mailing list (for some reason). Will be happy to hear thoughts on this, Standa </pre> </blockquote> <pre wrap="">I'm not a big fan of NSS, it has it's issues. As the author of the Python binding I'm quite aware of all the nasty behaviors NSS has and needs to be worked around. I wouldn't be sad to see it go but OpenSSL has it's own issues too. If you remove NSS you're also removing the option to support smart cards, HSM's etc. Perhaps before removing functionality it would be good to assess what the requirements are. </pre> </blockquote> <pre wrap="">I'm sorry I generalized too much, the original topic was moving away from python-nss (of which I am even more sorry as you're the author). </pre> </blockquote> <pre wrap="">We could use some ideas on how to handle replica installations in FIPS. We might use some flag in LDAP to indicate that a topology is FIPS-enabled. It seems like a good idea to force all servers in FIPS-enabled topology to also be FIPS-enabled. At the start of replica installation, a check could be performed to verify the FIPS topology status is the same as the current system's FIPS status. However, this proposal has a flaw. It is possible to simply install a FIPS-enabled replica and then turn FIPS off. This would result in non-FIPS systems being part of a FIPS-enabled topology. So we have a couple questions: Does it make sense to require all the servers in the topology to be either FIPS-enabled or FIPS-disabled? What would be a good approach to achieve this? Simply checking during installation does not guarantee that FIPS will stay turned on. </pre> </blockquote> <pre wrap="">You could set some value in the replicated tree on FIPS status and write a 389-ds plugin to refuse to start if the environment doesn't match. Given this is started first it should cause a cascade of failures so no services are available. rob </pre> </blockquote> <pre wrap="">Based on an offline discussion, we might just omit this feature entirely. Our goal is to enable FreeIPA installation of FIPS configured systems. It should be up to the customer to make sure other FIPS requirements are met, i.e. all servers are configured to use FIPS. </pre> </blockquote> <pre wrap=""> Up to you but this is bound to be an RFE and seems like quite a weakness to me. You'll want to be sure to enforce that any additional masters get FIPS by default if the initial master has it. In other words, they shouldn't need to remember to pass an option, it should be automatic. rob </pre> </blockquote> <pre wrap=""> +1 to Rob. We could operate between the two extremes: * Extreme 1: Ensuring that FIPS will remain enabled on all existing replica. * Extreme 2: Do not validate anything I.e. we could only: * Note in LDAP that first server was installed with FIPS * Check it at install time - prevent from installation of non-FIPS - prevent from installation of FIPS replica in non-FIPS topology It won't be bullet proof but it will check major mistakes which the admin can do by accident. </pre> </blockquote> <tt>I've updated the design document [1], sections Multiple Servers in Topology (in Design and Implementation). Instead of the originally proposed LDAP flag, we are proposing to check </tt><tt>/proc/sys/crypto/fips_enabled on the master (via RPC call) and on replica. Installation will proceed only if these match. See the design for more details. [1] - <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/FreeIPA-on-FIPS">http://www.freeipa.org/page/V4/FreeIPA-on-FIPS</a> </tt> <pre class="moz-signature" cols="72">-- Tomas Krizek</pre> </body> </html>