[http-auth] (due Oct 04) Mutual-auth issues (part 3)
Yutaka OIWA <y.oiwa@aist.go.jp> Wed, 23 September 2015 14:27 UTC
Return-Path: <y.oiwa@aist.go.jp>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8111A6EE0 for <http-auth@ietfa.amsl.com>; Wed, 23 Sep 2015 07:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 oXXTEWU1B6JL for <http-auth@ietfa.amsl.com>; Wed, 23 Sep 2015 07:27:18 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0061.outbound.protection.outlook.com [104.47.124.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312A91A21BD for <http-auth@ietf.org>; Wed, 23 Sep 2015 07:27:18 -0700 (PDT)
Received: from OS1PR01MB0200.jpnprd01.prod.outlook.com (10.161.230.139) by OS1PR01MB0198.jpnprd01.prod.outlook.com (10.161.229.18) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 14:27:15 +0000
Received: from OS1PR01MB0200.jpnprd01.prod.outlook.com ([10.161.230.139]) by OS1PR01MB0200.jpnprd01.prod.outlook.com ([10.161.230.139]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:27:15 +0000
From: Yutaka OIWA <y.oiwa@aist.go.jp>
To: "http-auth@ietf.org" <http-auth@ietf.org>
Thread-Topic: (due Oct 04) Mutual-auth issues (part 3)
Thread-Index: AdD2C0A8YXdwq6b8Q9+w1xwKGLCSuQ==
Date: Wed, 23 Sep 2015 14:27:14 +0000
Message-ID: <OS1PR01MB0200AAA1E15F1B757914887EA0440@OS1PR01MB0200.jpnprd01.prod.outlook.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp;
x-originating-ip: [61.196.47.27]
x-microsoft-exchange-diagnostics: 1; OS1PR01MB0198; 5:07AZlvKfwygelw6AXtgjUafbYFLVaF3nxP1kn4bchOgc8BizjoThR7omsdd0rsJ++6wtQnAlkhI8594RE+8gVAeXIsTbZliYd2/bcs4wkTejBQrnNrkg4+do8dovttoEVZMIEuMzgTFDOTgeMMEqPw==; 24:kLNhvjo+teFHnQa262T3hJq9KiSHuTrsfq/zkNlAnvGqz7iqPyuH1RM0DUuE/9LGcojZ3xNGI3nCw4Qw6pyDWLqDw8ALcbhpayxXYLD2FmQ=; 20:1kkpfC3/mDbMYcibdc6h5cIpudQ0c5dLrtZL291SF7iA3AjEsY9SRYkhQLZ/lesNLu11j+KUB1MsoLoOfJ7F8Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0198;
x-microsoft-antispam-prvs: <OS1PR01MB0198CAFF44D73C3A226FC96DA0440@OS1PR01MB0198.jpnprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:OS1PR01MB0198; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0198;
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(504964003)(199003)(189002)(92566002)(54356999)(62966003)(46102003)(50986999)(74316001)(68736005)(66066001)(2900100001)(122556002)(74482002)(77156002)(33656002)(86362001)(229853001)(2351001)(2501003)(106356001)(107886002)(450100001)(77096005)(76576001)(101416001)(105586002)(189998001)(87936001)(102836002)(19580405001)(5001920100001)(5004730100002)(5007970100001)(5002640100001)(19580395003)(64706001)(97736004)(40100003)(15975445007)(11100500001)(5003600100002)(5001960100002)(5001860100001)(4001540100001)(5001830100001)(81156007)(110136002)(10400500002); DIR:OUT; SFP:1101; SCL:1; SRVR:OS1PR01MB0198; H:OS1PR01MB0200.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: aist.go.jp
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:27:14.6052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 18a7fec8-652f-409b-8369-272d9ce80620
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0198
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/bexxdLQChgeGj_UHZyLnqEVYHxY>
Subject: [http-auth] (due Oct 04) Mutual-auth issues (part 3)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Sep 2015 14:27:22 -0000
Dear all HTTPAUTH WG members, I'd like to have your comments on the following four issues. Please make your initial response *before October 04*, or the WG will consider these issues as successfully resolved (as the WG Chair said in the Prague meeting.) We appreciate your responses in any of the following form: * on the github issue tracking system (comments, pull-request etc.) * on this mailing list * on the private email We'll summarize comments on the medium above, and send it to this mailing list. (Please be understood that your comments on the private email may be included in the summary and published.) This time, all of issues are related with TLS channel bindings. Related part is Section 7 of the draft-ietf-httpauth-mutual. (P8) Is it reasonable to use RFC 5929 "TLS channel binding"? We guess general consensus is "yes", with some care for known vulnerabilities. These comments are already reflected in the latest draft. Additional comments are welcome. https://github.com/yoiwa/httpauth-mutual/issues/8 (P9) tls-unique binding is somewhat tricky with HTTPS authentication, as keys might be different among multi-trip exchange requests, especially when anonymous TLS ciphersuite is used. Current definition "will work", at least. Do you think the current text is satisfactory? Are more cautionary texts needed? https://github.com/yoiwa/httpauth-mutual/issues/9 (P10) If 512-bit-worth user authentication is performed on TLS channels with 256-bit-worth server authentication (RSA certificate with SHA-256 hash), is it satisfactory to use 256-bit channel binding datum? Use of RFC 5929 implies this, because binding datum size is determined only by TLS certificate hash algorithm. https://github.com/yoiwa/httpauth-mutual/issues/10 Thank you in advance for your cooperation. -- Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group Information Technology Research Institute National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]