Decentralized User Authentication in a Global File System

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 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

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

Local names tony asdof876a4we7p7oif

Remote names [email protected] [email protected]

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

Shaded nodes are local to the authentication server

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

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


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


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


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


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


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!


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


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


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


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


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?


Unanswered Questions How well does the system perform under

heavy load? Have you stress-tested the system?

Questions?

Documents

Decentralized User Authentication in a Global File System