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, 09 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>, <yutaka@oiwa.jp> > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
- [http-auth] Alexey Melnikov's Discuss on draft-ie… Alexey Melnikov
- Re: [http-auth] Alexey Melnikov's Discuss on draf… Kathleen Moriarty
- Re: [http-auth] Alexey Melnikov's Discuss on draf… 大岩寛
- Re: [http-auth] Alexey Melnikov's Discuss on draf… Yutaka OIWA
- Re: [http-auth] Alexey Melnikov's Discuss on draf… kathleen.moriarty.ietf
- Re: [http-auth] Alexey Melnikov's Discuss on draf… Kathleen Moriarty