W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [kitten] [apps-discuss] [saag] HTTP authentication: the next generation

From: Dave Cridland <dave@cridland.net>
Date: Mon, 13 Dec 2010 11:23:04 +0000
Message-Id: <2229.1292239384.281779@puncture>
To: Adrien de Croy <adrien@qbik.com>, Yoav Nir <ynir@checkpoint.com>, General discussion of application-layer protocols <apps-discuss@ietf.org>, websec <websec@ietf.org>, Common Authentication Technologies - Next Generation <kitten@ietf.org>, "http-auth@ietf.org" <http-auth@ietf.org>, "saag@ietf.org" <saag@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Eliot Lear <lear@cisco.com>
On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote:
> for instance what would you propose for non-browsers, which perform  
> a large proportion of all HTTP transactions.
I agree a solution is needed for non-browsers (including IPP, for  
example). I disagree this needs to be, or should be, the same as a  
solution for web apps. I disagree that non-browser security is even a  
major priority at this point in time - it's adequately served by TLS  
and client certificates and/or Basic auth, depending on the security  
model desired - this latter I appreciate is a personal opinion.

However there is no doubt at all that current webapp deployments are  
in need of a serious improvement in security, given that these  
generally use TLS only during authentication itself, and use  
plaintext usernames and passwords for the authentication itself.

> Also, it seems like it would make the problem about a billion times  
> worse putting the auth into the application, where there are no  
> standards, and therefore it would need to be re-implemented for  
> each different application... kinda like what we have now already.

Yet every webapp currently uses a form, and it's so close a standard  
that browsers can, and do, spot login forms and allow the credentials  
to be cached. As such, I fail to see why we wouldn't want to place  
better authentication at that layer, where it's quite likely to be  
actually used.

> SASL is an orthogonal concept.  It's just a framework to negotiate  
> auth, whether that's over HTTP or something else.  So, it's a bit  
> of a red herring in this.

Right, that's fair enough.

> The trick is to get the application to actually use the auth of the  
> protocol.

Yes, but the problem is that existing, deployed, webapps could use  
Basic right now - they all just ask for a username and password after  
all. Yet none of them do, in part because of integration issues, but  
mostly I suspect due to usability and branding issues.

We could deploy some more advanced mechanisms in HTTP auth tomorrow,  
and nobody would use those either.

Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Received on Monday, 13 December 2010 11:23:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC