Re: [pkcs11] User types - discussion thread

[Stef Walter <stefw@redhat.com>]

On 13.10.2013 22:34, Michael StJohns wrote:
> 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.

FWIW, I'd be more interested in implementing the former, albeit less
comprehensive version.

Wouldn't multiple user's on a token be representable as separate tokens?
If a multi-user token is inserted, then multiple tokens would be present.

However, I am interested to see what an optional standardized
comprehensive version might look like, and how the two would interact.

Cheers,

Stef