Re: Past Proposals for HTTP Auth Logout

Bruno,

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

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

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.


> (Is there anything in XMLHttpRequest about trying first without
> 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.


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


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

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

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

Received on Thursday, 25 February 2010 21:21:51 UTC