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 10:25:52 +0000
Message-Id: <2229.1292235952.971571@puncture>
To: 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 Sun Dec 12 22:06:29 2010, Yoav Nir wrote:
> - It has to be integrated in the protocol, not the application

What?! No. It must be integrated in the application. If nothing else  
can be learnt, then learn this one thing - we have had Basic and  
Digest support in the protocol for years, but because they cannot  
easily be integrated into the application, no serious consumer  
applications use them, even though what they provide is never any  
better than Basic.

If I could wave a magic wand and have all my wishes come true, I'd  
embed SASL into the web browser such that:

- Users are presented with visually-distinct controls embedded into a  
web page for authentication, much like Extended Validation. Perhaps  
focussing them turns the address bar red or something.
- The SASL message exchanges happen over a WebSocket or equivalent  
low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I  
imagine a webbrowser gets given one or more URIs to use for  
communications).
- The result of this is a one-time password intializer.
- Subsequent requests and responses occur with traditional HTTP auth,  
using some OTP mechanism that requires only a single message.

The two parts of the protocol can, and should, be split - many  
existing websites use a cookie as the result of authentication, and  
having a more secure variant of this alone would be extremely useful.

Note that the key portion of this - embedded SASL - is not really  
HTTP auth at all, but a Web Application Auth - since that's really  
the other party to the authentication, it seems quite obvious to me  
that this should be the authenticating entity.


> - It has to be secure against phishing - if the attacker gets you  
> to authenticate, they can't later use that authentication to  
> connect to the real server
> - If the authentication succeeded, then (a) you typed your password  
> correctly, and (b) this is really the server
> 
> EAP has some methods that do this. SASL can probably be made to do  
> this, but with an extra layer.
> 
> 
SASL also has methods that will do this, I think - I'm not sure what  
additional layer you're referring to here.

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 10:26:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:34 GMT