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 Network File server Database 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 Network Servers Aura

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 System Setting Aura File server rNurse rwDoctor RightsRole Doctor Surgeon […] Alice RoleUser K K Get role key Role Key = H K (roleList) M, MAC roleKey (M) R, MAC roleKey (R)

16 Protocol Details (1)  Setup – Aura and server share K  Generation of role key – role Key c =MAC K (I c,H(roleList),expiry,[..]) I c = Identity of client C roleList = list of all roles of the client expiry = validity period of the role key [..] = constraints and other stuff  Securely transfer roleKey c to the client –A  C: roleKey c, roleList, expiry

17 Protocol Details (2)  Freshness – – C  S: M, MAC roleKey c (M) M=Req,I c,roleList,expiry,currentRole,r – S  C: M={Resp, r, s}, MAC roleKey c (M)

18 Protocol Details (3)  C  S: M, MAC roleKey c (M) –M = {Opr, Oid, I c, roleList, expiry, currentRole, r, s}  Server – Checks if currentRole is present in roleList – Generates roleKey c from K,I c,roleList,expiry – Verifies MAC roleKey c (M) and freshness – grants access rights according to the RBACL stored  S  C: M, MAC roleKey c (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 role Key

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 Implementation Plans (1) NFS with ext3 LDAP Instant revocation Periodic download Open {UID = random, GID = H(rolename)} NFS ?? 1.Password 2.Public key

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?