Subject: [http-auth] Some strawman for implementation/design template (Re: Anyone on mailing list working for browser vendor)

From: Yutaka OIWA <[email-masked]>
Date: Tue, 19 Feb 2013 03:40:05 +0900

Dear all,

I strongly feel that working-code principle is thought important by
many people here, and we're managing to keep (at least one of) our code
up-to-date, at least in regards to the new specification draft,
so that we can see how the new things will work.
We're not always possible to be keep it day-by-day,
by at least we intend to as much as possible.

Another concern is how to convince people to implement many independent
proposals into working code, which would require independent maintanance
works (even if the people like several individual proposals).
Designing and implementing an multi-message authentication is
really cumbersome, and people will not want to do it for two times or more.

As a possible workaround to this, I wrote up a small (?) strawman proposal
for having a "common basis" for shared functionalities.
As you may know, my Mutual proposal already has a working mechanism
for efficient re-authentication, nonce managements, channel binding and
others. I extracted all the things which are not specific to PAKE- (or ZKPP-)
based authentications, and compiled into a single draft named
"Common Template for HTTP Message-based Multi-hop Authentication"
(draft-oiwa-httpauth-multihop-template-00).

It is just a strawman and I'm not forcing people to use this
template in any way, but if you like it, you can design your
own multi-message authentication by just defining a few key-exchange
functions only, quoting the draft for all the rest. You will almost
automatically have fast re-authentication, channel binding
and nonce management mechanisms on the wire.
Also, from the implementors' perspective, one can share the
working code for all protocols based on the template,
greatly reducing the maintenance and debugging overhead.

I am quite open for improving the proposals, including incompatible changes
to the message format.  If such a movement become successful,
I would rewrite my own proposal to use the common vehicle as well.

Please take a look and give us comments.
The strawman proposal is available from:
http://www.ietf.org/id/draft-oiwa-httpauth-multihop-template-00.txt

2013/2/7 Yutaka OIWA <[email-masked]>:
> 2013/2/6 Yoav Nir <[email-masked]>:
>>> On 06/02/2013, at 2:54 AM, Julian Reschke <[email-masked]> wrote:
>>> OTOH, two major browsers are Open Source projects; has anyone committed to keeping patches for them up-to-date, at least?
>>
>> AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAuth) has been implemented in a browser, and that was a patch over Firefox 3.5 (current version is 18)
>
> The FF implementation is available on
> <https://www.rcis.aist.go.jp/special/MutualAuth/index-en.html>.
> We're currently implementing the protocol also on Chromium source codes.
>
> --
> 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]

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