Role-based authentication framework for enterprise

1. Role-based authentication framework for enterprise Vishal Kher Yongdae Kim Friday, November 19, 2004

2. Outline • Motivation • Role-based authentication framework • Requirements • Assumptions • Schemes • Related work • Implementation Plans

3. A Simple Enterprise • How to provide authentication and access control across multiple servers? • Admins. need to maintain this info. for individual servers • Too cumbersome and difficult • Prone to errors • Unnecessary repetition of work Database server File server Network File server

4. Managing multiple systems is hard • In an organization, users require access to multiple systems • File servers, Data base servers, travel/retirement accounts • These systems require some form authentication and authorization • This information can get updated independently • Hard to maintain consistency across multiple systems System independent authentication and authorization operations

5. Who should access the data? • In an enterprise, end users do not ``own'' data • Access decisions based on user’s job function or “role” • Role-based access control (RBAC) uses this fact • Role is a set of transactions • Transaction (operation) is unit of control • r/w, search, deposit, withdraw, accept proposals • Permissions are assigned to “Roles” • Member enjoys the privileges assigned to the role • Role Membership can change frequently • Typically roles do not change frequently • Roles and permissions can be inherited or constrained

6. RBAC Continued • Requires thorough analysis and policy decisions • Depends on an organization • Once framework is set-up administrative task is to assign user’s to roles • Advantages • Ease of management and reduce cost of administration • Less errors • Can describe complex access control policies • Implementation • Sun Solaris 8.0, Oracle 9iAS • Web server for UNIX and NT - NIST • Recently, NIST proposed RBAC standard

7. Whats in it for me? • How can a user acquire his roles? • How can a user prove his roles? • How can a system administrator revoke a user and/or user’s roles?

8. Current Storage Servers • Heavily based on UNIX-style UID and GID • Access decisions are primarily based on UID/GIDs • File ACL: user/group/other • Perils of UID/GID style access control • How to maintain a global UID/ GID mapping? • How to find all files associated with a particular UID? • Difficult to maintain and administer this information • Backups • Data is long-lived • What if the UID/GID doesn’t exist while restoring old backed-up data • root has to recover the data • But the data doesn’t really belong to root

9. The Final Theme • Efficiently use RBAC authentication framework • Can be combination of capability and identity credentials • Free servers from the bondage of UID/GID style access control • File access based on roles • Change file access semantics from UID/GID to roles only

10. Related Work • Kerberos and other 3-party protocols • No notion of roles/groups • Cannot specify constraints on the roles • Sometimes RBAC needs support for authorization • Mixture of access permissions as well as list of roles • Most of the other schemes use public keys • Use extension field of X.509 v3 (list roles) • X.509 attribute certificate (ACL in certificate) • Not appropriate for high performance applications • File servers, HPC • High client-side latency and high load on the file servers • Use symmetric key techniques

11. Outline • Motivation • Related work • Role-based authentication framework • Requirements • Assumptions • Scheme • Implementation Plans

12. Applying Role-based Policies • Central Policy Manager (Aura) determines policies • User – role assignment • Role – permission assignment • Revocation and other management activities • Other servers implement these policies • Data access based on roles Aura Network Servers

13. Requirements • Role membership and policies should be maintained by a central entity • Entity should be different from local admins. • Clients should get appropriate roles and should be able to prove his/her roles • Client – Server Mutual authentication • Authentication based on symmetric keys • Efficient revocation mechanism • File access should be based on roles

14. System Assumptions • Aura is a trusted entity • Clients are not trusted • Can perform all kinds of active/ passive attacks • Server – client communication link is insecure • No underlying security protocol such as IPSec • Aura can communicate securely with clients • Servers are trusted to play their role appropriately

15. User Role Alice Doctor Surgeon […] Get role key Role Key = HK(roleList) Role Rights Doctor rw M, MACroleKey(M) Nurse r R, MACroleKey(R) System Setting K Aura K File server

16. Securely transfer roleKeyc to the client • A  C: roleKeyc, roleList, expiry Protocol Details (1) • Setup • Aura and server share K • Generation of role key • roleKeyc=MACK(Ic,H(roleList),expiry,[..]) • Ic =Identity of client C • roleList = list of all roles of the client • expiry = validity period of the role key • [..] = constraints and other stuff

17. Protocol Details (2) • Freshness – • C  S: M, MACroleKeyc(M) • M=Req,Ic,roleList,expiry,currentRole,r • S  C: M={Resp, r, s}, MACroleKeyc(M)

18. Protocol Details (3) • C  S: M, MACroleKeyc(M) • M = {Opr, Oid, Ic, roleList, expiry, currentRole, r,s} • Server • Checks if currentRole is present in roleList • GeneratesroleKeyc • fromK,Ic,roleList,expiry • Verifies MACroleKeyc(M)and freshness • grants access rights according to the RBACL stored • S C: M, MACroleKeyc(M) • M = {Response, r, s}

19. Revocation • Revocation of client • Expiry field in roleKey • Revocation list • File manager can push it to devices • Devices can pull periodically using LDAP • Client’s role • This information can be include in revocation list • Include an expiry field with roles in the roleKey

20. Revocation (Contd.) • Revocation of entire role • This information can be include in revocation list • Changes to RBACL • Store an object per role on the device • Doubly linked pointer to all objects accessed by the role • Advantage • Faster lookup • Disadvantage • Space • Frequent updates of this object

21. Advangates • Centralized revocation and management • Simple role-based authentication • Direct access to servers after acquiring initial roleKeys • No public key operations on data path • Free from the UID problem

22. Password • Public key ?? Implementation Plans (1) LDAP Periodic download Instant revocation Open {UID = random, GID = H(rolename)} NFS NFS with ext3

23. Implementation Plans (2) • Main challenge • Getting rid of UID/GID • Format for roleKeys • How to map role to some id? • Hash of role name? • Unique global and permanent id • Change NFS RPCs to modify access semantics • Role-based access control list • Linux ext3 extended attributes

24. Thank You Suggestions?