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

Alan DeKok <aland@deployingradius.com> Mon, 13 December 2010 14:15 UTC

Return-Path: <aland@deployingradius.com>
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 0275E3A6E96; Mon, 13 Dec 2010 06:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level:
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 G+DQnsAnEMXX; Mon, 13 Dec 2010 06:15:20 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 1E2D728C0E4; Mon, 13 Dec 2010 06:15:20 -0800 (PST)
Message-ID: <4D062AD8.4080805@deployingradius.com>
Date: Mon, 13 Dec 2010 15:16:56 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
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>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 13 Dec 2010 09:49:40 -0800
Cc: Eliot Lear <lear@cisco.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, websec <websec@ietf.org>, "kitten@ietf.org" <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>
Subject: Re: [apps-discuss] [saag] [kitten] 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 14:15:21 -0000

Yoav Nir wrote:
> Because I'd rather not implement too many mechanisms in my browser or in my web server.
> 
> And if EAP integrates better with RADIUS,

  It's more "already integrated with RADIUS", and "RADIUS integrates
with LDAP".

> while SASL integrates better with LDAP, it's still bad design to expose the server's backend to the client by the authentication protocol.

  EAP is already being transported over PPP, ethernet, RADIUS, Diameter,
and other transport/authentication protocols.  It's used because adding
it is easy, and it separates the authentication protocols from the
application.

  As for SASL, that's not my area.

  Alan DeKok.