Decentralized User Authentication in a Global File SystemGoalsWhy not certificates?SFS ServersSelf-Certifying NamesAuthentication ServersGroupsGroup membersSlide 9Group CachingResolving MembershipProblemsScalabilityACLsCertificates RevisitedDecentralized User Authentication in a Global File SystemCS294-4 PresentationNikita BorisovOctober 6, 2003Goals•Authenticate users to access the file system•Support remote administrative domains•Use only local information at access time•Avoid certificatesWhy not certificates?•Complicated infrastructure•Certificate chain hard to compute (e.g. SDSI)•Or inflexible trust structure (e.g. VeriSign)•Overkill for a file system?SFS Servers•Each server has a public key•Key part of the name (“self-certifying”)–mit.edu,anb726muxau6phtk3zu3nq4n463mwn9a•Use key to authenticate server and set up a secure connection–Connection provides confidentiality & integritySelf-Certifying Names•Public keys are explicit–Always together with the name•No PKI necessary–Avoids organizational and technical issues•Keys are obtained out-of-band–Perhaps falling back on peopleAuthentication Servers•One server per administrative domain–Identified by self-certifying hostname•Authenticate users–Unix passwords, public keys, SRP, …•Manage local names and groups•Export user and group records to remote serversGroups•Defined within an administrative domain•Has a list of members and a list of owners•Each user may define their own groups–E.g. alice.friends•Members/owners can be remote or localGroup membersMember type ExampleLocal user U=nikitabLocal group G=nikitab.friendsRemote user [email protected],wxyweq…Remote group [email protected],r34qduk…Public key P=d43dft5tr50lkxsdre42…Group members•Local users & groups–As defined by the authentication server•Public key hashes–Allow ad-hoc users–Protect privacy•Remote users & groups–Retrieved from remote servers–Authenticity protected by self-certifying nameGroup Caching•Group definitions may be distributed on many servers•Each authentication server resolves and caches entire group membership•Cache ensures all necessary information is locally available at time of access–Though it may be out of dateResolving Membership•Expand group names•Query remote servers for group & user definitions•Recursively query any new remote names•Cache updated every hour•Use version numbers to send deltasProblems•Freshness–Eventual consistency–Use out-of-date data for an hour–Longer if server unavailable•Revocation–Easy to revoke users (with a delay of 1 hour)–Hard to revoke server keysScalability•All relevant group members cached on local server•[email protected] may be large•[email protected] wouldn’t work–It would work with certificates•Limit members to 1,000,000 to prevent DOS•Most sharing groups are small–C.f. Athena at MITACLs•Each file and directory has an ACL–Stored in first 512 bytes•Lists local users and groups and access rights–Read, write, modify ACL•Remote names and public keys have to be indirected through a group–Save on space–Easier to change membershipCertificates Revisited•What did we lose?–Human-readable namespace–Key management/revocation–Offline operation–Scalability•Are these not important for a global
View Full Document
Unlocking...