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 ACLs
• Implementation Details
• Performance Evaluation
• Conclusion and Critique

3
Outline

• Introduction
• Authentication Protocol
• Extending to ACLs
• 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 (ACLs) 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 ACLs
• 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 clients private
  key
• Decrypt authentication server decrypts the
  request using the clients 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_at_db.uwaterloo.ca
• Asdof876a4we7p7oif_at_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 arent 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 Users 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 ltusergt.ltcanonocal_name
  gt
• 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 members 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 Us 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 --gt public key hashes
• Remote groups --gt 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 ACLs
• Remove group or user from the ACL

40
Outline

• Introduction
• Authentication Protocol
• Extending to ACLs
• Implementation Details
• Performance Evaluation
• Conclusion and Critique

41
Extending to ACLs

• Specify rights for a user or group to files in
  the system
• Each file has one Access Control List (ACL)
• SFS ACLs 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 ACLs
Permission Effect on Files Effect on Directories
r Read file -
w Write File -
l - List in directory
i - Add to directory
d - Delete from directory
a Edit ACL Edit ACL
Extended version of Andrew File System (AFS)
43
Extending to ACLs

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

44
Outline

• Introduction
• Authentication Protocol
• Extending to ACLs
• 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
  ACLs
• SFS stores ACLs
• In the first 512 bytes of a file
• In a special .SFSACL for directory ACLs
• Allows quick and efficient access to ACLs should
  a user request a file or directory

47
Implementation Details

• ACLs are written and stored in text format
• ACLBEGIN
• sysanonymousli
• grouptony.cs856lid
• systonylida
• 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 ACLs and granted permissions in order
  to avoid repeated NFS file/directory accesses

49
Outline

• Introduction
• Authentication Protocol
• Extending to ACLs
• 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

51
Performance Evaluation

• (1) First experiment fetched an entire set of
  groups and user records as the server had not
  cached them
• Number of bytes transferred scaled linearly with
  number of records transferred

52
Performance Analysis

• (2) Second experiment fetched changes to a set of
  records from remote servers
• Number of bytes transferred scaled linearly with
  number of changes

53
Performance Analysis

• Tests consisted of 1000 groups that contained
  varying numbers of users between 0 and 10 000

54
Performance Analysis

• Symbol Background
• Q size of RPC request
• R size of RPC reply
• M users or changes in the group to be
  downloaded
• S size of a single user or change
• O RPC overhead incurred for each additional 250
  users
• B total number of bytes transferred

55
Performance Analysis
To Transfer Q R S M O B
0 users 72 136 40 0 216 208
10 000 users 72 136 40 10 000 216 408 632
0 changes 72 108 40 0 180 180
1000 changes 72 108 40 1000 180 40 720
All numbers (except M) are in bytes
56
Performance Analysis

• Results show that
• B Q R (M x S) floor(M / 251) x O
• Authentication server limits the size of an RPC
  message
• Hence, only 250 entries can be transferred at
  once
• Larger groups require multiple queries
• Why is this done???

57
Performance Analysis

• Results also show that RPC overhead is
  insignificant
• Only 400 Kb needed to transfer 10 000 users
• Only 8424 bytes of RPC overhead!
• 2 of the total transfer amount
• Results demonstrate the implementation can handle
  the MIT Athena authentication server size
• Currently has 1610 users in the largest group
• Requires 65 904 bytes to transfer!

58
Performance Analysis

• ACL implementation introduces a performance
  penalty
• Requires extra overhead to request and read/write
  the ACL for a file or directory
• Used a benchmark to determine the extra overhead

59
Performance Analysis

• Benchmark used to create, read and delete 1000
  files of 1024 bytes each
• Found that it SFS overhead is
• 14 for creating files
• 3 for reading from files
• 6 for deleting files
• Overhead is attributed to cache updates and extra
  requests needed to implement ACLs with the NFS

60
Performance Analysis

• Slowdown without caching of files was about 26
• Predicted was 167???
• Difference is believed to be due to caching in
  the buffer of the entire file when the ACL is
  read
• Experiments indicate that additional overhead for
  ACLs causes a performance degradation
• Most applications expected to have a small
  performance impact because of ACLs
• Checked empirically with a download, unpack and
  install of Emacs
• Only 2 slowdown!

61
Outline

• Introduction
• Authentication Protocol
• Extending to ACLs
• Implementation Details
• Performance Evaluation
• Conclusion and Critique

62
Conclusion and Critique

• Authors have demonstrated a reliable system that
  works in the real world
• System is currently implemented with an MIT
  database
• Performance overhead in a network environment is
  acceptable
• 3 overhead for reads of small files is
  acceptable when it already takes several seconds
  to read the file over the network

63
Conclusion and Critique

• Contributes a new authentication protocol
• Generality is sacrificed for ease of use and
  implementation simplicity
• Lacks the generality of authentication using
  certificate based systems
• Benefits from a simpler implementation

64
Conclusion and Critique

• Pre-fetching and caching of remote users and
  groups allows credentials to be issued without
  significant overhead at authentication
• Experiments demonstrated the systems ability to
  scale and still perform well
• Get the open source software at www.fs.net

65
Conclusion and Critique

• Overall, paper was well written
• Easy to follow
• Easy to understand
• Written at a level that is easy to understand by
  novice and advanced readers
• Shows that a decentralized authentication system
  works in practice
• Performance evaluation to back it up

66
Conclusion and Critique

• Introduction, abstract and keywords are
  appropriate to the topic
• Presents an introduction that pops some questions
  into mind
• Very few spelling and grammar issues, or typos

67
Conclusion and Critique

• Missing some important information
• How easy is it to attack this system? (i.e. DoS,
  password cracking, replay and key wear attacks,
  etc.)?
• What are the weak points of the system (i.e.
  ACLs stored in plain text, passwords in one
  location, etc.)?
• How does the system perform and what is the
  overhead with larger files? Do larger files
  impose any additional overhead on NFS?

68
Conclusion and Critique

• Unanswered Questions
• Does having only 512 bytes for storage of the ACL
  limit the number of people that can access the
  file? Would it be more appropriate to have a
  separate file for each ACL, or a searchable ACL
  database?
• Can a user be deleted, and through some malicious
  act, keep other servers from finding out through
  DoS attacks, etc? Do cached records expire?
• What happens when an entire server is removed? Do
  cached records expire?
• System is not designed for use in situations with
  millions of users/groups, but how does it perform
  in this situation?

69
Conclusion and Critique

• Unanswered Questions
• How well does the system perform under heavy
  load? Have you stress-tested the system?

70
Questions?