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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 15 November 2016 05:07 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DE01298C5; Mon, 14 Nov 2016 21:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uOiW0oy8Zyb; Mon, 14 Nov 2016 21:07:04 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC713129501; Mon, 14 Nov 2016 21:07:03 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id 12so79818380uas.2; Mon, 14 Nov 2016 21:07:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AoYW1yW6H/lv1DyTOB2etdpbDO+V3KfHBVORePRSpTs=; b=uj7eVf63MmieCir+Uvi0blDZO7WPYeMxVZNZ9d6k8jMoOsJ6mKVPtB3CzZwkSzOteK /enH5tKsifzzFW0vqsGREfPLsM7ZS9Na+DQOG3f4RiwNVxL/9W5ks6xLE5xqfT56y9RL w2HpsMUjmX8neZfJkLhdHWKORkDZCKrfORxp3W+HtsskaNM6ldpiMUcZxTEXIcy8l03H PxKm4cjXnUkmawIKJmL7RVWuRCAI6y+2pk30GFFmpfOUSoYgJD60yRyb+lk3FmsovnVx JIY/3h6SytRiFys6hkyDGSPwQzjNgpGXiQF7Cr0g/G1ibUfT6dKmKUFM+Fu3Paj9SH2b Ts8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AoYW1yW6H/lv1DyTOB2etdpbDO+V3KfHBVORePRSpTs=; b=h9ZkW4xoOKTAAD/l3HsfRiusmOWCPKSEfaC08xTmv8tIgJ5hk2wsUPFgBXktPnRUDT WV/hDCgO0IqDiVqp5vTm3Pp5C82ihV2TNhLnxQ9/PQXsWR+nq2DgWQpFujzkUK0J/iBr nB4G2v1nWS9LmNuymi0cABovsJlyuY2JOoqhPTL0Eg740tHKLcYHkv7bfFzdiWDHtug5 dae7ui2Is7b3CVnFw2eoA5fdPXGOxgz7XGYHqbfZXWhz+9BEBla7iJDA/uuAN3NG5zCo g/Jf7AVD30g7zRadsPkAI4lHVpby3nw6Ty99Ao+ZybmPKujnBGFGuYxXmnUKhWY/hK2V NOVQ==
X-Gm-Message-State: ABUngvcMeDi1B+NH36nJTbj8gg6HdIuiMRx5WAAj8o1CzpTKxVNp+i42g2Bbt5Nr/05qXB7S0vc8j96aDSZYSQ==
X-Received: by 10.176.0.147 with SMTP id 19mr10152617uaj.20.1479186422761; Mon, 14 Nov 2016 21:07:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.82.143 with HTTP; Mon, 14 Nov 2016 21:07:02 -0800 (PST)
In-Reply-To: <830EE33D-60BC-48BF-BF96-275ACC563CB6@gmail.com>
References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> <CAHbuEH6VfOOG3+nzAfje=TiNVpfC0Eqmxwnj6gO3bE1Q4oZ6oQ@mail.gmail.com> <a539d222-6eac-555d-8e22-8320fabac5b8@aist.go.jp> <830EE33D-60BC-48BF-BF96-275ACC563CB6@gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 15 Nov 2016 00:07:02 -0500
Message-ID: <CAHbuEH6==TpBsS2Ty=KSDJHs8yWKznhepGP_BZVTSYGHgzx5bw@mail.gmail.com>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Content-Type: multipart/alternative; boundary=001a113dda6049114805414fedda
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/CaNSPUrhlnblB-mV6axRcSSiB7Q>
Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" <http-auth@ietf.org>, httpauth-chairs@ietf.org, The IESG <iesg@ietf.org>, Alexey Melnikov <aamelnikov@fastmail.fm>
Subject: Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 05:07:06 -0000

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, <kathleen.moriarty.ietf@gmail.com> wrote:

>
>
> Please excuse typos, sent from handheld device
>
> > On Nov 9, 2016, at 2:18 AM, Yutaka OIWA <y.oiwa@aist.go.jp> 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 <aamelnikov@fastmail.fm
> >
> >> 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
> >>> http-auth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/http-auth
> >
> > --
> > 大岩 寛   Yutaka OIWA             (国研)産業技術総合研究所 情報技術研究部門
> >                                     サイバーフィジカルウェア研究グループ長
> >                                      <y.oiwa@aist.go.jp>jp>, <
> yutaka@oiwa.jp>
> > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405
> 46B5]
>



-- 

Best regards,
Kathleen