FIPS Compliance

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

FIPS Compliance

Sean McGinnis
I'm interested in some feedback from the community, particularly those running
OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
are looking for.

I've been seeing small changes starting to be proposed here and there for
things like MD5 usage related to its incompatibility to FIPS mode. But looking
across a wider stripe of our repos, it appears like it would be a wider effort
to be able to get all OpenStack services compatible with FIPS mode.

This should be a fairly easy thing to test, but before we put in much effort
into updating code and figuring out testing, I'd like to see some input on
whether something like this is needed.

Thanks for any input on this.

Sean

[0] https://en.wikipedia.org/wiki/FIPS_140-2
[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: FIPS Compliance

Joshua Cornutt
Sean,

I'm, too, am very interested in this particular discussion and working
towards getting OpenStack working out-of-the-box on FIPS systems. I've
submitted a few patches
(https://review.openstack.org/#/q/owner:%22Joshua+Cornutt%22) recently
and plan on going down my laundry list of patches I've made while
deploying Red Hat OpenStack 10 (Newton), 13 (Queens), and community
master on "FIPS mode" RHEL 7 servers.

I've seen a lot of debate in other communities on how to approach the
subject ranging from full MD5-to-SHAx transitions to putting in
FIPS-aware logic to decide hashes based on the system to just deciding
that the hashes aren't used for real security and thus are "mostly OK"
by FIPS 140-2 standards (resulting in awkward distro-specific versions
of popular crypto libraries with built-in FIPS awareness). Personally,
I've been more in favor of a sweeping MD5-to-SHAx transition due to
popular crypto libraries (OpenSSL, hashlib, NSS) indiscriminately
disabling MD5 hash methods on FIPS mode systems. With SHA-1 collisions
already happening, I imagine it will meet the FIPS banhammer in the
not-so-distant future which is why I have generally been recommending
SHA-256 as an MD5 replacement, despite the larger output size (mostly
an issue for fixed-sized database columns).

There is definite pressure being put on some entities (commercial as
well as government / DoD) to move core systems to FIPS mode and
auditors are looking more and more closely at this particular subject
and requiring strong justification for not meeting FIPS compliance on
systems both at the hardware and software levels.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Doug Hellmann-2
In reply to this post by Sean McGinnis
Sean McGinnis <[hidden email]> writes:

> I'm interested in some feedback from the community, particularly those running
> OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
> are looking for.
>
> I've been seeing small changes starting to be proposed here and there for
> things like MD5 usage related to its incompatibility to FIPS mode. But looking
> across a wider stripe of our repos, it appears like it would be a wider effort
> to be able to get all OpenStack services compatible with FIPS mode.
>
> This should be a fairly easy thing to test, but before we put in much effort
> into updating code and figuring out testing, I'd like to see some input on
> whether something like this is needed.
>
> Thanks for any input on this.
>
> Sean
>
> [0] https://en.wikipedia.org/wiki/FIPS_140-2
> [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
>
> _______________________________________________
> OpenStack-operators mailing list
> [hidden email]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

I know we've had some interest in it at different times. I think some of
the changes will end up being backwards-incompatible, so we may need a
"FIPS-mode" configuration flag for those, but in other places we could
just switch hashing algorithms and be fine.

I'm not sure if anyone has put together the details of what would be
needed to update each project, but this feels like it could be a
candidate for a goal for a future cycle once we have that information
and can assess the level of effort.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Julia Kreger


On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann <[hidden email]> wrote:
Sean McGinnis <[hidden email]> writes:

> I'm interested in some feedback from the community, particularly those running
> OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
> are looking for.
[trim]

I know we've had some interest in it at different times. I think some of
the changes will end up being backwards-incompatible, so we may need a
"FIPS-mode" configuration flag for those, but in other places we could
just switch hashing algorithms and be fine.

I'm not sure if anyone has put together the details of what would be
needed to update each project, but this feels like it could be a
candidate for a goal for a future cycle once we have that information
and can assess the level of effort.

Doug


+1 to a FIPS-mode. I think it would be fair to ask projects, to over the course of the next month or three, to evaluate their current standing and report what they perceive the effort to be.

I think only then we can really determine if it is the right direction to take for a cycle goal.

-Julia

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Luke Hinds


On Tue, Nov 6, 2018 at 2:04 PM Julia Kreger <[hidden email]> wrote:


On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann <[hidden email]> wrote:
Sean McGinnis <[hidden email]> writes:

> I'm interested in some feedback from the community, particularly those running
> OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
> are looking for.
[trim]

I know we've had some interest in it at different times. I think some of
the changes will end up being backwards-incompatible, so we may need a
"FIPS-mode" configuration flag for those, but in other places we could
just switch hashing algorithms and be fine.

I'm not sure if anyone has put together the details of what would be
needed to update each project, but this feels like it could be a
candidate for a goal for a future cycle once we have that information
and can assess the level of effort.

Doug


+1 to a FIPS-mode. I think it would be fair to ask projects, to over the course of the next month or three, to evaluate their current standing and report what they perceive the effort to be.

I think only then we can really determine if it is the right direction to take for a cycle goal.

-Julia
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@...?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Understand it's early to be discussing design, but would like to get it on recordĀ  that if we can, we should try to use 'Algorithm Agility' rather then all moving to the next one up and setting to SHA<XXX>. That way we can deal with what might seem unfathomable now, happening later (strong cryptos getting cracked).



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Doug Hellmann-2
Luke Hinds <[hidden email]> writes:

> On Tue, Nov 6, 2018 at 2:04 PM Julia Kreger <[hidden email]>
> wrote:
>
>>
>>
>> On Tue, Nov 6, 2018 at 5:07 AM Doug Hellmann <[hidden email]>
>> wrote:
>>
>>> Sean McGinnis <[hidden email]> writes:
>>>
>>> > I'm interested in some feedback from the community, particularly those
>>> running
>>> > OpenStack deployments, as to whether FIPS compliance [0][1] is
>>> something folks
>>> > are looking for.
>>> [trim]
>>>
>>> I know we've had some interest in it at different times. I think some of
>>> the changes will end up being backwards-incompatible, so we may need a
>>> "FIPS-mode" configuration flag for those, but in other places we could
>>> just switch hashing algorithms and be fine.
>>>
>>> I'm not sure if anyone has put together the details of what would be
>>> needed to update each project, but this feels like it could be a
>>> candidate for a goal for a future cycle once we have that information
>>> and can assess the level of effort.
>>>
>>> Doug
>>>
>>>
>> +1 to a FIPS-mode. I think it would be fair to ask projects, to over the
>> course of the next month or three, to evaluate their current standing and
>> report what they perceive the effort to be.
>>
>> I think only then we can really determine if it is the right direction to
>> take for a cycle goal.
>>
>> -Julia
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> Understand it's early to be discussing design, but would like to get it on
> record  that if we can, we should try to use 'Algorithm Agility' rather
> then all moving to the next one up and setting to SHA<XXX>. That way we can
> deal with what might seem unfathomable now, happening later (strong cryptos
> getting cracked).
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Yeah, it feels like we want 1 place to get the right "current"
algorithm. Unfortunately, we still need to support those old ones
because we need to be able to validate any existing data like stored
signatures.

Is there already a python library out in the wild that we could use for
providing a consistent API for that? If not, perhaps building that is an
independent step someone could be working on now.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Joshua Cornutt
In reply to this post by Sean McGinnis
Doug,

I have such a list put together (my various installation documents for
getting these clouds working in FIPS mode) but it's hardly ready for
public consumption. I planned on releasing each bit as a code change
and/or bug ticket and letting the community consume it as it figures
some of these things out.

I agree that some changes may break backwards compatibility (such as
Glance's image checksumming), but one approach I think could ease the
transition would be the approach I took for SSH key pair
fingerprinting (also MD5-based, as is Glance image checksums) found
here - https://review.openstack.org/#/c/615460/ . This allows
administrators to choose, hopefully at deployment time, the hashing
algorithm with the default of being the existing MD5 algorithm.

Another approach would be to make the projects "FIPS aware" where we
choose the hashing algorithm based on the system's FIPS-enforcing
state. An example of doing so is what I'm proposing for Django
(another FIPS-related patch that was needed for OSP 13) -
https://github.com/django/django/pull/10605

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Julia Kreger


On Tue, Nov 6, 2018 at 9:19 AM Joshua Cornutt <[hidden email]> wrote:

Another approach would be to make the projects "FIPS aware" where we
choose the hashing algorithm based on the system's FIPS-enforcing
state. An example of doing so is what I'm proposing for Django
(another FIPS-related patch that was needed for OSP 13) -
https://github.com/django/django/pull/10605


This was the approach I was thinking. We ideally should allow and enable evolution, but we would still need the hard "FIPS 140-2" operating mode flag which would be a hard break for pre-existing clouds whose data and checksum information had not been updated already. Maybe in any process to collect community impact information, we could also suggest projects submit what they perceive an upgrade path to be to take an existing cloud to a FIPS 140-2 enforcing mode of operation.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Joshua Cornutt
In reply to this post by Sean McGinnis
The downside of this particular approach is that systems that get
promoted to "FIPS mode" will get into a sticky situation as the code
originally set hashes to use MD5 but then switches to SHA-x after
users may have already used MD5 (and thus have that data stored /
recalled). The best way really would be make them as configurable
options by the user and only baking in decisions for methods that can
handle floating between FIPS and non-FIPS modes.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Doug Hellmann-2
In reply to this post by Joshua Cornutt
Joshua Cornutt <[hidden email]> writes:

> Doug,
>
> I have such a list put together (my various installation documents for
> getting these clouds working in FIPS mode) but it's hardly ready for
> public consumption. I planned on releasing each bit as a code change
> and/or bug ticket and letting the community consume it as it figures
> some of these things out.

It's likely that the overall migration will go better if we all have the
full context. So I hope you can find some time to publish some of the
information you've compiled to help with that.

> I agree that some changes may break backwards compatibility (such as
> Glance's image checksumming), but one approach I think could ease the
> transition would be the approach I took for SSH key pair
> fingerprinting (also MD5-based, as is Glance image checksums) found
> here - https://review.openstack.org/#/c/615460/ . This allows
> administrators to choose, hopefully at deployment time, the hashing
> algorithm with the default of being the existing MD5 algorithm.

That certainly seems like it would provide the most compatibility in the
short term.

That said, I honestly don't know the best approach for us to take. We're
going to need people who understand the issues around FIPS and the
issues around maintaining backwards-compatibility to work together to
create a recommended approach. Perhaps a few of the folks on this thread
would be interested in forming a team to work on that?

Doug

> Another approach would be to make the projects "FIPS aware" where we
> choose the hashing algorithm based on the system's FIPS-enforcing
> state. An example of doing so is what I'm proposing for Django
> (another FIPS-related patch that was needed for OSP 13) -
> https://github.com/django/django/pull/10605
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Joshua Cornutt
On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann <[hidden email]> wrote:

>
> Joshua Cornutt <[hidden email]> writes:
>
> > Doug,
> >
> > I have such a list put together (my various installation documents for
> > getting these clouds working in FIPS mode) but it's hardly ready for
> > public consumption. I planned on releasing each bit as a code change
> > and/or bug ticket and letting the community consume it as it figures
> > some of these things out.
>
> It's likely that the overall migration will go better if we all have the
> full context. So I hope you can find some time to publish some of the
> information you've compiled to help with that.
>
> > I agree that some changes may break backwards compatibility (such as
> > Glance's image checksumming), but one approach I think could ease the
> > transition would be the approach I took for SSH key pair
> > fingerprinting (also MD5-based, as is Glance image checksums) found
> > here - https://review.openstack.org/#/c/615460/ . This allows
> > administrators to choose, hopefully at deployment time, the hashing
> > algorithm with the default of being the existing MD5 algorithm.
>
> That certainly seems like it would provide the most compatibility in the
> short term.
>
> That said, I honestly don't know the best approach for us to take. We're
> going to need people who understand the issues around FIPS and the
> issues around maintaining backwards-compatibility to work together to
> create a recommended approach. Perhaps a few of the folks on this thread
> would be interested in forming a team to work on that?
>
> Doug
>

I'd be interested in that. Good idea

> > Another approach would be to make the projects "FIPS aware" where we
> > choose the hashing algorithm based on the system's FIPS-enforcing
> > state. An example of doing so is what I'm proposing for Django
> > (another FIPS-related patch that was needed for OSP 13) -
> > https://github.com/django/django/pull/10605
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: [hidden email]?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack-operators] FIPS Compliance

Doug Hellmann-2
Joshua Cornutt <[hidden email]> writes:

> On Wed, Nov 7, 2018 at 7:30 AM Doug Hellmann <[hidden email]> wrote:
>>
>> Joshua Cornutt <[hidden email]> writes:
>>
>> > Doug,
>> >
>> > I have such a list put together (my various installation documents for
>> > getting these clouds working in FIPS mode) but it's hardly ready for
>> > public consumption. I planned on releasing each bit as a code change
>> > and/or bug ticket and letting the community consume it as it figures
>> > some of these things out.
>>
>> It's likely that the overall migration will go better if we all have the
>> full context. So I hope you can find some time to publish some of the
>> information you've compiled to help with that.
>>
>> > I agree that some changes may break backwards compatibility (such as
>> > Glance's image checksumming), but one approach I think could ease the
>> > transition would be the approach I took for SSH key pair
>> > fingerprinting (also MD5-based, as is Glance image checksums) found
>> > here - https://review.openstack.org/#/c/615460/ . This allows
>> > administrators to choose, hopefully at deployment time, the hashing
>> > algorithm with the default of being the existing MD5 algorithm.
>>
>> That certainly seems like it would provide the most compatibility in the
>> short term.
>>
>> That said, I honestly don't know the best approach for us to take. We're
>> going to need people who understand the issues around FIPS and the
>> issues around maintaining backwards-compatibility to work together to
>> create a recommended approach. Perhaps a few of the folks on this thread
>> would be interested in forming a team to work on that?
>>
>> Doug
>>
>
> I'd be interested in that. Good idea

I added "FIPS compliance" to the list of community goal ideas in
https://etherpad.openstack.org/p/community-goals (see number 35,
currently at the bottom of the etherpad).

Please add more detail there about what exactly is involved, references,
etc. -- whatever you think would be useful to someone learning about
what this is.

>
>> > Another approach would be to make the projects "FIPS aware" where we
>> > choose the hashing algorithm based on the system's FIPS-enforcing
>> > state. An example of doing so is what I'm proposing for Django
>> > (another FIPS-related patch that was needed for OSP 13) -
>> > https://github.com/django/django/pull/10605
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: [hidden email]?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev