Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF

Yutaka OIWA <y.oiwa@aist.go.jp> Tue, 14 June 2011 22:46 UTC

Return-Path: <yutaka-oiwa-aist-temp@g.oiwa.jp>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E611E8144 for <http-auth@ietfa.amsl.com>; Tue, 14 Jun 2011 15:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.943
X-Spam-Level:
X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd4I2+QjZNga for <http-auth@ietfa.amsl.com>; Tue, 14 Jun 2011 15:46:34 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5A6611E811E for <http-auth@ietf.org>; Tue, 14 Jun 2011 15:46:33 -0700 (PDT)
Received: by gxk19 with SMTP id 19so5204123gxk.31 for <http-auth@ietf.org>; Tue, 14 Jun 2011 15:46:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.29.2 with SMTP id g2mr39986ybj.109.1308091593279; Tue, 14 Jun 2011 15:46:33 -0700 (PDT)
Sender: yutaka@g.oiwa.jp
X-Google-Sender-Delegation: yutaka@g.oiwa.jp
Received: by 10.151.103.4 with HTTP; Tue, 14 Jun 2011 15:46:33 -0700 (PDT)
In-Reply-To: <BANLkTimT=_qyi5vNoe0tqw8od6mWsjfuzA@mail.gmail.com>
References: <BANLkTi=9TZU=pguCGhLHY+=GbCNjR6w-dA@mail.gmail.com> <E1QWLjG-0007nd-EG@login01.fos.auckland.ac.nz> <BANLkTimT=_qyi5vNoe0tqw8od6mWsjfuzA@mail.gmail.com>
Date: Wed, 15 Jun 2011 07:46:33 +0900
X-Google-Sender-Auth: bIWuwIZskZKs0zlP1QWrp3ZCdaY
Message-ID: <BANLkTi=PTXc_VxFsyyUB75X3=fH1ymPYTQ@mail.gmail.com>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: public-identity@w3.org, http-auth@ietf.org
Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 22:46:34 -0000

2011/6/15 Nico Williams <nico@cryptonector.com>:
> On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann
> <pgut001@cs.auckland.ac.nz> wrote:
>> Phillip Hallam-Baker <hallam@gmail.com> writes:
>>>what would we want HTTP authentication to look like?
>>
>> I have a suggestion for what it shouldn't look like: Any method that hands
>> over the password (or a password-equivalent like a password in hashed form) as
>> current browsers do should be banned outright, and anyone who implements
>> hand-over-the-password should killed and eaten to prevent them from passing on
>> the genes.
>
> +1.

+1, although the original statement is a bit too strong in wording for me :-)

>  - Is this to be done in TLS?  HTTP?  Or at the application-layer?
>
> IMO: TLS is too low a layer to do authentication in, and doing it in
> HTTP would require retrofitting too many HTTP stacks.  Doing it at the
> application layer has a number of advantages.

IMO, I agree that TLS is too low.
However, although the application layer use-case exists,
I believe that for general use cases HTTP-auth layer is more appropriate,
because the trust relationship becomes much simpler.

Backward-compatibility is important, and all intermediates *should* and
*in most cases will* work well with new http authentication
that completely complies with existing HTTP auth framework design.
All they've needed is just forward auth-related headers to the origin server.
We've done some experiment around my proposal,
and it worked quite well with all existing stacks,
including proxies, "SSL accelerators" and load balancers.
(Yes, we've carefully designed the protocol so that it can work in this way.)
Do you need some more detail on it?

Required code modification is almost the same magnitude in both cases,
because we need to change the client, and to add some server-side thing.
we can keep all other intermediates as it is.
Some client-side change is necessary in both cases to make mutual
authentication trustful and unforgeable.
In server-side, http-layer authentication can be implemented in either
in the server or in the application.