Subject: Re: Past Proposals for HTTP Auth Logout

From: Tim <[email-masked]>
Date: Thu, 25 Feb 2010 08:06:56 -0800

Bil,

I've taken your trick for log outs and combined it with a few other
tricks to build a sample application which achieves login, logout, and
password changes all without the traditional HTTP authentication
prompt.  Take a peek:

  http://www.vsecurity.com/download/tools/fbha-poc_0.1.zip

It seems to work well in IE 6, 7, and 8, as well as Firefox, Chrome,
and Safari.  It still doesn't work in Opera, but I think that's a lost
cause until the proposed W3C standard is adopted.  That standard, if
adopted, would also make this code a lot simpler for other browsers.
I haven't tested it in other browsers, besides these top 5.

In any case, I think it shows how this is possible even now with
current browser limitations, but I still feel strongly that an
HTTP-level log out mechanism is needed for those without JavaScript.

thanks,
tim

---

From: Story Henry <[email-masked]>
Date: Thu, 25 Feb 2010 17:23:14 +0100

On the same note.

What would really help for the foaf+ssl [1] RESTful distributed authentication system, would
be if we could somehow push browser vendors to improve their ssl stack - and part of 
this may require tying ssl more closely to HTTP - so that they don't automatically
send an SSL certificate once a user has connected to a site. Currently browsers such as
firefox require a restart before they ask you which certificate you wish to choose.
 
 One suggestion is that one should be able to see what client certificate has been used
when connecting to a web site, so that one could change it

   http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox

The advantage of foaf+ssl over the traditional HTTP login is that it does not even require
a username or password on the part of the user, without any of the traditional problems associated with certificates, as the certs are self signed.

	Henry
  
[1] http://esw.w3.org/topic/foaf+ssl

On 31 Jan 2010, at 04:39, Tim wrote:

> Bil,
> 
>> Here's an example of using AJAX to log out a user via HTTP Auth:
>> 
>> 	http://www.corry.biz/logout_demo/
> 
> Oh, nice, I hadn't thought of this before.  To summarize, you just set
> up a page within the protection space which always returns a 200 code
> and then access it via XMLHttpRequest with a bogus password.  What
> browsers have you tested this on?
> 
> So it appears with logins and logouts, AJAX + response code hacks are
> possible to make this work right now.  I still think an HTTP-level
> session termination mechanism is worthwhile for user agents that don't
> want to rely on JavaScript, but for most developers, this could be the
> missing piece to make HTTP auth usable again.
> 
> thanks!
> tim
>

---

From: Bruno Harbulot <[email-masked]>
Date: Thu, 25 Feb 2010 18:23:12 +0000

Hello Tim,

> I haven't tested it in other browsers, besides these top 5.

There was a similar discussion on rest-discuss a few days ago:
http://tech.groups.yahoo.com/group/rest-discuss/message/14856

Alan Dean was looking for something that would work with Digest auth. I 
just don't see that being possible with the current XMLHttpRequest 
specifications (since you can't specify Digest premptively).

Although it's slightly out of context, here is what I replied off-list 
later on too:
> 
> Unfortunately, I think you're going to have to use a popup or a form/cookie.
> 
> There's an HTTP Cookie auth draft that might help, but it doesn't seem to have gathered much momentum. Even if it did (from the spec point of view), getting it implemented across the board seems tough (it's hard to explain why do this when people use cookies and it works in most cases). REST advocates understand what the problem is, but generally, I suspect most developers don't.
> 
> You might be able to put that AJAX form in the entity associated with the initial 401 response (and get away with a missing WWW-Authenticate with most browsers).
> From there making it use Digest for the first request sounds doable, but quite hard for subsequent (non-AJAX) requests.
> 
> I generally wish there was a "WWW-Authenticate: Form" mechanism (or some form of security token, or cookie like this IETF draft), but for this to be effective, it would need to be implemented in major browsers.
> I've also tried to suggest a "WWW-Authenticate: Transport" (or some other name), mainly for TLS client certificate authentication, but it didn't go very far (I'd need to improve the idea). 

It seems there's a discussion in the HTML5 WG about accessing cookies 
from HTML, but I haven't followed it. I'm not sure how good an idea this 
is. Such mechanism could enable AJAX forms to set the authentication 
cookie/token perhaps.
I'd prefer a solution that has a clearly separated authentication scheme 
(rather than using 'Cookies' at all, have a separate authentication 
token store in the browser, capable of login/logout), but the 
'WWW-Authenticate: Cookie' scheme seems it could be a reasonable compromise.

> HTTP-level log out mechanism is needed for those without JavaScript.

I'm not sure being able to log out from Basic/Digest auth is an HTTP 
issue; it sounds more like a issue of browser interface and/or 
interaction between the webpage and the browser's handling of 
authentication: HTML 5 might be a good place to discuss this.
I do think, however, that there's room for new "WWW-Authenticate" 
schemes: something for 'Cookies' (or generic auth token) and something 
for 'Transport' (to indicate that the authentication is done out of the 
HTTP scope, e.g. via the underlying SSL/TLS stack).

Best wishes,

Bruno.

---

From: Tim <[email-masked]>
Date: Thu, 25 Feb 2010 11:05:09 -0800

Hi Bruno,

> http://tech.groups.yahoo.com/group/rest-discuss/message/14856

Thanks for the link, I'll take a read through.

> Alan Dean was looking for something that would work with Digest
> auth. I just don't see that being possible with the current
> XMLHttpRequest specifications (since you can't specify Digest
> premptively).

Well, actually in HTTP authentication, user agents are supposed to
request the resource without credentials initially.  Once prompted
with a 401, they then know what HTTP authentication mechanisms are
supported by the server and can choose which to use.  There is
actually no other way to implement Digest authentication without this
initial 2-step process since the browser needs the Nonce and other
information to get started.

In the application I put together (using tidbits of information from
many of the same sources mentioned in that thread and elsehwere),
browsers do indeed request the resource first without credentials,
receive a 401, then turn around and try the credentials given in the
open() method.

As far a specifying which HTTP auth scheme to use in JavaScript, no
there isn't a way to do this.  Ultimately, the JavaScript in this
approach must be supplied by the same server doing the authentication
(due to same-origin restrictions on XMLHttpRequest), so it's really a
moot point.  That same server advertises the available methods in the
next request.

I definitely see the desire to restrict the authentication method due
to man-in-the-middle attacks, but specifying the auth scheme in
JavaScript buys you nothing here.  Someone can just MitM the
JavaScript.  As mentioned in my paper, the only way around this kind
of downgrade attack is for browsers to know a priori which scheme is
supported.  Since this isn't possible with current protocols, I
suggested browsers caching which sites support stronger auth schemes
when they are first accessed and then requiring those auth schemes be
used in the future.  See the paper for details.

> > I generally wish there was a "WWW-Authenticate: Form" mechanism (or
> > some form of security token, or cookie like this IETF draft), but for
> > this to be effective, it would need to be implemented in major
> > browsers.

I don't think this is a good idea, personally.  It seems to be
directed at making badly designed authentication standardized.

> >I've also tried to suggest a "WWW-Authenticate: Transport" (or
> >some other name), mainly for TLS client certificate
> >authentication, but it didn't go very far (I'd need to improve the
> >idea).

You should look at the Mutual authentication scheme proposed by Yutaka
OIWA (mentioned in this aging thread).

> It seems there's a discussion in the HTML5 WG about accessing
> cookies from HTML, but I haven't followed it. I'm not sure how good
> an idea this is. Such mechanism could enable AJAX forms to set the
> authentication cookie/token perhaps.
> I'd prefer a solution that has a clearly separated authentication
> scheme (rather than using 'Cookies' at all, have a separate
> authentication token store in the browser, capable of login/logout),
> but the 'WWW-Authenticate: Cookie' scheme seems it could be a
> reasonable compromise.

I don't think any of this complexity is necessary.  With one very
simple, backward compatible change to HTTP, the ability to do a log
out, one already has all of the pieces to do very powerful and secure
forms-based session management.  That is, if the XMLHttpRequest
proposed standard is adopted as-is with respect to 401 handling.  This
then opens up the possibility using dozens of possible HTTP
authentication schemes which are much better than digest auth.

> authentication: HTML 5 might be a good place to discuss this.

Take a look at the reasoning presented in the rest of this thread.  
In summary: 

HTTP authentication allows one to log in, but why doesn't allow one to
log out?  Application developers need to be able to drive the log out
process, they can't rely on browser user interfaces.  (There's nothing
wrong with browser-driven log outs, but we need application-driven
ones as well).

One could place log outs into HTML or JavaScript standards, but why
the asymmetry?  What about user agents that don't support JavaScript?
What about automated user agents that don't deal with HTML content at
all?  HTTP-driven log out makes sense in more situations than the
other approaches.

> schemes: something for 'Cookies' (or generic auth token) and
> something for 'Transport' (to indicate that the authentication is
> done out of the HTTP scope, e.g. via the underlying SSL/TLS stack).

But like I said, this is just standardizing bad practices.  See the
paper.  By inventing new WWW-Authenticate methods which just continue
to use cookies, you through out several good HTTP auth schemes and
have to reinvent the wheel based on limited primitives (cookies).

Instead, let us fix the user interface problems with existing auth
schemes and suddenly we give application developers a whole lot more
options.  XMLHttpRequest objects can let us get there, for the most
part.

thanks for the feedback,
tim

---

From: Bruno Harbulot <[email-masked]>
Date: Thu, 25 Feb 2010 20:20:23 +0000

Hi Tim,

> information to get started.

Yes, you're right (and what I said was confusing).
The problem is that Basic authentication can be preemptive (I suppose a 
user agent could know it has to authenticate via Basic auth preemptivly 
and RESTfully if it's somehow indicated by some hypermedia... debatable).

The XMLHttpRequest via username/password seems to do preemptive Basic 
authentication implicitly. What I was discussing there was about Digest 
authentication via XMLHttpRequest, which I don't think is possible 
because of this.
Indeed, XMLHttpRequest should probably try first to see which challenge 
scheme it gets, but it seems it doesn't.

> receive a 401, then turn around and try the credentials given in the

I've just run your test with HttpFox (after closing/reopening the 
Firefox), and I don't see any 401. It does the authentication preemptively.
(Going onto the private resource directly also triggers a browser popup 
as expected.)

> used in the future.  See the paper for details.

Yes, indeed. (I also need to read you paper in more details.)

> directed at making badly designed authentication standardized.

There is a case to be made for more general tokens, whether we call them 
cookies or not. It's not just about forms.

There are a number of other forms of authentication that would benefit 
from this. I'm thinking in particular of the SAML variety.
Even with its HTTP redirect binding, you more or less need some sort of 
cookie to establish an authenticated session, so as not to be redirected
all the time. The HTTP Post binding is probably even worse: you post an 
entire SAML Response to "log on".

Browsers could potentially support some "WWW-Authenticate: SAML" scheme, 
but I don't see that happening any time soon. I'd guess when this 
happens, SAML will be out of fashion and replaced with something new.

This is not about standardising bad practices. It's just that there are 
cases that Basic and Digest can't handle. I'd go as far as saying that 
for an authentication mechanism to be secure, you need some form of 
preestablished negotiation and session.
The important point here, for the HTTP mechanism to work, is that this 
negotiation ought to be integrated with the 401 status code and 
associate headers, like Digest does.

While 'WWW-Authenticate: Cookie' may be about standardising the (bad) 
cookie practice. Having something well defined for a shared secret would 
be a good idea, I think.

> OIWA (mentioned in this aging thread).

Thanks for the pointer.

> authentication schemes which are much better than digest auth.

(Is there anything in XMLHttpRequest about trying first without 
preemptive Basic when the username and password are specified? I can't 
find it.)

> wrong with browser-driven log outs, but we need application-driven

Fair enough, but that's about having the application driving the HTTP 
authentication mechanisms altogether (Basic/Digest/Negotiate/...), which 
are currently reserved to the browsers, logout being only a part of it.

> all?  HTTP-driven log out makes sense in more situations than the

I'm not saying there shouldn't be an HTTP logout from the browser, I'm 
just saying it's not the domain of the HTTP spec. As you say, it's 
application-driven, and that application is HTML-based. It's a matter of 
interaction between the hypermedia and the user-agent, which only then 
interacts via HTTP.

> have to reinvent the wheel based on limited primitives (cookies).

My concern behind 'WWW-Authenticate: Transport' was more related to 
SSL/TLS client-certificate authentication. (You don't seem to mention it 
much in your paper.)

The problem is that, currently, there's no way for an HTTP application 
(by this I mean the service that's running on top of the TLS layer) to 
say that it would like a client certificate, or that an unsuitable 
certificate was presented. It's all done at the TLS layer.
To request a client-certificate, you either have to configure the socket 
in advance or renegotiate (although it's effectively done transparently 
from the HTTP layer, hence the TLS renegotiation problems).
If no certificate is presented, their is no way to present another 
challenge (or even just an explanatory message) associated with a 401 
status (the server may even be configured to close the connection).
If the certificate isn't suitable, the TLS handshake will just close the 
connection abruptly. If it's accepted at the TLS level, but not what the 
HTTP application was after, there's no way to tell the browser it should 
try to present another one.
What's above talks about certificates, but the same could apply to 
Kerberos cipher suites (not talking SPNEGO here).

There simply just is a kind of authentication that's not in the domain 
of HTTP, but underlying it, hence this 'WWW-Authenticate: Transport' 
suggestion (could be another name...).

Best wishes,

Bruno.

http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet

---

From: Tim <[email-masked]>
Date: Thu, 25 Feb 2010 13:21:19 -0800

Bruno,

> The problem is that Basic authentication can be preemptive (I
> suppose a user agent could know it has to authenticate via Basic
> auth preemptivly and RESTfully if it's somehow indicated by some
> hypermedia... debatable).
> 
> The XMLHttpRequest via username/password seems to do preemptive
> Basic authentication implicitly. What I was discussing there was
> about Digest authentication via XMLHttpRequest, which I don't think
> is possible because of this.
> Indeed, XMLHttpRequest should probably try first to see which
> challenge scheme it gets, but it seems it doesn't.
>
> ...
>
> (Going onto the private resource directly also triggers a browser
> popup as expected.)

Hmm, now that I think about it more, you are probably right.  Some
browsers could be preemptively sending Basic auth, which is *wrong*,
of course, not to mention dangerous, but saves a smidge of time.

In my implementation, I either prompt for Basic or Digest, not both.
So if a browser ships out Basic when Digest is the only thing running,
they still get a 401 and have to switch over to Digest.  From that
point on, browsers cache the Digest credentials and keep sending
those.

As I just implied, Digest is definitely doable with
XMLHttpRequest-based logins, logouts, and credential refreshes
(password changes).  Try out my sample app again with the referenced
python-digest module installed and see how that works for you.

> There is a case to be made for more general tokens, whether we call
> them cookies or not. It's not just about forms.

Oh I agree, cookies will be around for a long time and that's fine.
I'm just saying we should move away from using them to track
authenticated sessions.

> There are a number of other forms of authentication that would
> benefit from this. I'm thinking in particular of the SAML variety.
> Even with its HTTP redirect binding, you more or less need some sort
> of cookie to establish an authenticated session, so as not to be
> redirected
> all the time. The HTTP Post binding is probably even worse: you post
> an entire SAML Response to "log on".

Actually, Digest authentication in particular supports a limited form
of cryptographic cookies which could be used for single sign-on
scenarios like this.  It maybe somewhat limited, but it would be much
safer in many respects.  Check out the RFC's discussion of "opaque"
values.

> This is not about standardising bad practices. It's just that there
> are cases that Basic and Digest can't handle. I'd go as far as
> saying that for an authentication mechanism to be secure, you need
> some form of preestablished negotiation and session.

Let us put Basic auth to rest.  It's obviously problematic and is
essentially stateless.  Consider that Digest authentication is
stateful and, as I just mentioned, has features which can be useful
for passing session information between different servers.  Note that
it is designed for use across multiple domains.  My papers thus far
only touch on this point and mention it can be used for SSO, but
taking a deep dive into the RFCs should help you understand how
flexible it could be, if only application server support was better.

But application server support will never happen so long as web
developers and designers percieve HTTP authentication as unusable.
That's where I'm starting the battle.

> The important point here, for the HTTP mechanism to work, is that
> this negotiation ought to be integrated with the 401 status code and
> While 'WWW-Authenticate: Cookie' may be about standardising the
> (bad) cookie practice. Having something well defined for a shared
> secret would be a good idea, I think.

The problem with cookies for authentication protocols is that there's
no client-side intelligence.  They're a simple storage bin where
clients aren't instructed to hash things, verify signatures, and so
on.  This simple primitive can't be used to produce more secure
protocols, it's basically a cryptographic dead-end.

> preemptive Basic when the username and password are specified? I
> can't find it.)

Hmm, actually you might be right about this too.  This wouldn't be
defined in relation to XMLHttpRequests, but rather in HTTP.  Here's a
snippet from RFC 2617, which I read to mean something different in the
past:

  "A user agent that wishes to authenticate itself with an origin
   server--usually, but not necessarily, after receiving a 401
   (Unauthorized)--MAY do so by including an Authorization header
   field with the request."

So it isn't necessary to receive the 401 first.

Of course doing otherwise with Basic auth is foolish, since it leaks
credentials.

For security reasons, using Basic and Digest together is a problem
when it comes to downgrade attacks, so if servers reject Basic, it
doesn't present a compatibility problem.  Someone should log a
security bug with Mozilla about the Basic stuff...

> Fair enough, but that's about having the application driving the
> HTTP authentication mechanisms altogether
> (Basic/Digest/Negotiate/...), which are currently reserved to the
> browsers, logout being only a part of it.

Right.  If applications can't drive the log out (like they can with
cookies), then we'll never convince developers to use HTTP auth.

> I'm not saying there shouldn't be an HTTP logout from the browser,
> I'm just saying it's not the domain of the HTTP spec. As you say,
> it's application-driven, and that application is HTML-based. It's a
> matter of interaction between the hypermedia and the user-agent,
> which only then interacts via HTTP.

Are all applications HTML based?  No.  Many nowadays are generating
XML as the primary content.  In RESTful land I would expect that to be
especially the case.

Right now, users can be logged out with an HTTP Set-Cookie header.
Why not an HTTP header which terminates an HTTP auth session?  I
actually have another suggestion for this in my paper, but it has been
less popular thus far with browser vendors (the few who have bothered
to comment...).

> SSL/TLS client-certificate authentication. (You don't seem to
> mention it much in your paper.)

No I don't, since it's such a big bag.  Most people don't have the
time/motivation to read my 10 page papers, and to take on TLS issues
in that one would have made it 50. =)

I do think client certificates would be great, but given the recent
plethora of problems with SSL/TLS (and it's implementations) recently,
I think having a second layer of protection is a good idea.  Also, I
believe it will take a lot of effort to convince many application
developers to leave behind username/password systems in favor of
certificates.

> The problem is that, currently, there's no way for an HTTP
> application (by this I mean the service that's running on top of the
> TLS layer) to say that it would like a client certificate, or that
> an unsuitable certificate was presented. It's all done at the TLS
> layer.
> To request a client-certificate, you either have to configure the
> socket in advance or renegotiate (although it's effectively done
> transparently from the HTTP layer, hence the TLS renegotiation
> problems).
> challenge (or even just an explanatory message) associated with a
> 401 status (the server may even be configured to close the
> connection).
> If the certificate isn't suitable, the TLS handshake will just close
> the connection abruptly. If it's accepted at the TLS level, but not
> what the HTTP application was after, there's no way to tell the
> browser it should try to present another one.
> There simply just is a kind of authentication that's not in the
> domain of HTTP, but underlying it, hence this 'WWW-Authenticate:
> Transport' suggestion (could be another name...).

Yes, I think I've seen this stuff discussed elsewhere in the context
of the TLS renegotiation issues.  I think it would be a good idea to
improve interaction between the layers for sure, and making client
certificates more usable is definitely a good goal.

Best,
tim