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

Dave Cridland <dave@cridland.net> Mon, 13 December 2010 10:24 UTC

Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A64D28C0E3; Mon, 13 Dec 2010 02:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYtbAzJLozZ9; Mon, 13 Dec 2010 02:24:25 -0800 (PST)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 7F1B33A6D7A; Mon, 13 Dec 2010 02:24:24 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 2834911680FB; Mon, 13 Dec 2010 10:26:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718q9D-RRrSU; Mon, 13 Dec 2010 10:25:53 +0000 (GMT)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EDEAF1168110; Mon, 13 Dec 2010 10:25:52 +0000 (GMT)
References: <4D02AF81.6000907@stpeter.im> <p06240809c928635499e8@[10.20.30.150]> <ADDEC353-8DE6-408C-BC75-A50B795E2F6C@checkpoint.com> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <A23730A9-728B-4533-96D7-0B62496CC98A@checkpoint.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com>
In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com>
MIME-Version: 1.0
Message-Id: <2229.1292235952.971571@puncture>
Date: Mon, 13 Dec 2010 10:25:52 +0000
From: Dave Cridland <dave@cridland.net>
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>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Dec 2010 10:24:26 -0000

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