SDSI and namingCS380L: Mike DahlinNovember 24, 2004Our system is ’key-centric’: SDSI principals are public digital signature verification keys.Rivest and Lampson1 Preliminaries1.1 Review1.2 Outline• Naming problem• SDSI key ideas• A few implementation details• Self-verifying names1.3 Preview2 Naming: fundamental problem• symmetric key: “authentication server”– e.g., Kerberos, most BAN examples– Problem: authentication server must be on line– Problem: Single authentication server inappropriate for large-s cale system spanning ad-ministrative domains• Fundamental problem: naming– Which names correspond to which keys?• Public key infrastructure– Use public-key encryption: certificates binds name to public key∗ “certificate authority” with well-known public key rather than on-line authenticationserver with whom I share a secret key– Allow hierarchies of certificates∗ Note: though this is typically done with public key, there is no fundamental reasonhierarchies of authentication servers could not be constructed– e.g.,1∗ (Mike Dahlin Kdahlin)KUT∗ (University of Texas KUT)KV eriSign∗ “verisign vouches that KUTis the University of Texas’s public key and the unversityof texas vouches that Kdahlinis Mike Dahlin’s public key– Advantages:∗ Allows off-line CA∗ Allows complex hierarchies of trust– Key questions:∗ How do we know to trust verisign?∗ When should we trust UT to vouch for names (should you believe “foo.com vouchesfor KXis Microsoft’s public key”?)• Existing solutions– DNS – no security (yet)– ship root CA with binaries (e.g., browser ships with root keys for VeriSign, USPS, etc.)– non-hierarchical∗ ssh – first time you contact a new machine, you get to decide whether to accept bindingof name to key∗ pgp – similar (with some efforts to build “web of trust”)• Example of more general problem: which data correspond to name– If I can solve this problem for keys, I should be able to solve it for files, IP addresses, etc.– SFS, Freenet – files– Replace DNS’s administrative root (mechanism) with “anyone is a root” (policy)∗ Verisign is a source of names just like ICAAN∗ Research project: replace DNS with “anyone can be root”3 SDSIEditorial: one of the le ssons in operating system design is to make the interface actually reflect whatis really going on. E.g.,“An interface should capture the minimum essentials of an abstraction....the interface must notpromise more than the implementor knows how to deliver.” (B. Lampson “Hints for computer sys-tem design”) Examples in class: exokernel – export th hardware interface; active messages – highperformance messaging by making interface match what hardware really does; scheduler activations;...Key ideas:• principals are public keys– If you remember one thing, remember this– Much cleaner (imho) than traditional definition of naming∗ Traditionally: start with principals (users, machines, ...)∗ which keys belong to which principals?∗ bind key to a principal?2– SDSI: principals are keys (within the system nothing else makes sense)∗ Certificates are just opinions about names you might find convenient to use whenreferring to keys (principals)– This seems subtle, but until I read this paper, I never realized how broken the standardway is...• local name space– principal – global– name – local∗ “The principal you call alice-smith may be different from the principal I call alice-smith.”∗ Think of names as “local names” or “nicknames”– Everyone is a CA∗ natural – of course anyone can sign certificates, the question is how to interpret them...∗ Natural – anyone can generate a nickname for a principal∗ Interface reflects reality– linked local name space∗ Everyone is a CA and can generate nicknames∗ Anyone is welcome to use anyone else’s nicknames∗ syntactic sugar:· bob’s alice’s mother· verisign’s visa’s account-3402938402384· edu’s cmu’s cs’s search-committee’s chair∗ an explicit principal ID is a global name (albeit hard to remember)· explicit principal ID == public key (or in some systems cryptographic hash ofpublic key)· “[crypt/RSA-512] =ldkfli23u0934ndfli3248jl28dfh2l4098dsf=”’s bob· This case not em phasized in the SDSI paper, but it turns out to be a powerfulidea...∗ a few easy to remember global names· verisign!!· USPS!!· DNS!!· Highly desirable that these be standardized everywhere; but no mechanism to en-force this (Assert-Hash provides sanity check)∗ so really all names I see are (a) relative to “me”, (b) global, or (c) meaninglessMY bob’s alice’s mother· verisign!!’s visa’s account-234234802384· DNS!!’s edu’s cmu’s cs’s search-committee’s chair· “[crypt/RSA-512] =ldkfli23u0934ndfli3248jl28dfh2l4098dsf=”’s bob∗ Different names can refer to same principal· We can have different nicknames for different people· Verisign!!’s microsoft’s CEO· DNS!!’s com’s microsoft’s “Bill Gates”3• Group– convenient for describing access control∗ Define group in one step∗ Add group to ACL in another step∗ Simplify auditing – group can be given meaningful name– each group “owned” by a principal∗ DNS!!’s mit’s biology-department’s faculty∗ owning principal can issue signed statements “¡principal¿ is member of ¡group¿”• Role– 2 reasons for rolls∗ convenient for access control – make intentions more clear (e.g., e mail from “m ike asfaculty at UT” v. “mike as independent consultant”)∗ Support for “least privlege”(e.g., “mike as machine user” v. “mike as machine admin-istrator” v. “mike as running software I downloaded from who knows where on theweb”)∗ Note: least privlege roles talked about a lot but used less...psychological acceptability?– an individual may create a public key for each role he/she plays∗ faculty-role∗ mike-travel-key∗ “bob can sign statements as the principal I call bob or as the principal I call bob’sfaculty role. I can distinguish these cases, and recognize when Bob is acting in hisfaculty role as opposed to acting as bob.”– another strategy: create a group for each role (e.g., “¡principalX¿ is a member of hospital’shead-nurse”)– the two strategies differ in who controls who is acting in the role– also, “the second method has the slight disadvantage that the principal