Re: [ietf-http-auth] HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim?

On Thu, Dec 24, 2009 at 12:28 PM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> Dear people on IETF apps-discuss/public-web-security mailing lists
> and other related lists,
>
> I would like to introduce our proposal on HTTP mutual authentication.
>
>  (I directed the Reply-to: header to the newly-created
>  public-web-security mailing list, but I also welcome private replies
>  or those to other lists.)
>
> Our proposal brings a strong, password-based mutual authentication
> to the HTTP authentication protocol.
> Our aims are to overcome several deficiencies (both for security and usability)
> on current HTTP authentication mechanisms, and to replace weak form-based
> authentication, which are used in most current Web apps, with
> stronger HTTP protocol-supported authentications.
> We designed the protocol so that (a) it removes any threats related to
> password/secret stealing like phishing or other attacks, (b) it will be
> extremely easy-to-use, and (c) it can accept many Web applications
> which were not well-supported with current HTTP authentication
> architecture (in RFC 2617).
> We believe that this is a correct direction for the future of
> the Web application authentication.
>
> Our proposed draft spec is available from
>   <http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05>.

A few comments (in random order):

Why introduce the Optional-WWW-Authenticate? why not just use a
WWW-Authenticate header in non-401 responses?
See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78#comment:4

Figure 2 talks about a 200-opt-B0 response which isn't defined
anywhere (200-Optional-B0 is defined in section 12, why not define it
in section 4, even if it just points to the "full definition" in
section 12, but it would make the spec much more easy to follow)

In the next version of draft-broyer-http-cookie-auth (and as already
briefly discussed in ietf-http-wg and ieth-http-auth), I'm going to
propose the addition of a new status code (308, Unauthorized, See
Other), which seems to be equivalent to your proposed
"Authentication-Control: Mutual location-when-unauthenticated=xxxx"
(you'd use a 308 with a WWW-Authenticate response header, just like a
401 but with a Location header).
Why did you chose this approach instead of introducing a new status code?
The main difference seems to be that if a client doesn't support
Authentication-Control (or the auth-scheme it contains) it'll present
the 401 response body to the user (or whichever equivalent behavior
for non-browser UAs), whereas if the client doesn't support the 308
status code (whichever the auth-scheme), it should per HTTP follow the
redirect (in practice unfortunately browsers don't do that and just
present the response body, so you'd have to include a <meta refresh>
and/or some script to make sure the user is redirected to the login
form).


Otherwise, this "Mutual Authentication Protocol for HTTP" looks good
and far more secure than cookie-based solutions used nowadays (I'm far
from being a security expert though). My main concern is that it needs
browsers to explicitly implement it, which makes it unusable in the
short term (I don't know if it's possible to plug new auth-schemes
into Internet Explorer, but if it's not, then it'll be unusable in the
*long* term too, at least on the Web), except if used in addition with
another auth-scheme, such as Basic, Digest or the Cookie scheme I'm
proposing (which has the great advantage of working seamlessly in
non-implementing browsers, with the only (known) exception of Opera
versions before Opera 10.00).
Browsers implementing Mutual-auth would choose it as it is more secure
than those other schemes (well, I actually cannot judge, but that's
what you're saying ;-) ), and others would fallback to the alternate
auth-scheme. You'd however have to do extensive testing to determine
the recommended order of the WWW-Authenticate headers (IIRC some
browsers only look at the first WWW-Authenticate header, so some of
them could use the alternate auth-scheme instead of Mutual and others
fail to authenticate altogether)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Received on Monday, 4 January 2010 10:27:02 UTC