Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

Modules Control Access to Objects

Overview

Service provider modules manage objects that are manipulated through the service provider's APIs. Each service provider can control access to these objects on a per request basis according to a policy enforced by the provider. Most of the access-controlled objects are persistent, but they can exist only for the duration of the current application execution. Examples include:

Authorization to use a cryptographic key stored by a CSP
Authorization to use a particular secret managed by a CSP
Authorization to write records to a particular data store

A service provider must make an access control decision when faced with a request of the form "I am subject S. Do operation X for me." The decision requires the service provider to answer two questions:

Is the requester really the subject S?
Is S allowed to do X?

The first question is answered by authentication. The second question is answered by authorization.

Authentication as Part of Access Control

There are various forms of authentication. Traditionally, the term is applied to authentication of the human user. A human is often authenticated by something he or she knows, such as a passphrase, a PIN, etc. More secure authentication involves multiple factors:

something the human knows
something the human possesses
something the human is, in the form of a biometric authentication.

It is also possible to authenticate an entity using public key cryptography and digital certificates. The entity holding a keypair can be a hardware device or instance of some software. The device or the software acts on behalf of a human user. Each entity is identified by a public signature key. Authentication is performed by challenging the entity to create a digital signature using the private key. The signature can be verified and the entity is authenticated. The digital certificate and the digital signature are credentials presented by the entity for verification in the authentication process.

Each service provider defines a policy regarding the type and number of authentication credentials accepted for verification by the service module. The credentials can be valid for some fixed period of time or can be valid indefinitely, until rescinded by an appropriate revocation mechanism.

CDSA defines a general form of access credential a caller can present to service providers when operating on objects, whose access is controlled by the service provider. A credential set consists of:

Zero or more digital certificates
Zero or more samples

If the service provider caches authentication and authorization state information for a session, a caller may not be required to present any certificates or samples for subsequent accesses. Typically at least one sample is required to authenticate a caller and to verify the caller's authorization to perform a CDSA operation.

The general credential structure is used as an input parameter to functions in various categories of security services. A caller can provide samples through the access credentials structure in one of several modes or forms:

Immediate values contained in the credentials structure - for example, a PIN, or a passphrase
By reference to another authentication agent who will acquire and verify the credentials - for example, a biometric device and agent to acquire and verify biometric data from the caller, a protected PIN pad or some external authentication mechanism such as PAM.
By providing a callback function that the service provider can invoke to obtain a sample on-demand - for example, invoking a function challenging the caller to sign a nonce
Any combination of these forms

The service provider uses credentials to answer the authentication question.

Authorization as Part of Access Control

Once any necessary authentication samples have been gathered, authorization can proceed. Just providing a password or biometric sample does not imply that the user providing the sample should get the access he or she is requesting. An authorization decision is based on an authorization policy. In CDSA, an authorization policy is expressed in a structure called an Access Control List (ACL). An ACL is a set of ACL entries, each entry specifying a subject that is allowed to have some particular access to some resource. Traditional ACLs, from the days of early time sharing systems, identify a subject by login name. The ACLs we deal with can identify a subject by login name, but more generally, the Subject is specified by the identification template that is used to verify the samples presented through the credentials.

The ACL associated with a resource is the basis for all access control decisions over that resource. Each entry within the ACL contains:

Subject - a typed identification template (a type designator is part of the Subject, because multiple Subject types are possible)
Delegation flag - indicating whether the subject can delegate the access rights (this only applies to public key templates)
Authorization tag - defining the set of operations for which permission is granted to the Subject (the definition of authorization tags is left to the Service Provider developer, but in the interest of increased interoperability, we define tags for the basic operations represented by the defined standard API.
Validity period - the time period for which the ACL entry is valid
Entry tag - a user-defined string value associated with and identifying the ACL entry

The ACL entry does not explicitly identify the resource it protects. The service provider module must manage this association. The basic authentication process verifies one or more samples against templates in the ACL. Each ACL entry with a verified subject yields an authorization available to that subject.

Beyond the basic process, it is possible to mark an ACL entry with the permission to delegate. The delegation happens by one or more authorization certificates. These certificates act to connect the authorization expressed in the ACL entry from the public key subject of that entry to the authorization template in the final (or only) certificate of the chain. That is, an authorization certificate acts as an extension cord from the ACL to the actual authorized subject. Delegation by certificate is an option when scaling issues mitigate against direct editing of the ACL for every change in authorized subject.

Service provider modules are responsible for managing their ACLs. When a new resource is created at least one ACL entry must be created. The implementation of ACLs is internal to the service provider module. The CDSA interface defines an CSSM_ACL_ENTRY_PROTOTYPE that is used by the caller and the service provider to exchange ACL information.

When a caller requests the creation of a new resource, the caller should present two items:

A set of access credentials
An initial ACL entry

The access credentials are required if the service provider module restricts the operation of resource creation. In many situations, a service provider allows anyone to create new resources. For example, some CSPs allow anyone to create a key pair. If resource creation is controlled, then the caller must present a set of credentials for authorization. Authentication will be performed based upon the set of samples introduced through the credentials. Upon successful authentication, the resulting authorization computation determines if the caller is authorized to create new resources within a controlled resource pool or container. If so, the new resource is created.

When a resource is created, the caller also provides an initial ACL entry. This entry is used to control future access to the new resource and its associated ACL (see Resource Owner). The service provider can modify the caller-provided initial ACL entry to conform to any innate resource access policy the service provider may define. For example, a smartcard may not allow key extraction. When creating a key pair on the smartcard, a caller can not give permission to perform the CDSA operation CSSM_WrapKey. The attempt will result in an error.

Resource Owner

How a given resource controller actually records the ownership of the resource is up to the developer of that code, but the "Owner" of a resource can be thought of as being recorded in a one-entry ACL of its own. Therefore, conceptually there are two ACLs for each resource: one that can grow and shrink and give access to users to the resource, and another that always has only one entry and specifies the owner of the resource (and the resource ACL). On resource creation, the caller supplies one ACL entry. That one entry is used to initialize both the Owner entry and the resource ACL. This is to accommodate the common case in which a resource will be owned and used by the same person. In other cases, either the Owner or the ACL can be modified after creation.

Only the "Owner" is authorized to change the ACL on the resource, and only the "Owner" is authorized to change the "Owner" of the resource. Effectively, the "Owner" acts as "the ACL on the ACL" for the full lifetime of the resource. In terms of an ACL entry, it only contains the "subject" (i.e., identifies the "Owner"), and the "delegate" flag (initially set to "No delegation"). The "Authorization tag" is assumed to convey full authority to edit the ACL, and the "Validity period" is assumed to be the lifetime of the resource. There is no "Entry tag" associated with the "Owner". Note that an "Owner" may be a threshold subject, identifying many "users" who are authorized to change the ACL. Note also that "Ownership" does not convey the right to delete the resource; that right may or may not be conveyed by the ACL.

CDSA defines functions to modify an ACL during the life of the associated resource. ACL updates include:

Adding new entries
Replacing/updating existing entries
Deleting an existing entry
Changing the "Owner"

Modifying an ACL is a controlled operation. Credentials must be presented and authenticated to prove that the caller is the "Owner".

Click here to return to the publication details.

Contents

Next section

Index