Improving Web Security: AJAX + GSS/SAML/other authentication + channel binding to TLS


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:

  1. 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),
  2. bind this authentication to the TLS sessions used between the client and the server,
  3. 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:

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:

  1. The user visits an http:// URL (no https; using https is OK, but it requires a server cert valid to some trust anchor).
  2. 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.
  3. 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).


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


Post a Comment:
Comments are closed for this entry.

I'm an engineer at Oracle (erstwhile Sun), where I've been since 2002, working on Sun_SSH, Solaris Kerberos, Active Directory interoperability, Lustre, and misc. other things.


« September 2016