Representation and Evaluation of Security Policies for Distributed System Services

1. Representation and Evaluation of Security Policies for Distributed System Services Presentation By Girija Gavankar

2. Outline • Abstract, Motivation • Framework • Policy Language,generic conditions • EACL, EACL Rules and Evaluation, Credentials • GAA-API Approach • GAA-API components • Conclusion • Status

3. Abstract • A New Model for Authorization that integrates both Local and distributed access control policies. • This model is also extensible across applications and administrative domains. • Introduces a general mechanism which can implement several security policies including - ACLs - Role-based access control -Capabilities - Lattice-based access control • Thus can be useful in Grid infrastructure.

4. Motivation • User needs to be authenticated • Restrictions on granted access and resources • Customization of policies • Enforcement of policies Domain A Domain B Request for resource database Security Policy A Security Policy B

5. Framework • Designed such that it applies to a distributed system that spans multiple autonomous domains without central management authority • Components of the Architecture - Authentication Mechanism - Group Server - GAA- API - Delegation support

6. Outline • Abstract, Motivation • Framework • Policy Language,generic conditions • EACL, EACL Rules and Evaluation, Credentials • GAA-API Approach • GAA-API components • Conclusion • Status

7. Policy Language Example :: Joe and members of department-1 can can print documents on Monday through Friday 9:00 AM to 6:00 PM • Security policy associated with a protected resource consist of - a set of allowed operations, - a set of approved principals and - optional constraints • But to specify conditional restrictions on the access rights, the traditional ACL and capability abstractions must be extended • To implement a policy, we should be able to define - access identity - a set of access rights - grantor identity - a set of conditions

8. Policy Language • Policy language is represented by a sequence of tokens, each token has - Token type - Defining Authority - Value Example : Specifying Access Identity Specifying Access rights Token Type:access-user-id Defining authority: KerberosV5 Value :girija@usc.edu Token Type :Pos-access-rights Defining Authority:Local Manager Value :FILE:read,write

9. Generic conditions • Time • Location (host/domain/networks) • Message protection constraints (confidentiality,Integrity) • Connection (Security of connection,BW) • Multi-level security constraints (lattice-based) • Privilege constraints (clark-wilson) • Payment(must be paid prior to access) • Quota(a currency and a limit) • Strength of authentication (set of authentication Mech.) • Attributes of subjects(subject must have set of attributes )

10. EACL • Extends the conventional ACL concept by allowing on to specify conditional authorization policies • Implemented as conditions on authentication and authorization credentials Token Type:access-id-GROUPDefining Authority:DCEValue:15 Token Type:pos-access-rights Defining Authority:local-manager Value:FILE:read FILE:write Token Type:location Defining Authority:system-managerValue:*.USC.EDU

11. EACL Rules and Evaluation • A single EACL does not specify both –ve and +ve rights • If both are allowed in group entries, then the inconsistencies are solved by ordered interpretation • The authorization that has already been examined takes precedence over new Authorizations • Ordering Approach : - easier to implement - requires total ordering - needs careful writing of EACL by administrator - thus error-prone

12. Credential evaluation • May contain optional conditions associated with the granted rights • Example : Tom connecting from ORG.EDU to write to doc.txt at 5pm. • Following are the EACLs associated with doc.txt Identity credential: access-id-USER kerberos.v5 tom@ORG.EDUcondition: time-window pacific-time zone 6am-7pm Group membership credential: access-id-GROUP kerberosV5 admin@ORG.EDUcondition: privilege:restricted Delegation credential: grantor: grantor-id-USER kerberosV5 joe@ORG.EDUgrantee: access-id-USER kerberosV5 tom@ORG.EDUobjects: doc.txtrights: pos-access-rights local-manager FILE:writecondition: location local-manager *.org.edu

13. Outline • Abstract, Motivation • Framework • Policy Language,generic conditions • EACL, EACL Rules and Evaluation, Credentials • GAA-API Approach • GAA-API components • Conclusion • Status

14. Approach • Local policies: ACLs • Distributed policies: credentials • An optional condition field is added to ACLs(EACL) and credentials - conditions in credentials are evaluated in addition to the conditions in the matching ACL entries • Generic Authorization and Access control API (GAA API) • - gaa_get_object_acl • - gaa_check_authorization • GAA API Security Context

15. Approach contd… 5 5a GAA-get-object-ACL Application 6 EACL 1 4 GAA-check-Authorization 7 6b Security API (1, 2, 3, 4, 4a) request and verification of principal’s identity 4a 6a 2 3 (5, 5a) call to the gaa_get_object_acl, retrieval of appropriate EACL GAA- API Security Context Security Server (6, 6a, 6b) call to the gaa_check_authorization (7) GAA API answer

16. GAA_get_object_acl • gaa_get_object_acl ( minor_status, // OUT, mechanism-specific status code object, // IN, reference to the object to be accessed authr_db, // IN, pointer to application-specific authorization database retrieve, // IN, upcall function for the retrieval of the object ACL acl_handle // OUT, handle to the ACL, which is a subject of examination)

17. GAA_check_authorization • gaa_check_authorization ( minor_status, // OUT, mechanism-specific status code sec_context, // IN&OUT, principal's security context acl_handle, // IN, handle to ACL, which is a subject of examination; returned by the gaa_get_object_acl check_access_rights, // IN, OPTIONAL, list of access rights for authorization gaa_options , // IN, OPTIONAL, describes the behavior of the GAA API gaa_answer , // OUT , contains various information for further evaluation by an application )

18. GAA API gaa_answer • struct gaa_answer_struct { valid_time, // time period during which the authorization is granted granted_access_rights, // granted access rights conditions, // conditions on the granted access rights required_sec_attributes // information about additional security attributes required }

19. GAA Error Code • GAA_AUTHORIZED • GAA_NOT_AUTHORIZED • GAA_ADDITIONAL_CHECKS_REQUIRED

20. GAA security context • struct gaa_sec_context { identity_cred // identity credentials authorized_cred // delegated credentials, capabilities group_memb // grantee is a member of listed groups group_nonmemb // grantee is NOT a member of listed groups attributes // miscellaneous attributes attached to the grantee unevaluated_cred // unevaluated credentials connection_state // per-connection context condition_evaluation // evaluate application-specific conditions pull_cred // obtains the necessary credentials cred_evaluate // parse the acquired credentials }

21. Conclusions • Extending ACLs with “Conditions” allows flexibility in distributed Authorization mechanism • extensible across multiple applications supporting different operations and different kinds of protected objects • The problem of policy translation is resolved by providing generic evaluation functions • Currently integrated with Prospero Resource Manager and Globus Security Infrastructure

22. Status • Current Prototype - uses Kerberos - evaluation of identity credentials • Future Work - refining evaluation algorithm - evaluation of other types of credentials - requesting additional credentials and evaluation of acquired ones

23. Clark-Wilson • Developed to address security issues in commercial Environment. • 2 categories to realize integrity : - Well-Formed transactions - Separation of duty • Thus to integrate with GAA- API, -Represent a constraint that only trusted programs can modify objects, “application:Checksum ” OR“application:endorser” (valid certificate required) • For Dynamic separation of duties, “Privilege:restricted”– only one group at a time”

24. Lattice-based Policies • Madatory Confidentiality and Integrity • Objects as well as subjects assigned labels as follows, - Confidentiality Labels :Top-secret/NASA - Integrity Labels :High- Integrity, Low-Integrity • To prove eligibility to access an object, a subject has to present a valid credential, stating subject's security label • Eg. Conf-read-equal:confidentiality-label (subject must have equal clearance as to the conf-label)