[http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT)

["Alexey Melnikov" <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-httpauth-mutual-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS points and most of my comments!

I agree that the Introduction section might need an editing pass.

In Section 1, next to the last paragraph:

   The Mutual authentication protocol proposed in this document is a
   strong cryptographic solution for password authentications.  It
   mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you
forget to delete this instance?

In Section 9:

   In both cases, it is the sender's duty to correctly prepare the
   character strings.  If any non-normalized character string is
   received from the other peer of the communication, recipients MAY
   either use it as a bare UTF-8 string without any preparation, perform
   any appropriate preparations (which may cause authentication
   failure), or reject any ill-prepared inputs from the sender and
   respond as a communication error.

I think you are giving too many choices which might cause
interoperability issues.
Even reducing the choices from 3 to 2 would help here.

In Section 11:

      *  Otherwise, send a 200-VFY-S response.  If the session was in
         the "key exchanging" state, the session SHOULD be changed to an
         "authenticated" state.  The maximum nc and nc flags of the
         state SHOULD be updated appropriate.

Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are
possible reasons for a server implementation to violate these SHOULDs?

In Section 15:

It would be good to be able to bind extension data to shared secret
constructed by
both parties.