- From: Dave Cridland <dave@cridland.net>
- Date: Mon, 13 Dec 2010 10:25:52 +0000
- 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 UTC