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

kathleen.moriarty.ietf@gmail.com Wed, 09 November 2016 14:52 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 3BF751295D5; Wed, 9 Nov 2016 06:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 oRXOnp50jlyP; Wed, 9 Nov 2016 06:52:41 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 BB4AF1295A3; Wed, 9 Nov 2016 06:52:41 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id p16so127689832qta.0; Wed, 09 Nov 2016 06:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ev2fCzEVxpg+K0dRQ9pDgAbqpL2Dsu71qDoLsvjdQeo=; b=U2N031hOoh91yln7+DcX7FVjcGmkt3R8z/o1EFsTVOLWbSwQ3ay9m8n9kmC20qTm4y efizvrc4kLavwOM9nb/ECf2PJzsDmFfj3/8UUTcWQFcydOCYb/e8otvWWW8Gv9fTX/q2 xKeLM+AKhjhqoGFoPFyMm3YPo0R6aGJXM0VG8p710ksgF+bLZ/DrT8JNQQHA3/CW4EuQ iQVSDrPIkJUoV+MYa+O79RYlxF4KxI0L/ppgZTv10yGwPGAKcmNxGQbJ3vSDiOyV8Fx4 0g58GewuOixotOZH5K9y9SqyJm24CE4c3LJq99JxrHurow2ITJw/AIUj8W5nbdcTAyLe C6bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ev2fCzEVxpg+K0dRQ9pDgAbqpL2Dsu71qDoLsvjdQeo=; b=NaBKxm30Ji7sy3xlszVG66jDcH4XghkOEVls87GVJQwxcNvNS4KKMCMWQ3VfM2/UUw 4EDt9epvY5pxhdnzhmdOd6UPX41Q/4iqYRy2OWrkIRaYES+IcaIGEThEcWMdfmaNQxj6 2mpEIgxNDKYyNgpB4ydU2Vm0u6Eh4F47+ZKooZtw1ftu5LqYrc4IJYi2n0fq5DQvo4B6 FD7uFEpTZi2i8FTrLWTteSnDur1oLQ5mNpq8EtSMIHlxQWYZuVN2ZoH6zqYC27aq7KF7 V52hqOi/ml/lnXuKeUfsyWfwySU8OnOSqs7fE9Lxi5GuOHSljTWK65Bncs/2/cSOaPQZ 328w==
X-Gm-Message-State: ABUngvdIWchih+8I8Hy5EZeD/Ni2R7BqiTOEp/HUsfDh6FmojsdJM2idtWbXcqcXb4FMBQ==
X-Received: by 10.200.41.248 with SMTP id 53mr19698014qtt.3.1478703160800; Wed, 09 Nov 2016 06:52:40 -0800 (PST)
Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id x13sm22522668qkb.45.2016.11.09.06.52.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Nov 2016 06:52:40 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: kathleen.moriarty.ietf@gmail.com
X-Mailer: iPhone Mail (13G36)
In-Reply-To: <a539d222-6eac-555d-8e22-8320fabac5b8@aist.go.jp>
Date: Wed, 9 Nov 2016 09:52:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/km3txVzQl2VHZ6MsOL-lX8rCnHw>
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: Wed, 09 Nov 2016 14:52:44 -0000


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]