OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] FiPS Indicator proposal.

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Â

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.

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.

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 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 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.

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.

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.Â


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.



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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]