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

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 14 Nov 2016 21:33:48 -0800

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.

---

From: 大岩寛 <[email-masked]>
Date: Wed, 16 Nov 2016 04:50:58 +0000

Dear Alexey,

Thank you for your reviews.

> Exactly the same paragraph appears earlier in the same section. Did you forget
> to delete this instance?
> 
> In Section 9:
> 
> I think you are giving too many choices which might cause interoperability
> issues.
> Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are possible
> reasons for a server implementation to violate these SHOULDs?

I believe that these three points are addressed in draft-11.

> In Section 15:
> 
> It would be good to be able to bind extension data to shared secret constructed
> by both parties.

I think it's quite interesting.
However, I don't have a good idea for stable enough expression of this
for good interoperability.
(It's similar to header signing, it's important but difficult thing.)
If it will become important, I'd like to address it in possible future
revision of the protocol.
Currently, if some extension is really strongly "critical", we can define
a new variant of the "algorithm" to overcome that.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    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]