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

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

From: KIHARA, Boku <bkihara.l@gmail.com>
Date: Wed, 15 Jun 2011 18:44:37 +0900
Message-ID: <BANLkTikQ_FHo3_A8fNSDzzGk_puQwDKzTA@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, http-auth@ietf.org
Cc: public-identity@w3.org, websec@ietf.org, saag@ietf.org
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
>
Received on Wednesday, 15 June 2011 09:45:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 June 2011 09:45:05 GMT