Re: Past Proposals for HTTP Auth Logout

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

On Thu, Jan 28, 2010 at 7:42 PM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> 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 Friday, 29 January 2010 03:18:03 UTC