Subject: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim?

From: Yutaka OIWA <[email-masked]>
Date: Thu, 24 Dec 2009 20:28:46 +0900

Dear people on IETF apps-discuss/public-web-security mailing lists
and other related lists,

I would like to introduce our proposal on HTTP mutual authentication.

 (I directed the Reply-to: header to the newly-created
  public-web-security mailing list, but I also welcome private replies
  or those to other lists.)

Our proposal brings a strong, password-based mutual authentication
to the HTTP authentication protocol.
Our aims are to overcome several deficiencies (both for security and usability)
on current HTTP authentication mechanisms, and to replace weak form-based
authentication, which are used in most current Web apps, with 
stronger HTTP protocol-supported authentications.
We designed the protocol so that (a) it removes any threats related to
password/secret stealing like phishing or other attacks, (b) it will be
extremely easy-to-use, and (c) it can accept many Web applications
which were not well-supported with current HTTP authentication
architecture (in RFC 2617).
We believe that this is a correct direction for the future of 
the Web application authentication.

Our proposed draft spec is available from
   <http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05>.
We put a preprint paper on our concept at ArXiv 
   <http://arxiv.org/abs/0911.5230>,
and a presentation in a past httpbis WG is also available from
   <http://tools.ietf.org/agenda/74/slides/httpbis-3.pdf>,
I appreciate your reading and comments on those documents.

Furthermore, we have published a running code of the protocol
implementation for Mozilla Firefox, available from
   <https://bugzilla.mozilla.org/show_bug.cgi?id=532127>.
A pre-compiled binary, server-side implementations and running demonstration
are available in our website
   <https://www.rcis.aist.go.jp/special/MutualAuth/index-en.html>.

I noticed that the registration for IETF 77 at Anaheim is now open.
I would like to have a meet-up of people related to general HTTP
authentication issues/proposals at Anaheim.
I have been told from Lisa that there will be several HTTP-related
WGs and BoFs expected in Anaheim, and I think there will be a good 
opportunity for us to meet up.  If you have any good ideas, please let me know.

Have nice holidays, register for IETF 77 and see you in Anaheim!

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    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]

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 24 Dec 2009 15:47:51 -0500

> I appreciate your reading and comments on those documents.

Hi Yutaka,

I can not comment on the technical nature of your draft, but have a
few suggestions that might make some sentences flow better. I
capitalized words that I changed to draw notice to them, but these
would be lowercase in the corrected text.
Since I am not that familiar with what you are doing, make sure that
these suggestions do not change the intended meaning of your text.
They are mostly number or tense changes.

4.6 and 5, p17 diagram, INPUTTED not inputed

Unlike THE Basic and Digest HTTP access authentication protocol
[RFC2617], THIS protocol ensures that THE server knows the user's
entity (encrypted password) upon successful authentication.

...successful authentication to steal THE user's sensitive information,

THIS protocol prevents such attacks by providing users a way to...

If there is no matching user found, the server SHOULD construct a fake
w_B value, and let the protocol GO ON? CONTINUE? by sending A 401-B1
message.

If the validation has failed, it means that the authentication has
failed. (remove BEEN from has been failed)

In a response to a req-B1 message, when C has received a 401-B0
message, it means that the authentication has failed, possibly due to
the wrong password BEING given. (remove BEEN from has been failed,
remove THAT from due to that the wrong password, change has been given
to BEING given)

If the verification has SUCCEEDED, C will process the body of the message.

Both peers SHOULD reject any invalid UTF-8 sequences which CAUSE
decoding ambiguities

*  C HAS not sent the same value in the same session.

Step 7:  Check whether there is an available sid for the
authentication realm you EXPECT.

   Any kind of response OTHER than THOSE shown in THE above procedure SHOULD be
   interpreted as fatal communication error, and in such cases user
   clients MUST NOT process any data (contents and other content-related
   headers) sent from the server.

7.1 The value of this field MUST be a  string THAT contains an
absolute URL location.

use of this header with 200-optional-B0 messages IS not recommended.

7.2 The value of this field MUST be a string THAT contains an absolute
URL location.

This FIELD SHOULD only be used with 200-B4 messages.

7.3 This FIELD will be used with 200-B4 messages.

If this condition DOES not hold, the server MUST retry with another
value of s_B.

Just like Basic and Digest access authentication protocol, Mutual
authentication protocol supports multiple, separate authentication
realms to be set up inside each HOST.

Depending on the "path" parameters given in the "401-B1" message (see
Section 4), There may be several CANDIDATES... (lowercase there)

In this case, it is difficult for the authenticating server to acquire
the TLS key information which IS? used between the client and the
proxy.

In the Mutual authentication protocol, a session represented by a sid
is generated by... (lowecase by)

The client MAY send more than one REQUEST using a single session
specified by the sid.

In addition, for each SESSION,...

When the user INPUTS the username and password, the client resends the
request with a req-A1 header.

If the validation FAILS?, the client MUST NOT process any content sent
with the message, including the body part.

If user-names have to BE kept secret against eavesdropping, the server
must use full-scheme-type auth-domain parameter.

Server-side STORAGE of user passwords IS advised...

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads