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.
- [websec] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [websec] re-call for IETF http-auth BoF Harry Halpin
- Re: [websec] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [websec] [http-auth] re-call for IETF http-au… Julian Reschke
- Re: [websec] [http-auth] re-call for IETF http-au… Phillip Hallam-Baker
- Re: [websec] [http-auth] re-call for IETF http-au… Alexey Melnikov
- Re: [websec] [saag] [http-auth] re-call for IETF … Peter Gutmann
- Re: [websec] [saag] [http-auth] re-call for IETF … Nico Williams
- Re: [websec] [saag] [http-auth] re-call for IETF … Stephen Farrell
- Re: [websec] [saag] [http-auth] re-call for IETF … KIHARA, Boku
- [websec] Fwd: [saag] [http-auth] re-call for IETF… KIHARA, Boku
- Re: [websec] Fwd: [saag] [http-auth] re-call for … Thomas Roessler
- Re: [websec] [saag] [http-auth] re-call for IETF … Yutaka OIWA
- Re: [websec] [saag] Fwd: [http-auth] re-call for … SHIMIZU, Kazuki
- Re: [websec] [saag] Fwd: [http-auth] re-call for … Yutaka OIWA
- Re: [websec] [http-auth] [saag] Fwd: re-call for … Yutaka OIWA
- Re: [websec] [saag] Fwd: [http-auth] re-call for … Marsh Ray
- Re: [websec] [saag] [http-auth] re-call for IETF … Thomas Fossati
- Re: [websec] [saag] [http-auth] re-call for IETF … Phillip Hallam-Baker