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

Dear Nico,

Thank you for very prompt comment.

On 2011/06/15 8:47, Nico Williams wrote:
>>> +1.
>>
>> +1, although the original statement is a bit too strong in wording for me :-)
>
> Why?

Oh, just don't mind it in any technical way.
I just didn't prefer the wording like killing or eating people or technologies
and I have hesitated to put just "+1" with such things :-)
Another factor possibly in my mind at that moment were that I personally expect
the future transition to be more gradually, and I imagine the transition in some
form of "gradually cease to exist", rather than "stop and go another way".
Except for those trivial points, I agree that we should let people move to
technologies not relying to handing over the "reusable raw authentication
tokens", (including passwords, Digest password hashes, private keys and other
tokens) to authenticators.

>> IMO, I agree that TLS is too low.
>> However, although the application layer use-case exists,
>> I believe that for general use cases HTTP-auth layer is more appropriate,
>> because the trust relationship becomes much simpler.
>
> Can you explain what you mean by "the trust relationship becomes much simpler"?

OK.  I'll be happy if you can treat the following comments as possible
improvements proposal rather than critics.

I like your proposal very much, especially for using it for replacing current
authentications for internal communications initiated by script-based Web
applications. It seems to be well designed, have enough flexibility (including
introduction of mutually-authenticating underlying mechanisms) and useful
semantics.  You've mentioned in the draft that it can be implemented by client
scripts, although browser support is preferred, and it can really improve the
security of such applications.  Maybe this is one of the reasons why Sam Hartman
proposed abfab WG for possible discussion place.

However, I have a concern in directly using it for improving the security of Web
pages, e.g. against Phishing, which is the assumed use case of our proposal.
But before entering to the main topic, I want firstly to discuss some web-page
security model.

The current model of Web page security is top-to-down hierarchal model. The
topmost page, for which the address bar displays its location, must be secure:
it must be careful not to refer any malicious external contents including
images, applets and scripts, and all forms in that page must post to "trustful"
servers. Not to have any XSS vulnerability is needless to say.  And,
importantly, this is the *necessary and sufficient* requirements for that page.
 As top-to-down, each scripts and other contents included from that page has the
same requirements as necessary and sufficient conditions, too.  Assuming this,
all that users have to do is to think about whether the first page is trustful
or not. And it is almost what they can do at most, with existence of client-side
scripting.  Phishing pages make this top trust checking difficult for users.

Web-page mutual authentication will ensure the trust of this top page in effect.
Carefully reading our draft, you may find that the user-agents are allowed to
accept only new authentication requested by the top-most pages and ignore
others, and the result from the top-page authentication must be displayed.
Authentication algorithms are limited to those which provide equally-or-more
cryptographically secure authentication, it provides mandatory binding to the
originating host to prevent any forwarding, and authentication always happens
within the same top-page URL and nothing else, as usual http auth does. These
conditions are enough for browsers to trust authentication for the "whole"
displayed page, when the above security model is assumed.

In this perspective, your proposal seems to be currently too generic and too
flexible for this specific purpose. Initiating authentication from the
application layer makes more involvement of application-level contents,
including iframe, XMLHTTP and others. The browser must be careful not to display
any authentication results from any contents which are included by Phishing
servers, or from authentication requests forwarded to genuine servers.  Also,
the GSS-REST login process involves several URLs, which brings it complicates to
the security model and possible exploit points.

To this purpose, if we're going to use your GSS-REST proposal for securing
Web pages, I think we need to carefully define some subset "profile" which we
can trust for this specific purpose, and do analysis of it against the security
model.  For example, it should limit the underlying GSS mechanisms to use, it
should limit what resource can request new authentication to users, which set
of URLs can be accepted for GSS-login, and in which set of URLs the created
session URL can be, and for which resource the corresponding authentication
result will be shown in UI.  I found some good phrases in your security
considerations section, but I think we need even more.

I cannot judge whether this kind of restrictions increase or reduce the value of
your proposal, because it sacrifices its good properties of flexibility a lot
and introduces more complexities. If you're interested to go in this way, I'll
be happy in collaboration to discuss what properties are really required for
such a "profile".

> But let's say that the semantics and implementation and deployment
> considerations authentication at either layer are fully equivalent to
> those of authentication at the other layer...

I agree that HTTP auth and application auth have some duality in general.
Also, with above restricted "profile", I agree that those two approaches are, in
some sense, in duality.  I personally think, at this moment, both proposals have
some non-overwraping good use cases and is worth to go on both of them, rather
than choosing one.

I'd like, at this moment, firstly to investigate to define what kind of abstract
properties are required for web authentications, considering for several use
cases. The short-term goal of mine is to improve our problem statement document
to discuss at Quebec and further.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Wednesday, 15 June 2011 07:48:47 UTC