210 likes | 294 Views
Limited Delegation for Client-Side SSL. Nick Santos and Sean W. Smith Dartmouth College. 6 th Annual PKI R&D Workshop April 18, 2007. Worse Than Failure (doubles as a database of usability lessons). From http://worsethanfailure.com/Articles/Twice_Annual_About_Security.aspx.
E N D
Limited Delegation for Client-Side SSL Nick Santos and Sean W. Smith Dartmouth College 6th Annual PKI R&D Workshop April 18, 2007
Worse Than Failure(doubles as a database of usability lessons) From http://worsethanfailure.com/Articles/Twice_Annual_About_Security.aspx
But sharing passwords is a great use case! Sean Smith says: • It’s not about who you are. • It’s not about what you know. • It’s about who sent you! “Sharing passwords” might as well be called “user-to-user delegation of a well-defined set of privileges via a shared secret”
Who Understands User-to-User Delegation? • Lawyers • Doctors and Nurses • Most Democracies • Managers and Secretaries • H&R Block • Anyone who has ever gone on vacation • Teenage babysitters everywhere And Who Doesn’t? • Traditional PKI
A Belated Summary of This Talk Three Major Questions We Want to Think About: • How important is user-to-user delegation for a usable PKI? • How could this feature complicate (and enhance) a PKI implementation? • How feasible would it be to build and deploy such a feature?
The Experiment To help give us insight into some of these questions, we built a bunch o’ stuff for client-side SSL: • Limited delegation using proxy certificates • …with a user interface • …for use with Mozilla Firefox and an Apache web server • …as part of a deployable browser-extension with a corresponding server plug-in
Proxy Certificates • Easy implementation on top of X.509 • (all we do is add a ProxyCertInfo extension) With traditional X.509, the chain must end here Here, Charlie has access to Alice’s hay
What else can we do with delegation?Multiple Identities! Yolanda Zeke Alice Xavier Bob(with identities A, X, Y, Z) If people are delegating access willy-nilly, maybe we should let Bob speak on behalf of multiple people at once?
Modified Client-Side SSL (There’s more to it than just updating cert-validation code!) The standard… …and non-standard, with multiple identities
Firefox Alice willuse her web browser to issue proxy certificatesBob willuse his web browser to manage his proxy certificatesA point to ponder:how does Alice give Bob the proxy certificate she issued?
Apache The Server willsend a list of “privileges” that it supports—to Alice, in a cookieAlice willchoose a subset of this list of privileges to delegate to BobBob willpresent one or more certificate chains to The Server in an SSL session
User Flow Service providers use cookies to tell Alice what “permissions” they support.
User Flow By the proxy cert standard, I shouldn’t be creating proxy certs for pre-existing private keys. But it’s so much easier to ignore this!
User Flow Teaching NSS to read and write proxy certificates: Easy!
User Flow Teaching NSS to store proxy certificates without blowing up: Really hard!
User Flow Thanks to XPCOM, we can dynamically (at run-time) unload Firefox’s SSL handlers, and load our own in their place. So we can enable/disable delegation as needed.
Conclusions • Firefox and Apache, with their dynamically loaded modules, are well-architected to deploy such a system • Delegation does complicate PKI implementations, especially if you want limited privileges and multiple identities • How hard will it be to teach users how to delegate their PKI credentials? We still have no idea!
Thanks Thanks to our friends at the Dartmouth College PKI Lab, Doug McIlroy, Michael Fromberger, our PKI07 Reviewers, and the National Science Foundation