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

On Wed, Jun 15, 2011 at 2:48 AM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> On 2011/06/15 8:47, Nico Williams wrote:
>>> 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.

I don't recall Sam proposing that.

As for my comment about scripts, it was in reference to demonstration:
by having authentication at the application layer it's trivial to
demonstrate the protocol without platform nor browser integration (if
we have JS crypto).  But I don't believe in trusted scripts, so the
script comment is limited to demonstration.

> 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.

Do you agree that to defeat phishing (a subset of phishing anyways) we
need: mutual authentication and channel binding?

If not, what else do you think we need?  Or what do we need instead?

> 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.

I don't agree that that is necessary and sufficient.

Consider a phishing attack where a user is directed to a domain that
is confusable with one that the user trusts.  And imagine that the
malicious domain's servers have valid server certificates.  The
requirements you list above will not help the user detect such
malicious services.

Moreover, external contents, including scripts, is definitely allowed
to be referred to from pages -- it certainly happens all the time

>  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.

I don't think external content is at the root of phishing.

> Web-page mutual authentication will ensure the trust of this top page in effect.

OK, so you agree that mutual authentication is part of this.

> 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.

I don't find that at all.  What makes you believe that's the case?

And in any case, the problem is bound to be the same for HTTP-layer
authentication -- after all, HTTP can't possibly know that some
resource you're fetching is related to some other resource you've
already fetched.  The application has to be in charge of deciding when
authentication is required, and the application has to use
authentication whenever it's advisable.

A browser should use authentication for a page and all contents
referenced from it once the user initiated a login.  If a secure page
references external contents then the user agent has to be able to
authenticate the services offering that content.  There's no way that
HTTP can automatically do this for the user agent.

> Authentication algorithms are limited to those which provide equally-or-more
> cryptographically secure authentication, it provides mandatory binding to the

Equal to or more than... what?

> 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.

Remember too that HTTP is used for things that aren't web pages, that
aren't HTML.

> 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.

No, I think you've misunderstood.  My proposal is just a protocol,
browser UI elements (but only for browsers), and XMLHttpRequest
extensions.  The browser will have to get the UI elements right,
particularly in the case of frames.  Clearly frames and clickjacking
complicate the situation _for the browser_, but not for the
authentication _protocol_.  The URLs used by REST-GSS are not visible
to the user; they complicate nothing.

> 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 just started on it.  The Security Considerations section, and the
section on UIs needs more work, clearly.  But there's nothing here
that's going to be particularly different than for HTTP-layer
authentication.  Or perhaps you can show me how you'd handle these
problems in HTTP without addressing them in the application (I don't
think you can, but maybe I'm simply not creative enough to see what
should be obvious to me).

> 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".

Thanks.  I think this is a sort of collaboration already, since we're
actually going through these issues.

>> 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 to see more about those use cases for which only HTTP-layer
authentication works well or at all.

> 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.

Let's keep a few things clear too.  There's properties of the
authentication _protocol_, and properties of the _UIs_ (and APIs).  We
must address both, but they are not the same thing.

Here's a start:

0) We need to distinguish between "secure page" as in "we used TLS"
and "secure page" as in "we're logged in (and we used TLS)".  For this
we'll need new terminology.

1) Required properties of authentication protocols:

1a) mutual authentication;
1b) channel binding (because TLS is here to stay);
1c) must have a notion of login session.

2) Desired properties for authentication protocols:

2a) support for enterprise and Internet-scale authentication mechanisms;
2b) federation.

3) Required properties for _browser UIs_:

3a) must have a non-confusable trust path (e.g., browser chrome,
secure attention sequences, particularly when full-screen apps are
involved);
3b) must make clear to the user what page elements are authenticated
OR must not mix authenticated and non-authenticated contents (this
principle addresses the iframe issue, for example);
3c) non-external content references from logged in pages must be
obtained using the same logged in session;
3d) external content references from logged in pages either must be
disallowed or must require some clue from the page origin as to what
to do with them (authenticate? use TLS and here's the external
references' servers' TLS certs?);
3e) the UI must allow the user to distinguish between "secure" as in
"used TLS with server certs" and "secure" as in "logged in (and used
TLS)";
3f) the UI must allow the user to see the authenticated names of the
user and service.

4) Required properties for JavaScript APIs:

4a) the user agent must not expose all or any of the names of the
user's credentials to the calling script;
4b) the user agent must not allow the calling script to authenticate
to a different server than the one to which the authentication
messages are ostensibly being sent, otherwise the script could abuse
the user's credentials to login by proxy to other sites and gain
control of those new sessions;
4c) ...

What have I missed?  (Keep in mind it's the middle of the night for
me, so I'm sure I missed quite a few things.)  Most of the above I
either referred to explicitly in my presentation and I-D, or obliquely
for lack of time.

Thanks for you comments, particularly for elaborating on your trust
issue.  I don't believe the trust issue is germane to the
authentication protocol, but it is germane to how the user agent uses
authentication, and to the user agent UIs.

Nico
--

Received on Wednesday, 15 June 2011 08:49:30 UTC