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

["KIHARA, Boku" <[e-mail]>]

Missing Ccs? Forwarding:

---------- Forwarded message ----------
From: David S. Misell MBCS CISSP <[e-mail]>
Date: 2011/6/15
Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF
To: "KIHARA, Boku" <[e-mail]>


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" <[e-mail]>
Date: 15/06/2011 10:45 am

2011/6/14 Peter Gutmann <[e-mail]>:
> Phillip Hallam-Baker <[e-mail]> 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 <[e-mail]>:
> Phillip Hallam-Baker <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>
_______________________________________________
saag mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/saag