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

[Yutaka OIWA <[e-mail]>]

Dear Kathleen,

thank you very much.
I finally looked through all the comments (as far as I noticed),
and reflected for the draft candidate texts in the following location:
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-protocol.txt
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-algorithms.txt

Once the IETF draft submission system is reopened on 13 Nov, I'll submit the
revised draft formally to the IETF again.


On 11/08/16 10:44, Kathleen Moriarty wrote:
> 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
>>
> 
> 
> 

-- 
大岩 寛   Yutaka OIWA             (国研)産業技術総合研究所 情報技術研究部門
                                     サイバーフィジカルウェア研究グループ長
                                      <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]