- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Mon, 21 May 2012 20:08:59 +0900
- To: "http-auth@ietf.org" <http-auth@ietf.org>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
Received on Monday, 21 May 2012 11:09:51 UTC