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

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

From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Wed, 15 Jun 2011 23:24:58 +0900
Message-ID: <BANLkTinZ+G2w-ezkiOUCX9zScj4mGAx=SQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: public-identity@w3.org, http-auth@ietf.org
Dear Nico, (I'm sorry to you for duplicated posting as I forgot Cc)

I think that my point was not correctly explained to you.
I'm very sorry that my phrasing are understood in very opposite way.

2011/6/15 Nico Williams <nico@cryptonector.com>:

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

Yes, at least it is required.

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

You're correct, but my intention was different.

I guess you agree that Phishing is very different kinds of attack compared to
XSS, CSRF, SQL injection and many others.
Server admins and programmers can and must prevent XSS, CSRF, SQL injection
and others, but they cannot prevent Phishers from creating the Phishing site.
This is the first point.

Then, to prevent Phishing users, not the server owners, must notice that
Phishing is on going in some way.  Currently users must be very careful,
and mutual authentication can take this part. this is the second point.

Then, the third point is: the users must have to check only the validity of
the topmost page.  And all others are server's responsibility to correctly
refer all external information which requires.  In this way, my requirement
list is "what servers must do" and "what servers can do at most".
My intent for the "sufficient" was: means "all what they ought to do".

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

Yes, and if they are correctly referred to by the topmost page,
it is OK for users.
In anyway, the top-most page must be correctly written,
as users cannot check all subrequests the page has made.

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

I didn't said it...

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

Please see almost the last of section 8 "Decision procedure for client",
the paragraph starting from "The client software SHOULD...".
There is a special mention for interactive clients, which treats
sub-requests in a different way than the topmost document.

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

This is related to the second next question possibly...

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

...Than the currently-defined crypto algorithm.

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

Yes, and it is actually used in two very different ways.
One case is for subrequests, which are effectively part of the "Web page"
and it will typically require the same authentication (or none) as the topmost
page.  For this kind of contents, which is the first main target of
our proposal,
works quite well with our design, as it works for existing HTTP authentications.

The second use case is for application-issued requests (aka XMLHTTP request),
which has very application-specific semantics for authentication.
In this cases, it is better applications (in browser case, typically scripts
which is in or referred to by the topmost document) will determine how
they authenticate with resources.  For such purpose GSS-REST is really good,
OAuth also, and some people tends to use custom auth/authz
implementation by their own.  Our proposal, technically speaking,
can be used as an underlying protocol, but our design and requirements
for browsers are not considering this well, as this is not our main target.
And in this case, Phishing is not a main target for preventing
(the application typically knows which server to connect), but mutual
still gives a slight improvement for security, such as against transport-level
or TLS-level (such as a false certificate) attacks.

Another variant of the second case is completely non-Web applications
which uses HTTP as just underlying transport for various reasons
(simplicity, sharing code with the above second case, etc.)
I appreciate requests for supporting non-browser use cases, and I
really do it as a second target.
And it is actually much more trivial than supporting browsers.

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

Yes.  I have actually no doubt for the "a protocol" and "XMLHttpRequest" part.
My concern is only on the UI element part, which must be really
carefully designed
to prevent misunderstanding by users.

I think we do not need too much details on the some questions below, as
I believe that I can understand, mostly agree on your point and go productively.
so skipping...

> I'd like to see more about those use cases for which only HTTP-layer
> authentication works well or at all.

Technically we can tunnel both protocols into another layer by
defining too-restrictive hard-coded rules (because what you're doing
in apps-layer is actually in HTTP request, so we can easily exchange the
role of body and headers), but I think we certainly need such restrictions
to work well.

One point we are in disagreement on this is possibly that you're estimating
cost of introducing http-layer auth extension too expensive.
Of course, adding new request method (e.g. GET, POST etc.) or new
tunneling protocol (Upgrade:) is extremely extensive, because we really
have to upgrade all servers and all intermediates.
On the contrary, adding new authentication does not change all request
binary structure and thus it should go though all existing intermediates.
At least ours can be used with all intermediates which can pass
Digest authentication. We actually did field experiments in a part of
Yahoo! Japan web systems, which has a complex internal structures
with intermediate proxies and accelerators, and it worked quite well.

Adding auth protocol to the servers is modularized in most
production-level Web servers, and also many language platforms
(e.g. PHP) actually support passing authentication requests
transparently to the apps layer so that application framework
can handle authentication. If application are relying on the such platform-
or server-provided authentication, ours can be introduced
to the server-side with almost no cost.
For general cases we need to change some framework
part to adopt new authentication, but the cost is comparable
to change some framework for new apps-layer authentication.

Now I love to go to the next step...

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

Let's go :-)

> 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);

Agreed to this point.

> 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);

Hmm, I can doubt this.  In our application story, the top-most page
must be authenticated, but the subrequests can be done
in either ways.  If the top-most page is correctly written
(it is the server's responsibility), it refers all HTTPS sub-contents
not user-autheticated, and if we can either trust CAs
or have "LockCA" feature of Strict Transport Security, the security
will not be broken.

Currently, HTTP auth _does not_ require all-or-nothing, and HTTPS
_does_ require all-or-nothing which make some people irritating :-)
Actually, it can be in either design and people can decide.

# My personal feeling for the mixed contents on HTTPS is
# "not acceptable" for hard contents (e.g. scripts, HTML and style-sheets)
# but "acceptable" for just images if they need.

This is also related to the next two issues.

> 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?);

So, to this part, actually we can have several designs.

One important point here is that, even for the applications
which needs those strong properties and does it correctly,
loosening these rules 3b-3d to non-mandatory
will not sacrifice the security of such applications.
Even without these they can make it secure by themselves.
And loosening these rules will certainly benefit some other applications.
(On the contrary, for example, allowing non-mutual authentication
to use the same secure UI (which violates (or whatever worse)
3a, 3e and 0) will make secure application a "victim" of forged
Phishing attacks.)

And loosening these rules will certainly benefit some other applications.
So there will be a design choice.

For 3d), I agree that we need to provide some additional clues for them
so that the pages can use these if wanted, even when we do't let it mandatory.)

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

For the user yes, and in federation case also for the service.

# But, if this includes script-initiated request cases, it is *not always* true:
they can implement more complicated access patterns like
OAuth-like delegation, or using temporarily-generated id/credential
pair to authenticate to third-party resource servers.
In such case showing such internal authentication ID might be
inappropriate, although mutual authentication is still very useful.

For "4) Required properties for JavaScript APIs", sorry I don't have
enough concrete idea at this point.

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

Thank you very much, too.  Your comments and summarization
really help my understanding becoming much clearer.
Received on Wednesday, 15 June 2011 14:25:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC