Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)

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

Dear Alexey:

Thank you for really valuable comments.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is generally a well written document. I have a couple of important comments
> that I would like to see addressed and several less significant comments.
> 
> 1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP
> Authentication Schemes with IANA

Yes, we'll do it.

> 2) In Section 7:
> 
>    If HTTP is used on a non-encrypted channel (TCP and SCTP, for
>    example), the validation type MUST be "host".  If HTTP/TLS [RFC2818]
>    (HTTPS) is used with a server certificate, the validation type MUST
>    be "tls-server-end-point".  If HTTP/TLS is used with an anonymous
>    Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
>    (see the note below).
> 
>    Implementations supporting Mutual authentication over HTTPS SHOULD
>    support the "tls-server-end-point" validation.  Support for
>    "tls-unique" validation is OPTIONAL for both servers and clients.
> 
> I think the two paragraphs are in conflict. For example, the first one says
> that if TLS with server certificate is used, then "tls-server-end-point"
> MUST be supported. But the second says that it is SHOULD be supported.
> 
> If the intent of the first paragraph is to say what should appear syntactically,
> while the second paragraph explains what kind of validation is actually
> required, I think this still can be made clearer.
> 
> I suggest you either delete the second of these 2 paragraphs, or you need to
> reword text in the first (and possibly the second) to specify a non conflicting
> set of requirements.

We'll clarify it by replacing the second sentence by a text suggesting
tls-unique is not likely to be required to implement, in most cases.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

Thank you for many improvement suggestions.
For so many suggestions replacing SHOULD with MUST, most of these seem
to be correct.  We'll review all of these again to make a final decision.

> 3.2.2.  Strings
> 
>    All character strings MUST be encoded to octet strings using the
>    UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
>    [ISO.10646-1.1993].
> 
> This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest
> you use a Unicode reference.

We'll do it.

>    The numbers represented as base64-fixed-number SHALL be generated as
>    follows: first, the number is converted to a big-endian radix-256
>    binary representation as an octet string.  The length of the
>    representation is determined in the same way as mentioned above.
>    Then, the string is encoded using the Base 64 encoding [RFC4648]
> 
> I assume you meant Section 4 alphabet and not Section 5 alphabet from this RFC.
> Please add section reference to the above.

Good point to clarify it's a BASE64, not a filesystem-safe variant.
Thank you.

>    When the client is a Web browser with any scripting capabilities, the
> 
> Can you explain why scripting capabilities are important here?

I'll add some notice about security concern here.
The second paragraph describes possible use of mutual user authentication
as a replacement for host identity verification.

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

OK.  The point is that the "recipient" has freedom there:
it MAY accept and it MAY reject.

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

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