Re: Past Proposals for HTTP Auth Logout

Dear Tim,

Tim <tim-projects@sentinelchicken.org> writes:

> Hi Yutaka,
>
>> 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/ .
>
> 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.

Thank you :-)

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

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,

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

Received on Tuesday, 12 January 2010 14:06:45 UTC