decentralized user authentication in a global file system
DESCRIPTION
Decentralized User Authentication in a Global File System. Tony Young M.Math Candidate CS 856 - Fall 2004. Outline. Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique. Outline. Introduction - PowerPoint PPT PresentationTRANSCRIPT
Decentralized User Authentication in a Global File System
Tony Young
M.Math Candidate
CS 856 - Fall 2004
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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
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
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
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
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
Outline Introduction Authentication Protocol
Overview The Server Resolving Groups Optimizations Credentials
Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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)
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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
Extending to ACL’s
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)
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
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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
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
Implementation Details ACL’s are written and stored in text format
ACLBEGINsys:anonymous:ligroup:tony.cs856:lidsys:tony:lidaACLEND
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
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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
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
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
Performance Analysis
Tests consisted of 1000 groups that contained varying numbers of users between 0 and 10 000
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
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
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???
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!
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
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 ACL’s with the NFS
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
ACL’s causes a performance degradation Most applications expected to have a small
performance impact because of ACL’s Checked empirically with a download, unpack and
install of Emacs• Only 2% slowdown!
Outline
Introduction Authentication Protocol Extending to ACL’s Implementation Details Performance Evaluation Conclusion and Critique
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
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
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 system’s ability to scale and still perform well
Get the open source software at www.fs.net
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
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
typo’s
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. ACL’s 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?
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?
Conclusion and Critique
Unanswered Questions How well does the system perform under
heavy load? Have you stress-tested the system?