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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 14 June 2011 04:59 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9801F0C8C; Mon, 13 Jun 2011 21:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 tVokf5x1+QYJ; Mon, 13 Jun 2011 21:59:57 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8401F0C82; Mon, 13 Jun 2011 21:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1308027597; x=1339563597; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20hallam@gmail.com,=20julian.reschke@gmx.de|Subject: =20Re:=20[saag]=20[websec]=20[http-auth]=20re-call=20for =20IETF=20http-auth=20BoF|Cc:=20http-auth@ietf.org,=20pub lic-identity@w3.org,=20saag@ietf.org,=0D=0A=20=20=20=20we bsec@ietf.org|In-Reply-To:=20<BANLkTi=3D9TZU=3DpguCGhLHY+ =3DGbCNjR6w-dA@mail.gmail.com>|Message-Id:=20<E1QWLjG-000 7nd-EG@login01.fos.auckland.ac.nz>|Date:=20Tue,=2014=20Ju n=202011=2016:59:54=20+1200; bh=MuLKPw/XGt8/FxbjsT18BBlz9z5+VlWKDD31mvISxRs=; b=u8GyTUUZJnA+n4/Ubigmdb/xyqPe90Y+FrYU/aJN5u/o6DVEqGIHpvih zIKzySVlGGNfODw9OzvHpF9/bZ6BqGiQ8ELacqPQZQc+A5qdYyDa8B4W0 8J9sGPdoNSynDqAsmF2ubibn1qSVKQs1s5hLA9of67BBx49E4wPl+hzjx g=;
X-IronPort-AV: E=Sophos;i="4.65,362,1304251200"; d="scan'208";a="67285743"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jun 2011 16:59:54 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QWLjG-0004Wb-Hf; Tue, 14 Jun 2011 16:59:54 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QWLjG-0007nd-EG; Tue, 14 Jun 2011 16:59:54 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: hallam@gmail.com, julian.reschke@gmx.de
In-Reply-To: <BANLkTi=9TZU=pguCGhLHY+=GbCNjR6w-dA@mail.gmail.com>
Message-Id: <E1QWLjG-0007nd-EG@login01.fos.auckland.ac.nz>
Date: Tue, 14 Jun 2011 16:59:54 +1200
X-Mailman-Approved-At: Tue, 14 Jun 2011 01:10:40 -0700
Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org
Subject: Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 04:59:59 -0000

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.

The only permitted auth.form should be a dynamic, cryptographic mutual auth. 
that authenticates both the client and the server.  There are endless designs 
for this sort of thing around so the precise form isn't too important, as long 
as it's not hand-over-the-password.

Peter.