Decentralized User Authentication in a Global File System

1. Decentralized User Authentication in a Global File System Tony Young M.Math Candidate CS 856 - Fall 2004

2. Outline • Introduction • Authentication Protocol • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

3. Outline • Introduction • Authentication Protocol • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

4. Introduction • This paper presents an authentication server • Supports remote users and groups without the use of certificates • Establishes credentials for the user and returns them to the file system • Authenticates users without contacting remote authentication servers where user records might be stored • This might delay file system access while we have to contact possibly many intermediate servers

5. Introduction • The challenge is to provide a mechanism to support naming of remote users and groups in Access Control Lists (ACL’s) in a file system • Early network file systems (i.e. NFS, AFS, etc) do not provide means to do this • Other systems (i.e. SDSI, CRISIS, etc.) require the use of a complicated certificate infrastructure to perform authentication

6. Introduction • Authentication server is part of the Self-certifying File System (SFS) • System was implemented and is being used daily at MIT • Implementation has a performance overhead but the demonstration of usefulness is important

7. Introduction • SFS is a collection of clients and servers • Provide global file system, remote execution and user authentication • Clients and servers communicate using RPC calls • Makes use of the public-private key system to establish secure communications and perform authentication

8. Introduction • SFS guarantees three connection properties: • Confidentiality: passive attackers can only analyze traffic, not eavesdrop • Integrity: active attackers who can insert, delete, modify, delay and replay packets can only perform a DoS attack • Server Authenticity: servers must prove their identity using their private key • Clients implicitly trust the servers they are authenticating with

9. Outline • Introduction • Authentication Protocol • Overview • The Server • Resolving Groups • Optimizations • Credentials • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

10. Overview • Once clients setup a connection, they may authenticate at any time • Some actions will not require authentication • Authentication needs to happen once per session • Authentication takes three steps • Sign: sign a request with the client’s private key • Decrypt: authentication server decrypts the request using the client’s public key • Grant: credentials are granted to the user (file server keeps them and assigns them to all future operations by that client)

11. Overview

12. Overview • In the current implementation each file server has their own local authentication server • This is not necessary as several servers could potentially share one authentication server

13. The Server • Server provides two functions: • Provides an authentication service for other SFS servers • Provides an interface for users to manage their authentication information • A major challenge in developing the server is how to access remote user and remote group information • A remote server may be unavailable for some reason and not able to provide information • Remote groups could include other remote groups and this nesting could be many levels deep

14. The Server • Server maintains a database of users and groups and their information • Analogous to etc/psswd and etc/group in Unix • Server supports three RPC operations • Login: allows an SFS server to authenticate a user with a set of supplied authentication information • Query: allows a user or another server to query the database based on some piece of information • Update: allows a user to modify records in the authentication database

15. The Server • The server stores user and group information records • User record corresponds to one user in the SFS (local or remote) • Can contain the same information as a local etc/psswd information file • Group record corresponds to one group in the SFS (local or remote) • Can contain the same information as a local etc/group information file • Users and groups can be named by their user name, group name or public key SH-1 hash

16. The Server • Local names • tony • asdof876a4we7p7oif • Remote names • tony@db.uwaterloo.ca • Asdof876a4we7p7oif@db.uwaterloo.ca

17. The Server • Why use the public key hash? • Provide a way to name a user who is not associated with any authentication server • E.x. a cable modem user • Provide a means to keep user names or addresses private • E.x. user lists aren’t used to spam email accounts

18. The Server • User record contains • User Name: Unix user name • ID: Unix user ID • GID: Unix GID • (Record) Version: The version number of this record • Public Key: User’s public key • Privileges: Additional user privileges (i.e. “admin”) • SRP Information: Optional for users who want to use Secure Remote Password protocol • Audit String: Last user to edit the record (editing increments the record version)

19. The Server • Group record contains • Group Name: Unix-style name <user>.<canonocal_name> • ID: Unix-style unique ID • (Record) Version: The version number of this record • Owners: A list of the people that own this group (local and remote) • Members: A list of the people that are members of this group (local and remote) • Audit String: Last user to edit the record (editing increments the record version)

20. Resolving Groups • Local groups are part of a membership graph that defines the relationship between • Local groups • Group members • Group member’s members • … etc • Edge direction indicates membership • Each node represents one type of object (i.e. a group name, user name or public key hash) • An edge from public key hash P to user U means that P is the hash of U’s public key • P is a member of U

21. Resolving Groups Shaded nodes are local to the authentication server

22. Resolving Groups • To issue credentials, the authentication server must traverse the membership graph • Determine the groups that the user belongs to and add to credential list • Start at the node representing that user • Avoid cycles by not visiting a node twice

23. Resolving Groups • Constructing a membership graph can be done by constructing the (complimentary) containment graph • Same nodes as the membership graph but edges are opposite direction • I.e. the containment graph states the users and groups that are members of a group • E.x. an edge from group G to user U means that G lists U as a member or owner, etc. • Level 0 of the graph contains only local groups • Graph may be an arbitrary number of levels deep and may have cycles if groups recursively contain each other

24. Resolving Groups • Given the containment graph, constructing the membership graph is simple (complement the edges) • Can then be traversed in-order to issue credentials • Accurately constructing the containment graph is challenging • Groups can name remote users and groups that must be resolved • Construction operation must be efficient (i.e. not block and not take excessive time) • The graph is constantly changing as group membership changes

25. Resolving Groups • Authentication can be seen as happening in two parts: • Constructing the graph • Pre-fetch records and construct graph in the background • Cache records • Issue credentials • Traverse the tree and issue credentials to users • Pre-fetching and caching requires some cache update strategy to maintain freshness

26. Resolving Groups • Updating the cache is done periodically using the version number • Authentication server queries the site containing the user or group record • If the remote (original) copy has a higher version number, the changes that were made to the record are transmitted to the local site

27. Optimizations • Cached entries are held for each node in the containment graph with an out edge • Remote users --> public key hashes • Remote groups --> membership lists • Also contains reverse mappings to allow server to traverse membership graph • Constructed when the cache is updated

28. Optimizations

29. Optimizations • Given the previous membership graph, the cache entries would be: • g1: u1, p1, g3 • g2: g3, u2, g4 • u1: p2 • g3: p3, p4 • g4: u3, g2 • u3, p5

30. Optimizations • The server implements three optimizations: • Connection storing: The authentication server stores the connection it makes to each remote authentication server for connection resumption during the next update cycle

31. Optimizations • The server implements three optimizations: • Propagates changes: The server only propagates changes to records (denoted by the record version number) thus reducing the amount of data to be transferred

32. Optimizations • The server implements three optimizations: • Name to key mapping: Remote servers can translate the username to its public key before sending the user record in order to skip the step requesting the public key

33. Optimizations • Performance: • The cache determines the number of bytes needed to download a remote group membership list • If there is a cached copy, number of bytes is proportional to the number of updates • If there is no cached copy, number of bytes is proportional to the size of the group • Number of bytes required to fetch all entries depends on the number of entries

34. Optimizations • Performance: • The time to download all the entries depends on the depth of the graph • Each level of the containment graph is fetched in parallel from the various sites • Latency is the sum of the maximum latency at each level of the graph • Number of operations to setup a secure connection to each site is proportional to the number of sites • Remember: connections are stored and must only be established once

35. Optimizations • Scalability: • System is expected to scale to tens of thousands of groups and users • Not designed to scale to millions • For example to name all citizens of a country or Visa cardholders, etc. • This scale is unusual for a file server • System must be robust in the face of malicious servers that might return an arbitrarily large list of users/groups • Limit the number of entries and references to 1 million

36. Optimizations • Freshness: • How can we be sure that cached and periodically updated records are fresh? • User and group records have eventual consistency • I.e. up to date after the next update cycle (assuming all servers were available) • Tradeoff between efficiency and freshness • Chose efficiency as user records do not change often and delays (to contact remote server) during accesses is not acceptable • Time required to update a cached entry is less critical as it is a background task

37. Credentials • To authenticate • The user sends a request signed with their private key • The server decrypts with the users public key • If the request is successfully decrypted, the user is issued credentials

38. Credentials • Unix credentials • A set of UNIX access rights (such as file access rights, etc.) • Used in NFS and SFS file accesses • From etc/psswd and etc/group files • Public key • The SHA-1 hash of the public key used in authentication • Group List • List of groups to which the user belongs • Constructed from etc/group and traversal of the membership graph

39. Credentials • Revoking Credentials • Revoking a public key credential • Updated at the next update cycle • Revoking UNIX credentials • Remove the entry from etc/psswd or etc/group • Revoking group list credentials • Done at next authentication • Revoking ACL’s • Remove group or user from the ACL

40. Outline • Introduction • Authentication Protocol • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

41. Extending to ACL’s • Specify rights for a user or group to files in the system • Each file has one Access Control List (ACL) • SFS ACL’s contain four types of entries • User names and rights • Group names and rights • Public key hashes and rights • “Anonymous” to provide rights to all users

42. Extending to ACL’s Extended version of Andrew File System (AFS)

43. Extending to ACL’s • Remote users and groups cannot exist on local ACL’s • Add remote users and groups to a local group and add that group to the ACL • Prevents need to update thousands of ACL’s if a hostname where a user record comes from is changed • Instead, update only one group

44. Outline • Introduction • Authentication Protocol • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

45. Implementation Details • Client and server use RPC to communicate • Messages sent using public key cryptography • Authentication server makes use of a Berkeley DB backend to store user and group records, and cache entries • Allows system to scale to tens of thousands of nodes • SFS makes use of NFSv3 to store files on disk • Allows portability to any NFS implementation • Removes need to implement a new kernel-level file system

46. Implementation Details • UNIX provides no common location to store file ACL’s • SFS stores ACL’s • In the first 512 bytes of a file • In a special .SFSACL for directory ACL’s • Allows quick and efficient access to ACL’s should a user request a file or directory

47. Implementation Details • ACL’s are written and stored in text format ACLBEGIN sys:anonymous:li group:tony.cs856:lid sys:tony:lida ACLEND

48. Implementation Details • When a file/directory is requested, the system fetches the ACL and decides whether or not to grant the request based on user-supplied credentials • SFS caches ACL’s and granted permissions in order to avoid repeated NFS file/directory accesses

49. Outline • Introduction • Authentication Protocol • Extending to ACL’s • Implementation Details • Performance Evaluation • Conclusion and Critique

50. Performance Evaluation • RPC traffic accounted for only 900 bytes per request! • This is for the request and the reply, but excluding file and directory data • Two experiments were performed to measure total bytes transferred for authentication