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

[Kathleen Moriarty <[e-mail]>]

Hi Alexey,

Can you take a look at the updated draft to see if your concerns are
addressed?

Thank you,
Kathleen

On Wed, Nov 9, 2016 at 9:52 AM, <[e-mail]> wrote:

>
>
> Please excuse typos, sent from handheld device
>
> > On Nov 9, 2016, at 2:18 AM, Yutaka OIWA <[e-mail]> wrote:
> >
> > 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.
> >
>
> Thank you.  If you'd like to send in the draft via email and copy me, I
> will approve the publication so we can progress this draft and I believe
> close the WG.
>
> Thank you,
> Kathleen
>
> >
> >> 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]
>



-- 

Best regards,
Kathleen