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

[Anthony Bryan <[e-mail]>]

On Thu, Dec 24, 2009 at 6:28 AM, Yutaka OIWA <[e-mail]> wrote:
>
> 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.

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