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

Thomas Roessler <tlr@w3.org> Wed, 15 June 2011 13:44 UTC

Return-Path: <tlr@w3.org>
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 9EDA511E8145; Wed, 15 Jun 2011 06:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8]
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 f1qGXV3OW28X; Wed, 15 Jun 2011 06:44:26 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E911E8126; Wed, 15 Jun 2011 06:44:25 -0700 (PDT)
Received: from [88.207.143.141] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <tlr@w3.org>) id 1QWqOO-0002p8-OV; Wed, 15 Jun 2011 09:44:25 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Thomas Roessler <tlr@w3.org>
In-Reply-To: <BANLkTi=seeFm0F0TFoA9__uERg_F1L37Tg@mail.gmail.com>
Date: Wed, 15 Jun 2011 15:44:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3C31DB7-6AAA-4EF0-BA5F-BBE7C7EA6EEA@w3.org>
References: <trg0YszL9F4Q.471l1SVV@smtp.o2.co.uk> <BANLkTi=seeFm0F0TFoA9__uERg_F1L37Tg@mail.gmail.com>
To: "KIHARA, Boku" <bkihara.l@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org
Subject: Re: [websec] Fwd: [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: Wed, 15 Jun 2011 13:44:26 -0000

Make that public-identity@w3.org, not public-identity-request@w3.org. ;)
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)




On 2011-06-15, at 15:42 , KIHARA, Boku wrote:

> Missing Ccs? Forwarding:
> 
> ---------- Forwarded message ----------
> From: David S. Misell MBCS CISSP <07710380044@o2.co.uk>
> Date: 2011/6/15
> Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF
> To: "KIHARA, Boku" <bkihara.l@gmail.com>
> 
> 
> One time passwords should still be OK for poor auth methods, There is
> a series of SecurID based RFCs
> Kind Regards
> dave
> 
> -original message-
> Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF
> From: "KIHARA, Boku" <bkihara.l@gmail.com>
> Date: 15/06/2011 10:45 am
> 
> 2011/6/14 Peter Gutmann <pgut001@cs.auckland.ac.nz>:
>> 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.
> 
> To make the goal clear, let's list what kind of authentication methods
> should be avoided. One item is methods that hand over passwords,
> mentioned by Peter. Let me add methods whose UI can be imitated and
> the result can be forged by malicious sites. Like a padlock icon that
> insists the session is secured by TLS inside content area, Is a _secure_
> authentication method inside content area truly reliable?
> 
> * a method that hands over a password (or a password-equivalent)
> * a method whose UI can be imitated by malicious sites.
> 
> Of course there might be more items, please append.
> 
> # Peter, sorry for missing Ccs.
> 
> --
> KIHARA, Boku
> 
> 2011/6/14 Peter Gutmann <pgut001@cs.auckland.ac.nz>:
>> 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.
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>