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

[Kathleen Moriarty <[e-mail]>]

Hello,

I have not seen a response to this discuss (or some of the other comments),
please respond and discuss these questions and comments.  It would be good
to wrap up these last 2 drafts soon.

Thank you,
Kathleen

On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <[e-mail]>
wrote:

> 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.
>
>
> _______________________________________________
> http-auth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-auth
>



-- 

Best regards,
Kathleen