W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

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

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 15 Jun 2011 15:44:21 +0200
Cc: Thomas Roessler <tlr@w3.org>, http-auth@ietf.org, websec@ietf.org, saag@ietf.org, public-identity@w3.org
Message-Id: <E3C31DB7-6AAA-4EF0-BA5F-BBE7C7EA6EEA@w3.org>
To: "KIHARA, Boku" <bkihara.l@gmail.com>
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
> 
Received on Wednesday, 15 June 2011 13:44:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 June 2011 13:44:32 GMT