W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF

From: Nico Williams <nico@cryptonector.com>
Date: Tue, 14 Jun 2011 11:17:02 -0500
Message-ID: <BANLkTimT=_qyi5vNoe0tqw8od6mWsjfuzA@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: hallam@gmail.com, julian.reschke@gmx.de, public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org
On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Phillip Hallam-Baker <hallam@gmail.com> writes:
>>what would we want HTTP authentication to look like?
> I have a suggestion for what it shouldn't look like: Any method that hands
> over the password (or a password-equivalent like a password in hashed form) as
> current browsers do should be banned outright, and anyone who implements
> hand-over-the-password should killed and eaten to prevent them from passing on
> the genes.


> The only permitted auth.form should be a dynamic, cryptographic mutual auth.
> that authenticates both the client and the server.  There are endless designs
> for this sort of thing around so the precise form isn't too important, as long
> as it's not hand-over-the-password.

+1, particularly with regard to mutual authentication.  It's important
to understand that we need mutual authentication using something other
than the TLS server cert PKI for authenticating the server.

Some aspects of the designs are important.

For example:

 - Is this to be done in TLS?  HTTP?  Or at the application-layer?

IMO: TLS is too low a layer to do authentication in, and doing it in
HTTP would require retrofitting too many HTTP stacks.  Doing it at the
application layer has a number of advantages.

 - Shall we have just one authentication mechanism?

IMO: We can't pick a universal authentication mechanism that will work
for everyone, but if it helps get momentum I'd be happy to specify
something where we start with one mechanism but nothing prevents us
from adding others later.

Here's an example showing how to use SCRAM (a successor to DIGEST-MD5,
thus not terribly interesting, but pretend for a second that this is a
ZKPP) at the application layer and in a RESTful way:

C->S: HTTP/1.1 POST /rest-gss-login
      Host: A.example
      Content-Type: application/rest-gss-login
      Content-Length: nnn


S->C: HTTP/1.1 201
      Location http://A.example/rest-gss-session-9d0af5f680d4ff46
      Content-Type: application/rest-gss-login
      Content-Length: nnn


C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46
      Host: A.example
      Content-Type: application/rest-gss-login
      Content-Length: nnn


S->C: HTTP/1.1 200
      Content-Type: application/rest-gss-login
      Content-Length: nnn


Does that work for you?

Received on Tuesday, 14 June 2011 16:17:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC