Authorization and Certificates: Are We Pushing When We Should Be Pulling?

Transcription

1 Authorization and Certificates: Are We Pushing When We Should Be Pulling? Jason Crampton Hemanth Khambhammettu Information Security Group, Royal Holloway, University of London Egham, TW20 0EX, United Kingdom ABSTRACT Certificates have long been used to bind authorization information to an identity or public key. Essentially there are two ways in which a verifying authority (reference monitor) can obtain the information (from a certificate) that is required to make an access control decision: the requesting entity provides the privilege attributes to the verifying authority a push model; or the verifying authority obtains the privilege attributes from a trusted repository a pull model. In this paper we argue that a push model, which is used by most certificate-based authorization mechanisms, is inferior to a pull model, and present an architecture based on the pull model. KEY WORDS Authorization, Certificate, Pull Model, Push Model 1 Introduction The concept of a (digital) certificate is now well established and essentially provides a way of binding an identifier to a public key. Equally, it has long been recognized that the use of certificates raises some difficult questions [1]. The use of certificates has been extended in schemes like X.509 and SPKI to include authorization information, enabling the certificate holder to access computer resources. There are several authorization models for distributed computer systems that make use of attribute certificates, which contain authorization information. Among the most well known are SPKI [2], SESAME [3] and PER- MIS [4]. We believe that attribute certificates suffer from, and in some cases are more susceptible to, the same problems as ordinary certificates. The most urgent of these problems in this context is revocation of certificates. Let us suppose that a distributed computer system contains an authentication service and an authorization service. The former issues attribute certificates to users that successfully authenticate to the system, while the latter processes requests made by authenticated users to access resources within the system. An access request is submitted to the authorization service and is accompanied by the attribute certificate. The authorization service s decision is based on the nature of the request, the information in the certificate and the validity of the certificate. The validity of the certificate may be undermined for two main reasons: it may have expired or it may have been revoked. The former case is easy to identify if the certificate contains an expiration date and the integrity of the certificate can be guaranteed. There are several reasons why a certificate may be revoked: key compromise; the certificate holder may no longer be an approved user of the system (privilege revocation); or the access control data structures may have changed within the authorization system with the result that the certificate contains obsolete information. In any case, it is necessary for the authorization service to establish that the certificate is still valid. If the attribute certificates are issued by third parties, the timely identification of invalid certificates is known to be a difficult problem. The usual solution is for the issuing authority to generate certificate revocation lists (CRLs), but these are known to have certain problems and alternative solutions have been proposed [5, 6, 7]. In the authorization scenario outlined above, establishing whether a certificate is valid is relatively easy because the authentication service and authorization service are part of the same system. The authorization service can simply maintain its own CRL, which is consulted prior to making an access control decision. The main problem with CRLs is that they are published on a periodic basis. The authorization scenario we have described could broadly be described as a push model for certificate-based authorization, where the client provides the information required by the authorization service. However, if we need to check the validity of certificates it is fair to say that the client, while providing necessary information (in the form of a certificate) does not provide sufficient information to make an authorization decision. In particular, the authorization service needs to check that the client has provided a valid certificate. Rivest proposed a scheme where it is the client s responsibility to provide all necessary information to the server [7]. In the context of authorization, this is not possible as the client can hardly be expected to be aware of changes to the access control data structures on the server. In the next section we develop the arguments for using a pull model rather than a push model for certificate-based authorization decisions. In Section 3 we will discuss an architecture for certificate-based authorization based on a pull model. Finally we discuss related and future work and summarize the contributions of this paper.

2 2 Push Versus Pull models In traditional operating systems, an authenticated user is bound to a data structure that provides a security context for that user. When the user executes a program a process is created that inherits the security context of the user. When the process attempts to access a file, for example, the operating system s reference monitor compares the file s security context with that of the requesting process and makes an access decision. Such an authorization mechanism is based on a pull model, where the requesting entity provides security information about itself. Suppose now that the user s security context contains an association with some user group and that during the user s session his membership of that group is revoked. Then access requests made by that user will still be evaluated on the assumption that he is a member of that group, unless the operating system s reference monitor explicitly checks all group membership before making a decision. This is a problem common to all push models, and one which is particularly relevant in certificate-based authorization mechanisms. To our knowledge, all certificate-based authorization models use a similar model. One significant advantage of this approach is that the verifying authority is provided with the information required to take an access decision immediately. A corollary of this is that computational and communication overheads of making an access decision using a push model are negligible in principle. We would agree that these advantages are a compelling reason to use a push model if the information contained in the certificate is static and the validity of the certificate can be assumed. However, if the information contained in the certificate is liable to change or the certificate may be revoked, it is necessary for the verifying authority to check that the certificate can still be used for authorization purposes. That is, the verifying authority will need to check that no CRL exists for a certificate each time an access request is made. Clearly, this imposes considerable computational and communication overheads on the decision-making process. In short, it can no longer be assumed that the verifying authority has all the information it requires to service an access request and push models are likely to lose the benefits they offer over pull models. Furthermore, CRLs are known to have a number of problems that make them unreliable as a certificate status propagation mechanism [5, 6, 7]. 1 The freshness of CRLs will be vital for verifying authorities when making access control decisions. However, it is known that the periodic update and timely distribution of CRLs is a difficult problem. Online certificate verification schemes such as OCSP [9] provide an alternative to CRLs, but such schemes often depend on CRLs for retrieving certificate status information and thus share their 1 It has been noted that the use of CRLs may be the optimal solution in certain applications. McDaniel and Rubin [8] make a convincing case for the use of CRLs in a PKI that supports e-commerce applications, for example. limitations. One obvious solution to the problem of certificate validity is to give each certificate a limited period of validity. Then if a request is made within the time that the certificate is valid, then it is assumed that the information in the certificate can be trusted. We now have the obvious problem that a certificate may become invalid, but still be used for making access requests. Clearly, determining an appropriate validity period becomes vitally important. On the other hand, in a system based on a pull model, the verifying authority is responsible for obtaining the necessary authorization rather than relying on information supplied by the user. An authenticated user is given an authentication token that simply confirms that the user was recognized by the system. In a pull model, the authorization information is held on the server side in the form of a certificate. This certificate is created when the user is authenticated and stored in some trusted repository maintained by the system. An access request is accompanied by the authentication token, which provides a reference to the authorization token. The authorization token is pulled by the verifying authority from the repository in order to make an access decision. When authorization information relevant to a user needs to be updated, the system makes the appropriate changes to the authorization token. Hence, revocation of user s privileges can be performed efficiently by the system without the need to maintain CRLs and the verifying authority always has access to the latest authorization information. We believe that freshness of user privileges (in the form of a certificate) is desired in authorization scenarios as access control decisions will be based on this information. We argue that the pull model, although it requires a look up operation to find the required authorization information, is as efficient as push models because such models also require a look up operation to establish the validity of the certificate presented by the user. We also note that authorization information such as separation of duty constraints and authorization policy information are often stored on the server side and are retrieved by the authorization engine while making an access control decision. Hence, in a system based on a push model, where the user presents information in the form of a certificate, the additional authorization information required to make an access control decision, such as separation of duty constraints and authorization policy information, still needs to be retrieved by the authorization engine from the server side. Finally we note that the pull model supports the dynamic revocation of privileges because the server-side controls the authorization certificate. 3 A Pull Architecture In this section we outline an architecture that employs a pull model to retrieve authorization certificates. The architecture implements a role-based access control model incorporating a role hierarchy, a user-role assignment rela-

3 tion and a permission-role assignment relation [10]. The role hierarchy is determined by the Hasse diagram of a partially ordered set of roles R,. 2 The user-role assignment relation UA U R, where U is the set of users, is a binary relation that associates users with roles. Similarly, the permission-role assignment relation PA P R, where P is the set of permissions, is a binary relation that associates permissions with roles. An access control decision is made by determining which roles, and hence which permissions, a user is entitled to use. The architecture has five main components: an authentication engine, an interface, a session manager an authorization engine and a certificate repository. The session manager issues session certificates for authenticated users, which are stored in the repository. The session certificate is a kind of attribute certificate written in XML, similar to a capability card [11]. Broadly speaking, U is associated with the authentication engine, UA and RH with the session manager, and PA with the authorization engine. An overview of the architecture and information flow within it is shown in Figure 1. The initial point of contact for a user is the authentication engine, to which the user will submit credentials as part of some logon procedure. The authentication engine attempts to validate these credentials against a user data repository. If the logon process is successful, the authentication engine creates an authentication token, digitally signs it and forwards it to the interface. The interface has two main functions: to assess the validity of authentication tokens and access requests; and to act as an access control enforcement point. The interface handles two distinct types of requests: session certificate requests, which are forwarded to the session manager in order to create a session certificate; and access requests, which are forwarded to the authorization engine in order to make an access control decision. The session manager issues XML-based session certificates to authenticated users in response to session certificate requests from the interface. Session certificate requests are accompanied by appropriate logon information. Essentially, a session certificate identifies a set of roles allocated to a user for the lifetime of the session. Indirectly, a session certificate grants a user a number of permissions and hence is similar to a capability card [11] or a privilege attribute certificate [3]. The session certificate is a dynamic structure and may be changed by the session manager. The authorization engine is an access control decision point and only responds to access requests received from the interface. The session certificate will be used by the authorization engine to establish the legitimacy of an access request by a user. Decisions are made by the authorization engine on the basis of the role(s) contained in the session certificate, the permission-role assignment relation and any 2 In other words, the role hierarchy is the graph of the reflexive, transitive reduction of the partial order relation defined on the set of roles R. relevant authorization policy statements Session Certificate Updates A session certificate binds a user identity to a set of roles. Hence, changes to the user-role assignment (UA) relation and to the structure of the role hierarchy during the lifetime of a session certificate may affect the permissions available to the identity associated with a session certificate. In the proposed architecture, such changes are implemented by replacing the original session certificate with a new session certificate that reflects the changes. Thus, access decisions are based on the most recent roles available to a user. For example, suppose a user u logs on to the system and chooses to activate a certain set of roles {r 1,...,r n }. (Each of these roles must be assigned to the user in the U A relation.) Then a session certificate will be created containing those roles. If an administrator subsequently deletes (u,r i ) from the UA relation (that is, the user has his assignment to role r i revoked), then the session certificate is replaced with a certificate containing roles r 1,...,r i 1,r i+1,...,r n. If u tries to use permission p that is assigned (only) to role r i, then u will be denied access to that permission. Interesting questions arise when we consider a user who wishes to acquire a session certificate on the basis of certificates issued by third parties that attest to the identity and characteristics of the user. We will refer to this as anonymous authentication. Several researchers have investigated how role-based access control might provide a way of providing a security context (in our terminology, a session certificate) for anonymous users [12, 13]. In such scenarios it is necessary to record authentication information in the session certificate. Specifically, we must include references to any certificates that were either used to authenticate the user to the system or to provide information that led to the assignment of roles to that user in the session certificate. Clearly, this is a fruitful area for further research. We discuss some preliminary ideas in the conclusion to this paper. 4 Related Work SESAME, the result of a European initiative, is a security architecture based on Kerberos. SESAME uses role-based access control and privilege attributes certificates (PAC), which is a specific form of access control certificate that conforms to ECMA and ISO/ITU-T standards, for implementing authorization [3]. After a successful authentication process, the authentication server (AS) will issue a ticket to the user. An authenticated user will present this ticket to the privilege attribute server (PAS) to obtain a proof of his privileges in 3 Authorization policy statements may refer to the enforcement of separation of duty requirements. Consideration of such policy details are beyond the consideration of this paper.

4 Interface 3 Session Manager 4 5 User Repository 2 Authentication Engine Authorisation Engine 1 User authenticate to Authentication Engine 2 Authentication Engine returns the private key and authentication token to the user; forwards authentication token to Interface 3 Interface forwards authentication token to Session Manager 4 Session Manager creates session certificate and stores in the repository 5 User sends authentication token and digitally signed access request to Interface 6 Interface verifies the authenticity of access request and forwards to Authorization Engine 7 Authorization engine retrieves the session certificate of the user from the repository and makes an access control decision Figure 1. Overview of system architecture and operation the form of a privilege attribute certificate (PAC). The privilege attribute server (PAS) issues a PAC to an authenticated user u. The certificate is given a fixed period during which it is valid. An administrator subsequently updates the user-role assignment relation (before the expiry of the PAC). In other words, the privileges included within a valid PAC have been revoked but u can use those privileges while the certificate is valid. SESAME asserts that it had adopted a push model because of the advantages it offers over pull models. We believe that SESAME suffers with a problem of revocation of PACs where changes to access control data structures are not noticed until the expiry of the PAC. SPKI authorization certificates bind access rights to the public key of the user. In SPKI, authorization certificates are usually not stored in a global repository. Authorization certificates are pushed by the keyholder to the verifier. SPKI addresses revocation problems of the authorization certificates with timed CRLs, timed revalidations and one-time revalidation schemes. Khurana and Gligor note that SPKI does not resolve the transitive revocation problems, as it supports transitive distribution of delegated access privileges [14]. Permis uses X.509 attribute certificates (ACs) to carry authorization information in a privilege management infrastructure (PMI), which is similar to a public key infrastructure (PKI). Permis maintains the user s role ACs in LDAP directories and makes them publicly available. Revocation of user s role ACs is performed by simply deleting the user s role ACs from the LDAP directories. After a successful user authentication process, the ADF will retrieve the user s role ACs from LDAP directories and extracts roles from valid ACs, which are included in a subject object. When an access request is initiated by the user, the subject object is used by the ADF to make an access decision. Note that the roles included in the subject object are not updated during its lifetime. Hence, revocation of the user s role ACs will not be observed until the AEF decides to create a new subject object for that user. 5 Conclusion We have discussed the benefits of using a pull model to obtain authorization information, given that such information is dynamic and its accuracy is of particular importance. We outlined an architecture based on a pull model and described how updates to access control data structures would be immediately reflected in the information used to make an authorization decision. We focused on how our architecture might be used to authorize access requests initiated by previously known users of the system. However, it is becoming increasingly important in distributed object systems and web applications for anonymous users to access resources on the system. We intend to develop a trust model that enables the authentication of anonymous users based on identity certificates supplied by (perhaps partially) trusted third parties. Furthermore, we will create session certificates based on digitally signed assertions about these users. Examples of such assertions include professional affiliations, proof of employment and proof of educational qualifications. We expect that such assertions can be encoded using SAML. It will be necessary to provide a mechanism by which the session manager can update the session certificates of such users. Several schemes have been discussed in the literature that address revocation mechanisms of identity certificates where freshness of information is paramount. Cert em, a key management and certification system that is based on electronic-mail service, avoids the use of CRLs by storing the public-key certificate of the user in the local Keys Service Unit [15]. The validity of a certificate is asserted by the CA through the issuance of a Validity Statement. SPKI proposes a similar mechanism called onetime revalidation for providing the certificate status information [2]. We would like to investigate such mechanisms in the

5 context of authorization of anonymous users. One solution could be to include such third party identity certificate information within the session certificate and to periodically check the validity of the certificates supplied by the user that led to the creation of the user s session certificate. (We can imagine using a daemon process to poll the relevant third party servers to obtain a statement of validity for such certificates.) The roles included in the session certificate of the user will be updated by the session manager if any of those certificates are revoked by their issuing authorities. Providing support in our architecture for separation of duty requirements in complex application scenarios and the development of a Java-based API will also be addressed in our future work. References [1] P. Gutmann. PKI: It s not dead, just resting. IEEE Computer, 35(8):41 49, [2] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. SPKI certificate theory, IETF RFC [3] P. Ashley. Authorization for a large heterogeneous multi-domain system. In Proceedings of Australian Unix and Open Systems Group National Conference, pages , [11] K. Otani, H. Sugano, and M. Mitsuoka. Capability card: An attribute certificate in XML. IETF Internet Draft, Available at draft-otani-ccard-00.html. [12] A. Herzberg, Y. Mass, J. Mihaeli, D. Naor, and Y. Ravid. Access control meets PKI, or: Assigning roles to strangers. In Proceedings of IEEE Symposium on Security and Privacy, pages 2 14, [13] M.A. Al-Kahtani and R. Sandhu. Induced role hierarchies with attribute-based RBAC. In Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies (SACMAT-03), pages , [14] H. Khurana and V. D. Gligor. Review and revocation of access privileges distributed with PKI certificates. In Proceedings of the 8th International Workshop on Security Protocols, pages , LNCS [15] J. Lopez, A. Maa, and J. J. Ortega. Cert em: Certification system based on electronic mail service structure. In Proceedings of Secure Networking (CQRE 99), pages , LNCS [4] D. W. Chadwick and A. Otenko. The PERMIS X.509 role-based privilege management infrastructure. In Seventh ACM Symposium on Access Control Models and Technologies, pages , [5] S. Micali. Efficient certificate revocation. Technical Report MIT/LCS/TM-542b, MIT, [6] M. Naor and K. Nissim. Certificate revocation and certificate update. In Proceedings of 7th USENIX Security Symposium, pages , [7] R. Rivest. Can we eliminate certificate revocation lists? In Proceedings of Second International Conference on Financial Cryptography, pages , LNCS [8] P. McDaniel and A. Rubin. A response to Can We Eliminate Certificate Revocation Lists?. In Proceedings of Fourth Internation Conference on Financial Cryptography, pages , LNCS [9] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet public key infrastructure online certificate status protocol - OCSP. IETF Internet Draft, RFC 2560, Available at [10] R.S. Sandhu, E.J. Coyne, H. Feinstein, and C.E. Youman. Role-based access control models. IEEE Computer, 29(2):38 47, 1996.