RE: [pkcs11] User types - discussion thread

[Chris Zimman <czimman@bloomberg.com>]

Hi Mike

I would agree with your comment around role based access control in terms of it being constricting.  For our needs, it just simply did not work.  To that end, we added CKU_EXTENDED_LOGIN:

#if defined(BPKCS11_EXTENDED_LOGIN)

/* Bloomberg extension for token login */
#define CKU_EXTENDED		3

typedef struct {
    CK_UTF8CHAR_PTR	*username;		/* User name */
    CK_ULONG		name_len;		/* Length of user name */
    CK_VOID_PTR	context;		/* Used to pass around token specific context data */
    CK_ULONG		context_size;		/* Size of context data */
} CK_EXTENDED_LOGIN;

#endif	/* defined(BPKCS11_EXTENDED_LOGIN) */

We have the extended attributes to do things that you mention, such as allow one user to create a key and provide fine grained access control to other users that can access the key.  You can extend this somewhat arbitrarily as well in terms of the access control policies (e.g. user X creates a key, shares with user Y, but says that user Y can only use the key M-F between 8AM - 5PM, etc.).

--Chris

-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Michael StJohns
Sent: Sunday, October 13, 2013 4:34 PM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] User types - discussion thread

In PKCS11 there are currently two types of users, CKU_USER, CKU_SO and CKU_CONTEXT_SPECIFIC.  The USER type, when logged in, can access all the keys on the token, use them and change their attributes within the limits of PKCS11 policy.

The SO user type has only a single function defined in PKCS11 as far as I can tell  - marking keys as trusted.

The CONTEXT_SPECIFIC user seems to be used only for those keys that require authentication each time they're used.

The above provides only a minimal amount of role based policy protections.  Over the years I've found this minimal set of roles to be somewhat constricting in building PKCS11 applications as they don't provide granular enough control over the token.  We've added a few additional attributes (CKA_COPYABLE and CKA_DESTROYABLE) as of 2.40 that provide some improvements, but I think we should consider modifying the model either slightly or comprehensively:

Slightly:  One of the big issues I've encountered with PKCS11 is that the creators of the key materials are not always the users of the key materials.  That leads to complications in managing the token in that we'd (e.g. my customers) *really* like to prevent the users of the key 
materials from either creating or destroying key material.   
CKA_DESTROYABLE works for the destroying part, but there's no way to prevent the creation.  A slight modification to the above set of user types might be the addition of a CKU_SESSION_USER who's allowed read-only access to token key material for use, but can't create or destroy any CKA_TOKEN=true objects - the session user MAY create session key material as necessary.  A second slight modification might include the addition of a CKU_OWNER_USER who in addition to all the access a CKU_USER gets may set key protection attributes on the keys irrespective of normal policy (e.g. can violate the stickyness rules for 
attributes).    So CKU_OWNER_USER > CKU_USER > CKU_SESSION_USER in terms 
of access.

Comprehensive:  Another possible approach may be to go to a full user (vs role) based system where each object is tagged both with the owner (who gets to set attributes) and the users allowed to use the object.  
There's probably also the concept of a token owner who gets add and delete users. Obviously, this would be a bit more disruptive than the 
simple additions described above.    It would require a more 
comprehensive user management system than currently exists, and a set of 
functions to manage the access control lists for the objects.    But 
this approach may be required to support multi-party (m of n) authorization models.


A third option is to standardize both - but make the "comprehensive" 
version optional.


Thoughts?

Mike



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