Next in thread →
Next in month →
Re: [pkcs11] FiPS Indicator proposal.
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 <>
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
Next in thread →
Next in month →