Subject: Past Proposals for HTTP Auth Logout

From: Tim <[email-masked]>
Date: Thu, 7 Jan 2010 10:24:09 -0800

Hello,

I appologize in advance if this is not an appropriate place to ask
this question.

I'm doing some research and I'm interested in learning about any past
proposals to augment HTTP authentication (basic/digest) with a logout
feature.  I have spent several hours reading mailing list archives and
searching the web, and while I've found plenty of related information,
I'm surprised to find no concrete proposals for this feature.

Surely I'm missing something.  Could someone point me in the right
direction?

Thanks much,
tim

---

From: Albert Lunde <[email-masked]>
Date: Thu, 7 Jan 2010 15:04:48 -0500

> Surely I'm missing something.  Could someone point me in the right

Speaking as a non-expert...

This tends to be a problem that relates to application sessions
as much as to HTTP protocol-level authenication. It seems to be
possible to solve at the level of a single application, and
hard to solve at the next level of federated authetication.

Thus the Shibboleth project is periodically explaining why they
don't provide single logout:

<https://spaces.internet2.edu/display/SHIB2/SLOIssues>

<https://wiki.brown.edu/confluence/display/CISDOC/
Shibboleth+and+Application+Logout+Best+Practices>

The varied way that different HTTP clients handle cookies,
kerberos tickets, and other authentication credentials probably
makes it harder to manage.  

Web Single-Signon systems seem to depend on gimmicks outside the 
scope of HTTP as, such in order to work with existing web
browsers.

-- 
    Albert Lunde  [email-masked]
                  [email-masked]  (address for personal mail)

---

From: Nicolas Alvarez <[email-masked]>
Date: Thu, 07 Jan 2010 18:41:03 -0300

> I'm surprised to find no concrete proposals for this feature.

I don't see how that concerns HTTP; it's a missing feature on the browsers.

Credentials are sent on every request. All you need is a logout button on 
the *browser* that makes it stop sending credentials. Go file feature 
requests to the browser vendors :)

-- 
Nicolas

(I read mailing lists through Gmane. Please don't Cc me on replies; it makes 
me get one message on my newsreader and another on email.)

---

From: David Morris <[email-masked]>
Date: Thu, 7 Jan 2010 13:51:39 -0800 (PST)

> requests to the browser vendors :)

So on what basis does the browser prompt again? It is likely a better user
experience if the flush credentials is part of a server response to a
web page logout button which lets both ends know the logout occured and
takes the user to a page which doesn't immediately present a new 
credential dialog.

---

From: Tim <[email-masked]>
Date: Thu, 7 Jan 2010 14:12:13 -0800

Hi David and Nicolas,

> >requests to the browser vendors :)

I don't necessarily disagree with you Nicolas.  Having this feature is
a good thing.  Unfortunately, with the current status quo of
cookie-based authentication (which I detest on various security
grounds), users are conditioned to expect logout functionality in the
web application itself.

> takes the user to a page which doesn't immediately present a new

This is exactly what I am wishing existed in HTTP.  I have ideas for
how to do this with minimal impact on existing user agents, but I
wanted to make sure I understood what had already been discussed in
the past.

tim

---

From: Tim <[email-masked]>
Date: Thu, 7 Jan 2010 14:29:19 -0800

> hard to solve at the next level of federated authetication.

Ok, I suppose things might get complicated at a SSO/federated level.
The vast majority of applications don't currently need to worry about
this.  I guess it's important to think about in relation to digest
authentication though, since it does support SSO-like features.

> scope of HTTP as, such in order to work with existing web

Sounds complicated...  I'll have to read up on it more.

tim

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 08 Jan 2010 09:39:05 +0100

> takes the user to a page which doesn't immediately present a new  

This is a hypermedia and/or browser issue, not an HTTP issue. The  
server can send along with the 401 response a representation to  
display. Maybe the version of the page for unauthenticated users. The  
browser can display a less annoying dialog or button in the GUI  
showing the client that it *can* login. Otherwise the client could  
continue or be redirected to a non-auth version of the Web site.

It is just a matter of what the browser makes of the 401 response. It  
need not display the login dialog right away.

Jan

--------------------------------------
Jan Algermissen

Mail: [email-masked]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 08 Jan 2010 18:56:15 +0900

Dear Tim,

Currently I am implementing/specifying a log-out feature as a part of
our Mutual authentication protocol proposal: more detail for our
proposal are at
  https://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 and
  https://www.rcis.aist.go.jp/special/MutualAuth/ .

Because the proposal aims to replace both Basic/Digest AND form-based
authentication in a future, we needed to design a useful log-out
feature, which are required to support many currently-cookie-based web
applications.

Regarding log-out implementation on HTTP authentication,
discarding a username/password pair and all session keys (e.g. nonces
in Digest) associated to that pair should basically be fine.
However, I thought there are a few features needed to be added to current
HTTP protocol, to support various services currently implemented in web
applications.  I added such a few features as a part of our proposal.

I currently propose it as a part of our Mutual auth. protocol, but if
people are interested, it can be reorganized as a generic extension to
HTTP 1.1.  Please look and tell me your impression if any.  We already
have a patch to Mozilla Firefox, based on our proposal.

If you are interested, the following are the detail:

What I added in the proposal are

  - a facility for client to request log-out.

  - a response header for server to request client to force log-out.
    (logout-timeout field, specified in Sections 4.6 and 7.3 of our proposal)
    it can either be timeout-based or be immediate.

  - a response header for server to request client to be redirected when
    user requests a log-out (location-when-logout field, Sec. 7.2).
    This will be especially useful when the user requests log-out on
    a page served to a POST request.

Federated log-in (Single Sign-on) on domain tree level is supported
natively in Mutual auth proposal, so single-sign-off will also work
(If one server request log-out, the user will be logged out from
 all sites within the SSO domain.)

P.S.

I also found a possible mis-concept or mis-parsing on conflict between
caching and log-out.  Currently many browsers' caches do not distinguish
authenticated contents and unauthenticated contents on the same URI.
This causes some weired behavior happening on log-out and log-in.
For details, see http://t01.rcis.jp/moz-auth-cache-bug/ and 
https://bugzilla.mozilla.org/show_bug.cgi?id=533412 .

I would be happy if HTTP RFC explicitly says that the contents for
different users (distinguished in a user-name of underlying authentication)
should not be served by the caches (both public and private), unless
the server explicitly state it as sharable (by Cache-control: public header).

# I personally think that current HTTP specification for the private cache
# do not consider such situations.

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

---

From: Tim <[email-masked]>
Date: Fri, 8 Jan 2010 09:19:40 -0800

Hi Jan,

> display. Maybe the version of the page for unauthenticated users.
> The browser can display a less annoying dialog or button in the GUI
> It is just a matter of what the browser makes of the 401 response.
> It need not display the login dialog right away.

Ok, so thinking about this more, is this the algorithm you propose
browsers use?

  Browser receives 401

  If auth type and realm match those of any cached credentials, then:
    Clear cached credentials
    Show body of 401 response to user

  Otherwise: Prompt user for new credentials

That's the only way I can think of where this would be workable.  It's
clearly not the way any browser does it today.  Is this kind of
algorithm mentioned anywhere in any of the RFCs?  I'm guessing not...
Don't get me wrong, it does make sense, but I can also understand why
browsers never got around to doing this.

My goal is to make HTTP-based (basic, digest, or other) authentication
viable in the majority of web applications.  While it might be
possible to convince the top 2-3 browsers to change behavior by asking
nicely, it may be easier to define an explicit logout response header
or type which makes it blatantly obvious what's supposed to happen.
If I can't convince at least the top 2 browsers to make logouts user
friendly, then no app developer will ever even consider HTTP based
authentication.

thanks,
tim

---

From: Tim <[email-masked]>
Date: Fri, 8 Jan 2010 09:59:40 -0800

Hi Yutaka,

>   https://www.rcis.aist.go.jp/special/MutualAuth/ .

Cool.  While I like Digest a lot better than basic auth, it still
leaves much to be desired, particularly in all of it's optional
features and ambiguous RFC. =\  I think it's definitely a good idea to
provide more HTTP auth options.

> feature, which are required to support many currently-cookie-based web

Yes, I think an explicit log out function is a necessity.  I am still
leaning toward an explicit response to effect that, as I guess you do.

> applications.  I added such a few features as a part of our proposal.

I have not yet had time to grok your new protocol, so I appologize if
I don't understand how you plan on implementing this...

> have a patch to Mozilla Firefox, based on our proposal.

I think it would *definitely* be beneficial to users and to the
adoption of your protocol if there were a more explicit log out
function for all HTTP auth.

Right now, developers don't bother with HTTP auth in most cases
because they can't customize the login forms and there's the
impression that there's no way to log out.  There are hacks out there
to achieve login with XMLHTTPRequests and this will hopefully be made
easier as the interface is standardized.  (I plan on describing this
in detail in a future paper.)

So logouts are still outstanding.  There are also AJAX hacks to make
this work in some browsers, but it's not a great solution.  Yes, you
could ask all browsers to change behavior with 401s to make this
possible, but application developers will likely find it confusing to
send a 401 with a login form in one case, and send a 401 with a
"you've successfully logged out" page in another case.  Introducing a
more explicit HTTP code for this will make it easier for browsers to
differentiate and also for developers.

In any case, I think if the user interface problem were solved for
Basic and Digest, then transitioning to Mutual or any other more
advanced auth scheme would be much easier.

>     a page served to a POST request.

Ok, interesting.  Sounds very featureful, which is good in the long
run.  For my interests, I would want something bloody simple in it's
most basic form with room for extensibility.

My initial thought was to define a new 2XX response code which
required one or more WWW-Authenticate headers (or a header type that
has a similar form to WWW-Authenticate).  The header would define, at
a minimum, the authentication protocol and the realm.  It could have
additional protocol-specific elements, such as crypto blobs (to
integrity protect the log out), or even elements which define which
specific domains should be removed from the protection space (in the
case of Digest and perhaps Mutual, this would allow remaining
protection spaces to remain in the session).

However, it probably doesn't make sense to define a new 2XX code, now
that I think about it more.  The same could be achieved by a simple
header in a 200 OK response.  The key here, is to use a 2XX of some
kind so that if a browser doesn't support the new header, it'll just
ignore it and developers can use AJAX hacks in the body to achieve the
same end in popular browsers during the transition period. 

Would something like this work with your new protocol?  Also, what is
the goal of the location-when-logout design?  Could the body of a 200
response as I propose not achieve a similar goal?  It's just that it
seems confusing to mix 2XX/3XX/4XX semantics by having a redirect
instruction potentially appear in non-3XX response types.

Thanks!
tim

---

From: David Morris <[email-masked]>
Date: Fri, 8 Jan 2010 11:02:24 -0800 (PST)

On Fri, 8 Jan 2010, Jan Algermissen wrote:

>> takes the user to a page which doesn't immediately present a new credential 
>> dialog.
>> 
>
> This is a hypermedia and/or browser issue, not an HTTP issue. The server can 
> send along with the 401 response a representation to display. Maybe the 
> version of the page for unauthenticated users. The browser can display a less 
> annoying dialog or button in the GUI showing the client that it *can* login. 
> Otherwise the client could continue or be redirected to a non-auth version of 
> the Web site.
>
> It is just a matter of what the browser makes of the 401 response. It need 
> not display the login dialog right away.

That is really not true ... what any part of the process 'could' or 'can'
do is not relavent to interoperability. The point of standards is that all
parties know what is expected of their behavior and what they can expect
from the other parties.

web authentication lacks a specified way to close the door once it is 
open. Providing a door close function is a requirement on HTTP.

There is sufficient evidence after 15 years that browser implementors 
haven't chosen to implement even a simple credential flush dialog. 
When you use a browser to access www-auth protected content, do you have a 
solid understanding of when your credentials are invalidated? Or exactly
how they are used? If you use multiple browser windows, opened as 
processes? Opened as new windows? How about tabs? I have no confidence 
that I understand the span of applicability with anything short of 
rebooting the system insuring credentials are purged. I've been an 
implementor of web technology based applications since 1994. If I'm not 
confident, how do you expect the average user to even understand there
to be a problem?

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 08 Jan 2010 20:19:32 +0100

Tim,

>  Otherwise: Prompt user for new credentials

Sort of - I just meant to sketch how it might work. I think some  
standard link relation might be better, e.g.

GET /protected.html

401 Authorization Required
Content-Type: text/html

<html>
<head>
   <link rel="noauth-version" href="/unprotected.html"/>
</head>
<body>...</body>
</html>

Then the browser had a way to make a choice between

- showing the dialog as currently done
- showing a button in the browser GUI for this page and display the  
noauth version
- provide the dialog but include a button in the dialog to go to the  
noauth version

Browsers that do not know noauth-version would not change their  
behavior.

This could also be used in a Link header if the payload is not HTML.

Hmmm - that is actually all not bad - maybe someone should register  
such a relation?

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 08 Jan 2010 20:27:07 +0100

On Jan 8, 2010, at 8:02 PM, David Morris wrote:

>> [..]
> web authentication lacks a specified way to close the door once it  
> is open. Providing a door close function is a requirement on HTTP.

But how can it be any simpler (and thus easier to understand) than to  
send with each request the credentials if the intention is to  
authenticate for a protected resource? And to tell the browser to stop  
sending them (and forget them if desired)?

Most browsers today ask for auto-auth behavior for non HTTP  
authentication anyway - just copying the standard behaviour of how  
HTTO auth is implemented in browsers.

I think what would maybe address your worries is if the browser  
displayed the used credentials in the GUI on a per-page basis so you;d  
know what is going on. OTH, most sites do atht anyhow by displaying  
'You are logged in as foo' on the page.

Jan

>
> There is sufficient evidence after 15 years that browser  
> implementors haven't chosen to implement even a simple credential  
> flush dialog. When you use a browser to access www-auth protected  
> content, do you have a solid understanding of when your credentials  
> are invalidated? Or exactly
> processes? Opened as new windows? How about tabs? I have no  
> confidence that I understand the span of applicability with anything  
> short of rebooting the system insuring credentials are purged. I've  
> been an implementor of web technology based applications since 1994.  
> If I'm not confident, how do you expect the average user to even  
> understand there
> to be a problem?
>

---

From: Tim <[email-masked]>
Date: Fri, 8 Jan 2010 11:50:02 -0800

> standard link relation might be better, e.g.

Well, if it isn't well defined somewhere, then it will never fly.  You
see, those who chose what authentication gets used are application
developers.  They use cookies because it gives them full control over
the user interface and a whole lot of other application behaviors.

If browsers don't change in unison to a behavior like you propose,
then app developers will never adopt better authentication protocols.
Just not worth the effort.

> Then the browser had a way to make a choice between

Choice of UI needs to be taken out of the browser's hands when it
comes to log out.  Sure, it's great if browsers give users a button or
menu to clear credentials (which many now do, different in each
browser), but the resulting landing page upon log out needs to be
fully controlled by the

> - showing the dialog as currently done

Status quo, no good.

> - showing a button in the browser GUI for this page and display the

Possibly workable.  My thought for logging in again would just be an
HTML link in the body of the 401, set by the application developer,
which points the user back to log in (possibly on the same page).  A
button provided by the browser wouldn't hurt either.  As I said,
convincing browsers to make this change may be quite difficult though.

> - provide the dialog but include a button in the dialog to go to the

Not workable.  If a user clicks log out in the application itself,
they don't expect to be prompted immediately.  This is the UI problem
that causes HTTP auth to be rejected by developers.

> Hmmm - that is actually all not bad - maybe someone should register

Then we're back to headers again... why not just start with an auth
response header that provides this functionality regardless of content
type, and also provides:

  - The ability to authenticate the logout response, as some more
    secure protocols may require.
  - The ability to log out of single applications when multiple
    applications are authenticated with one set of credentials.
  - Extensibility which ties directly into new HTTP authentication
    types.

tim

---

From: Mike Kelly <[email-masked]>
Date: Sat, 09 Jan 2010 15:19:34 +0000

David Morris wrote:
> When you use a browser to access www-auth protected content, do you 
> have a solid understanding of when your credentials are invalidated? 
> Or exactly
> implementor of web technology based applications since 1994. If I'm 
> not confident, how do you expect the average user to even understand 
> there
> to be a problem?
>

Browsers just need to provide a standardized javascript API for setting 
and flushing the Authorization header (per domain).

'Logging In and Out' is a purely client-side concern, so it seems a good 
candidate for solving with code on demand - since there's really no 
visibility to lose.

- Mike

---

From: Albert Lunde <[email-masked]>
Date: Sat, 9 Jan 2010 12:10:09 -0500

> candidate for solving with code on demand - since there's really no  

I'd argue that the federated case, or even the problem of invalidating
application sessions in a load-balanced web application makes
it a total-system problem.

There does seem to be a user-interface and management issue 
with providing a unified interface to all the possible sorts of login 
credentials, that gives their scope and human meaning.

Off-hand, we've got Basic and Digest Auth passwords, kerberos
tickets in several forms, encrypted cookies, SAML assertions,
and probably stuff tied to session keys in the HTML or URLs.

There are too many messy issues in the big picture...

If I use a magic new feature to "log out" of an intranet site 
autheticated with MSIE, have I just dumped the kerberos tickets 
for our AD domain?

Can you provide a human-readable, non-spoofable way to label
the credentials?

Can the protocol be spoofed

---

From: Tim <[email-masked]>
Date: Sat, 9 Jan 2010 15:19:39 -0800

> Browsers just need to provide a standardized javascript API for
> setting and flushing the Authorization header (per domain).

This is a possible solution, if all browsers supported JavaScript.
Most don't.  Most only support ECMAScript and I'm sure you know how
ugly this stuff gets in practice.

At a more abstract level, HTTP handles log-ins in stateful
authentication protocols, but you're asking JavaScript to handle log
outs.  This asymmetry seems confusing.

> 'Logging In and Out' is a purely client-side concern, so it seems a
> good candidate for solving with code on demand - since there's
> really no visibility to lose.

No, I think you're mistaken here.  It is also a concern for
cryptographic protocols.  Typically, any secure protocol will define
some kind of session key which needs to be forgotten once the session
is over.  Server and client need to synchronize this.

Regards,
tim

---

From: Tim <[email-masked]>
Date: Sat, 9 Jan 2010 15:32:59 -0800

> it a total-system problem.

There is a big picture to look at, certainly, but one can't lose sight
of what's actually going on in application development today.  I do
application penetration testing and security code review for a living,
so I look at a lot of applications.  The vast majority simply use
cookie-based frameworks and any advanced authentication/authorization
frameworks (if used at all) are not exposed to clients at all.

> credentials, that gives their scope and human meaning.

I'm merely trying to make existing standards usable in practice.  The
key to this is allowing application developers to control the user
experience for login and logout.

> and probably stuff tied to session keys in the HTML or URLs.

I'm not concerned about browser cookies.  They're a de facto standard
and, likely because of this, are riddled with security problems.

I'd like to remove the barriers to entry for Basic and Digest
authentication, and hopefully, any additional HTTP authentication
schemes. If Basic and Digest were widely usable, I believe future ones
would be easier to transition to.  

> There are too many messy issues in the big picture...

Can you name more, besides the two below?

> autheticated with MSIE, have I just dumped the kerberos tickets 

That could be kerberos-specific behavior.  As I proposed in an earlier
email, a response header could define the auth scheme, realm, and any
additional scheme-specific information.  I suppose an auth scheme
could decide not to implement such a feature.

> Can the protocol be spoofed 

Optional scheme-specific information could easily provide a signature
or other integrity protection for the logout response itself,
autheticating it.  That one, at least, I thought of.

Any general authentication control header shouldn't cause problems for
existing auth schemes, but if it's up to the scheme to define that,
then that shouldn't be an issue.

thanks,
tim

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 12 Jan 2010 22:32:16 +0900

Tim <[email-masked]> writes:

> Also, what is

This is to support client-initiated log-out, and generally not
needed for server-initiated log-out as you might guess.

# Clicking a "log-out" link to log-out is a server-initiated log-out.

In our current proposal, when the server request a log-out
a usual positive response with a header
"Authentication-control: Mutual logout-timeout=0" will be sent
from the server. And this will cause the client memory of
the user/pass associated to the current request to be erased.
In this case we can just use usual 302/303 responses for redirection.

However, if a client user requests browser to log-out
(our test implementation browser a "log-out" UI button),
the client will clear a user/pass memory and then "reload" the
current page by default.
While it should be OK to reload a GET request,
it is undesirable to reload other kinds of requests like "POST"s.

# In most cases, the final actions which authenticated users want to
# do will be POST requests (e.g. a "Check out the shopping cart" button :-).

Our "location-when-logout" directive suggests client to change this
default behavior; it will move to a new specified location (with a GET
request), instead of reloading.

# And this is why our draft encourages applications to send an
# appropriate location-when-logout directive for every POST request.

So, it seems to be not similar to a Location in 3XX response for me; it
is more like a special link activated after logging-out.  Another
possible solution may be a special-meaning Link: header, but I think
that our current design is better than that.

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 12 Jan 2010 23:06:13 +0900

Dear Tim,

> provide more HTTP auth options.

Thank you :-)

> Would something like this work with your new protocol?

I don't know much about a AJAX hack, but I agree that a 200 response
with a new header would be the better for several reasons.

  * It is simpler :-),

  * Behaves well with existing clients, and

  * Responses will not always be 200; it may also be a 3XX response
    which redirects client users back to an unauthenticated top page.

In our proposal the header 
  "Authentication-Control: Mutual logout-timeout=0"
will possibly serve exactly the same purpose which you want.
If there is a better generic solution, I will probably go on it.

# Allowing the keyword other than "Mutual" (or remove it)
# in our Authentication-Control header may be one possibility :-)

I was thinking that a simple directive "log out from the current
authentication realm in your request" is enough for most use cases,
because authentication realm is usually fixed at the first response
for the authorization request.

# Mutual explicitly supports domain-level SSO, where authentication
# realm spans over several hosts inside one domain, and clients will
# automatically send authorization requests for such hosts
# requesting for a same "realm" value.)

Is there a possible interesting use-cases for such a partial log-out?
It seems to make authentication model very complicated, and we might
also need a way for "adding a new to a current authentication domain"
and a careful security analysis/considerations.

# But I feel it interesting and worth thinking :-)

A separate mail is for the rest of your mail...

Cheers,

---

From: Tim <[email-masked]>
Date: Tue, 12 Jan 2010 19:28:56 -0800

>     which redirects client users back to an unauthenticated top page.

Yes, I also think an HTTP header makes the most sense.  As far as 3XX
responses, I'm not necessarily against them, but I haven't really
thought about what any ramifications might be.

> If there is a better generic solution, I will probably go on it.

Yes, I think something like that makes sense.  How about this
variation (sorry for the lack of BNF/etc grammar):

  Authentication-Control: [SCHEME] realm="[REALM]", ... [EXTENSIONS] ...

The only required pieces being the scheme and the realm.  So for
Mutual authentication, it may look like:

  Authentication-Control: Mutual realm="...", logout-timeout=0

For Basic it might look like:

  Authentication-Control: Basic realm="...", logout="true"

> and a careful security analysis/considerations.

I agree that partial logout could become quite confusing.  I think the
choice of how that would work and could be interpreted by clients
should be left up to the individual authenticaiton schemes.

The advantage of a general header like the one above is the
flexibility for providing this and more importantly, providing
integrity protection/authentication for the logout response.

I hope to release a paper in the next few weeks describing why HTTP
authentication is still relevant and how to make it more usable in
theory and practice.  Your feedback has been most helpful.  I will
post a link here when I have it ready. 

Thanks,
tim

---

From: David Morris <[email-masked]>
Date: Tue, 12 Jan 2010 21:46:05 -0800 (PST)

> post a link here when I have it ready.

Perhaps more important than browser considerations is support of
programatic User Agents where there is no direct human interaction.
HTTP authentication is certainly relevant in that space and should
be covered in any proposals for enhancement.

There is also what I'd call an intermediate User Agent ... where a
person may trigger a data transfer task interactively but not
care about success or failure. A common example would be Subversion.

Dave Morris

---

From: Tim <[email-masked]>
Date: Tue, 12 Jan 2010 22:14:04 -0800

> care about success or failure. A common example would be Subversion.

Very true, it is easy to get focused on popular browsers.  While I
didn't call it out explicitly, non-interactive clients is one reason
why I feel having a change in HTTP itself is useful, rather than in
some content standard (HTML, etc) that many of these agents may not
support.

Regards,
tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 13 Jan 2010 08:46:50 -0500

> I appologize in advance if this is not an appropriate place to ask

Feel free to ask questions, but this group is not chartered to add
features to HTTP authentication schemes. The charter is here:

<http://www.ietf.org/dyn/wg/charter/httpbis-charter.html>

> feature.

That would address one shortcoming of those schemes, but they both
have more fundamental problems. See

<http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-03#section-2.2>

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Jan 2010 14:55:40 +0100

> <http://www.ietf.org/dyn/wg/charter/httpbis-charter.html>

Yes.

> <http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-03#section-2.2>

True as well. But that being said: just because there are many problems 
to solve doesn't mean we shouldn't try one at a time (if (!) it's 
possible to both specify the solutions and deploy them).

BR, Julian

---

From: Tim <[email-masked]>
Date: Wed, 13 Jan 2010 08:43:58 -0800

Hello Robert,

> <http://www.ietf.org/dyn/wg/charter/httpbis-charter.html>

Yes, I understand.  Sorry if you feel I've hijacked the list.  Just
couldn't find a better place to ask questions or solicit discussion.
I merely wanted to make sure my understanding of issues was firm
before proposing changes to the security community.  I hope to follow
up with an RFC draft if it makes sense in the future.

> <http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-03#section-2.2>

Yes, of course these cannot be considered secure on their own.
However, for various reasons not mentioned in that document, I
consider form+cookie authentication much worse than say, the HTTP
digest scheme.  (I will back this up with some arguments in the paper
I mentioned I'm working on.)  All would require something like TLS to
be truly safe, but I think a better way forward (than continued
reliance on cookies) is to make HTTP authentication viable again to
allow for more better designed, standardized, authenticaiton
protocols.

Regards,
tim

---

From: Tim <[email-masked]>
Date: Tue, 26 Jan 2010 10:28:52 -0800

Hello,

I've finally published the paper I mentioned previously in relation to
this thread:
  http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

Thanks to everyone who provided suggestions.  I'm very much interested
in any feedback on the paper itself, for those who have time to trudge
through it.

cheers,
tim

---

From: figroc <[email-masked]>
Date: Thu, 28 Jan 2010 19:09:46 +0800

Hi Tim,

    Rather introducing the new Authentication-Control header, I'd
prefer utilize the Authentication-Info header. For the current
request, HTTP server still needs to send the response with
Authentication-Info header, we can just add a new parameter, such as
terminate="true" as presented in your paper.
    As for customizable login form, there are some proposals
suggesting integration with HTML5 form authentication which talk about
sending authentication information through normal form submission. I'd
rather let HTML5 capable browsers submit authentication information
through Authorization header, that'd be more consistent. If we allow
WWW-Authentication present in 2xx/3xx response, legacy browsers will
act as usual.
    BTW, why don't we introduce SRP to HTTP authentication? In my
experience, that servers must store password hashes (A1 values) which
can be used to authenticate against server directly is a big security
drawback.

Regards,

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 28 Jan 2010 20:42:59 +0900

Dear Figroc,

> can be used to authenticate against server directly is a big security

Please refer our draft draft-oiwa-http-mutualauth-05
<http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05>,
which is almost exactly what you want.
It introduce a strong password-based cryptographic authentication
into HTTP.  In this scheme, no passwords or equivalent authentication
tokens will be sent in cleartext, and server-side stored tokens
cannot be used in client-side for authentication, even if it were stolen.

# For the detail of this proposal, further discussion might be
# in apps-security or OAuth ML preferably, as ours is going to
# be reassigned to that WG.

> terminate="true" as presented in your paper.

I proposed the Authentication-Control header in the draft (section 7),
and in my earlier personal draft (unpublished one between -04 and -05)
it WAS in the Authentication-Info header.

The reason why a separate header is preferable came from our
implementation experience: Authentication-Info header will be
generated by HTTP servers, usually with per-directory or per-server
configuration. On the other hand, Authentication-Control headers may
be required to be determined by per-URI or even per-request basis, and
thus possibly generated by CGIs.  We found that mixing the two
information from different origins inside HTTP servers may be
theoretically possible but tricky and cumbersome, and separating it
will simplify the implementations significantly.  So I added a
separate header to the finally-submitted draft.

# At least in Apache it will involve more additional hooks and
# finer control of the loading order of extension modules required,
# which might cause installation-time problems.

I understand that the merging to one header is "clearer" in theory,
but it is a trade-off between theoretical clearness and implementation
simpleness, of which we took the latter (at least currently).

---

From: Tim <[email-masked]>
Date: Thu, 28 Jan 2010 07:58:25 -0800

Hello,

Thanks for taking a look through the paper.

> terminate="true" as presented in your paper.

I thought about this, but unfortunately the Authentication-Info header
does not include the realm, so it would be a little weird trying to
adapt it for other authentication schemes.  If the only concern was
giving Digest authentication a log out, then that would be fine, but I
am trying to look at the big picture for other, better authentication
schemes.

> WWW-Authentication present in 2xx/3xx response, legacy browsers will

I'm not intimately familiar with the HTML5 process or all possible
proposals, but the ones I've read appear to be a big step backward.
They appear to be trying to create a new authentication scheme to
codify forms-based authentication.  I don't see how that would be
compatible with things like digest authentication.

Note that HTML forms and JavaScript hacks could be relied on for a
rich user interface, but it would still be perfectly acceptable for
legacy browsers or persons with accessibility requirements to directly
access a protected area and receive the standard generic login form.

The logout piece here is more problematic though.  I think achieving
this in HTTP is much more preferable, starting with 401 handling
changes.

> can be used to authenticate against server directly is a big security

I think Yutaka covered this point.  I think SRP would be great, but
since most browsers already support digest and it's better than
cookies, my thought was to make HTTP auth generally usable again, let
people benefit immediately from digest's security properties and then
later it won't be as difficult to transition to better HTTP auth
schemes.

Thanks for the feedback,
tim

---

From: figroc <[email-masked]>
Date: Fri, 29 Jan 2010 11:17:30 +0800

Hi Yutaka,

    I'm sincerely sorry, I wasn't aware of http-mutualauth. I've read
the draft, and it does exactly what I want. I see why you introduce
Authentication-Control which is a bit different from Tim's.
    Although, including the first request and the first challenge
response (401-B0), there are six messages involved to have the request
successful. I wonder could we achieve this within four messages? I'm
aware of that letting the server give w_B away first is risky, but
exchanging six messages is a bit much. If we carefully construct the
algorithm, we can achieve this as TLS-SRP does.

    And there is a sentence in "2.  Protocol Overview" confusing me, it reads:
        o  In a response to a req-B1 message, when C has received a 401-B0
                                       ^^^^^^^
            message, it means that the authentication has been failed,
            possibly due to that the wrong password has been given.  C MAY
            ignore the body of the 401-B0 message in this case.
    The "req-B1" comes out of nowhere and has no explanation.

Regards,
Figroc

---

From: Bil Corry <[email-masked]>
Date: Fri, 29 Jan 2010 01:42:38 -0800

Yutaka OIWA wrote on 1/12/2010 6:06 AM: 
> I don't know much about a AJAX hack

Here's an example of using AJAX to log out a user via HTTP Auth:

	http://www.corry.biz/logout_demo/

- Bil

---

From: Tim <[email-masked]>
Date: Sat, 30 Jan 2010 19:39:45 -0800

Bil,

> 	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: Bil Corry <[email-masked]>
Date: Sun, 31 Jan 2010 12:52:23 -0800

> browsers have you tested this on?

Yes, when logging out, I use AJAX to "log in" the user with a bogus password.  That causes the browser to replace the real creds with bogus ones internally, and essentially causes the user to be logged out as the creds no longer work (it now sends the bogus creds).

> missing piece to make HTTP auth usable again.

I agree that having an explicit logout mechanism is preferable -- thank you for the work you're doing on it.  I only came to the above solution after many many hours of experimenting.  It works in FF3.5, FF3.6, IE8 and Safari 4.  I'm pretty sure it works with older versions too.  I haven't tried Chrome, Opera or Konqueror, not sure if it works with them or not.

- Bil

---

From: mike amundsen <[email-masked]>
Date: Sun, 31 Jan 2010 17:01:13 -0500

Bill:

This solution works in Chrome (4)

However, it does not work in Opera (9), or IE7.

I posted the resulting screen shots here:
http://amundsen.com/examples/misc/http-auth-logout.html

mca
http://amundsen.com/blog/