RE: [pkcs11] Fwd: [pkcs11-comment] CKA_ALWAYS_AUTHENTICATE usability issues

[Johnson Darren <darren.johnson@gemalto.com>]

That is an interesting email.

I've never given that attribute much thought until recently while working with some "authenticate on use" scenarios.

In general I think there is room for improvement with CKA_ALWAYS_AUTHENTICATE, but I don’t think it should go the direction suggested below.
I've added my thoughts and opinions below marked by [DJ]

I'd be interested in taking part in any discussions that may take place on this topic.

Thanks
DJ

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Valerie Fenwick
Sent: Wednesday, November 09, 2016 3:29 PM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Fwd: [pkcs11-comment] CKA_ALWAYS_AUTHENTICATE usability issues

I wasn't sure if Bob or I had forwarded this yet, or not. Please do take a look.


-------- Forwarded Message --------
Subject: [pkcs11-comment] CKA_ALWAYS_AUTHENTICATE usability issues
Date: Fri, 30 Sep 2016 19:48:14 +0000
From: Woodhouse, David <david.woodhouse@intel.com>
To: pkcs11-comment@lists.oasis-open.org <pkcs11-comment@lists.oasis-open.org>

In §4.9 of the v2.40 specification, it states of CKA_ALWAYS_AUTHENTICATE that "This attribute may only be set to CK_TRUE when CKA_PRIVATE is also CK_TRUE."

So in order to perform a C_FindObjects() to locate a key, and then immediately use it for a crypto operation, it would be necessary for the user to provide the same PIN twice in quick succession.

[DJ]  You raise an interesting question here.  I know we often encounter customer applications that use that work flow [ C_OpenSession(), C_Login(), C_FindObjects(), C_Sign(), C_Logout()].  Requiring the PIN twice is inconvenient but can easily be handled by an application that knows its keys have the attribute set.  However it would be extremely painful and slow if a PIN Entry Device is used.

If the key did not suffer the CKA_PRIVATE attribute, and was permitted to have only the CKA_ALWAYS_AUTHENTICATE attribute, then this would not be a problem. It would be *visible* to the C_FindObjects() call without a C_Login(), and then the user is required to provide the PIN once for each actual *usage* of the key.

Surely that seems like a reasonable usage model? Why do we require that CKA_PRIVATE be set? Can this restriction be relaxed?

[DJ] It certainly sounds reasonable when you use it as a way to work around your two login problem.  But I don’t know how practical it is.  If CKA_PRIVATE=CK_FALSE, then the object is a "public object" and can be used in a public session so requiring authentication to use this type of object doesn't really make sense.  At least in my opinion.
This is just my opinion, but I consider "always authenticate" as an additional level of control on objects that you are required to authenticate before you can access/use.  To me, it does not make sense to put authentication requirements on objects that do not require authentication to access.  If you want to restrict access to them, set them as CKA_PRIVATE.
The only reason I can think of right now to justify your request is so that someone could create an environment of public objects and can do everything other than use an object without presenting authentication data.  But even then, I'm not sure how many people would want their sensitive objects publically visible.
Is there another reason to allow this attribute on public objects other than to work around the current restriction in the standard that requires two logins?

A nasty workaround exists for this situation: Some tokens set CKA_ALWAYS_AUTHENTICATE on a key when the word 'always' in it isn't actually true — under *some* circumstances they might actually permit a crypto operation to complete without returning CKR_USER_NOT_LOGGED_IN.

The popular PIV token can be operated this way — the *hardware* needs a VERIFY operation immediately prior to use of the SIGN key, but doesn't care whether at the PKCS#11 level that VERIFY operation was triggered by a CKU_USER login, or a CKU_CONTEXT_SPECIFIC one.

[DJ] I would consider the PIV case an instance/example of a vendor deciding to bend the rules a bit to make the product more user.  I think we should consider modifying the standard to allow this type of use case.  I would not want to officially allow the scenario you describe above... a generic C_Login(CKU_USER) login to satisfy the requirements of CKA_ALWAYS_AUTHENTICATE, but certainly allow it through something similar like C_Login(CKU_USER|CKU_CONTEXT_SPECIFIC) as an example.  Obviously we'd want something more official than that... it is just an example.

So if the PKCS#11 usage flow involves C_Login(CKU_USER), C_FindObjects(), C_Sign(), then as far as the PIV hardware is concerned that final C_Sign() can actually happen *without* any reauthentication.
The PKCS#11 provider in that case can simply let it succeed without returning CKR_USER_NOT_LOGGED_IN.

One can also imagine hardware devices which require reauthentication after a timeout — so having entered the PIN, the device can be used for a number of crypto operations for a number of seconds or minutes, before it demands the PIN again.

[DJ]  I agree there is a need/use-case for batch processing like this... so I think we should consider introducing the  idea of "authentication once and allow N operations" in to the PKCS#11 standard.  It should not fall under the umbrella of the CKA_ALWAYS_AUTHENTCATE attribute as this attribute should ALWAYS require authentication which satisfies a different use-case .

Applications can happily support this model by simply pretending they 'forgot' the CKA_ALWAYS_AUTHENTICATE attribute was set, and attempting the crypto operation anyway. If it works, all well and good. And if it return CKR_USER_NOT_LOGGED_IN, they go ahead with the CKU_CONTEXT_SPECIFIC login as required.

Is this workaround a reasonable one — or are tokens *required* to return CKR_USER_NOT_LOGGED_IN in that case? Or are applications
*required* to perform the CKU_CONTEXT_SPECIFIC login, and never to actually trigger the CKR_USER_NOT_LOGGED_IN response that is defined in the spec?

[DJ] In my opinion, an application that is using keys with CKA_ALWAYS_AUTHENTICATE set will either know that it is set and perform the extra login call, or it will be written such that it checks if the attribute is set and behave accordingly.  I don’t like the idea of promoting application writers to try the easy and less secure way in hopes that it might work, and then fail over to a more secure way.  Application writers should be extremely aware of their environment, their keys and the attributes set on their keys.  PKCS#11 is a very flexible and powerful standard, however it is far too easy to misuse as well.
Again this is just my opinion... if there is any error on a crypto operation (other than CKR_BUFFER_TOO_SMALL in the right conditions), then the application should assume that the crypto operation context is no longer valid.  The PKCS#11 standard current does not have a way to cancel a crypto context (at least not yet) so there is an implicit understanding (maybe there is explicit text about this, I don’t remember right now) that if an error occurs then the  library/token/hsm will clean up the context and a new operation can be initialized.
So for your work around to work, when they get CKR_USER_NOT_LOGGED_IN they would need to call C_SignInit(), C_Sign(), hanle the error, C_SignInit(), C_Login(CKU_CONTEXT_SPECIFIC), C_Sign().

If not considered reasonable, can it be *made* so in a subsequent update to the spec? Perhaps by a CKA_SOMETIMES_REAUTHENTICATE option (with a better name, perhaps), or by some other method?

[DJ] Its just my opinion, but I don’t think there is a strong need to allow this type of behavior.  But maybe the group wants to entertain adding this level of user-friendliness in to the standard.

 From the token's point of view, one potential justification (albeit somewhat tongue-in-cheek) for the "sometimes I make you reauthenticate, sometimes I don't" model is to claim that the CKA_ALWAYS_AUTHENTICATE attribute has temporarily been set to CK_FALSE on the key in question...

--
--
                   Sent with Evolution's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation






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

________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.