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

[大岩寛 <[e-mail]>]

Dear Alexey,

Thank you for your reviews.

> ----------------------------------------------------------------------
> 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?

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: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]