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

大岩寛 <> Tue, 08 November 2016 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 691F4129C89; Tue, 8 Nov 2016 00:56:45 -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 dyHjOIXgPrZB; Tue, 8 Nov 2016 00:56:43 -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 1D350129C8B; Tue, 8 Nov 2016 00:56:43 -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=iLUwznzU5qaFK+ccla39WFkJAMKwzeA3S2+LM2JcrVA=; b=MZ9Z8piJTVMwSD6mkCj6WrpeLxNiU/95ij7NhitkjDbmmzxi2JbNHqzl+HKLvW99Qht5I8MTCjXuTB2f7aCRWO/WK0TtTR1qnSHMV6S9FgG/DiEmrdIOG6sliKZFL82F70SQ5RlCXL5QQ/Vz1oG9ji6k4Z8OJbqlgoHp4k2p1gA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 8 Nov 2016 08:56:39 +0000
Received: from ([]) by ([]) with mapi id 15.01.0693.016; Tue, 8 Nov 2016 08:56:39 +0000
From: 大岩寛 <>
To: Alexey Melnikov <>, The IESG <>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)
Thread-Index: AQHSNcrlDn92ybNtU0qJdkTyqetj76DOy4uQ
Date: Tue, 08 Nov 2016 08:56:38 +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-ms-office365-filtering-correlation-id: 3be89c08-df05-4ffe-0e64-08d407b52714
x-microsoft-exchange-diagnostics: 1; TY1PR01MB0586; 7:OzeyD0wycUsM+m0Cp2IBHFdzL8P38ZwxZfiVL6wV8Tq+iw8VlyDFzYQHJkarbCrkIRPuFT373TWe0t672M+uwpZo68/BeegotphH9ex1MzfxZienQb6QBJIEl7hKeV/6h8UOuNd1o9/RMtjXtRKzO9gKdikNbJr45Rx+L79uv4NneHacryt+kBdnrPhUToD8aGNxwL1/5bVQWF8CJ+VDclZPpZKqGBWVXItWjnaLanniWZyZMBQ2TY9nWQY5vH4NprmfhNwYpPBmYVorD68QeyJdcVqQg4DNk8Chk8sXK/SUCXq6FzYEuBuRpr4eFV05faXO+w5zurZOYHv/jRxIMJ7wu3KOvQzHPv+vLQJdxrk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0586;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:TY1PR01MB0586; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0586;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(2950100002)(33656002)(8936002)(8666005)(42882006)(5660300001)(7846002)(9686002)(105586002)(8676002)(87936001)(3280700002)(66066001)(5001770100001)(189998001)(106356001)(106116001)(345774005)(68736007)(3660700001)(81156014)(81166006)(122556002)(101416001)(54356999)(50986999)(86362001)(76576001)(74316002)(85182001)(586003)(102836003)(230783001)(6116002)(2906002)(3846002)(2900100001)(92566002)(4326007)(77096005)(74482002)(305945005)(7736002)(7696004)(97736004)(76176999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0586;; 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: 08 Nov 2016 08:56:39.0171 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 18a7fec8-652f-409b-8369-272d9ce80620
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0586
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and 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: Tue, 08 Nov 2016 08:56:45 -0000

Dear Alexey:

Thank you for really valuable comments.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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

Yes, we'll do it.

> 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.

We'll clarify it by replacing the second sentence by a text suggesting
tls-unique is not likely to be required to implement, in most cases.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------

Thank you for many improvement suggestions.
For so many suggestions replacing SHOULD with MUST, most of these seem
to be correct.  We'll review all of these again to make a final decision.

> 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.

We'll do it.

>    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.

Good point to clarify it's a BASE64, not a filesystem-safe variant.
Thank you.

>    When the client is a Web browser with any scripting capabilities, the
> Can you explain why scripting capabilities are important here?

I'll add some notice about security concern here.
The second paragraph describes possible use of mutual user authentication
as a replacement for host identity verification.

> 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.

OK.  The point is that the "recipient" has freedom there:
it MAY accept and it MAY reject.

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

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]