Re: Past Proposals for HTTP Auth Logout

Dear Figroc,

figroc <figroc@gmail.com> writes:

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

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.

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

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

-- 
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 Thursday, 28 January 2010 11:43:34 UTC