Improving Web Security: AJAX + GSS/SAML/other authentication + channel binding to TLS
Authentication
Leif Johansson has a couple of Internet-Drafts (proposals for RFCs) [1][2] that would provide for a novel way to deal with authentication in web applications. This is all related to Sam Hartman’s Internet-Draft on dealing with phishing. The idea in Leif’s I-Ds is to:
- provide a way to do multi-round-trip user/server authentication over HTTP 1.0 (and 1.1), starting with the GSS-API (but applicable to SAML profiles and other schemes),
- bind this authentication to the TLS sessions used between the client and the server,
- and use cookies to bind all those sessions together with the same authentication event.
Imagine that you have multiple identities, which you may have enrolled for in a variety of ways (such as at a brick&mortar location, or online via another identiy (e.g., via your ISP), or online much like when you sign up for free e-mail accounts.
Now imagine that you can authenticate these identities using a strong network authentication mechanism (say, Kerberos V), so you don’t have to type passwords into forms anymore. And imagine that there are authentication federations, so that you can use one identity in many places without having to expose your passwords to many servers. Lastly, imagine that you can authenticate to some website using an HTTP URL (as opposed to HTTPS) and that immediately you’re redirected to the HTTPS URL for the same without having to click through the “give your money away to the nice attacker?” dialog box. Oh, and one more thing: this happens with some website designer UI control.
And all that with protection against MITMs, without necessarily depending on DNSSEC, nor on a true PKI.
That’s what we’re talking about here.
The components of this are, then:
- a specification for user<->server mutual authentication that works over HTTP 1.0 with no extensions to HTTP (Leif has one for using the GSS-API);
- a specification for binding authentication to TLS (Leif’s also, based on );
- applicable security mechanisms, such as Kerberos V, DIGEST-MD5, and many others;
- XMLHttpRequest extensions for providing website designers with some (constrained) control over authentication UI.
The XMLHttpRequest extensions I have in mind are, roughly:
- a method for requesting GSS-API (or other) authentication with a given {mechanism,
identity, [federation]} tuple as an argument; - a method for requesting GSS-API auth but with the browser displaying
an identity selection dialog or, better yet, with a DOM object
representing where on the page the browser should prompt for identity
(but the browser should not make its UI elements for this available to
the calling script via the DOM, so there’s no way to leak the set of identities the user has to any script on the page);
When either of these methods is used the browser will then do the HTTP_S_+GSS+channel binding dance,
even if the page where the script is running came from HTTP_not_S.
And then it will, for the length of the session, accept the server’s
certificate as valid for the server’s name from the URL being fetched
(which, while we’re at it, must not be cacheable).
The script should set a cookie when the XMLHttpRequest succeeds —
we can’t be doing the HTTPS+GSS+cb dance for every URL, just once a
session, thank you (or until the cookie expires).
We’ll want another host object to help with online enrollment. This
object/class (prototype) should have a method to set the credentials
for a {mechanism, federation, identity} tuple. When this method is
called the user should be prompted in browser chrome as to whether to
accept this credential, and whether to accept it only for this host,
this session, whatever.
Putting it all together:
- The user visits an http:// URL (no https; using https is OK, but it
requires a server cert valid to some trust anchor). - The page a that site loads a script that uses an XMLHttpRequest
object to do GSS+channel binding, authenticating the user to the site, the server
to the client, and binding the server’s cert to this authentication.
The script will set a secure only cookie for fast user
re-authentication and it will ensure that the selected ID is remember
subsequently. - The UI will look like this: there will be an “authenticate” button,
and maybe an “authenticate as…” button — click there and it all
goes. But also there will be another kind of lock icon to go with the
TLS one, or perhaps a different shape and color for the existing one,
to indicate that stronger authentication has been done (we want users
to want this).
Enrollment
So you travel and sometimes use kiosks or other people’s ‘puters.Which means you may not have your long-lived credentials with you. All you have
then are plain old username+password credentials, and, perhaps, the ability to use your cell phone. So you do
traditional username+password (preferably a temporary one obtained via your cell phone) form authentication, and a script
enrolls new GSS creds for you and your browser. But there may be a
field in the HTML form for limiting the lifetime of the resulting
credentials (described, perhaps, as a session?).
When you enroll for an identity for the first time there’d be no
username+password, just captchas/whatever, of course.
Actually, this too might be a good candidate for design as a new
method of XMLHttpRequest…
So we can’t get rid of passwords in all circumstances —
preferably you could carry your non-password credentials on a token, but
we’ll assume you can’t. But perhaps we can get the number of
passwords you need to remember down to a manageable few, corresponding
to how many federations you have identities in.
I think some parts of this might be very easy to prototype with
Mozilla, particularly if we stick to building only extensions to the
XMLHttpRequest object (then we don’t have to learn how to write
plug-ins, new host objects, etc…).