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

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

Alexey Melnikov has entered the following ballot position for
draft-ietf-httpauth-mutual-10: Discuss

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/



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

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.


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


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?

3.2.  Values

   The parameter values contained in challenge/credentials MUST be
   parsed strictly conforming to the HTTP semantics (especially un-
   quoting of the string parameter values).  In this protocol, those
   values are further categorized into the following value types: tokens
   (bare-token and extensive-token), string, integer, hex-fixed-number,
   and base64-fixed-number.

   For clarity, implementations are RECOMMENDED to use the canonical
   representations specified in the following subsections for sending
   values.  Recipients SHOULD accept both quoted and unquoted
   representations interchangeably as specified in HTTP.

I think the last SHOULD must be a MUST, because clients that generate
these values
might be using libraries that automatically quote values. So this is
really not
under sender's control.


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.

In 3.2.3:

I think you are overusing SHOULDs instead of MUSTs in many
places in the document (not just just in this section). For example:

   When
   these values are generated from any cryptographic values, they SHOULD
   have their "natural length"; if these are generated from a hash
   function, these lengths SHOULD correspond to the hash size;

Why not a MUST here?

   if these
   are representing elements of a mathematical set (or group), its
   lengths SHOULD be the shortest for representing all the elements in

Again, why not a MUST? Having a unique encoding will improve
interoperability.

   the set.

   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.

   without any spaces and newlines.  Implementations decoding base64-
   fixed-number SHOULD reject any input data with invalid characters,
   excess/insufficient padding, or non-canonical pad bits (See Sections
   3.1 to 3.5 of [RFC4648]).

7.1.  Applicability notes

   When the client is a Web browser with any scripting capabilities, the

Can you explain why scripting capabilities are important here?

   underlying TLS channel used with HTTP/TLS MUST provide server
   identity verification.  This means (1) anonymous Diffie-Hellman key
   exchange cipher suites MUST NOT be used, and (2) verification of the
   server certificate provided by the server MUST be performed.

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.