Our model is designed for a system that spans multiple administrative domains where each domain can impose its own security policies. It is still necessary that a common authentication mechanism be supported between two communicating systems. The model we present enables the syntactic specification of multiple authentication policies and the unambiguous identification of principals in each, but it does not translate between heterogeneous authentication mechanisms.
We have integrated our distributed model for authorization with the Prospero Resource Manager (PRM), a metacomputing resource allocation system developed at USC. PRM uses Kerberos [2] to achieve strong authentication. PRM uses calls to the Asynchronous Reliable Delivery Protocol (ARDP) [16], a communication protocol which handles a set of security services, such as authentication, integrity and payment. ARDP calls the Kerberos library through a security API, requesting the principal's authentication information.
In addition, we have integrated the framework with the Globus Security Infrastracture (GSI), a component of the Globus metacomputing Toolkit [18]. GSI is implemented on top of the GSS-API which allows the integration of different underlying security mechanisms. Currently, GSI implementation uses SSL authentication protocol with X.509 certificates.
Public key authentication requires consideration of the trustworthness of the certifying authorities for the purpose of public key certification. Authentication can not be based on the public key alone, anybody can issue a valid certificate.
Certificates can comprise a chain, where each certificate (except the last one) is followed by a certificate of its issuer. Reliable authentication of public key must be based on complete chain of certificates which starts at an end-entity (e.g. user) certificate, includes zero or more Certification Authorities (CA) certificates and ends at a self-signed root certificate. A policy must be specified to validate the legitimacy of the received certificate chain and the autenticity of the specified keys. The policy must express the following trust constraints:
1) Constraints placed in the certificates by CA when issuing a certificate. They are represented as a list of certificate extensions and marked as critical/non-critical. For example, the extension may contain policy specifying that no further delegation of CA authority is allowed.
2) Specify trustworthness of CA to sign certificates for limited set of users.
3) Restrictions on certification path:
a) Permitted and denyed subtrees of CA authorities.
b) Limit the length of certificate chains (depth of the subtree).
4) Restrictions imposed on cryptographic attributes: - accepted signature scheme (e.g. DSA/SHA, RSA/MD2) - minimum public key length (768, 1024 bits)
5) Deciding to trust particular end-entity certificate for particular purpose.
The following is an example of an EACL used for describing the Globus policy for what CAs are allowed to sign which certificates. The Globus CA can sign certificates for the Globus or the Alliance. The Alliance CA can sign certificates for the Alliance.
| Token Type: access_id_CA | ||
| Defining Authority: X509 | ||
| Value: /C=US/O=Globus/CN=Globus CA |
| Token Type: pos_access_rights | ||
| Defining Authority: globus | ||
| Value: CA:sign |
| Token Type: cond_subjects | ||
| Defining Authority: globus | ||
| Value: /C=us/O=Globus/* /C=us/O=Alliance/* |