Re: [http-auth] [saag] re-call for IETF http-auth BoF

[Yutaka OIWA <[e-mail]>]

Dear Hannes,

thank you for good questions.

Hannes Tschofenig <[e-mail]> writes:

>  * What is the biggest problem? 
>     You, for example, point to the usage of forms for user
>     authentication in Web pages in the agenda proposal.  The NSTIC
>     fans seem to believe that passwords are the problem to begin
>     with.

IMO, the main point is the lack of the protection for the
authentication credentials, and the lack of the mutual agreement and
assurance about authentication results.

For the first point, in current technology, the passwords are almost
used as a naked token (including the Digest authentication), which is
too weak in current computation environment; there are no protection
against steal by the communicated peer, no protection against
forwarding, etc. I understand that there will be no single solution to
solve the all problem, for example some high-secure applications such
as NSTIC or corporate-value banking needs cryptographic strong
credentials.  But, at the same time, passwords are the only tokens
which can be easily portable by human without help of mechanical
storages.  Both current federated ID management and cloud-based
password management, or even issuing/managing client certificates
online are relying on the password authentication in some form as a
starting point.  It is still worth to improve security of initial
password authentication with those stories.

For the second point, in many high-value applications the security
(privacy) of the user-submitted data is equally or even more important
as/than the integrity of client authorization (I do NOT mean that the
latter is unimportant :-).  Strong mutual authentication is a
important key for this.  Virtually all authentication technologies
which are currently available to Web are weak in this aspect,
including TLS client certificate authentication.  I believe that even
for non-password-based authentication this is important to be fixed.
I currently do not have a proposal for those non-password stories, but
we should really work on this, I believe.

As I mentioned and promised in the previous Bar-BoF, my proposal can
(and will) be separated to a core mutual authentication framework and
a specific algorithm for password-based authentication.  I welcome to
use the framework part for mutually securing other types of
authentications (if algorithmically applicable) as well as password
authentications.  It can also potentially provide shared keys for
channel-binding for higher-layer applications.

The third point, not mentioned earlier, is that all kinds of current
authentication methods, both password- and non-password-based, are 
just hard to use compared to Form-based authentication.
I'm also working on this "applicability" problem and proposing a solution.

>  * What solution approach is most promising? (or multiple approaches)

>      You seem to suggest to standardize a strong-password based
>      authentication mechanism in
>      http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 NSTIC
>      fans seem to believe that the approach is towards stronger
>      credentials (non-password-based) and the usage of federated
>      log-ins.  Again others believe that we will never agree on a
>      single authentication protocol and hence we need a framework
>      that allows passwords to be plugged in dynamically.  Browser
>      vendors are interested, as you may recall from the Identity in
>      the Browser discussion, in standardizing username/password form
>      indications so that the user does not need to type their
>      username & password too often into forms - but the browser does
>      it instead.

I believe we need multiple approaches, depending on the nature of each
specific application.  In my opinion, password authentication and
(better) certificate/private-key authentication are needed as starting
points.  I don't believe that current TLS client cert auth is the
perfect solution for the latter, however.  I also would like to see
how they can be integrated with federated authentication mechanisms.
Pluggable approaches need a little-bit careful consideration about the
mutual influences of plug-ins against total security, but my proposal
is actually going in that way in some aspects, as mentioned above.

# I really want to see someone proposing a draft fixing the
# certificate-based authentication to be more secure and useful :-)

In my personal opinion, browser-assisted fill-ins are in a different
layer, which means that we like to have both at the same time in the
future.  To easily use my proposed technology we need a good password
managers, and to make the browser-stored password secure in all time,
(I believe) we need a good underlying protocol e.g. for mutual
assurance and portability.

My personal intention to proposing BoF and a working group (if people
agrees) is to solve the whole problems, not only our proposed ones.
Currently I only have our draft to count on, but I really don't want
to finish by standardizing ours only.

# How should I write an agenda (or a proposed charter) in this situation?
# "Start-then-recharter" approach will work?

I don't know, however, how much extent of those can be worked on by
our proposed group within next several seasons.  I hope as much as
possible :-)

>  * How do we motivate the different stakeholders to implement and
>  deploy our favorite solutions? (There is also the usability issue
>  for the user.)

>     Whatever you come up with changes are needed on the client, and
>     on the server side. That requires a lot of cooperation.

This was (is) one of the most hard points for us (I believe not only
for our group :-).  But, for ensuring mutual authentication integrity,
we need at some point to change both peers anyway.

For the "technical" usability/deployability problem of the RFC 2617
HTTP authentication, we're actually proposing a solution for that.
For gradual transition, our current proposal can be parallel-served
with existing form-based authentication framework for transition
periods.  We also keep trying to keep contact with browser vendors, of
course.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]