Re: [pkcs11] FiPS Indicator proposal.

[Robert Relyea <rrelyea@redhat.com>]

On 7/20/21 6:20 PM, Tim Hudson wrote:

As always, having a concrete proposal to read makes it a lot easier to have a discussion on the topic.

I don't get the whole concept here of having both a current and a last okay flag - there is no requirement for that in the IGs.

For those who haven't read the details go to 2.4.CÂ Approved Security Service Indicator inÂ

https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

The only actual requirement present is that there needs to be an indication that some approved service was used.

So unlike FIPS140-2 where you can have a module mode which is on or off, you need to be able to indicate that a service was used that is approved.

There is no requirement to separate this across multiple services.

If you only have approved services then you have nothing you actually have to do.

"In this case, an explicit indication via the use of a static code or an implicit indication via the successful completion of a service is sufficient."

It is explicit that successful completion of the service is a sufficient indicator.

So if you are a traditional module with the concept of a FIPS mode in which only approved services are accessible then the successful function return codes are the required indicator.

Nothing new is required.

It is only when you have a mixture of approved and non-approved that something different needs to be provided - but again it is a rather "simplistic" concept.

"For those modules implementing both approved and non-approved security services, a shared indicator common to multiple approved security services can be used."

There is nothing about needing to know what the current not-yet-completed service status is.

So there is actually nothing that indicates we need to have the FIPS_OK and FIPS_LAST_OK flags.

That really makes the proposal a bit of a mix in terms of what it is doing - and it isn't solving a concrete FIPS requirement but seems aimed at something different.

So the purpose of the FIPS_LAST_OK is to deal with the case where you are calling C_WrapKey specifically. There is no way to to see the 'current FiPS indication because there is no active session. FIPS_LAST_OK handles this. Also, from a practical point of view in *using* fips indicators in an application like NSS, the NSS calls for some operations like sign do a C_SignInit/C_Sign in a single operation, so the upper level application doesn't have access to the FIPS_OK state because it's gone once C_Sign occurs.

This developed out of trying to use the indicators rather than from the NIST requirements itself. (I can handle the second case in NSS by having NSS squirrel away the FIPS_LAST_OK, but then I still don't have a solution for C_WrapKey.

Note that the flags returned in the flags field of a C_GetSessionInfo are the same flags passed into C_OpenSession - that is what applications expect. They aren't really "dynamic" as such in current usage - just a copy of what the caller provided when they called C_OpenSession. You've basically changed a fundamental concept here in this change.

So I'm willing to look at other options. My original proposal was to add a new function to fetch the state, which Daniel suggested wasn't needed since we could use the session flags. So I see a couple of options here:

1) go back to adding a new function (I'm not excited about this, I like Daniel's suggestion).

2) co-opt the SessionInfo state. This has an issue that it's a highly incompatible change. Applications (at least NSS) uses state heavily to determine login state of the token adding bits to state, or changing the definition of state could interfere with this.

3) Go with what I've defined here.

4) add a CKF_EXPECT_FIPS_INDICATORS flag to flags, and then put the FIPS indicates in the state (probably as 'overlay bits, so that they can be masked out of the current state variable. (I'm OK with this, but I prefer 3).

5) Other suggestions?

Separately, the wording about "conforming to the approved security policy" is in itself highly problematic - as there are things in the security policy that are about what the operator does and not about what the module itself does. The module cannot make any such claim about the operator's action - only about its configuration and use of its services. That means narrowing such statements to the configuration the module is operating under being consistent with configurations that is allowed in the security policy (but even that wording too has challenges as security policies are pretty broad documents).

I'm willing to look at other wording, but it's important to note the the state of the FIPS indicators are tied to the token's FIPS validation, and what exactly the token claims. For instance, my token may support CKM_AES_GCM, but for some reason (test vectors were ran, lab found some issue that violated some IG in my code), I dropp CKM_AES_GCM as approved in my security popolicy. The FIPS indicators for CKM_AES_GCM in *my* token need to be FIPS_OK.

The other thing about the security policy, is it contains things (like in openssl) that the application is responsible for the protection of CSPs. In that cause an openssl token could potentially accept C_CreateObject() keys with CKA_FIPS_OK set to true, where as NSS would not. It also punts the requirements for us to define what exactly is allowed -- it becomes basically a negotiation between the vendor/lab/NIST and the rule could (and probably would) change over time.

Upshot, I'm not wedded to that wording, but I'd like a proposal for what the wording should be to capture the above issue.

I think we should also generalise things - so this isn't a FIPS specific thing as such - but is about operating in a mode that matches a validation or some form or another.

There are a lot more validation schemes in use than FIPS140-2 and FIPS140-3. And if we did note this as specific to FIPS140-3Âthen we should have FIPS140-3 in the name itself - FIPS isn't specific enough.

I am definitely not worded to the name, but it is pretty tied to FIPS140-3. If my token is conformant to some other evaluation, then that would be a different indicator. So even if the name doesn't say FIPS, It explicitly means FIPS.

I'm also open to suggestions on the _OK in the name as well. Also is there a collision issue between CKA_FIPS_OK and CKF_FIPS_OK in our testing framework which drops the CKA_ and CKF_ from the names?

I also think that we should be looking at validations in a more general context and not looking at this as slipping a flag (or two) into the session info structure.

In the KMIP TC we took a much more general approach about being able to report information about validations.

SeeÂhttps://docs.oasis-open.org/kmip/kmip-spec/v2.1/os/kmip-spec-v2.1-os.html#_Toc57115737 for a direct link to the current specification (and this is unchanged in the almost finished 3.0 specification).Â

There are also a pile of different ways we could approach this - like using the CK_C_INITIALIZE_ARGS struction to pass in a flag or add an additional function for indication of approved function usage.

Or we could use the CK_NOTIFY capability in the C_OpenSession and add a flag to indicate an approved service was used.

We could indicate in the flags to initialise what level of notifications we want to have processed or something along those lines.

    These are all quite different from my original proposal, which is
    basically this proposal with a function to fetch the flags and was
    available for review for several weeks before this one.

I think the notify approach is actually a much cleaner way to meet the requirements than your proposed new signaling approach in the session flags.

You could then also add notifications for non-approved function usage or other such potentially useful concepts.

So from a practical point of view, I'm not sure how this works in a complex application like firefox. With the flags approach I'm able to easily indicate FIPS/nonFIPS state for an entire SSL connection with minimal work in the actual SSL code. One issue with the Notify is when do you do it on a session that is reused. You would have to notify on C_XXXXInit(), Notify if some not FIPS operation happens, Notify on C_XXXFinalize() , plus what happens when you have more than one operation. I could make this work at the NSS level, but it would be a lot more work than simple indicators.

I also think it is important to keep in mind that the problem here is that the module has to have some way to indicate this - there is no requirement on the application to use the module capability.

There is no *FIPS* requirement. However, NSS already has high level API's to surface this up to the application. I think application ability to use this is an important consideration.

bob

Tim.

On Wed, Jul 21, 2021 at 10:24 AM Robert Relyea <rrelyea@redhat.com> wrote:

OK, I've finally got the FIPS indicator propsosal in a proposal form. A
lot of the NSS design I realized was specific to how I wanted to
implement it in NSS, but other tokens could impliment things differently.

The proposal adds CKF_FIPS_OK and CKF_FIPS_LAST_OK to session flags,
CKA_FIPS_OK to the key object, and CKR_FIPS_INVALID to the errors.

I've added some prose about how they interact, but most of the
interaction is really defined by the token's security policy.

It's too late to expect full discussions tomorrow, but I didn't want to
arbitrarily post this after the meeting tomorrow. I'm open to feedback,
a lot of the prose can be cleaned up.

Bob


https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/68854/PKCS11_FIPS_Indicator_proposal.pdf


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php