Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT)

大岩寛 <> Wed, 16 November 2016 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AAC2129648; Tue, 15 Nov 2016 20:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SnLcNMMVvUmF; Tue, 15 Nov 2016 20:51:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B49EA129472; Tue, 15 Nov 2016 20:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pu8m253afLEU08g2DY08uMe3o2vGBRuHeNz3rfhts7M=; b=ghjiVt44F2alfxzDhUHIaTeC9j08S23hnMnclFmpgVvf5yTLoixDXBdbOgFcUPMJoL9kEhV8oyTMgMyLQjUX12znoLYJOx/RWAsPTXRwWlveWCzuH4PNR8lUxaPJsgRRXG42so61OgzGcFZ4WAGDpeklI2WiqLd9NBQz7i699t4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Wed, 16 Nov 2016 04:50:58 +0000
Received: from ([]) by ([]) with mapi id 15.01.0721.015; Wed, 16 Nov 2016 04:50:58 +0000
From: 大岩寛 <>
To: Alexey Melnikov <>, The IESG <>
Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT)
Thread-Index: AQHSPwHZFR+mHpAHAEOgxXkOqeRPfqDbCWyQ
Date: Wed, 16 Nov 2016 04:50:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; TY1PR01MB0587; 7:GEuLRqzeEuKzOkjcPYJApi6sBl7nmIqsLLqx81eBga+fL4oJyNKRDrfhFGp3DX+QCe4b8sbT98LguVdpxGTpS3ehiDymow5piqENM9X7WwvMI1tnjNQSZMHu1UYfTGMCcyYDoXmo9P5JpGdL4hNJGVkICYCOO6jgK2wPxD4bC6OlGwtrvFwoxIHPk/JovEt4NBI/gsAPCjL6M5amDLYvtRXcVsEkIvzWADw2YoTa3DqeRcHbvZ4qN9Vw9TmiVOawk8rEMPvXBtMcDLV1cyKBfYhcyVZrkvwpv+ucJwFZH/Yxrq4sX/1/iWTjTaxQUeYey0ZdmGihZo1ll/zr7GBOYRRDjo8d0BGBXFMjqOMo8z4=
x-ms-office365-filtering-correlation-id: 1476824e-4ba1-431b-d31c-08d40ddc281a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0587;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324); SRVR:TY1PR01MB0587; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0587;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(8676002)(6116002)(33656002)(3846002)(102836003)(76176999)(86362001)(54356999)(81156014)(74316002)(8936002)(76576001)(74482002)(9686002)(77096005)(101416001)(106356001)(105586002)(6506003)(122556002)(551544002)(97736004)(106116001)(229853002)(2906002)(81166006)(50986999)(5660300001)(68736007)(8666005)(92566002)(4326007)(189998001)(2900100001)(305945005)(42882006)(345774005)(3660700001)(87936001)(3280700002)(5001770100001)(2950100002)(85182001)(7696004)(66066001)(7736002)(7846002)(230783001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0587;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 04:50:58.2214 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 18a7fec8-652f-409b-8369-272d9ce80620
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0587
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2016 04:51:10 -0000

Dear Alexey,

Thank you for your reviews.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for addressing my DISCUSS points and most of my comments!
> 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?
> 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?

I believe that these three points are addressed in draft-11.

> In Section 15:
> It would be good to be able to bind extension data to shared secret constructed
> by both parties.

I think it's quite interesting.
However, I don't have a good idea for stable enough expression of this
for good interoperability.
(It's similar to header signing, it's important but difficult thing.)
If it will become important, I'd like to address it in possible future
revision of the protocol.
Currently, if some extension is really strongly "critical", we can define
a new variant of the "algorithm" to overcome that.

Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <>, <>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]