Subject: [http-auth] http-auth: Mutual - drafts updated

From: Yutaka OIWA <[email-masked]>
Date: Mon, 21 May 2012 20:08:59 +0900

Dear all,

I have updated my three drafts related to the HTTP authentication:

http://tools.ietf.org/html/draft-oiwa-http-mutualauth-11
http://tools.ietf.org/html/draft-oiwa-http-mutualauth-algo-02
http://tools.ietf.org/html/draft-oiwa-http-auth-extension-01

The first one is the main draft introducing a cryptographic strong
mutual authentication using weak secrets (i.e., password) to HTTP.
Both password safety and the server-to-client authenticity assurance
is the key features of the proposal.

The second one is defining an example crypto algorithm for use with
the above.

The last one is a companion draft making a small but powerful enough
(I believe so) semantic extensions to HTTP authentication, which can be
used just like API calls from Web applications, so that
it can support modern Web applications.  This erases (or
at least mitigates) many problems which prevent introduction of strong
authentication to Web in a browser- (not content-)controlled manner.

By the first proposal, we can replace Basic and Digest with stronger
crypto-based authentications.  Using both the first and the third,
we can also introduce that strength to applications which currently
use custom application-implemented authentications, too.
I will add some use-case examples to the last draft soon, hopefully.

I'll ask to Mark separately off-list for handling of second and third drafts
under the prescribed procedure, then I'm going to submit the set as an httpbis
auth candidate within a week or so.

Appendix 1: main updates from the previous drafts:
  - extending stale session notification to more generic indications.
  - updated to follow the latest httpbis syntax conventions.

Appendix 2: about crypto choices:
In the previous side meetings, we have discussed that
crypto choice discussions should be postponed for another appropriate time.
We are still maintaining the second draft now, however,
just because we need at least one choice for testing and evaluating
implementations.  So, if you have opinions about algorithm choices,
please keep that in mind, and so do I.
The title of the second draft has been renamed slightly to reflect that.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                              Research Institute for Secure Systems (RISEC)
    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]