- From: Dave Cridland <dave@cridland.net>
- Date: Mon, 13 Dec 2010 11:23:04 +0000
- 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. -- 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