From nobody Tue Nov 1 06:58:15 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E837D129426; Tue, 1 Nov 2016 06:58:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147800869091.23840.18136834516271995868.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 06:58:10 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-httpauth-mutual-10=3A_=28with_COMMENT=29?= X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 13:58:11 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well written spec! One important question: Doesn't this spec need to register a new HTTP Authentication Schemes ("Mutual") with IANA? Further minor comments/questions: 1) Somehow I don't understand this: "For responses, the parameters "reason", any "ks#" (where # stands for any decimal integer), and "vks" are mutually exclusive; any challenge MUST NOT contain two or more parameters among them. They MUST NOT contain any "kc#" or "vkc" parameters." Who is 'they' in the last sentence? 2) "Typically, clients can ensure the above property by using a monotonically-increasing integer counter that counts from zero up to the value of nc-max." Wouldn't it be better to use a randomized number? 3) Nit: s/Even if the request-URI does not have a port part, v will include the default port number./Even if the request-URI does not have a port part, vh will include the default port number./ From nobody Tue Nov 1 07:06:26 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A824012944B; Tue, 1 Nov 2016 07:06:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147800918266.23964.2036672957524529397.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 07:06:22 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org Subject: [http-auth] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-httpauth-mutual-algo-06=3A_=28with_COMMENT=29?= X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 14:06:22 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-httpauth-mutual-algo-06: No Objection 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-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In relation to Alvaro's comment on draft-ietf-httpauth-mutual, the first part of the Intellectual Properties Notice does not seem to apply here and the note is probably not needed at all. From nobody Tue Nov 1 07:30:05 2016 Return-Path: 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 34350129705; Tue, 1 Nov 2016 07:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 TK_HDhrV2hdv; Tue, 1 Nov 2016 07:29:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180E71296FB; Tue, 1 Nov 2016 07:29:54 -0700 (PDT) Received: from [192.168.178.20] ([93.217.118.239]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MV5hN-1cMoLq3WP7-00YNgc; Tue, 01 Nov 2016 15:29:51 +0100 To: Mirja Kuehlewind , The IESG References: <147800869091.23840.18136834516271995868.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <86fe8602-91c7-aff0-ad16-419c9a45891f@gmx.de> Date: Tue, 1 Nov 2016 15:29:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147800869091.23840.18136834516271995868.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0qHbFzojEPGJIP7QoK/NAytu/JEkPKO99Vzuwgbd4jYFvIiiyXy q1zU5J6Oh1QKGgpy0eDYMBOd4QQZg/6OI4ywAIzA3x2v9dJOFEvhXBYAeiTFVkFrnqqb2ki wNhWS+zRWIQmbtJ+sQe+OEl2RJyrOCQda0h4lm4VBmei9wg06t3bHg/Oavrq4QLspcXUId0 VfPaIUzJuB0MtODxkDsOg== X-UI-Out-Filterresults: notjunk:1;V01:K0:F5JPw/CvvRY=:w/NgAlusitvkRryGpRHIdM vqc+oAAXN/QSUsPf/sjf6WogUfdAvzxltVA91vfRCyyl3nF5NjqGy3aeXlrTKDrPUEwNIx0hX RQz1XBQcEU3I8g7MB6+AXS7sWq6LB8YxppUVpp3Z/spSQYnnwcR56K+49mr1SF4J8UktLTHpg 7V0W78uA3BkyHkyy+sWaMEU/3YFSzmQyJ+erXi4W3PDg+fenTh1nkRqd0FoOvU7evkOMPdo9i cP5iUDc2ESGaVYBJp+VFKZQ2f5YHSFcCCCBK9hWuXhGGy6k0KasSVFpXL8/d28WZuTVEJqq2F YTS39bC6SqcIb8Ruh+Il3GsinrvFpJi8L29af/0fnLTBUOPPOSLZc91caeWri7NkPAzc6cSvM hrSXito1J2x79Kh+q3scUNIO9Mv+8w+hK0piaLVgLwJnrpzeuaAt1zf+v1hTbjjX6sCtl/oE2 XHCWaq7/F6yVK4EiAUi4hIE1KI/DIt+RvkSL8dn6zlzZN6m67I04sThe+GBOz3xk+QHgF0mfj 7qBLzuYlo3Nwoq6jZUoznsCwaBmoVChzZTIewB2EwjR+x4y03nyhKJi39GMURa77Sr5nj5dN/ qwaIBJeZdss1ExFLsE2asL3iwALdJ9Aa4eSxiQeAZxbbP5O+pC8XYqMPla9JnrYXfSvV0+2Oa HXGt99+tuvzYvOm2VJnCdVDJOycRKN/UDy/uwIsHpeq31je268ELpueGvar2MRrAeQJ3Uyt0h BOireq8yTp1XgntJ6iec08DJopvb9le4OupQIiq4w5QU9dXrYQBruyuhq5D1ESaq54UFoSaRJ Cf47khr Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, http-auth@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-httpauth-mutual-10=3A_=28with_COMMENT=29?= X-BeenThere: http-auth@ietf.org 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, 01 Nov 2016 14:29:57 -0000 On 2016-11-01 14:58, Mirja Kuehlewind wrote: > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this well written spec! > > One important question: > Doesn't this spec need to register a new HTTP Authentication Schemes > ("Mutual") with IANA? > ... Indeed, it has to. Best regards, Julian From nobody Tue Nov 1 14:54:23 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 672D712955C; Tue, 1 Nov 2016 14:54:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147803726238.23936.13603337353694114557.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 14:54:22 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org, bill.wu@huawei.com Subject: [http-auth] Benoit Claise's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:54:22 -0000 Benoit Claise has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some editorial comments from our OPS-DIR reviewer, Qin Wu. I believe this document is ready for publication. Here are a few editorial comments I like to ask authors to consider: Minor issues: 1. Section 1.1 said: “ When a natural number output is required, the notation INT(H(s)) is used. ” I will see INT(H(s)) as a formula to convert H(s) into natural number 2. Section 2, 1st paragraph: What is DL-based notations? Can you expand DL? Is it Description Logic or something else? You can consider to add acronym and abbreviation section. 3.Section 2, 2nd paragraph and the figure that describe protocol exchange for four value Where you define the first two messages in this draft? Are you referred to the first messages that contain ID, K_c1 and K_s1 respectively in the figure? I don’t see you specify message format or give a message name? I don’t see you related text with the message shown in the figure? In addition, where the last two message defined in [I-D.ietf-httpauth-mutual]? Can you provide section number? By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and am wondering if this draft really defines the first two messages? Or four message shown in the figure are all defined in the [[I-D.ietf-httpauth-mutual]. 4.Section 3.1, 3rd paragraph said: “ The functions named octet(), OCTETS(), and INT() are those defined in the core specification [I-D.ietf-httpauth-mutual]. “ Is the core specification [I-D.ietf-httpauth-mutual]the core document mentioned in section 3? If yes, please make them consistent. 5.Section 3.3, symbol “G” g: for "the generator" associated with the group. How the symobol “G” is different from symbol “g”in the section 3.2? Does G stand for the generator associated with the defined group? What do you mean “the defined point”? Would be great to clarify the difference between G and g. 6.Section 5.2 said: “ In the EC setting, r has to be prime. Defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions. “ What is EC setting? Please expand EC? Elliptic Curve? Please make this clear or add this abbreviation into abbreviation section. Nites: 1.Section 1,1st paragraph s/ use withMutual authentication protocol/ use with Mutual authentication protocol 2.Section 5.2 s/ mixing values from from two/ mixing values from two -Qin From nobody Tue Nov 1 14:56:03 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B3F1298C8; Tue, 1 Nov 2016 14:56:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147803736185.23916.11651954827701159675.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 14:56:01 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org, bill.wu@huawei.com Subject: [http-auth] Benoit Claise's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:56:02 -0000 Benoit Claise has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Forget about my last COMMENT, which was for a different draft From nobody Tue Nov 1 14:57:18 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1FB129A19; Tue, 1 Nov 2016 14:57:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147803743730.23848.16641230739986102968.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 14:57:17 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org, bill.wu@huawei.com Subject: [http-auth] Benoit Claise's No Record on draft-ietf-httpauth-mutual-algo-06: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:57:17 -0000 Benoit Claise has entered the following ballot position for draft-ietf-httpauth-mutual-algo-06: No Record 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-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some editorial comments from our OPS-DIR reviewer, Qin Wu. This document defines four HTTP Mutual authentication algorithms which use with Mutual authentication protocol for HTTP, two for Discrete Logarithm settings, two for elliptic curve settings. In addition, the security of this algorithm is well analyzed. There is no major issue. I believe this document is ready for publication. Here are a few editorial comments I like to ask authors to consider: Minor issues: 1. Section 1.1 said: “ When a natural number output is required, the notation INT(H(s)) is used. ” I will see INT(H(s)) as a formula to convert H(s) into natural number 2. Section 2, 1st paragraph: What is DL-based notations? Can you expand DL? Is it Description Logic or something else? You can consider to add acronym and abbreviation section. 3.Section 2, 2nd paragraph and the figure that describe protocol exchange for four value Where you define the first two messages in this draft? Are you referred to the first messages that contain ID, K_c1 and K_s1 respectively in the figure? I don’t see you specify message format or give a message name? I don’t see you related text with the message shown in the figure? In addition, where the last two message defined in [I-D.ietf-httpauth-mutual]? Can you provide section number? By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and am wondering if this draft really defines the first two messages? Or four message shown in the figure are all defined in the [[I-D.ietf-httpauth-mutual]. 4.Section 3.1, 3rd paragraph said: “ The functions named octet(), OCTETS(), and INT() are those defined in the core specification [I-D.ietf-httpauth-mutual]. “ Is the core specification [I-D.ietf-httpauth-mutual]the core document mentioned in section 3? If yes, please make them consistent. 5.Section 3.3, symbol “G” g: for "the generator" associated with the group. How the symobol “G” is different from symbol “g”in the section 3.2? Does G stand for the generator associated with the defined group? What do you mean “the defined point”? Would be great to clarify the difference between G and g. 6.Section 5.2 said: “ In the EC setting, r has to be prime. Defining a variation of this algorithm using a different domain parameter SHOULD be attentive to these conditions. “ What is EC setting? Please expand EC? Elliptic Curve? Please make this clear or add this abbreviation into abbreviation section. Nites: 1.Section 1,1st paragraph s/ use withMutual authentication protocol/ use with Mutual authentication protocol 2.Section 5.2 s/ mixing values from from two/ mixing values from two -Qin From nobody Tue Nov 1 16:57:38 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 895CA1295F6; Tue, 1 Nov 2016 16:57:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 16:57:33 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 23:57:33 -0000 Terry Manderson has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing a very detailed document. A few minor comments. 1) Please review the introduction, there are several grammatical errors in there. Meaning still came through just fine, but they were a little distracting. 2) The state machine diagram of the client is quite complex. A candidate for the new RFC format? 3) I agree with Alvaro's comment on the IPR. Thank you for making it royalty free, however not sure you need to add the text in the RFC. 4) This to me seems as it is essentially a shared secret construct, one sentence from RFC 2361 (security considerations) seems applicable here. "All the security in this system is provided by the secrecy of the private keying material." If this the case, please provide ample warning that (as one would expect) loss of the password from either the client or the server results in a complete compromise. From nobody Wed Nov 2 01:41:24 2016 Return-Path: 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 74872129453; Wed, 2 Nov 2016 01:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 fji_lAlRoHeN; Wed, 2 Nov 2016 01:41:20 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0063.outbound.protection.outlook.com [104.47.93.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354DE129420; Wed, 2 Nov 2016 01:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eTGg3HqJEmuFimE/F/X+iIeQtgNardKbzBYqXSKmUgQ=; b=LNiQQ/2C0Dp1yJV2Q9gTXAmlYF6KGzC/wAOHjNCFBq40Ac/U7xdy/zDN3h7PYZTL9E3+FPivmnWwWZ+plreQQ8HO1eGpU+23CFVuqtJNkZ7JH7VWWk4EvkOTIY8y9Rz+3404yM2mjH3RMGDBIfHPyYkvio9+cHz1oTz71QJ2+ns= Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) by TY1PR01MB0586.jpnprd01.prod.outlook.com (10.167.157.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Wed, 2 Nov 2016 08:41:17 +0000 Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) by TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) with mapi id 15.01.0693.009; Wed, 2 Nov 2016 08:41:17 +0000 From: =?utf-8?B?5aSn5bKp5a+b?= To: Terry Manderson , The IESG Thread-Topic: Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) Thread-Index: AQHSNJu5xGpJ15g3s0WN1353MighAKDFX2hw Date: Wed, 2 Nov 2016 08:41:16 +0000 Message-ID: References: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.com> In-Reply-To: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.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: [150.29.149.29] x-ms-office365-filtering-correlation-id: 8edd825c-45af-4c4a-4a78-08d402fc02f9 x-microsoft-exchange-diagnostics: 1; TY1PR01MB0586; 7:BF3H/fIF8RboTWYrmltlaR/q3gjSHVtJt180z/Bac2K6Xwh2BqkqF1fVQjbKNRCjlyOML5QmsnHW2MQTY0Ql5d2u1+fud7LWTQ1Xv63C802hWIGymgsQfznw475etHoawBqlWP5kOR+HuiNGiuRbfmpDcWk9tlATC3f7hJBjmIgF+C5jZi8W6DaqwDnPdrG5p3e1PzAbItbOKVJb4wQSzJ35Y5ck2u775yZyKRH5V0hJkC++Az4+/dHDI0Pfizu1nXzELFgLPnFGj8NY4EB3vonUBHYc98LNxf70uFsVn3sUV/IzxL3R0oSMiCmLS3zAXwGC7GZN405NLTjn4jXfICwLze2VKQ52xDs8KbQbJZo= 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)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:TY1PR01MB0586; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0586; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(45984002)(15594002)(199003)(122556002)(9686002)(345774005)(105586002)(10400500002)(66066001)(81156014)(86362001)(81166006)(106116001)(7736002)(5002640100001)(106356001)(74316002)(7696004)(19580405001)(8936002)(305945005)(68736007)(76576001)(2906002)(2950100002)(42882006)(77096005)(7846002)(97736004)(3660700001)(8676002)(5001770100001)(230783001)(54356999)(101416001)(92566002)(5660300001)(33656002)(551544002)(4326007)(2900100001)(87936001)(3280700002)(74482002)(11100500001)(189998001)(102836003)(6116002)(3846002)(76176999)(50986999)(19580395003)(586003)(85182001); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0586; H:TY1PR01MB0588.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: aist.go.jp 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-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2016 08:41:16.9927 (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: "http-auth@ietf.org" , "draft-ietf-httpauth-mutual@ietf.org" , "httpauth-chairs@ietf.org" Subject: Re: [http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org 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, 02 Nov 2016 08:41:22 -0000 RGVhciBUZXJyeSwgdGhhbmsgeW91IHZlcnkgbXVjaC4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENP TU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcyBmb3Igd3JpdGluZyBhIHZlcnkg ZGV0YWlsZWQgZG9jdW1lbnQuDQo+IA0KPiBBIGZldyBtaW5vciBjb21tZW50cy4NCj4gDQo+IDEp IFBsZWFzZSByZXZpZXcgdGhlIGludHJvZHVjdGlvbiwgdGhlcmUgYXJlIHNldmVyYWwgZ3JhbW1h dGljYWwgZXJyb3JzIGluDQo+IHRoZXJlLiBNZWFuaW5nIHN0aWxsIGNhbWUgdGhyb3VnaCBqdXN0 IGZpbmUsIGJ1dCB0aGV5IHdlcmUgYSBsaXR0bGUgZGlzdHJhY3RpbmcuDQoNCldlJ2xsIGRvIGl0 Lg0KDQo+IDIpIFRoZSBzdGF0ZSBtYWNoaW5lIGRpYWdyYW0gb2YgdGhlIGNsaWVudCBpcyBxdWl0 ZSBjb21wbGV4LiBBIGNhbmRpZGF0ZSBmb3INCj4gdGhlIG5ldyBSRkMgZm9ybWF0Pw0KDQpNYXli ZSA6LSkgIEkgaGF2ZSBwaWN0dXJlLWJhc2VkIChIVE1ML1BERikgdmVyc2lvbnMsIHRvby4NCg0K PiAzKSBJIGFncmVlIHdpdGggQWx2YXJvJ3MgY29tbWVudCBvbiB0aGUgSVBSLiBUaGFuayB5b3Ug Zm9yIG1ha2luZyBpdCByb3lhbHR5DQo+IGZyZWUsIGhvd2V2ZXIgbm90IHN1cmUgeW91IG5lZWQg dG8gYWRkIHRoZSB0ZXh0IGluIHRoZSBSRkMuDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRo ZSBzdWdnZXN0aW9uLg0KDQo+IDQpIFRoaXMgdG8gbWUgc2VlbXMgYXMgaXQgaXMgZXNzZW50aWFs bHkgYSBzaGFyZWQgc2VjcmV0IGNvbnN0cnVjdCwgb25lIHNlbnRlbmNlDQo+IGZyb20gUkZDIDIz NjEgKHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zKSBzZWVtcyBhcHBsaWNhYmxlIGhlcmUuDQo+ICJB bGwgdGhlIHNlY3VyaXR5IGluIHRoaXMgc3lzdGVtIGlzIHByb3ZpZGVkIGJ5IHRoZSBzZWNyZWN5 IG9mIHRoZSBwcml2YXRlIGtleWluZw0KPiBtYXRlcmlhbC4iIElmIHRoaXMgdGhlIGNhc2UsIHBs ZWFzZSBwcm92aWRlIGFtcGxlIHdhcm5pbmcgdGhhdCAoYXMgb25lIHdvdWxkDQo+IGV4cGVjdCkg bG9zcyBvZiB0aGUgcGFzc3dvcmQgZnJvbSBlaXRoZXIgdGhlIGNsaWVudCBvciB0aGUgc2VydmVy IHJlc3VsdHMgaW4NCj4gYSBjb21wbGV0ZSBjb21wcm9taXNlLg0KDQpXZSBhbHJlYWR5IHB1dCBz b21lIGFuYWx5c2lzIG9uIHRob3NlLCBidXQgd2UnbGwgbWFrZSBpdCBtb3JlIHByb21pbmVudC4N Ck1vcmUgcHJlY2lzZWx5LCBsb3NzIGZyb20gdGhlIGNsaWVudCBpcyByZWFsbHkgY3JpdGljYWwg KGV2ZW4gd2l0aCBhIHN0cm9uZyBwYXNzd29yZCk7DQpMb3NzIGZyb20gdGhlIHNlcnZlciBpcyBv bmx5IHNldmVyZSB3aGVuIHRoZSBwYXNzd29yZCBpcyB3ZWFrIGZvciBkaWN0aW9uYXJ5IGF0dGFj a3MuDQoNCg0KLS0gDQpZdXRha2EgT0lXQSwgUGguRC4gICAgICAgTGVhZGVyLCBDeWJlciBQaHlz aWNhbCBBcmNoaXRlY3R1cmUgUmVzZWFyY2ggR3JvdXANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJbmZvcm1hdGlvbiBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZQ0KICAg IE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBBZHZhbmNlZCBJbmR1c3RyaWFsIFNjaWVuY2UgYW5kIFRl Y2hub2xvZ3kgKEFJU1QpDQogICAgICAgICAgICAgICAgICAgICAgTWFpbCBhZGRyZXNzZXM6IDx5 Lm9pd2FAYWlzdC5nby5qcD4sIDx5dXRha2FAb2l3YS5qcD4NCk9wZW5QR1A6IGlkWzQ0MDU0NkI1 XSBmcFs3QzlGIDcyM0EgNzU1OSAzMjQ2IDIyOUQgIDMxMzkgODY3NyA5QkQyIDQ0MDUgNDZCNV0N Cg0K From nobody Wed Nov 2 01:55:44 2016 Return-Path: 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 06C3C12947D; Wed, 2 Nov 2016 01:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 zGrcc5hqCY1q; Wed, 2 Nov 2016 01:55:41 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0076.outbound.protection.outlook.com [104.47.93.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB281129411; Wed, 2 Nov 2016 01:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yfG2xwZqw0HZOdlSaGJ7oVH+ZWpVTOggKzjGwzhJtfw=; b=cpBaOtijF7hbfH0sPb4p84ylHtm76y43GrJqRFwnbKUjDZt57nKgQUaQUf9qgCiXv51ALPQ2AijlhbQ/2gOKQOmYGdJaiQ3XhFuWAoLXLNCODbBsi1A1dhkeuW7V6DBZ04nt7lSQh3382xidJtmqrmNdUIIvkeEYyFEs55+bzuM= Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) by TY1PR01MB0587.jpnprd01.prod.outlook.com (10.167.157.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Wed, 2 Nov 2016 08:55:37 +0000 Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) by TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) with mapi id 15.01.0693.009; Wed, 2 Nov 2016 08:55:37 +0000 From: =?utf-8?B?5aSn5bKp5a+b?= To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-httpauth-mutual-10:_(with_COMMENT)?= Thread-Index: AQHSNEf9quOyW8ARUEKI1Qq0z2sw5qDFYhsA Date: Wed, 2 Nov 2016 08:55:36 +0000 Message-ID: References: <147800869091.23840.18136834516271995868.idtracker@ietfa.amsl.com> In-Reply-To: <147800869091.23840.18136834516271995868.idtracker@ietfa.amsl.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: [150.29.149.29] x-ms-office365-filtering-correlation-id: 92a3aff3-62d0-4c13-9a80-08d402fe03a5 x-microsoft-exchange-diagnostics: 1; TY1PR01MB0587; 7:CVjieV/DcFrzjTUxwXxxfh7JujEYEmqtCvaQqhWqjUcqA3crScbagW+zkrNecilJzxzBdNZZqTnmXnr5jGliF0Zh2ZAvYh+n1kHtIznDqlXIsozfcl0MPZKvUrnkKzRk/xEzSingZ9ZtMTj4JVLG3o2FTIGzZ52xQ4MNbnJ4d7edDKmTY1pStbpep/9vbiQ40E324Iyocmu2lzo9QLyo65UK3J7U/g8yI9bJsUFN5IZNY6tEgnjZ+xPnm8W6/ohQpCqW7EqUUm9LMgKg2cyLnPAz/IsZyZf5UutzFG3BLgl0Q75Hg5Vq6fjK97QTSD+dyI1bRw/EnQZa9TJpiTvV9MGx622EMr99fKx8XUYt+JE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0587; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:TY1PR01MB0587; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0587; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(45984002)(199003)(92566002)(33656002)(7736002)(77096005)(305945005)(2900100001)(7846002)(189998001)(66066001)(5002640100001)(85182001)(87936001)(74482002)(230783001)(50986999)(42882006)(5660300001)(8936002)(81166006)(105586002)(81156014)(19580395003)(10400500002)(106356001)(97736004)(54356999)(76176999)(86362001)(2950100002)(101416001)(19580405001)(224303003)(106116001)(3280700002)(3660700001)(11100500001)(2906002)(122556002)(76576001)(224313004)(6116002)(74316002)(102836003)(3846002)(68736007)(7696004)(586003)(9686002)(5001770100001)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0587; H:TY1PR01MB0588.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: aist.go.jp 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-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2016 08:55:37.0114 (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: "http-auth@ietf.org" , "draft-ietf-httpauth-mutual@ietf.org" , "httpauth-chairs@ietf.org" Subject: Re: [http-auth] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-httpauth-mutual-10=3A_=28with_COMMENT=29?= X-BeenThere: http-auth@ietf.org 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, 02 Nov 2016 08:55:43 -0000 RGVhciBNaXJqYSwgdGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzLg0KDQoNCj4g T25lIGltcG9ydGFudCBxdWVzdGlvbjoNCj4gRG9lc24ndCB0aGlzIHNwZWMgbmVlZCB0byByZWdp c3RlciBhIG5ldyBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZXMNCj4gKCJNdXR1YWwiKSB3aXRo IElBTkE/DQoNCkFzIEp1bGlhbiBzdWdnZXN0ZWQsIHllcy4NCldlJ2xsIGFkZCBvbmUgbW9yZSBj bGF1c2UgdG8gSUFOQSBjb25zaWRlcmF0aW9uLg0KDQo+IEZ1cnRoZXIgbWlub3IgY29tbWVudHMv cXVlc3Rpb25zOg0KDQo+IDEpIFNvbWVob3cgSSBkb24ndCB1bmRlcnN0YW5kIHRoaXM6DQo+ICJG b3IgcmVzcG9uc2VzLCB0aGUgcGFyYW1ldGVycyAicmVhc29uIiwgYW55ICJrcyMiICh3aGVyZSAj IHN0YW5kcw0KPiAgICAgICBmb3IgYW55IGRlY2ltYWwgaW50ZWdlciksIGFuZCAidmtzIiBhcmUg bXV0dWFsbHkgZXhjbHVzaXZlOyBhbnkNCj4gICAgICAgY2hhbGxlbmdlIE1VU1QgTk9UIGNvbnRh aW4gdHdvIG9yIG1vcmUgcGFyYW1ldGVycyBhbW9uZyB0aGVtLg0KPiAgICAgICBUaGV5IE1VU1Qg Tk9UIGNvbnRhaW4gYW55ICJrYyMiIG9yICJ2a2MiIHBhcmFtZXRlcnMuIg0KPiBXaG8gaXMgJ3Ro ZXknIGluIHRoZSBsYXN0IHNlbnRlbmNlPw0KV2UnbGwgY2hhbmdlIGl0IHRvICJ0aGUgcmVzcG9u c2VzIi4NCg0KPiAyKSAiVHlwaWNhbGx5LCBjbGllbnRzIGNhbiBlbnN1cmUgdGhlIGFib3ZlIHBy b3BlcnR5IGJ5IHVzaW5nIGENCj4gICAgbW9ub3RvbmljYWxseS1pbmNyZWFzaW5nIGludGVnZXIg Y291bnRlciB0aGF0IGNvdW50cyBmcm9tIHplcm8gdXAgdG8NCj4gICAgdGhlIHZhbHVlIG9mIG5j LW1heC4iDQo+IFdvdWxkbid0IGl0IGJlIGJldHRlciB0byB1c2UgYSByYW5kb21pemVkIG51bWJl cj8NCg0KVGhpcyBpcyBieSBkZXNpZ24uDQpVc2Ugb2YgYW4gYWxtb3N0LXNlcXVlbnRpYWwgY291 bnRlciBtYWtlcyBlZmZpY2llbnQgZGV0ZWN0aW9uIG9mDQpyZXBsYXllZCBjaGFsbGVuZ2VzIGJl IHBvc3NpYmxlIHdpdGggY29uc3RhbnQgbWVtb3J5IHNwYWNlLg0KVXNpbmcgcmFuZG9tIG51bWJl cnMsIHRoZSBzZXJ2ZXJzIG11c3QgcmVtZW1iZXIgYWxsIHVzZWQgbm9uY2VzDQp0byBkZXRlY3Qg cmVwbGF5cywgd2hpY2ggcmVxdWlyZXMgbWVtb3J5IHNwYWNlIHByb3BvcnRpb25hbCB0bw0KdGhl IGxpZmV0aW1lIG9mIHRoZSAic2hhcmVkIGtleSIgKHogaW4gdGhlIHNwZWNpZmljYXRpb24pLg0K SW4gdGhpcyBhbGdvcml0aG0sIHNoYXJlZCBrZXlzIGFyZSBjcnlwdG9ncmFwaGljYWxseSBnZW5l cmF0ZWQNCiJzdHJvbmcgc2VjcmV0cyIsIHNvIHVzZSBvZiBzZXF1ZW50aWFsIGNvdW50ZXJzIHdp bGwgbm90IGRlY3JlYXNlDQp0aGUgc2VjdXJpdHkgc3RyZW5ndGggb2YgdGhlIHdob2xlIHByb3Rv Y29sIHNpZ25pZmljYW50bHkuDQpSZXBsYXkgYXR0YWNrcyBhcmUgbW9yZSBpbXBvcnRhbnQgdG8g YmUgcHJldmVudGVkLg0KDQo+IDMpIE5pdDogcy9FdmVuIGlmIHRoZSByZXF1ZXN0LVVSSSBkb2Vz IG5vdCBoYXZlIGEgcG9ydCBwYXJ0LCB2IHdpbGwgaW5jbHVkZQ0KPiB0aGUgZGVmYXVsdCBwb3J0 IG51bWJlci4vRXZlbiBpZiB0aGUgcmVxdWVzdC1VUkkgZG9lcyBub3QgaGF2ZSBhIHBvcnQgcGFy dCwNCj4gdmggd2lsbCBpbmNsdWRlIHRoZSBkZWZhdWx0IHBvcnQgbnVtYmVyLi8NCg0KVGhhbmsg eW91Lg0KDQoNCi0tIA0KWXV0YWthIE9JV0EsIFBoLkQuICAgICAgIExlYWRlciwgQ3liZXIgUGh5 c2ljYWwgQXJjaGl0ZWN0dXJlIFJlc2VhcmNoIEdyb3VwDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSW5mb3JtYXRpb24gVGVjaG5vbG9neSBSZXNlYXJjaCBJbnN0aXR1dGUNCiAg ICBOYXRpb25hbCBJbnN0aXR1dGUgb2YgQWR2YW5jZWQgSW5kdXN0cmlhbCBTY2llbmNlIGFuZCBU ZWNobm9sb2d5IChBSVNUKQ0KICAgICAgICAgICAgICAgICAgICAgIE1haWwgYWRkcmVzc2VzOiA8 eS5vaXdhQGFpc3QuZ28uanA+LCA8eXV0YWthQG9pd2EuanA+DQpPcGVuUEdQOiBpZFs0NDA1NDZC NV0gZnBbN0M5RiA3MjNBIDc1NTkgMzI0NiAyMjlEICAzMTM5IDg2NzcgOUJEMiA0NDA1IDQ2QjVd DQo= From nobody Wed Nov 2 08:05:36 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2946D129677; Wed, 2 Nov 2016 08:05:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147809913113.24126.1665111260189905880.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 08:05:31 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 15:05:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1 = I agree with Terry that the introduction would benefit from an edit pass. = Section 2.3 = "The server MAY have thrown out the corresponding session from the session table." This seems like an inappropriate use of normative MAY, as it is describing behavior in the past. Either "MAY throw out" or "may have thrown out" would be appropriate. "Under the appropriate settings and implementations, most of the requests to resources are expected to meet both criteria, and thus only one round-trip of request/response will be required." This statement seems to presume much wider deployment than I would anticipate for this experiment. If I understand correctly, you would need mutual auth implemented by a sufficient proportion of servers to justify providing a knob in a browser that allows the user to indicate that he wants to send a key exchange in the first request to sites that have required mutual auth in the past. Is that what is meant by "settings"? If so, I think this either requires more explanation about the circumstances under which "most" requests can be reduced to 1 RT, or this statement needs to be qualified at a level below "most." = Section 4.1 = "user-unknown: this is a special case of auth- failed, suggesting that the provided user name is invalid. The use of this parameter is NOT RECOMMENDED due to security implications, except for special-purpose applications where it makes sense." The exception case here seems underspecified. It's not clear what kind of "special-purpose" application would warrant this in light of the information it potentially leaks and the fact that such applications, if they do not have scripting capabilities, do not require transport security when using this protocol according to Section 7. I have the same question about invalid-credential. From nobody Wed Nov 2 12:20:51 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0953B129801; Wed, 2 Nov 2016 12:20:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147811444699.24078.6906484597191128701.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 12:20:46 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Alexey Melnikov's No Record on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:20:47 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Record 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only reviewed sections 1-6, but I am sending my comments so far: 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: 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]). From nobody Wed Nov 2 18:57:54 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5E127078; Wed, 2 Nov 2016 18:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813827363.24114.15910508774033704329.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 18:57:53 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Ben Campbell's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:57:54 -0000 Ben Campbell has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Most of my comments have already been covered by others. I agree with others that the introduction really needs more editing. I share the question about the IPR section. In general, IETF stream documents are not expected to contain licensing language beyond that in the TLP. OTOH, that's about copyright, and this is clearly not--but I wonder why the existing IPR disclosure is not sufficient. If the section is to remain, I suggest making sure this has been reviewed by someone from the IETF trust prior to publication. - Section 16: I don't think 2119 MUSTs are appropriate for IANA instructions. -- I think the registration policy you are looking for is "Specification Required". From nobody Wed Nov 2 19:03:36 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D9127078; Wed, 2 Nov 2016 19:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813861228.24090.9299414198966449646.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 19:03:32 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org Subject: [http-auth] Ben Campbell's No Objection on draft-ietf-httpauth-mutual-algo-06: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 02:03:32 -0000 Ben Campbell has entered the following ballot position for draft-ietf-httpauth-mutual-algo-06: No Objection 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-algo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja that the IPR section in this draft seems misplaced, and applies more to the mutual-auth mechanism draft. If it needs to stay in this draft, please see my comment about the similar section in the mutual-auth draft. From nobody Thu Nov 3 05:07:53 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5F1294C2; Thu, 3 Nov 2016 05:07:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2016 05:07:45 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [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 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:07:45 -0000 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. From nobody Thu Nov 3 06:40:13 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1612961C; Thu, 3 Nov 2016 06:40:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147818041154.22776.7199213368635708346.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2016 06:40:11 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:40:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-httpauth-mutual-10: Yes 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for persisting through a long IETF process with this. I think it's a fine experimental spec. From nobody Mon Nov 7 17:44:42 2016 Return-Path: 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 546FD1295CB; Mon, 7 Nov 2016 17:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fwa6ox6lKYl1; Mon, 7 Nov 2016 17:44:33 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 78CF11295BD; Mon, 7 Nov 2016 17:44:33 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id b35so135378572uaa.3; Mon, 07 Nov 2016 17:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+sQ7ahZGhCePkvBA3bGOOZ1qmeWtB/0IvnrrvQYiVkk=; b=E5RPrMFEsxJvAzixzdlhpKYJQ7UKYymzqFNJY7djpvxA3V4HXO5PFPPFUZnxXWaD7k W7m3FOJm2z5GPAQO0tXTkkmpuRgM2bq2lxuEX17ZgNY79hQ44rBfUpm5zr3GBGDHJZY7 l7rf6XwAiOhyFSqD+nPMzAefp7YBgTEhKyn+6dTkI4R3mDs0Pc8QdGk07+v6ufvrs1kQ UysFcUJc6rToufemHHx6uQEbhWHEqHA3urGsC80i/Ndl/XTt97r77ZoFdQl5h+ZKoRPt 5pwPZu9W4f+Wlg8eoKUQBCbbV3FiJluKFX9Qc+BUscWS3vztEQD+U6HyDY6u4FutFKDj e2tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+sQ7ahZGhCePkvBA3bGOOZ1qmeWtB/0IvnrrvQYiVkk=; b=kXx/vfAYZYyepunCO6hCin0Y3U6HsxlMvXC8FEmuxltAXxStdMCzlBozKrPsBl6q2V rr+wuiHKbd2BOlECn7s5+LMirb0U75xcNQg7eVNS09P1C0xMh8JswWoTA8vnAcEVqITQ Nv5v84FtZr6qGwfMQdbrNFt6qBScWXekHsISeUFagb6s0M1e3aN90NXawco2JphKu0Kn epdMG8+87AFS50B+ibQm5MvHPcE5xE2YO6Aq5m32CZXJcRdAbE0QzxR1bHWY2visRYT9 QE3nftSb6nd9QPK0MP8eJ9S0feJskIKpFWipKiobuNlFcq6FqDlOQ4ft83BGQeeDbSsb 5pGA== X-Gm-Message-State: ABUngvdqfHJEF7L+XO/IuMuGAYZtkQXnTbtQ0ptL86HX+gHfarw6vENywD9hgeuqQc+0o10k1oErxK9rJd1wng== X-Received: by 10.176.85.24 with SMTP id t24mr6842297uaa.21.1478569472608; Mon, 07 Nov 2016 17:44:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Mon, 7 Nov 2016 17:44:32 -0800 (PST) In-Reply-To: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Mon, 7 Nov 2016 20:44:32 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f403045dd96030cec20540c0483a Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" , The IESG , httpauth-chairs@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 01:44:36 -0000 --f403045dd96030cec20540c0483a Content-Type: text/plain; charset=UTF-8 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 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 > -- Best regards, Kathleen --f403045dd96030cec20540c0483a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have not seen a response to th= is discuss (or some of the other comments), please respond and discuss thes= e questions and comments.=C2=A0 It would be good to wrap up these last 2 dr= afts 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/<= wbr>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/dr= aft-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:

=C2=A0 =C2=A0If HTTP is used on a non-encrypted channel (TCP and SCTP, for<= br> =C2=A0 =C2=A0example), the validation type MUST be "host".=C2=A0 = If HTTP/TLS [RFC2818]
=C2=A0 =C2=A0(HTTPS) is used with a server certificate, the validation type= MUST
=C2=A0 =C2=A0be "tls-server-end-point".=C2=A0 If HTTP/TLS is used= with an anonymous
=C2=A0 =C2=A0Diffie-Hellman key exchange, the validation type MUST be "= ;tls-unique"
=C2=A0 =C2=A0(see the note below).

=C2=A0 =C2=A0Implementations supporting Mutual authentication over HTTPS SH= OULD
=C2=A0 =C2=A0support the "tls-server-end-point" validation.=C2=A0= Support for
=C2=A0 =C2=A0"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:

=C2=A0 =C2=A0The Mutual authentication protocol proposed in this document i= s a
=C2=A0 =C2=A0strong cryptographic solution for password authentications.=C2= =A0 It
=C2=A0 =C2=A0mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you
forget to delete this instance?

3.2.=C2=A0 Values

=C2=A0 =C2=A0The parameter values contained in challenge/credentials MUST b= e
=C2=A0 =C2=A0parsed strictly conforming to the HTTP semantics (especially u= n-
=C2=A0 =C2=A0quoting of the string parameter values).=C2=A0 In this protoco= l, those
=C2=A0 =C2=A0values are further categorized into the following value types:= tokens
=C2=A0 =C2=A0(bare-token and extensive-token), string, integer, hex-fixed-n= umber,
=C2=A0 =C2=A0and base64-fixed-number.

=C2=A0 =C2=A0For clarity, implementations are RECOMMENDED to use the canoni= cal
=C2=A0 =C2=A0representations specified in the following subsections for sen= ding
=C2=A0 =C2=A0values.=C2=A0 Recipients SHOULD accept both quoted and unquote= d
=C2=A0 =C2=A0representations 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.=C2=A0 Strings

=C2=A0 =C2=A0All character strings MUST be encoded to octet strings using t= he
=C2=A0 =C2=A0UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
=C2=A0 =C2=A0[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:

=C2=A0 =C2=A0When
=C2=A0 =C2=A0these values are generated from any cryptographic values, they= SHOULD
=C2=A0 =C2=A0have their "natural length"; if these are generated = from a hash
=C2=A0 =C2=A0function, these lengths SHOULD correspond to the hash size;
Why not a MUST here?

=C2=A0 =C2=A0if these
=C2=A0 =C2=A0are representing elements of a mathematical set (or group), it= s
=C2=A0 =C2=A0lengths SHOULD be the shortest for representing all the elemen= ts in

Again, why not a MUST? Having a unique encoding will improve
interoperability.

=C2=A0 =C2=A0the set.

=C2=A0 =C2=A0The numbers represented as base64-fixed-number SHALL be genera= ted as
=C2=A0 =C2=A0follows: first, the number is converted to a big-endian radix-= 256
=C2=A0 =C2=A0binary representation as an octet string.=C2=A0 The length of = the
=C2=A0 =C2=A0representation is determined in the same way as mentioned abov= e.
=C2=A0 =C2=A0Then, the string is encoded using the Base 64 encoding [RFC464= 8]

I assume you meant Section 4 alphabet and not Section 5 alphabet from
this
RFC. Please add section reference to the above.

=C2=A0 =C2=A0without any spaces and newlines.=C2=A0 Implementations decodin= g base64-
=C2=A0 =C2=A0fixed-number SHOULD reject any input data with invalid charact= ers,
=C2=A0 =C2=A0excess/insufficient padding, or non-canonical pad bits (See Se= ctions
=C2=A0 =C2=A03.1 to 3.5 of [RFC4648]).

7.1.=C2=A0 Applicability notes

=C2=A0 =C2=A0When the client is a Web browser with any scripting capabiliti= es, the

Can you explain why scripting capabilities are important here?

=C2=A0 =C2=A0underlying TLS channel used with HTTP/TLS MUST provide server<= br> =C2=A0 =C2=A0identity verification.=C2=A0 This means (1) anonymous Diffie-H= ellman key
=C2=A0 =C2=A0exchange cipher suites MUST NOT be used, and (2) verification = of the
=C2=A0 =C2=A0server certificate provided by the server MUST be performed.
In Section 9:

=C2=A0 =C2=A0In both cases, it is the sender's duty to correctly prepar= e the
=C2=A0 =C2=A0character strings.=C2=A0 If any non-normalized character strin= g is
=C2=A0 =C2=A0received from the other peer of the communication, recipients = MAY
=C2=A0 =C2=A0either use it as a bare UTF-8 string without any preparation, = perform
=C2=A0 =C2=A0any appropriate preparations (which may cause authentication =C2=A0 =C2=A0failure), or reject any ill-prepared inputs from the sender an= d
=C2=A0 =C2=A0respond 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:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Otherwise, send a 200-VFY-S response.=C2=A0 If= the session was in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the "key exchanging" state, the= session SHOULD be changed to an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"authenticated" state.=C2=A0 Th= e maximum nc and nc flags of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state 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<= /a>



--
Best regards,
Kathleen
--f403045dd96030cec20540c0483a-- From nobody Tue Nov 8 00:56:53 2016 Return-Path: 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 691F4129C89; Tue, 8 Nov 2016 00:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 dyHjOIXgPrZB; Tue, 8 Nov 2016 00:56:43 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0051.outbound.protection.outlook.com [104.47.92.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D350129C8B; Tue, 8 Nov 2016 00:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; 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 TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) by TY1PR01MB0586.jpnprd01.prod.outlook.com (10.167.157.16) 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 TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) by TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) with mapi id 15.01.0693.016; Tue, 8 Nov 2016 08:56:39 +0000 From: =?utf-8?B?5aSn5bKp5a+b?= 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, 8 Nov 2016 08:56:38 +0000 Message-ID: References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> In-Reply-To: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.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: [150.29.149.249] 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; H:TY1PR01MB0588.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: aist.go.jp 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-OriginatorOrg: aist.go.jp 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: "http-auth@ietf.org" , "draft-ietf-httpauth-mutual@ietf.org" , "httpauth-chairs@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 08:56:45 -0000 RGVhciBBbGV4ZXk6DQoNClRoYW5rIHlvdSBmb3IgcmVhbGx5IHZhbHVhYmxlIGNvbW1lbnRzLg0K DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhp cyBpcyBnZW5lcmFsbHkgYSB3ZWxsIHdyaXR0ZW4gZG9jdW1lbnQuIEkgaGF2ZSBhIGNvdXBsZSBv ZiBpbXBvcnRhbnQgY29tbWVudHMNCj4gdGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIGFkZHJlc3Nl ZCBhbmQgc2V2ZXJhbCBsZXNzIHNpZ25pZmljYW50IGNvbW1lbnRzLg0KPiANCj4gMSkgQXMgTWly amEgcG9pbnRlZCBvdXQsIHRoaXMgc3BlYyBuZWVkcyBuZWVkIHRvIHJlZ2lzdGVyICJNdXR1YWwi IEhUVFANCj4gQXV0aGVudGljYXRpb24gU2NoZW1lcyB3aXRoIElBTkENCg0KWWVzLCB3ZSdsbCBk byBpdC4NCg0KPiAyKSBJbiBTZWN0aW9uIDc6DQo+IA0KPiAgICBJZiBIVFRQIGlzIHVzZWQgb24g YSBub24tZW5jcnlwdGVkIGNoYW5uZWwgKFRDUCBhbmQgU0NUUCwgZm9yDQo+ICAgIGV4YW1wbGUp LCB0aGUgdmFsaWRhdGlvbiB0eXBlIE1VU1QgYmUgImhvc3QiLiAgSWYgSFRUUC9UTFMgW1JGQzI4 MThdDQo+ICAgIChIVFRQUykgaXMgdXNlZCB3aXRoIGEgc2VydmVyIGNlcnRpZmljYXRlLCB0aGUg dmFsaWRhdGlvbiB0eXBlIE1VU1QNCj4gICAgYmUgInRscy1zZXJ2ZXItZW5kLXBvaW50Ii4gIElm IEhUVFAvVExTIGlzIHVzZWQgd2l0aCBhbiBhbm9ueW1vdXMNCj4gICAgRGlmZmllLUhlbGxtYW4g a2V5IGV4Y2hhbmdlLCB0aGUgdmFsaWRhdGlvbiB0eXBlIE1VU1QgYmUgInRscy11bmlxdWUiDQo+ ICAgIChzZWUgdGhlIG5vdGUgYmVsb3cpLg0KPiANCj4gICAgSW1wbGVtZW50YXRpb25zIHN1cHBv cnRpbmcgTXV0dWFsIGF1dGhlbnRpY2F0aW9uIG92ZXIgSFRUUFMgU0hPVUxEDQo+ICAgIHN1cHBv cnQgdGhlICJ0bHMtc2VydmVyLWVuZC1wb2ludCIgdmFsaWRhdGlvbi4gIFN1cHBvcnQgZm9yDQo+ ICAgICJ0bHMtdW5pcXVlIiB2YWxpZGF0aW9uIGlzIE9QVElPTkFMIGZvciBib3RoIHNlcnZlcnMg YW5kIGNsaWVudHMuDQo+IA0KPiBJIHRoaW5rIHRoZSB0d28gcGFyYWdyYXBocyBhcmUgaW4gY29u ZmxpY3QuIEZvciBleGFtcGxlLCB0aGUgZmlyc3Qgb25lIHNheXMNCj4gdGhhdCBpZiBUTFMgd2l0 aCBzZXJ2ZXIgY2VydGlmaWNhdGUgaXMgdXNlZCwgdGhlbiAidGxzLXNlcnZlci1lbmQtcG9pbnQi DQo+IE1VU1QgYmUgc3VwcG9ydGVkLiBCdXQgdGhlIHNlY29uZCBzYXlzIHRoYXQgaXQgaXMgU0hP VUxEIGJlIHN1cHBvcnRlZC4NCj4gDQo+IElmIHRoZSBpbnRlbnQgb2YgdGhlIGZpcnN0IHBhcmFn cmFwaCBpcyB0byBzYXkgd2hhdCBzaG91bGQgYXBwZWFyIHN5bnRhY3RpY2FsbHksDQo+IHdoaWxl IHRoZSBzZWNvbmQgcGFyYWdyYXBoIGV4cGxhaW5zIHdoYXQga2luZCBvZiB2YWxpZGF0aW9uIGlz IGFjdHVhbGx5DQo+IHJlcXVpcmVkLCBJIHRoaW5rIHRoaXMgc3RpbGwgY2FuIGJlIG1hZGUgY2xl YXJlci4NCj4gDQo+IEkgc3VnZ2VzdCB5b3UgZWl0aGVyIGRlbGV0ZSB0aGUgc2Vjb25kIG9mIHRo ZXNlIDIgcGFyYWdyYXBocywgb3IgeW91IG5lZWQgdG8NCj4gcmV3b3JkIHRleHQgaW4gdGhlIGZp cnN0IChhbmQgcG9zc2libHkgdGhlIHNlY29uZCkgdG8gc3BlY2lmeSBhIG5vbiBjb25mbGljdGlu Zw0KPiBzZXQgb2YgcmVxdWlyZW1lbnRzLg0KDQpXZSdsbCBjbGFyaWZ5IGl0IGJ5IHJlcGxhY2lu ZyB0aGUgc2Vjb25kIHNlbnRlbmNlIGJ5IGEgdGV4dCBzdWdnZXN0aW5nDQp0bHMtdW5pcXVlIGlz IG5vdCBsaWtlbHkgdG8gYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50LCBpbiBtb3N0IGNhc2VzLg0K DQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5r IHlvdSBmb3IgbWFueSBpbXByb3ZlbWVudCBzdWdnZXN0aW9ucy4NCkZvciBzbyBtYW55IHN1Z2dl c3Rpb25zIHJlcGxhY2luZyBTSE9VTEQgd2l0aCBNVVNULCBtb3N0IG9mIHRoZXNlIHNlZW0NCnRv IGJlIGNvcnJlY3QuICBXZSdsbCByZXZpZXcgYWxsIG9mIHRoZXNlIGFnYWluIHRvIG1ha2UgYSBm aW5hbCBkZWNpc2lvbi4NCg0KPiAzLjIuMi4gIFN0cmluZ3MNCj4gDQo+ICAgIEFsbCBjaGFyYWN0 ZXIgc3RyaW5ncyBNVVNUIGJlIGVuY29kZWQgdG8gb2N0ZXQgc3RyaW5ncyB1c2luZyB0aGUNCj4g ICAgVVRGLTggZW5jb2RpbmcgW1JGQzM2MjldIGZvciB0aGUgSVNPIDEwNjQ2LTEgY2hhcmFjdGVy IHNldA0KPiAgICBbSVNPLjEwNjQ2LTEuMTk5M10uDQo+IA0KPiBUaGlzIGlzIHRoZSBzYW1lIGFz IFVuaWNvZGUgMS4xLiBVbmljb2RlIG5vdyByZWxlYXNlZCB2ZXJzaW9uIDkuMCEgSSBzdWdnZXN0 DQo+IHlvdSB1c2UgYSBVbmljb2RlIHJlZmVyZW5jZS4NCg0KV2UnbGwgZG8gaXQuDQoNCj4gICAg VGhlIG51bWJlcnMgcmVwcmVzZW50ZWQgYXMgYmFzZTY0LWZpeGVkLW51bWJlciBTSEFMTCBiZSBn ZW5lcmF0ZWQgYXMNCj4gICAgZm9sbG93czogZmlyc3QsIHRoZSBudW1iZXIgaXMgY29udmVydGVk IHRvIGEgYmlnLWVuZGlhbiByYWRpeC0yNTYNCj4gICAgYmluYXJ5IHJlcHJlc2VudGF0aW9uIGFz IGFuIG9jdGV0IHN0cmluZy4gIFRoZSBsZW5ndGggb2YgdGhlDQo+ICAgIHJlcHJlc2VudGF0aW9u IGlzIGRldGVybWluZWQgaW4gdGhlIHNhbWUgd2F5IGFzIG1lbnRpb25lZCBhYm92ZS4NCj4gICAg VGhlbiwgdGhlIHN0cmluZyBpcyBlbmNvZGVkIHVzaW5nIHRoZSBCYXNlIDY0IGVuY29kaW5nIFtS RkM0NjQ4XQ0KPiANCj4gSSBhc3N1bWUgeW91IG1lYW50IFNlY3Rpb24gNCBhbHBoYWJldCBhbmQg bm90IFNlY3Rpb24gNSBhbHBoYWJldCBmcm9tIHRoaXMgUkZDLg0KPiBQbGVhc2UgYWRkIHNlY3Rp b24gcmVmZXJlbmNlIHRvIHRoZSBhYm92ZS4NCg0KR29vZCBwb2ludCB0byBjbGFyaWZ5IGl0J3Mg YSBCQVNFNjQsIG5vdCBhIGZpbGVzeXN0ZW0tc2FmZSB2YXJpYW50Lg0KVGhhbmsgeW91Lg0KDQo+ ICAgIFdoZW4gdGhlIGNsaWVudCBpcyBhIFdlYiBicm93c2VyIHdpdGggYW55IHNjcmlwdGluZyBj YXBhYmlsaXRpZXMsIHRoZQ0KPiANCj4gQ2FuIHlvdSBleHBsYWluIHdoeSBzY3JpcHRpbmcgY2Fw YWJpbGl0aWVzIGFyZSBpbXBvcnRhbnQgaGVyZT8NCg0KSSdsbCBhZGQgc29tZSBub3RpY2UgYWJv dXQgc2VjdXJpdHkgY29uY2VybiBoZXJlLg0KVGhlIHNlY29uZCBwYXJhZ3JhcGggZGVzY3JpYmVz IHBvc3NpYmxlIHVzZSBvZiBtdXR1YWwgdXNlciBhdXRoZW50aWNhdGlvbg0KYXMgYSByZXBsYWNl bWVudCBmb3IgaG9zdCBpZGVudGl0eSB2ZXJpZmljYXRpb24uDQoNCj4gSW4gU2VjdGlvbiA5Og0K PiANCj4gICAgSW4gYm90aCBjYXNlcywgaXQgaXMgdGhlIHNlbmRlcidzIGR1dHkgdG8gY29ycmVj dGx5IHByZXBhcmUgdGhlDQo+ICAgIGNoYXJhY3RlciBzdHJpbmdzLiAgSWYgYW55IG5vbi1ub3Jt YWxpemVkIGNoYXJhY3RlciBzdHJpbmcgaXMNCj4gICAgcmVjZWl2ZWQgZnJvbSB0aGUgb3RoZXIg cGVlciBvZiB0aGUgY29tbXVuaWNhdGlvbiwgcmVjaXBpZW50cyBNQVkNCj4gICAgZWl0aGVyIHVz ZSBpdCBhcyBhIGJhcmUgVVRGLTggc3RyaW5nIHdpdGhvdXQgYW55IHByZXBhcmF0aW9uLCBwZXJm b3JtDQo+ICAgIGFueSBhcHByb3ByaWF0ZSBwcmVwYXJhdGlvbnMgKHdoaWNoIG1heSBjYXVzZSBh dXRoZW50aWNhdGlvbg0KPiAgICBmYWlsdXJlKSwgb3IgcmVqZWN0IGFueSBpbGwtcHJlcGFyZWQg aW5wdXRzIGZyb20gdGhlIHNlbmRlciBhbmQNCj4gICAgcmVzcG9uZCBhcyBhIGNvbW11bmljYXRp b24gZXJyb3IuDQo+IA0KPiBJIHRoaW5rIHlvdSBhcmUgZ2l2aW5nIHRvbyBtYW55IGNob2ljZXMg d2hpY2ggbWlnaHQgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eQ0KPiBpc3N1ZXMuDQo+IEV2ZW4gcmVk dWNpbmcgdGhlIGNob2ljZXMgZnJvbSAzIHRvIDIgd291bGQgaGVscCBoZXJlLg0KDQpPSy4gIFRo ZSBwb2ludCBpcyB0aGF0IHRoZSAicmVjaXBpZW50IiBoYXMgZnJlZWRvbSB0aGVyZToNCml0IE1B WSBhY2NlcHQgYW5kIGl0IE1BWSByZWplY3QuDQoNCj4gSW4gU2VjdGlvbiAxNToNCj4gDQo+IEl0 IHdvdWxkIGJlIGdvb2QgdG8gYmUgYWJsZSB0byBiaW5kIGV4dGVuc2lvbiBkYXRhIHRvIHNoYXJl ZCBzZWNyZXQgY29uc3RydWN0ZWQNCj4gYnkgYm90aCBwYXJ0aWVzLg0KPiANCg0KLS0gDQpZdXRh a2EgT0lXQSwgUGguRC4gICAgICAgTGVhZGVyLCBDeWJlciBQaHlzaWNhbCBBcmNoaXRlY3R1cmUg UmVzZWFyY2ggR3JvdXANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmZvcm1h dGlvbiBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZQ0KICAgIE5hdGlvbmFsIEluc3RpdHV0 ZSBvZiBBZHZhbmNlZCBJbmR1c3RyaWFsIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kgKEFJU1QpDQog ICAgICAgICAgICAgICAgICAgICAgTWFpbCBhZGRyZXNzZXM6IDx5Lm9pd2FAYWlzdC5nby5qcD4s IDx5dXRha2FAb2l3YS5qcD4NCk9wZW5QR1A6IGlkWzQ0MDU0NkI1XSBmcFs3QzlGIDcyM0EgNzU1 OSAzMjQ2IDIyOUQgIDMxMzkgODY3NyA5QkQyIDQ0MDUgNDZCNV0NCg== From nobody Tue Nov 8 22:06:50 2016 Return-Path: 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 8C35F12962A; Tue, 8 Nov 2016 22:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 YaAAqFrDFCiQ; Tue, 8 Nov 2016 22:06:46 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0063.outbound.protection.outlook.com [104.47.92.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D1B1295C6; Tue, 8 Nov 2016 22:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gtF6bAotrvACllquFqMSVY9w7Ew25pkpv1HoAY6EKUE=; b=XeoD8h96q1vb5VXDePaLZlskR7ciHN/WbHsCbVZ0n2FiciTWzFve2SBpIauAUvZW2nroxMuyqUNR/kkoZqdmNKRJPjIwAogydPKOeQaAq+YKqbLdopbJjrV2uFAsdYOBkFcbE1Ki27NQkXuVcC82JWfK3NwjBSzlsOcVhPgWhv8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp; Received: from [150.29.149.113] (150.29.149.113) by OS2PR01MB0577.jpnprd01.prod.outlook.com (10.167.176.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 06:06:40 +0000 To: Mirja Kuehlewind , The IESG References: <147800918266.23964.2036672957524529397.idtracker@ietfa.amsl.com> From: Yutaka OIWA Message-ID: <18c86726-506f-278f-39d9-04268c05749d@aist.go.jp> Date: Wed, 9 Nov 2016 15:06:36 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147800918266.23964.2036672957524529397.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [150.29.149.113] X-ClientProxiedBy: OS2PR01CA0072.jpnprd01.prod.outlook.com (10.165.51.160) To OS2PR01MB0577.jpnprd01.prod.outlook.com (10.167.176.15) X-MS-Office365-Filtering-Correlation-Id: 53390db4-5ed2-4968-6477-08d4086692f3 X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 2:W/LFOulcFPEH2NEup5AdxMJV7qDJ+PHCQ0zrC8uVbRaHk5f1UZZVnQ1qHt66LMa3RkZyieB4R+YggYDsNDd9lTZOKtXDa/ZWn5SqMWwVwr42VzLgVXn/7/q8mUhPlFTsJ8HYC9DYvI4J0hmUHW3zGdZpIssesou5CbJHFwpv6I6Brtsg8YK8OjVrtVTHCwtix1R1OBOAJadVqfwmvTQGVA==; 3:MdgoUkYoytPTLZ8FU/bSSLhq513Lqlr2Zca+1+s0OoYHwbUTLxTkXyyY/GQsaQUyVuIPX2mwSSRsIyKEKQfonhMHxoOEYYjAZyLZFAdg17pq4cnr+GLIYZtjB3Seqmlt26iT5PckCNYbUe5uLXebZg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0577; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 25:zI802tZ3dbSRAAKv0+Su99vRxY8vyyT6qnRtyYgeZ40N3sAub8pHlSvXvI/FG6M02HRutrFI+X/F98RiHOKggZAuOl/ZyX1xAVmjab/c+TxezRgING2N4wvnsF74wnv2SSfPmEtzEd+IYIH1gI/kivvxrHm3kHQ3b57JYmYu4apn+O4s6687IUM0ODh180Y2G9ZbZnmQjNsMr4XbJhASUe7LqE1xBiH4QDr6Lmy8HzP2qyBs3E4Iy5+y1tRalxzzxvoiE1icAYW5VPpHCg8R3B6V2opCuq6YbqkkN6IGScF9beEI+t9W0zl/6BD69Ycz0C8boWUY68GXX2Vf6bBoVR2QKp3NImptgDvaUUyfRQcY83FYFBu0+YOYV4/MFePNWB2Qix0h2JvR+fBiBtrcNxPf19FdrwxucKh6cueGk05QmTqlikbrGuQiKOpKR09Gz/gvXPvlcmCWmWZSB8tmrKZvXiQq2fhE3dLsAB4LZ6SX+S9YRKvWUWP9DC++IXilaZ5JUq28NVh6Ni4c3wP4xkaHVC+gSfNFSOTix3Dk2v67qRc0w4m/K+BbXqfjDp4V4fwhZNU9xenRNaHYSylgNcTSTK3zYlVpXZP44y3yYYWQq9AomM7iVatdZgQ6ecMO8o24AD0Go3ZATTfhRbn5j8FY7E7jiUfgQdjk1eOyCOXLEynTDwl+3Hz4W4uAXoBhqE+a1YQwW8Gy36J0OFZabKTrxMKmNKO+U3wz+1Ym/LTpz7WJG1kz218SD3A1/Q6cCmIW0Of8RfqkI3Eq9NeYzyC8bzO7sjNuby0YcvU/5sJmojXrk9j61OojZKyPGgL2 X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 31:XavD7zAZ5pmeW99lKvazhlJsladskk8Rbm+FE0wk8NEAvNV4ZzH0Zv43/U/WcSVQ8hbbryhh81UEQT/RPgHmpaYo7nwMOwpa/8VKJ8ytPNuSXZjzUJ2AsixcTZj1ce6Bjzw3hq5xfhDiyNhyRZo5XAAYO2AFgWHNJiuTlu32dCWehESp5wxx05+yDbquyFvQMXTrOjzHVu4VQfYvmfynD+wi732P0FbpTtWy5CmoMGTS7sqgAMcOnqgA+BScAuLg2Vv2wsQoo6yl3ycnCfT5bw==; 20:LHAAeU9+skV+R1KemJZ5V9J8uLcInEm11YK9uotVTcq6NVAKAlyf17tzOWKlD0gHmT22ETU13sSoU50WtXoaWAGcHWPbLd8gMj1T6BUHynPdYcSDKqWCPuNyaeFTvaqNSxx/NyCPPGOvPHgn4QULDCZ/ft4/fuAbO/7k9Nb4z+zJhRNpU0ozwxxy/WiQ8UuxF3DZ4bUrlurvZrRRBDKagqiAgvELZVJcuiluNQAKHsQN9f/q10NgMCcsfrxx3xqxS+Lx4shG2TlHvwK7H46NixwcxWEp/y8Otd89s1PDpwL4BIgWUdeKDfLFpW5kpSemJiN0S/O9FoLrTa19uJVgptOw0p4slnWuoLyllOYCcMQhZaPZtzEsUwhAfNLu1iFT5tFgP9EKSZ+aUCeddmhv6SqqiE0X78s05lNAFNHkiCfChf7Z+RwtamnlzhzZNJC11xLjOJ0x26obR6zf1QSAzuKwqiGO7kfnFD1pKD08tghtN9YM+w6QrrOGw8bnLGQ3zSbHxR5YIj35xtHcf1gLLCh7YhCZ+1le35z+iVw2Kts7SCmoDs01+UEsr7TyU+oOaxKPDMDyyOQQ8f6IS0iEecvQXYA3CAsxW9ZXgsKXQj0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:OS2PR01MB0577; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0577; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 4:AnO00EsGqm/Dus8XDDJ4t56qxJl5uiJ3xFSHx1mx6XaFkqe9h0OJbnGRWXrCI/XX8/4CoiR8e/CFgkmghg12ip4eQKnutKiBeRGXX68+sSYhl3e2BN9x8+k0OVnhSF49uSrNMe6GJalvETOzPjMFzgcU7NBeaVi8jzev+drKF4e8qkRSyaYgCY+0ZpwPDetno2C1sq5B/dvKAh5m8r0/+C8nXBO8FPNc1bDjjyAgvrPBufT5s8zd4hWks7FHUEpeoHHqdro+dO04c7LiGBZdTOSsg5d3U/hi6eyN3n+9pwo+wObqckmH5tt1hIOSp17oEkQ9AFU5wM2DTOCRSkxALYhQCI14cWVzp6spAV14/sATKDr4jmRNrLHoIMLmya9UlHRZyPTrY+IYvtpjpArPDR1dy/ODGRIZpzszsb1ixyE4p9tsY1YLHTnXwI6YEC+C X-Forefront-PRVS: 0121F24F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(189002)(24454002)(199003)(7846002)(47776003)(305945005)(65956001)(33646002)(74482002)(65806001)(23676002)(101416001)(50466002)(224313004)(31686004)(106356001)(230783001)(42186005)(224303003)(4326007)(105586002)(2906002)(6666003)(54356999)(86362001)(31696002)(76176999)(36756003)(5660300001)(586003)(2950100002)(65826007)(42882006)(345774005)(6116002)(3846002)(64126003)(5820100001)(2870700001)(83506001)(66066001)(50986999)(4001350100001)(81166006)(77096005)(189998001)(81156014)(5001770100001)(92566002)(7736002)(97736004)(68736007)(7099028)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:OS2PR01MB0577; H:[150.29.149.113]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwNTc3OzIzOm5LanhwaG1PS3BFUWNWWEliNW1jQUhnZGgv?= =?utf-8?B?MC9pMnJDeWM1Z0JoaXRlN3MwakJEUzQ3M2JkSmlNQi9xcHVZeCtsQVVDcTIr?= =?utf-8?B?UUR1a1FPdEdHSXlRR0tLS2xra0pSOUdreGUzVmZvb1BsaVd2bzJ4L3BHVEI4?= =?utf-8?B?YjhJYkdRaWQ4Y2FPK1pJaFpqSGhxOExDZGJzNVNwVnFWSkwwdlE4aFZKZ2Fu?= =?utf-8?B?b0xOeXBQWTdaMTFla3pLd0RCUGNoY3pUaEN1d2FIcUZkTm1iaWs3eVdSYTdp?= =?utf-8?B?MjIrR1kxVlkxdjI5UE5lNWhKTDdhUmMvZzUrQlZRMkFoL3pCaE1EQ3RLOTN2?= =?utf-8?B?cUp6Ym5QWTk4OGJuM0JpYURxcDIweFllY2kxZkljcVlOakJtaEdJQ3ZCL2U1?= =?utf-8?B?bCtucTY0Z1l3Q0Z6aVNGL05hWnFGaDNnU2F1VXgyMk1SSjdHK0ZnUmRsYSta?= =?utf-8?B?MzJpeGtnZjNPd1RLWGR2WUs1d1kzK0dnalBheks0a25pQUZTZVI2aDZ3MkV3?= =?utf-8?B?Rk81bUNHM0lwTDY2SGtZOTNrb2NxNjFlM0p1MTB3dEx3WXZmdW1lcy9FWldP?= =?utf-8?B?L01XODlWYURjM0doaGp2U1NYZ25DQnV6REU0bmt2MHJEQmdVWUJHUzloUk1l?= =?utf-8?B?cXExem5TbkhHeEVHYjF4cDFMVXBjM1hLN1BHSGhoa3cwVTZ3aHBYY0xsbnBH?= =?utf-8?B?dlpOZFdVOVl3RllsRnRMa0xpN1ZDd2RIcUhsWGc3eE03VlZQb0RRUXpwR29X?= =?utf-8?B?RzZTUTZ1VUw3MDY1MENuOEU0aUx3aHFtNDI3c3haSXoxNEFJc2ZZczJNWGM4?= =?utf-8?B?cGhYZHUxOGdreFpTaUtOTEVJUFBMTVBGWisybGUxWWNoWE9kV2hDM1oxOTRO?= =?utf-8?B?OXdUdUVoRDVtK0RSNEVxaHNEamlaQnVkSkt6ajM0WXNrbGNhMHVxejZ1cUVX?= =?utf-8?B?NCtnVXFsN3JNL0VYZ0d2UUdabWFYWDZBZ1dCR3hhYS9BNG1pQjBsaEk3UFVa?= =?utf-8?B?QnVIY3pEVHd6eW1vbG5OelQ4Y0dBYkVqaDY3bFdwQW9Wb0hmblNkWmRnd1Az?= =?utf-8?B?SlhoR0NCRkxRYkwvb0VUd2dCb1RLbThIWmFMVUNNKzU4b1Rxek9pd1ZrVWQ5?= =?utf-8?B?dEdnSHFqZ2ZaYSt0VDV3UEpvRVlkU1ZwUFpMcE50NUNpMnFhbmlrOTBlN3ll?= =?utf-8?B?UHNScEVPS2QvOG1PL0JjZnc2OE9rTlBpcEVwRlFoazF3UGpCMHZkek5kd2VQ?= =?utf-8?B?bXM2Qm8xb2t2Q2N1RnlrdlFnT0hVTUZqQ0wrZVRMN0YwL3htZ1VJeWNQZDhJ?= =?utf-8?B?M2pFN3pnVWJaNFhhWS9pclBvRXRkdVZhZ0plZE5YY1NidDNMcTRLd1V3SmZy?= =?utf-8?B?ak1QT05CaGxIOHEvbFFtblBMaWF2MnZteTVmb2piZ0dHZVBTci9xdCtlbWVR?= =?utf-8?B?SGVnYjZmUFJmcDVOYVRGT2FFdmlnQlJDYkVLSnFNRkx5enN6REhDb3NjV2Vj?= =?utf-8?B?U05CRmR0bTU2OTdianVkemUvcHdHZTJmRjNtQ3VKc1d0OGU4dVA0TFRid1B3?= =?utf-8?B?d2szbFhKZjZGaDF3WkREb0hOdGVhTFRPZmtwUTZhU1BwUkx4QXRId2V4T1A1?= =?utf-8?B?SHJmeDhVUWVIME84UTFZcW5ScGQySTBrSGF5c1ZCZkZEMGhRdkhsRzV5T0RW?= =?utf-8?B?Tnh4THVqQ09PVHdTaVZlei9RTm9ISnJKVzlqQnZlM1hXeUJ1TzBZNGs5enhh?= =?utf-8?B?WGMyWHVYYTdyalJ5VTA4VWdxVVYzZ0N0OWp2MFQ2OHMxa2RCMU1BYm44NTYv?= =?utf-8?B?TXg1VTdaTXoyN3pORnNqb3VhaFhaMjlGSWVDOFh1ZG03OUJLWTlNUUtEa3ND?= =?utf-8?B?dmxhY1gwdERvUWtybkV0dnhGclJhK29JZjNIaTVjL1FKTi80VDF6NWd6Z2hl?= =?utf-8?B?dnd2VmVPWGlnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 6:AZ6FZgWxlCwUvHwqvhkUOgtVoGTZ2tlMgR8buyxZIghAoj0a+K/qUowUXzHsnFfMtd8YJYc47jBZWtcrTmVlh9qD+/sW8qlns6Ne5r3cm8z4jGnP5154o8ppX118elmQrVQK+UjBJgco+aoF4nMXJcEXENrpZ8coMbYLAxcbn3JRdi2bDXFfYugENDIhKZG6j078vYWZ572jAUapTxAWujCnuod8AVSeqXunQAS6W1cYTVn46JrEizycu8ylum3iyMbycdtDeVL6a5EMZ6Zyi6Q+C22eHFJiDhY6z0c4icC/1nJJZNR868MjOt0EmouYUMTyRYSzujUCX56CrISCmg==; 5:SWuesRc2uoIl7sY/nfCZBOWkKtvZzCvP6O1I8Gr2nmr/tgkoUYjzWV9X2mIeqvYYHc0q4uBsxZ3I9hFTEkW+HwPOU9CTMeZlvlO2FXqsO6riqeLaBnkBx3PDPgWBkU8Mo3WcMeMedGirs5MzsdKCLA==; 24:t6xnwBGpz4j3ZdGccEtJq+3A3K5RWhmHLpW3rVwIf4Mlks12wKKt9v7ny6iGTckwFrZKiOXLz7wLnOORKoqpKK2GSjxt42i5E0CTDuwrYTo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0577; 7:kIsvjqxhobM6+IhmNXw+L10LT6bIbssKE3KXBSFhebhaO+hSm1TO7ouAQt0aVBOXbKrWcJo/SvwdcLtEeVQJT1f9XmotcHBmIcgBgqbC0IXH06B6HbZ+jiJIDXa0xrSqgo2qP3qxBuICwy/3wyMSgGMvTkWfiYITXA5Je/8PmovYGyml0/5ebtnT+7u1AYpyrFKNeUaopaZu44aYTwte5INN4OLdQCSzgkMJYHZB3gXJwFwSOCecW9wi4Y7yy5ma8a2VXEbIDMGiLSR4mRExdeWBcNAyznZJMCmeSRyE73lfGnxA1XlbUbNmzSuxTMLb9O/k5JfIPWZQBX7LWaogk1bb3yUx3ADt+a/Y3pEwygg= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 06:06:40.7209 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0577 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org Subject: Re: [http-auth] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dr?= =?utf-8?q?aft-ietf-httpauth-mutual-algo-06=3A_=28with_COMMENT=29?= X-BeenThere: http-auth@ietf.org 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, 09 Nov 2016 06:06:48 -0000 Dear Mirja, thank you for suggestion. We remove the whole IPR section in the next draft. On 11/01/16 23:06, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-httpauth-mutual-algo-06: No Objection > > 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-algo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In relation to Alvaro's comment on draft-ietf-httpauth-mutual, the first > part of the Intellectual Properties Notice does not seem to apply here > and the note is probably not needed at all. > > -- 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] From nobody Tue Nov 8 22:11:28 2016 Return-Path: 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 B225A129479; Tue, 8 Nov 2016 22:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 hqPN9Qji5dLr; Tue, 8 Nov 2016 22:11:18 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0048.outbound.protection.outlook.com [104.47.92.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEF512962A; Tue, 8 Nov 2016 22:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fpdb5jD0rD5mtMcoB9BZ7OirdeE5CY0nhdevJ93LA/Q=; b=gh0RdAsMBPsvgS0T4qHBZAYt6m9ksR3X0H/MvN4avnH7Ap2xmkaiyW3Ic4lJD/9mVC9Y4vF9Ktj1gQ8fVsO1YYzPNPMVpbaBaqjin0xL3tJC01qUp6KN8arfTlFC92hg7wlVpK9TqPEXKgUD7e3fhu+OETvQz7ksgpPPEToIXlo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp; Received: from [150.29.149.113] (150.29.149.113) by OSXPR01MB0583.jpnprd01.prod.outlook.com (10.167.146.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 06:11:14 +0000 To: Terry Manderson , The IESG References: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.com> From: Yutaka OIWA Message-ID: <8ee97cfb-1261-247b-24b3-e5f0d1396c42@aist.go.jp> Date: Wed, 9 Nov 2016 15:11:12 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Originating-IP: [150.29.149.113] X-ClientProxiedBy: TY1PR01CA0077.jpnprd01.prod.outlook.com (10.167.153.165) To OSXPR01MB0583.jpnprd01.prod.outlook.com (10.167.146.145) X-MS-Office365-Filtering-Correlation-Id: c46da920-2d17-44c1-28e3-08d4086735f2 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 2:AAHtApAzQot7etlZAqDxEnO7fBZDH1VH26VjJquaiOtta8k10WhpfsbXU9n4kR/6mDNIJ6hDn79po2/TC14OSI1BBZz5X5M/eScihr49hY2rgfpIJkW7B/Q2Mxck99T3h0lR4s7ehd0Bi1maOMA8hsWv8Z8HJJseKQWPWqbyuKlPdbRkl5qrfSkAghY5iQkGjQXLDGIcjR3HavzQaPZs2g==; 3:BD7ORBwQ4Ux7xtMhqazTkpV5Myfp5J3ZBUexNmsrTQVykUMESofKYRkWC1qQLwnyIywg0TqwdjbKRYR5hKeEXV0osIvmLBLv6qsyefpU6tHMukz7JspYblJriBaZJPJVGyOQ3qq5IvruE9wbIEG/xg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0583; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 25:xiNybMb9VY9tuarfEDteUOXr4onolEmm2km2fNZqx6NqJET9NOQ1tvYMC5DskOKFr0NIZzPtwZFuurQPvylYts9K+GqX+KCtSYfVZKwcaf4SuzaGdZOb6mRkfyBU0nZBaWLzl4zZrgBcvM49uG1JVDhXfhFQZwVB30RXFth1rYWPK+ktW+HZ6UzSRJaDshZ2YoucGKh13CDCS7e9G6BrFKz408ekhOZ/LIj1SR7I6Jthji3ZJ4yi/a7YN3Er016WjER2oA6l0n5/DB/Sefd71WaRtRQCu6ju8tmwvBi6LYFKJyXdRNy4jardExdMy3gnXEOXrDXaztvhaGoYekijby6/RgKgZQq9SNhgrBfiH1nbih2EQtlLRFi4yi4CkwOgUHVL/f6PRlvQU7K4zSc+h89InTGQNog4IbraCUyEF6r8GT2r6vTlAWxTN9q6B6OvHbrQNA1OR6zDviQBCe6x7eMsTKgC8qJlu4L0XXWLKS5BntRRbBS94PoBK4IP6xchyRHYBiK3xSIfPtSfb+jtgUb7SKxq56aCk+sGDlk2wkP74SEojyMS7aqVuUNDx2cPHu7cvFPQODV60MEJWFY6ebEkiSNa7hFKNhjA+5Ik1pQHBfdZPmRi2xjBcyBaP62POb0H7tVsqKKlF+ngdn4XJMvOzibLr1oO1at56DCHGVJitg0V9lsemy/L3/CbswVnHWpKeukWA8IcX2iYx7XWRu7U34JV2KxkCEEXyqnPM2bf9fGSeifyXUJHmrFepGeo X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 31:pjT4CmzPSTNNtPoI8CtT/UuS96QvXEX06UflVV1sbrK09AIX1xxhDW869IIjlQSouRkavjRTksz9gtip8LIbUMIpSdVpGiZ78XQOWu1zDrM2hGzkkb6PbtxJlixVnSKWtOEZkkATOBttbX+CbEnnVIyufnDKlPABbCkb9t9hHWnWM9N1u7QIpKDKw1oqR7clbq/9/bFnY6ioeskczyLrgt4qOEUwN5XxCHb7IL/VjHFUW1cTdcNgmUHCgdPGeaSs; 20:7AfId9T2p5CuHJ9QnBxs9yqr/E3dPxpdzopiKMI+z1VCkcMOthIVl1Y7olxaUGP4RKrYuHYfnkNa3z/Ms7XGYrsOpqn5Kx9MWhIxXlk73jIbsBZO1G6Nr4JNNmbNOjon2+ezSBDXylquUmVdCRdq6RJKT6HNcATnzw6TMomVhLs7bVrlBj+UggdZH4a3oc8aPFW2Ert7ote8StanH8MfmVA2ilISiw+rf8XA7pcbj1DMtZms8wliZbyjuSXx20NtQCNOy3jTwwnevhL37BdWADNVg/YT5RHKmVcKUtv7edEkTqhIGn9W8yZWAkVrqnXoX5WPtvFaurPWXPYd+LWf03hxjcIqqLZWmtOnUK7TqHOk+Lj92vEjULHTLZCBrCMmhu87xXbWQCm+rluWMfhW9FLLambOiUYZ9+C9vYev+99wWhxYK/XSs8vZ5mKsSXx66hiBikCJ1MrL/f5z9i8bvUdM/GJTwmiiPZpTQVgCra6If2aWnB9W9AqDw1T1zjF9VKetB5MGU0Mlu3ulwfiAy4hq60IggSlqPBr2KLsWKSukcuh/W7em/sQpmEcejEKLLnOv7MNsEpczygCI1qIWh/XZuNvyk4STkj5GLIUVhcM= 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)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:OSXPR01MB0583; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0583; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 4:ayJ2XZ4LN9+PaXJNBVyH0cIY2BW2TNnlAVh/zcgTYlrT+PGOU3XrurAGFpMalaDHQ6yg/fkLCAqFTnWvUVh6r49h2bAKHTV4o4ztUdYYLtCiSYIZI9EW3Jvb4GDlZef85WAOt/mGVubGuKoA2f+hscSe3g1yd87VaS1Bba5+4lzhKP/Y/yE6hbX6G57WbA0HzKvr4cvn5M6wQUnDJHfMkOq9bSghxe6AfXv5jsIWJmaTV9I87qcBkzmx4bHsAcxt7GuQupJlWP60OK0myapMEg/UqzVDuN3kg40nJuoRIQyxt9tcuQNC7dWoWypJNt+a0BseKKWuyetIG228iWm/L2skgLUERX57PcBz2uHdesFoxtbPTjUSPAcYZVUqwtoMYzn5Li0dkvpDSkxdSLu4Ogz2SSPJkzVUe/UmSbE2mU+ipSj2XzU7HVgEdxbRzUuO3Y6SoN8QCNHV0b5Ros8VcOcEHeK8Q7C2i9C5fk9RmU8= X-Forefront-PRVS: 0121F24F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(24454002)(199003)(189002)(42186005)(42882006)(77096005)(8676002)(65806001)(68736007)(2950100002)(74482002)(81166006)(6116002)(586003)(97736004)(3846002)(64126003)(65826007)(81156014)(92566002)(31696002)(4001350100001)(305945005)(31686004)(5001770100001)(2906002)(230783001)(50466002)(5660300001)(189998001)(50986999)(86362001)(7846002)(23736002)(551544002)(76176999)(7736002)(345774005)(33646002)(36756003)(83506001)(106356001)(65956001)(47776003)(230700001)(66066001)(105586002)(4326007)(101416001)(54356999)(120846001)(7099028)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:OSXPR01MB0583; H:[150.29.149.113]; 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) X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtPU1hQUjAxTUIwNTgzOzIzOjd3bmNCczUxbnBJMnlFVVFPMnY1YU8r?= =?iso-2022-jp?B?RGxiUUhVUDcwYWdVSm5LaVZyaWk4aWluSTdVL0VvYWNqbVJ4TEEvNHNW?= =?iso-2022-jp?B?cVRINlZHZGoyTTZUcnlhVWNrMFdtdGZJQ2p2QTJkRzRPUStaMnlqU3pI?= =?iso-2022-jp?B?SThMMGdnSnFyME4zK0NNK1JyQ1FlUkY4WjNIMVQ1ZDBibnhTbTdRNmJn?= =?iso-2022-jp?B?c3RURExuTk5xZmI5cWZHMzl4dXlCMFlpcWg4S2NrcEIyTE5Ec1J3eFBq?= =?iso-2022-jp?B?ako4blJmdk5LT25RSzhTdGUxNCtyV2VaSm5JODJPNkhFeThXNEhuUzV0?= =?iso-2022-jp?B?SWVhT0tPc2pQTXJiNWxhckFrYUY5K3pQQ2laOFp6NCtZK0l3TThuUU8w?= =?iso-2022-jp?B?NXlPUWJUQWsyalgvNklma3hnMjZWWE5NbG5zdkdSSzM0WGdaNU1CRmxV?= =?iso-2022-jp?B?WHBNV01vSXozb2FHWkl5ckhpbVB0WUlrWEJ0RmxiZmQranRlckdKdlA3?= =?iso-2022-jp?B?cTgvQkJqeG96Wi9zbHk3WXhZdDhjVS9EaHVJQmJmbXNsU2RDRTdqRmti?= =?iso-2022-jp?B?aXFyT2JYbkY4THFVc0JzWmhkTkZMNVhnVDhhT2lnKzQrRGVWK0V0dGtS?= =?iso-2022-jp?B?N3ZydnpqYVd4K055VmtjdkJhN2JxbE9Jd09lLzk2RzN1Y1NzU0NkZ2xU?= =?iso-2022-jp?B?VXg3T3V1WDJSRGpDa09HbXU3NmlVUTR3dVQwUXYxSjV4d1lNTVp6QW16?= =?iso-2022-jp?B?STdZZTlIT1d1S3IyaW9kSWJ1Z01TKzBLd0tYb3VSRGFzbXlUekE4ZzE2?= =?iso-2022-jp?B?dUJDaUVlMjhkRUUxV3RmditsZmRINlhYaU9YaUpvcjlLazhaMG5xdWVC?= =?iso-2022-jp?B?K0RNU1FnSG40N3FhMllXNnR0WW4veXZZb0R1amt2YXZ6VTVxUGV4eEpp?= =?iso-2022-jp?B?WG8rSUdVMDdBTDIxVzlzVmFES1BtRzVVWFZYOVJsK2JsQlU3dWs5WHU4?= =?iso-2022-jp?B?djYzZ0JMK3JHS1RZcGJtdXZuMGRVdFIzLzNUU1NlRmRlLzBncmFZY2Nj?= =?iso-2022-jp?B?MlZMUFVYNDg4VzNHWmRDS1Z1c1ZldmZtNlR2b0p3UVhxN2VnQ1p5TENn?= =?iso-2022-jp?B?YUROUEo5QkFaczQzemdqOGhpa1laZk1OaENDeHpHWXM0MEZiem5PV3Ni?= =?iso-2022-jp?B?NUFlN2NHS3lpWUlud2RBV21pOThwWVNkcEFuR09GdTF3Zkx4dFAxSFlv?= =?iso-2022-jp?B?RWZqb2tRTzRwdXVVVG9aVmhDUlVXeVZiSWtPdFN5em00dTN2MDdkNHlF?= =?iso-2022-jp?B?MXRwTkZHeGY5YWpLamZlSUU2NGN0WXNBRnJRQnBJQStCU2ZMekgraXZ4?= =?iso-2022-jp?B?eUZJVmxDZmdoNzhDdTNIUWFYQ1VGejFJbDFEMUlLTk9YbndQNzdpZ1FV?= =?iso-2022-jp?B?dFBmQnI4cVNZa1BnbGdwV3o0dE5xczFmMDZPangzZUV0d1p3WkJLY1Iy?= =?iso-2022-jp?B?ZWlLQzROUUFrdzZRYmx0VkdkWk5odEFHZ0xRSFkwUW5lZVluMkNZRjZV?= =?iso-2022-jp?B?dVVjOFhhQXJYSlFWZWFOWS9YZTgvT2t3Z0Z5SDFSREZHUFhaUGZCQits?= =?iso-2022-jp?B?MVlscUV1Y1JneXMreFVVd1owV1pHUE4yYnUweFQ4STI3YzlQSTJYVGZG?= =?iso-2022-jp?B?ZzB5VXZXb3NmbEVsYnpMelpDWklZYlZCODRNc2tsWGwvNlRHWlRjNjYy?= =?iso-2022-jp?B?b0JaaEhjL1ovWFdBbmd6OGRqNjVFbHFnNTBCYjBvK1AyRUhDdHVvLy85?= =?iso-2022-jp?B?VGozZExodmNiSE1YMitOVm11M2c2MkRhN1NIRGl2SzU0YlVzb2dXU3pD?= =?iso-2022-jp?B?ZHdWM01oMmt4THVOWVJ0SEt4aExRWmF6VlNIamRWa0ZEQU15ckYzVU1a?= =?iso-2022-jp?B?WExzVHVpNEREU2J2Y3FOVFZUWXR1MHVlV3ZDWmNMdStWSElTMFZodUMr?= =?iso-2022-jp?B?UmFKNW5MVi9HMUZPTG9TUlVyaWJuR3kyR0w4c0sxanZBTGR3eHErK3U=?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 6:mVqk34u1JMAUp/oM9NbL/x9TkPMtDgwEYWy8L6GbFuWBmDuBADTluHnBAaua3QpCDKJP/EvovcP6JjA+oqLscbc6MaDhiOBELKDSy2w3jwsvQ3e5RjbizD0OMIbxLqCw1VDzL5aTwxlXs/yEGIeSFoXFbpRNNtl/QoJo1XQC1st20AueZWbgyjvC8o0JOrd8S+koSAmIXCqbGa3DUu1kZP00+mpM34/fFS4I7LPoLhsZJN9EhVaYbNz//Mr7q2DHQ1T7VLqBQbT6MkQ4pdoKp3HIWCO/g6htaW/CgZFuAK8nZYlXBeP0DnlYlcbDBBTx5yGavRZwlkPXcgRu5oZM1DYz1GSWDSE52R/oTj+8Ntc=; 5:5WQN8ER7LGHvw12hVE2Oz4R+CEpWG4nqRcJcSVdSsw9yd3vERLvLSqp/3S9B72cO+bw4tRs2b6S6KFqjT+o8oZtPco+g3hd408rVxRCsNC+SlsSSZB1vSjNu8NVz4SPHyUIx5OaIJbGiTP4kCFK6kw==; 24:I/guL4OZ77wyWcyTG20yk4QJ+QwYyW8pAdRUgck0Huc3saO0gjbZpkZYqrjL3eVUEpOq+VJx2trYplswnbWmNfXU6WlyXBboofemHOiz20M= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0583; 7:iqEzbghtlylFKDqAoJJA0A1AB7FxQD6yX/7lllhixBxyHlH+LbWy5pO9CqiltQHMrgboT1GEPaeSxk0fG3YK3fk0DsBhPNc+Yd1bgmGPrXch4DqEMzJnpbOKf39rxxvc8SynVzEzrfyNUFbxiyw0xdrY60DaoOQ7KDpAKBOXxULEqogMWjwSYo6qIDf+fHuWOyd8ODtnHdRqsPryx0qT147nFSzGQuOcthOtOMUCmtamYq5n8I8a7dSf8zKpYhe9zfFNE0PmfemVL2fT37HywsDyK0b6Ssn87m217eEz4N6K97P0irGd+fZdKgm/UeB5rjuXaY9i9Zd8bNWwqG9UDYWrm1MaSeLLSjz9AQWnp58= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 06:11:14.2976 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0583 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: Re: [http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT) X-BeenThere: http-auth@ietf.org 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, 09 Nov 2016 06:11:21 -0000 Dear Terry, thank you for the detailed comment. On 11/02/16 08:57, Terry Manderson wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for writing a very detailed document. > > A few minor comments. > > 1) Please review the introduction, there are several grammatical errors > in there. Meaning still came through just fine, but they were a little > distracting. We try to improve it in the next draft. > 2) The state machine diagram of the client is quite complex. A candidate > for the new RFC format? Maybe :-) We have a vector-graphics version in our hand. (former submitted PDF versions have included it.) > 3) I agree with Alvaro's comment on the IPR. Thank you for making it > royalty free, however not sure you need to add the text in the RFC. Thank you. We remove it. > 4) This to me seems as it is essentially a shared secret construct, one > sentence from RFC 2361 (security considerations) seems applicable here. > "All the security in this system is provided by the secrecy of the > private keying material." If this the case, please provide ample warning > that (as one would expect) loss of the password from either the client or > the server results in a complete compromise. Situation is a bit more detailed (strong passwords are safe against server-side compromise), and We'll add a new subsection in Security Consideration. -- 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] From nobody Tue Nov 8 23:18:58 2016 Return-Path: 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 B7347129451; Tue, 8 Nov 2016 23:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 a8FlWZ4ue7BD; Tue, 8 Nov 2016 23:18:48 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0065.outbound.protection.outlook.com [104.47.92.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484F9129430; Tue, 8 Nov 2016 23:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P5MVwDshv28YaxDClbqZJ9dtBMjUJgBOM3VD97yFTg4=; b=JUJJgsjlYIOB/OpTZ2fR0IW5iomY0nKvyOSbsxPoI5irNZnKihR5GCn67N2+1oCqFxeVyi1rPojJ89l0lF37bY9XUPi/AL/xvDZNASfxmoDa+M2oNHA0YD9hngBa1Jf/Oi9j6thOcmMrJXFCMnkpz+3zBzd+pNMs+kbJC+mnz2k= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp; Received: from [150.29.149.113] (150.29.149.113) by TYXPR01MB0592.jpnprd01.prod.outlook.com (10.168.43.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 07:18:43 +0000 To: Kathleen Moriarty , Alexey Melnikov References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> From: Yutaka OIWA Message-ID: Date: Wed, 9 Nov 2016 16:18:41 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Originating-IP: [150.29.149.113] X-ClientProxiedBy: TYXPR0101CA0018.jpnprd01.prod.outlook.com (10.168.40.156) To TYXPR01MB0592.jpnprd01.prod.outlook.com (10.168.43.18) X-MS-Office365-Filtering-Correlation-Id: 25aaf251-b56e-44bd-d211-08d40870a36b X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 2:zFHFky+by9N7EVnWo5JHI+fRJHNNxh1nUgqLMh7JHpIpnNSnac32GeQmVFzJIb3I7VQH+wDZZvDDvVGLQTmMZaJU76MuMDqUUgB9lfbD2KWOvKiatzncJxnCEiWmjw9rkM0UzRYLGtNgU5ys2t9FbaJ9XhSOPHLY8/hHaqrZxDB+dc197sP5j+yJB+vO+ukxxb3Rh2Sxv1GFh9dOzqZvMw==; 3:e3Uhb/x1H0+xROwBm6Xuy3Iidre/G4YkxjCZH8KoE6AIbneN2opmsakQvt+MMQk8VH0HCseW55heAKHkISYX/uHgp4yziiatIor+nP2vN+lrOAWW6gR/h/9EaWrpehTrHhOPtc17kUHldLZWSE989w==; 25:VzpdGroIjZyNdA8bwTV9OT5RKkLK0EOmDmZNPvWiNY9Jy4n5Y6QJ1gFOvb9+hM6M0buNBgiiDy/TlKa3ENKjRHJ5MaK79Eu71BeAv1V7NUMk7kD3MJsvjFpkrz5ZOWJpfVH03iMwUfeK947EkEfv+KZWvA29PBbEHtqD/HRoQ9xwa2lvlBAUBQc+CTkRxSH+1FYXUacxNJzuYVpUfOZmfNsjmsXI7/tjaUDIhzvxGiiR2lEnSmd/GcZFUGzhXXeCQ1OtcrT9CJPeclONVTpnZM4loNgHBaRKJrRlUoldTle3GPeiAcQRT+JZTwEjG0qXLe5ZJV37ff9h9BQRgx8VPnkgpX4mZv4Pd0kPLvWNU8eB0LLSC8i2wMDSkqWYZnMLJnW+cZfjVieN6OXUQGO+6PQ1u3jJTB1PUQMlEnUzS/YN2jgR7hUIwAJneAfy9A4E X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0592; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 31:qc7xwyRdzAuHodpaO7IefXnNQfr1SjRTqoTCRkxEsHFfQ1aRmszHJLRL++luLtcvVlutGhjxCqAiEjMRwo9cUa1rwJiHNIly3gkbpu3qyZTZkcaOCGrAYcW1qtxxfrZXHzjdzfGEhYU8DrSLwo+urHt8x7ewZ8jhfYlOo7W7wqrw/9ukP5MpRxzEX+fdUzKtl4+iNyZwke+MwiiN52RLPYphTC2wsfe7R19J8QOLYKiqq/h6XuBuO2OPSMzVTY9DA0cUTSa+Wmxh33rSiXlVTg==; 20:N7RfjCQvr1/wGNIwa5lk/3PUE5TgqLyh9/Wa+n1dCr1ZvPxw/W86Q6mZ8WhSV0onFxSGdoDeFwgFaRiLCyliRe2w9T2iN8zsf/tq/tYKqT9CS1oWsTwK0AifcidrwFRfdeSp8DX8W3GoDlpVpeNhNchjUkQ47J5QMeoRyhBIB3Hc7PBz78n4vDogPMJ2Z9IGLf9JUS9ViAXGjjYE+vwYgqQ0oIK8VrnCD9NiXVocBqG7Awyu/kEOorEzjk51YUoocTSAQtNR6ltPTNLIU41Sxzt3QbqR/rLrybLVMTpI20X68ODJDrth8ScEN+mIv2e95YUxxmhHhZXPydXWkjVA65u/O7nm/pnAF+7H1UXSv2cm+pXuVRS6n4/ddBP3cNDgIbApJKeCr8cVxAxkSXEjn2kqnQnDVSL1OTMg7yMu/3PbZp0ALApp97WI0hSbYUbkW+6i4gP719tDSPYhb4igYKVZ9rQ7fz4AyLPM4RHvFpVlzEInWMi5q6WAQ/WtZZo/VDBjT1fwozg8QJ5Z8yd1VR1WeGU8/xMoRnhbX31dwePOUiK1Ht1t+rVWAKzKmwp0pfMhr07nzvMN28kdMTmOdhuB7WQs6m51XtDHG9G9Do8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105)(166708455590820)(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:TYXPR01MB0592; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0592; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 4:nwRbgLU0G2ZIhBcvz44inVwUnjaXXUcwDMQghAGR9OJ2V7b9vNLU+KgBL9F1Z/SWl5xZ4oGSqBGGE9AfgxRk4tiyPhGT/eAPkg/6wJHJuPJZBFvSY9D4m3dz1NT/nat7MVVEWBlcY9LpXFfz2IOcOT++SkV27KZD0gD6ps71vSGPpQYCiDBYKq5kQw9oXd0ASUnIZUqs0ly/kly7e5rphDs7A1uEpbWmPK61H5XG1WQsjs1jZSFjz+dxB+tk3+6eMeiDs0jJQQ4WamFBroKonkMIUMnHNow4ixR+x0/KF5XSNBbdWH6T3XTvLT6asBW9gM42f9YQxiRU2opJ4REhLOAohnTxshH6jFFeogtcVs7FtW3qPfPzVC3Ie90BQNxdyFgH1YUolonLcYHuQfFE9t0Q63Z+Ny9nQ4QcoLxmAtNPErZzbUdv0XuJJPmoUqkycUtCuv9C1G0jNtW4PhoPSj/fWmpMs+FTWbvoGLauBKQHyS24lC+aDlmUS9x5i7CNUalQ25q8zymB8+1zaooX3Mjmc98VXGyDDEu6j6GLfZo= X-Forefront-PRVS: 0121F24F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(25584004)(377454003)(24454002)(199003)(45984002)(189002)(86362001)(4326007)(65956001)(83506001)(81156014)(77096005)(81166006)(8676002)(4001350100001)(65806001)(50466002)(36756003)(5001770100001)(230700001)(33646002)(2906002)(68736007)(97736004)(586003)(31696002)(92566002)(551544002)(66066001)(42186005)(50986999)(76176999)(54356999)(23736002)(8666005)(2950100002)(101416001)(106356001)(7736002)(64126003)(3846002)(5660300001)(6116002)(230783001)(65826007)(305945005)(189998001)(47776003)(120846001)(31686004)(42882006)(105586002)(74482002)(7846002)(7099028)(7059030)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:TYXPR01MB0592; H:[150.29.149.113]; 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) X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtUWVhQUjAxTUIwNTkyOzIzOmJMYzdlSVNxK2xBRStrVEhna0FvYVpP?= =?iso-2022-jp?B?WGhEMSsvVTRtSUVXdzQwYTlwZU5OeXVyWWxJT0ZEZWJuby9IWllnZ0R0?= =?iso-2022-jp?B?NWViWG9zRC9Fa0Rja1BTWk94VmpOODN4VU40OXZQTFdDSHZlTElFalBi?= =?iso-2022-jp?B?SFNDOGtkR1hPUGRma3ZnMllUcFU3bVBQdGZLeS9ZNWxkUnUvS1VNVVkr?= =?iso-2022-jp?B?VlBvQ3FvdUIySUVVTHBTcnlvV1h5Yi9QMHRSVXZWMzkvdmg0MXUvbjAy?= =?iso-2022-jp?B?aVdGbkNNZ2N6Qmx5TldEMWk2RWNwUXRJbkd2dEtwZCtoVUViZGxQSnpJ?= =?iso-2022-jp?B?ZWNpTFlVd3dockdZanRSQ2lnSEgvQURaVXFzUGlDUnJoS0xDbFFvZlN5?= =?iso-2022-jp?B?L3oyV2RLUFEzbWY2LyszZlpPSUY4dEcrNy9QT2R5MzRyRC9Yc0k2M3c2?= =?iso-2022-jp?B?Z2lWcVVCNXNUakdpVmZsVU9VZms2L0dZUTFudHVxZHpFVmx1cWM0YW9R?= =?iso-2022-jp?B?RGZoVHM3QkU5b0laOWo4L2VXQVRxcUxBVVEyU2lGN3ErWmJiT04zdDJn?= =?iso-2022-jp?B?RHRZT3E5eStsVHhKSUhKY2lOZWM2eEZzNkZvRk1KbHRKUjJZcGtvQUxO?= =?iso-2022-jp?B?WGNTREhkMkx4ZU8zVTdWWFl3NlErRVZnRG54UmRNVGVkd1VxbVVKZGdz?= =?iso-2022-jp?B?OStEMGVoMUgyQkw5UlkvRlk1TVZUR3V4clROZFg1aWZDTFBGNU5KblhG?= =?iso-2022-jp?B?WFFRSFNuZ1h0VDNFR082U3FHOUthemdUa1hpMElxWG11d2FXSERaYldz?= =?iso-2022-jp?B?QmNENFNYamN6M0tad0Q1SGF4R0lvQzBIOWM2UUZBVWFQR2I2VGhCb0Ev?= =?iso-2022-jp?B?K0UxVm1lcXJrejIvZTFXYkpSS3NwRCtvbmZmTlVkK3N0UnRPcVViVHFr?= =?iso-2022-jp?B?ZmpYYnFtQWJhNld3R3RRZVhkVnFxaG1SMHRKR2dDbkd5RHZnNEpZT081?= =?iso-2022-jp?B?bjA2N2hvODI2Yzk4Uk9GM3RpYXRiN0Nra2p3b1FUYVRRc2I3bXZhZzVs?= =?iso-2022-jp?B?RWxESDRaTXhDUnFzN0I2ajF1R1BSMk5OdUh2Nm1tUWF4Y291U1ZPSVlH?= =?iso-2022-jp?B?RitFb3JueERVeW9wOFlTYlRMQTJQRXBzNk1MRzEwOFlNU0gzNUVNMXhS?= =?iso-2022-jp?B?cTJ0YiswUk1qbWlKWlpBZGV5OWdEU3BqT1VRaVg2T04xVEwxbE5yTmh0?= =?iso-2022-jp?B?TjBxZm8yNWNPcVpldG5pb1FodFEwbUxVMFh1WU1XUjlmUG9JSzNZVmtD?= =?iso-2022-jp?B?dEx6TkZpYXkweU5CV29zQUc1c1hkbXNtNGtydHFUTXFWc2tRRGFMbDJ6?= =?iso-2022-jp?B?SGRhWlhCaFNJbDZ3YTBGam5WbUpCci9tdVJ3OFk5TWMyNDgrNXcwVmM1?= =?iso-2022-jp?B?dHFMVS81RWVaNFNpUVppeEJLQXBMSHJmNkRxZGVzN0dtQ0JsbGF6Uzdt?= =?iso-2022-jp?B?SktpUW9PT05CUS9uZTFwQW1FMVlIdk1Tem9HZlQ3ajR4OUxOZHNzKzJ4?= =?iso-2022-jp?B?SkhZOEJxa3ZYSktReGlCemx1bUUwK1JlQmNjVGxJbHZ6MUlOdENtYUtT?= =?iso-2022-jp?B?bFdTWkg4RlROeVA2TjljOGd3SGpDL3FDbXVFQVZjRG95dXlJY1JZM3ZQ?= =?iso-2022-jp?B?eDN4cElNWUhESzZVNFVWam51YTBWcGM2MVlMUSt5eFhTN1BBMjBMeHBy?= =?iso-2022-jp?B?RVlwOXY2TUdCMUNtcFUzWktOcDc2ajNuUkd3OVM0MGlrQlpaTHhKd0xS?= =?iso-2022-jp?B?UU5rcTJnd2tpdFdmNThTT0V1a0oyU1VGb0FRRGFSUWU3eEZJd2NLdFZL?= =?iso-2022-jp?B?bVBtSVRPT1JmNExmS0I1QzNVM1NYU3ZpeFEwbFNXTnlwbncrUWJPL3pN?= =?iso-2022-jp?B?RWJERW1iL0RTbmgxbVRLQy8xVk9wQXZKWE04RDU2eWV0UUdPZVZ4ajFs?= =?iso-2022-jp?B?SStyWVQvZHI0eHRCQ1dZOU0wcEF5YlRSQkdjT1pvR1oxZGQrNXN0UGJQ?= =?iso-2022-jp?B?ajJPTFJiQkNXSy9KQ0FtdG0wRUluVnFxZEYyN3ZhOXFNUko2bHNJVlZ2?= =?iso-2022-jp?B?cHlFcFVzcWNvbnFhb2pOUkdzT1pKTUxvVGtQMTZ6WjViUWV1L0NxZ0ts?= =?iso-2022-jp?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 6:w494XZpHnmDzjwUCQSLdhUO5Zb/7l93PUreDz9DmuG4IcOmMEcC74CrTVnjzb9bquzunMGP+09/M12XdKbY3IGKGP59OSGWMynIncrfHA6mV5n8JTwmMnaQORZABlB06beECJvMXWTN259MFIES5j6uNejZy7RK1fJwdswbIevwLMZjN6WhQMYQLiBh26r5myJ8zmO7EDJID5Jj5nuBkCoBfv/HjMc9l4LR2SFLnycpfOmrzFoKRudTV1lOJT8bqV7G0e6VRoMd6ikVJ8IE4lnB9KGgjECMEv8b+j5kojvn3kOR3Fdma/V5Em6KTUs+2fU8QNv7GHnocRcvOJkgQIUbVs0mhf5gfOBxnOZ7KSQ0=; 5:ANMbSj3CZhJyvLegRGJC9XLJTAIQSzHEo4SO2jA6VQ0SskWJ1VIBRMB47FF1OYqohY5Opteuy8UKKTwmuTHpwADOcW74RRHTjC7sTH7OsqIGJrpX4qts7VCLYnCWVsEso5YB09EOyr6nsBD5iir/2A==; 24:AvZccw6CNo441JDoU1ifDH+vjLFsS5VD3jo8+urE3Ly9/GBq7qfKMhSsFfsErE9ULqt3ohabVVLSxDHcwFnNTv2C+wKEURY+TACJFdljRRA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 7:/P+Ko18pfaocZK+A0EN3ybGZtd2zLoYlF5nED6iPYHoLFerq0tOKSFkQn5SYI5TcxHPFJ9kloveDEpEu2zbdUPo6FaMhbbwi6vwypMyTk3buocjFY57NIrm8vUHsBSolET5Ceee9EmZsY96a4oqKtM/kPQzw3xGPJ5RuZtOAYIBnsRa1AnYc3PDmyvVMgHO1QrDBMqOKjK4us5hEEc2Y47XaJVI2nUzeAAE5R+tUQIhh3duDckUi5niRcaXq4WNZnMjz9yAgbXEdwHjh9lbyRyRVv9Hu9WBHC35yARSzGEzLKi4dMZY5tonZc7uyar9aOUn9Ex1BfJpf/LreV6uj0SIdKra8OyDYAYeI1UgMkK0= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 07:18:43.6743 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0592 Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" , The IESG , httpauth-chairs@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 07:18:51 -0000 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. 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 > 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 >> > > > -- $BBg4d(B $B42(B Yutaka OIWA ($B9q8&(B)$B;:6H5;=QAm9g8&5f=j(B $B>pJs5;=Q8&5fItLg(B $B%5%$%P!<%U%#%8%+%k%&%'%"8&5f%0%k!<%WD9(B , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Tue Nov 8 23:27:50 2016 Return-Path: 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 05B261295D0; Tue, 8 Nov 2016 23:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 uZeBe-3LhEwz; Tue, 8 Nov 2016 23:27:41 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0070.outbound.protection.outlook.com [104.47.93.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F4F129430; Tue, 8 Nov 2016 23:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N/rKdLLxCa0D2nrnR9wsfLNo+xoDTLzdLncTabHdmSM=; b=At8cYFQOdb4Fp12qwI6K6Fvn8rTJWYu50f/VM/MTy+eoYjAuOMH/DBKl9y3XElZdG/5FJrNBM7bz1iuWLG5biUe+39zAikYTfsflgFGUccKQALNgqmF2yioxDtxgcuUaaijTyY6MV/EIkClYrhi/+MvBw6y8Q7mm+C6pkignAW8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp; Received: from [150.29.149.113] (150.29.149.113) by OSXPR01MB0582.jpnprd01.prod.outlook.com (10.167.146.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 07:27:37 +0000 To: Benoit Claise , The IESG References: <147803743730.23848.16641230739986102968.idtracker@ietfa.amsl.com> From: Yutaka OIWA Message-ID: Date: Wed, 9 Nov 2016 16:27:35 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147803743730.23848.16641230739986102968.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Originating-IP: [150.29.149.113] X-ClientProxiedBy: OS1PR01CA0015.jpnprd01.prod.outlook.com (10.161.225.153) To OSXPR01MB0582.jpnprd01.prod.outlook.com (10.167.146.144) X-MS-Office365-Filtering-Correlation-Id: 989f60be-9b0a-4bcf-595c-08d40871e188 X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0582; 2:T34aQOWFjR3ApjEsXzwkP5sbi+09peVaXU2mfBlx1qLT7mBrqkr34nv22uqvXx+kSTNUUjZQiPprqLFkE/se65qu86hkRZkpweq58EDP/+09XCwx7N9hy3Ksb2e3klXfi7/cxI1jvTMN3wXsT7mvGo3L6slp6lRXaUATvovtSYkrI1a6EcVnNiDqyp7j98KXkl+kHej6rU+k2iVPVekV6g==; 3:hb7uXtWbGTz+Q6RoGXE/OE5IF+stwMS/WfS/FoqYgPXT3JmKGKZ6ZMg9R1Lp4HBjxi93+dymK7WMyL6vEEdSAOwEKpf1zQZjOyzi9u0+7RwjfLvsJ2MYJojQiaDUae2861GY1bU9oifn6/0acpjHHw==; 25:dFuLbxs57qGpP2MYH1N+SK+bPZpF7MCRYKNYh8p22x8oAZNHrcLkHBkahkIcT5OgCv5cjAjb2vrszcVEbn6xtipLCIhFnWifc4CgA29XsG/x2Jwcvv3BKefZ7MR74CQok+a9E2jaO/YQLxQjv7kreNSJ4k5D+WC8P7WQYdTPimv4og1lDPNMCZCh0QeobsS6zeNZXsOL5uKsWBQHLFJEuwWIMFYxBVe0KOwwjHtLwfdBdEjCOhb9USyhf8YmQM4VzJVY47pH6Yi3RjtfoR+GzbuFEazp1nImsPTB6OlGlFOzMRmswxKAQpHdFDGgzpluGSLiBjv3SOwspUsEIcWKnuEt2ek4tgNAOFAmObcfWQvMqcL6XG1Q/ojIDiWSFbQZJdhzJQJlnRWoUz7wnWqFMC9khNEhqVZG1Y46nfMqTuM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0582; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0582; 31:8XOgl+x5987VBbc1la3VTGEsunTeCfkQBEGvIKvQMQxLlu/GCDLokDE4geeiJkvFQNjznGUUSQ+GvvEEZ8b+Num5jYmikObl6JndH8tXUi3Vn/XQzm0XY8LsLM7020sVexSIf7vHN2T/1StBxzLApuyW2N84Dmyc2l9WjfAnHRE7veMjlD6hdEAH0lB23PiYbrFyRm8VAE/fLE3j/4XbvXNH0mV6fPJDtzk+l0sQCTRfnBP5jNVj//v4cvbLDTpIz8m1WceEkCusUxlBmACfX6kPu84anxwg0zFO/bMiu7s=; 20:4pQtv3CA9b/uML7c8hK+UhW3OV7e8AxOy8FdciBPuesgkGBW64kO18mKP+C1RzBYx1+dIoL13I+O4nToBgmdH2/0z8z0Rk3/Nu4f+5bDb1fzwBBPjM/QdbZE5iNi6rQoJrLVGiC50aVTeeNufAxtAJQh2y5HwrkkDlN3WvyfrJM3nLiP8YGKLaCrrZY0eu8oqnLjHY2De+aWmk3NW4tFKzSMsF1mBaBT+3/dhFQE+pjJwXkkiHcyGYgYL7V1hgExWgX0nLGB2bmSbtmVuMGi0ysuzgnbuQZEODXNsaUYy2MWpnWdJ4JQKwjS05OwzhzjOxGk6sz13p0FIMeiCqa5+7A5FET+qNI07oDK46xs534+SL6o7B0xrOPFrIVJ4nswVg2+Csi4aHVvQXJ4rWafkaaq0nE17DgXbb/5wGWTnARfR9jtROCcjk9X4x/40pKNtCgzmf3Gj5XitSCbaZYPGJ59N+4HbhjLw4ni/0y+qohWOLZriwbTUtNdPIsbg/gf9uI02xtvItJ0FH+4JmWDcz1VzA++4RElxHKkmjivcONso0tkfqHNjVV/oBPzhlgkpDX33vTUZvM7azBIYYLdtxnqzdyUeiJj68Ztt6iRsUs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:OSXPR01MB0582; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0582; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0582; 4:CUK7yha8RLrunH8RwVIC86qna6PkHjJyalrzX7N8tbkfT2BwyrKOIr9Pg2I9D4IuhXkidMSwZAvEvy/K9I4WdAC7Pf/v/ZDaklQn0bu/FXKdGnLe6WG7uRit4oZ+ckFEUP+cg11ziD6v1z6YxEUTErb3ZT5pmN9G1YSOaPwUGsSQHixO875ZA3X6iYWZNGOQy6xCkX1mdgJJFi/dXE7G3w+hfVoYHLWm+gvn34yxP8mvVcZVr4ff+O8gzmElaFcIn36SfR4lLtx0G/DM8FVLsiabkK6UPelU2jWsJuvnnwdQGBIlkmXwhV9j1Nhg9P5Xsj1nz+4rQrEWFCUNA3tH4E3lFZulISxggUVj5B8G0MWUEndylh9JnbYLD/KfbEgnrte6kM1mO4NscrryLKEgSjxNNAU6bvnbo3ygCBdddXriUwFAmIn6BT1kfZPykGldtIRbaZA6DoZbCbuoCaRN8iMlg4Nr0qLG3iscpMP7xxY= X-Forefront-PRVS: 0121F24F22 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(24454002)(586003)(230700001)(5660300001)(92566002)(105586002)(8676002)(66066001)(83506001)(97736004)(47776003)(106356001)(77096005)(4001350100001)(120846001)(5001770100001)(65956001)(101416001)(64126003)(230783001)(345774005)(31686004)(68736007)(81166006)(50986999)(76176999)(31696002)(81156014)(74482002)(6116002)(50466002)(42882006)(36756003)(7736002)(42186005)(65806001)(2906002)(4326007)(65826007)(7846002)(23736002)(305945005)(189998001)(2950100002)(86362001)(33646002)(3846002)(54356999)(7099028)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:OSXPR01MB0582; H:[150.29.149.113]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtPU1hQUjAxTUIwNTgyOzIzOmpqOFpjaXZMcVFTMUF4MGxkbW5uRnZH?= =?iso-2022-jp?B?SWh4UzFlQ3dIODZJREdPdHFmcTdLV1NTcXQ4T2ZoVi82UDVhNWtYdHlS?= =?iso-2022-jp?B?YWxUUUZrZkZlSHJzS0tvazMyVmJhaDAwK2Q0djVvajFKdzZLcUxmLzA4?= =?iso-2022-jp?B?Z0pNR3YvcllUcklVNmtibkozQ2ZNc2ZEMlRxZ1JGMmw5b0RqdW1IZlNW?= =?iso-2022-jp?B?akgxaTlabjQ3SUVCb1I2cnJaTlB0c3J5cXN3OUJxY0I2UjA0TEVkYlY5?= =?iso-2022-jp?B?cVpQQVdMTE80OVBzQ0U3YzRsbDQ5aTlLTkdHRzlFT3RldHBzeWR0ajM5?= =?iso-2022-jp?B?RkZUdDc0YlZOVVBqOXBRdVFraGZyN1ZrU015WmQ2VmNBcndVZnBQaWxE?= =?iso-2022-jp?B?M2NKLzVrTmlkbmdOQk9Ja3VIK3RIUzFwaHlvZU9Wdm4ycTlaRXpGZzd5?= =?iso-2022-jp?B?RHVET0c0eDl6cTNFUHduNytjZWRIRUx5SWRkQjNFQTBMNVBvRHU0SDEw?= =?iso-2022-jp?B?UDBqdUdpc1hsTndpbU80bEx3bWdsZjZCWmphR1U5L3BtODhFUlBGYi8v?= =?iso-2022-jp?B?SkJkYVhXa2ExSWZiQ0ZBMGM2ckpxZ3BJbzdmQmZPdUNjSlZTallaTTdx?= =?iso-2022-jp?B?L1hGUEpuYUN6ZHh2dDlTUjN5S2EwRmQ5MTBJbmN1bVRlaWljTGNaSDFa?= =?iso-2022-jp?B?SkhzanI3SW5XQTFHUXM1RFVFaWlpakJrK1hmRENWcU5UVDVpTFVjeTNp?= =?iso-2022-jp?B?Y2JNTEhrd3prWlJyUmNIWHFmVnlhQXBuWFkrbkpDTkJOOWp1T3pKUkFN?= =?iso-2022-jp?B?bFYvYzZ2UkNnVktYMjI2K0Z0ZWY5enlIajQ4T3pRa2NZc2wyMGtXallq?= =?iso-2022-jp?B?VzdVaTFEOTJmMkdXU1JTcTFkRXFuMWZaejk0WDRoTGxaZEI3SUk3WGg2?= =?iso-2022-jp?B?cEV0N0tWdkY2dC9vNWZITytOU2VCcnRWUlNMNk5GbWNhNzMvR05Bd01Z?= =?iso-2022-jp?B?aXVHVzdJWHpBaFBOazhHWlVrcjJNYnR5UXBsS3Q0eGtWd3czL1NtcFE1?= =?iso-2022-jp?B?QmxxM25JS3lINFRFc0M5NHdtTmdPOUE5ZU1iQmwyZUpIOVBtdGtneGVq?= =?iso-2022-jp?B?Ui9XVWdWNC9VdW8wakE3MGZ5bTRxTGVRVWFFUU1HcXc3T1RuUXVidmh5?= =?iso-2022-jp?B?ZG5CTGtSMUFqY0EwK2pjVnQ1Sm05WXd6ZjczN2FiRGZML21JZE9DUyto?= =?iso-2022-jp?B?U09KeE5sdGp3bXpuTFhzSGVOdDJJVlZaVEdvaThJa2I5TEY1c1FUZjR1?= =?iso-2022-jp?B?S2ZUNlE2WjNnWjk4S0prZEJVMHdrUTNtWUFQeGZNVU5nSFAwSnlKbU9q?= =?iso-2022-jp?B?UzhFbXJQcDJoa1JTRDNia1FVdUx0anZmUk9oMW5FNldDSWNSdFc0aUQx?= =?iso-2022-jp?B?b3JlZVl6b2pmM21kQ3hDSWRsZ1UwUW1TMXEzTzl1NysycUgweXhYUnY2?= =?iso-2022-jp?B?MWZJUStnQVYvT05xdzJod3QvRzQwTHVrcHVHSDJnWHRXWXY0OGVUY2Qr?= =?iso-2022-jp?B?UVJYWmJMZjZ0NGpNUVE5Q25yZDNmNmpOK3pUVStFUExqZ2Z6Y1B4dlhF?= =?iso-2022-jp?B?ZkJhT3hjTlJMamhEQUdWdUxPZkhnanpWaEZxS2JTR3Q0WTMvTE9rV1FT?= =?iso-2022-jp?B?V1UzUTZzS3JRR2c5dUhLRnhCeE1HU2ZxZnFqN1prQzJPSkJzeXhNZjVV?= =?iso-2022-jp?B?VWJyenZ5c1BqNThuNTY0ZzQ5bTgwNW45R0VFdkZZUzBGQ204eU5QME51?= =?iso-2022-jp?B?NmQ0aGRlWHF1S2s2WkFnS0pFWVdHV29ROC9VdjZrWEpnVUpLaVNCN3hE?= =?iso-2022-jp?B?YTVRY2piUWx1OFNscGs2SGkzUXpDMDJ2QnZSakRYN3RGMEhYZnBtSHhV?= =?iso-2022-jp?B?bzR6dzRTRmhad2E0MXk5c1NoOHpKZy9OdWp3bEFqT0N0MHVFeW1XUmVW?= =?iso-2022-jp?B?VlU3OXgyNDd2TXh4aXNHb3RPY1E9?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0582; 6:wUCoBt46NfVrQ7dM8gelgQ9I4hRm6l9ukZ5CH4P7oZgPkO51oylBrrX9ESm6eztBGB4b5aL+tibY7ujjHSjDq0eYRJ0TS6grSt7RS98VmS/59As6j5LXWUy5wcc3018PniUJEUQxu2rh7GbKtmcM4xRkizTJtSoMllvLl1rZ2y03NWrzBq7O8OE+9liC7NE8rAQeztj+FTkUQwuGy4gecivGxk29Z+55dCtg/RvWZ39EvKIk4dJaDNg3vJr7e82dIpHSt1sE7/ZFu0ra5n7gb5XqKXnj37q7xOBPAsvYqQ0HT3jdRo6yRCDJcCZwVDRVzQZQ6kT2p0PFfrcBZ7Ms9g==; 5:0dt3744L8EXHylJ0UyW6OA7ACA+SJa/54g74174Gx2CL48aigPOt+Y26i2obf5dRUm52q775gbNj3HTjYgx7tpHVTLd4KDPK9LhOC1Ja4gN6d4SLy86ZKJfHQw2iXABeoEJ9eDboSentw+GdjaY5Sw==; 24:jc6deIVYiYOxPuMZluNn32nvRNRMiZnj/HvWSyUatRPvIx6hPpq9Lf5wCsFeZ6wYbKZ2adiwSp53ma51Q4tqEmN+E4L2ltEAzBCeSIju8SU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0582; 7:SsqhZP+wdo+60LEiD0Yq8l4b1MmN0XSUvPPibXYihfsMqlytWuuUFRML9E1FI16BguVfepxsWgMLO6GjVU5Hpba9d+gzWaTXkiQScyPjgwGJPVXMT0quOsiwZAglVU2LNgd4OnswR0/V9e+9a0cqb1ovgv0siK+Z/zZyp/zQV4ZJs9IjAm/seFukMWkDc/oNJ9WeU/PmfpodpJZHZpq/mTwJXEUpVw5cNg7KyVom51aU/dXhq/GvDysxWaDCqnB1xrxJmkRQ8BsmAccUNKjU6pP5DwK+/XB7NEuHQ05ttx8rgLeIxd3nZ5H4ihZ35HrohNDpNBhyu7FFnyXQYzfrvt0gHKYKXMT7IEeU7RwboLI= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 07:27:37.2827 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0582 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org, bill.wu@huawei.com Subject: Re: [http-auth] Benoit Claise's No Record on draft-ietf-httpauth-mutual-algo-06: (with COMMENT) X-BeenThere: http-auth@ietf.org 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, 09 Nov 2016 07:27:44 -0000 Dear Benoit, thank you for forwarding the comments from Qin Wu. We reflect these comments to the next draft. On 11/02/16 06:57, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-httpauth-mutual-algo-06: No Record > > 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-algo/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some editorial comments from our OPS-DIR reviewer, Qin Wu. > > This document defines four HTTP Mutual authentication algorithms which > use with Mutual authentication protocol for HTTP, two for Discrete > Logarithm settings, two for elliptic curve settings. In addition, the > security of this algorithm is well analyzed. > > There is no major issue. I believe this document is ready for > publication. Here are a few editorial comments I like to ask authors to > consider: > > Minor issues: > > 1. Section 1.1 said: > > $B!H(B > > When a natural > > number output is required, the notation INT(H(s)) is used. > > > > $B!I(B > > I will see INT(H(s)) as a formula to convert H(s) into natural number > > 2. Section 2, 1st paragraph: > > What is DL-based notations? Can you expand DL? Is it Description Logic or > something else? > > You can consider to add acronym and abbreviation section. > > 3.Section 2, 2nd paragraph and the figure that describe protocol exchange > for four value > > Where you define the first two messages in this draft? Are you referred > to the first messages that contain ID, K_c1 and K_s1 respectively in the > figure? I don$B!G(Bt see you specify message format or give a message name? I > don$B!G(Bt see you related text with the message shown in the figure? > > > > In addition, where the last two message defined in > [I-D.ietf-httpauth-mutual]? Can you provide section number? > > By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has > already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and > am wondering if this draft really defines the first two messages? Or four > message shown in the figure are all defined in the > [[I-D.ietf-httpauth-mutual]. > > > > 4.Section 3.1, 3rd paragraph said: > > $B!H(B > > The functions named octet(), OCTETS(), and INT() are those defined in > > the core specification [I-D.ietf-httpauth-mutual]. > > $B!H(B > > Is the core specification [I-D.ietf-httpauth-mutual]the core document > mentioned in section 3? If yes, please make them consistent. > > > > 5.Section 3.3, symbol $B!H(BG$B!I(B > > g: for "the generator" associated with the group. > > How the symobol $B!H(BG$B!I(B is different from symbol $B!H(Bg$B!I(Bin the section 3.2? Does > G stand for the generator associated with the defined group? What do you > mean $B!H(Bthe defined point$B!I(B? Would be great to clarify the difference > between G and g. > > > > 6.Section 5.2 said: > > $B!H(B > > In the EC setting, r has to be > > prime. Defining a variation of this algorithm using a different > > domain parameter SHOULD be attentive to these conditions. > > $B!H(B > > What is EC setting? Please expand EC? Elliptic Curve? Please make this > clear or add this abbreviation into abbreviation section. > > > > Nites: > > 1.Section 1,1st paragraph > > s/ use withMutual authentication protocol/ use with Mutual authentication > protocol > > 2.Section 5.2 > > s/ mixing values from from two/ mixing values from two > > > > -Qin > > -- $BBg4d(B $B42(B Yutaka OIWA ($B9q8&(B)$B;:6H5;=QAm9g8&5f=j(B $B>pJs5;=Q8&5fItLg(B $B%5%$%P!<%U%#%8%+%k%&%'%"8&5f%0%k!<%WD9(B , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Wed Nov 9 06:52:46 2016 Return-Path: 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: 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> To: Yutaka OIWA Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" , httpauth-chairs@ietf.org, The IESG , Alexey Melnikov 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 14:52:44 -0000 Please excuse typos, sent from handheld device=20 > On Nov 9, 2016, at 2:18 AM, Yutaka OIWA wrote: >=20 > Dear Kathleen, >=20 > 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-algorithm= s.txt >=20 > Once the IETF draft submission system is reopened on 13 Nov, I'll submit t= he > revised draft formally to the IETF again. >=20 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 t= he WG. Thank you, Kathleen >=20 >> On 11/08/16 10:44, Kathleen Moriarty wrote: >> Hello, >>=20 >> 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 goo= d >> to wrap up these last 2 drafts soon. >>=20 >> Thank you, >> Kathleen >>=20 >> On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov >> wrote: >>=20 >>> Alexey Melnikov has entered the following ballot position for >>> draft-ietf-httpauth-mutual-10: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> 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. >>>=20 >>> 1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP >>> Authentication Schemes with IANA >>>=20 >>> 2) In Section 7: >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>> I agree that the Introduction section might need an editing pass. >>>=20 >>> In Section 1, next to the last paragraph: >>>=20 >>> The Mutual authentication protocol proposed in this document is a >>> strong cryptographic solution for password authentications. It >>> mainly provides the two key features: >>>=20 >>> Exactly the same paragraph appears earlier in the same section. Did you >>> forget to delete this instance? >>>=20 >>> 3.2. Values >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> 3.2.2. Strings >>>=20 >>> 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]. >>>=20 >>> This is the same as Unicode 1.1. Unicode now released version 9.0! I >>> suggest you use a Unicode reference. >>>=20 >>> In 3.2.3: >>>=20 >>> I think you are overusing SHOULDs instead of MUSTs in many >>> places in the document (not just just in this section). For example: >>>=20 >>> 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; >>>=20 >>> Why not a MUST here? >>>=20 >>> if these >>> are representing elements of a mathematical set (or group), its >>> lengths SHOULD be the shortest for representing all the elements in >>>=20 >>> Again, why not a MUST? Having a unique encoding will improve >>> interoperability. >>>=20 >>> the set. >>>=20 >>> 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] >>>=20 >>> I assume you meant Section 4 alphabet and not Section 5 alphabet from >>> this >>> RFC. Please add section reference to the above. >>>=20 >>> 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]). >>>=20 >>> 7.1. Applicability notes >>>=20 >>> When the client is a Web browser with any scripting capabilities, the >>>=20 >>> Can you explain why scripting capabilities are important here? >>>=20 >>> 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. >>>=20 >>> In Section 9: >>>=20 >>> 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. >>>=20 >>> I think you are giving too many choices which might cause >>> interoperability issues. >>> Even reducing the choices from 3 to 2 would help here. >>>=20 >>> In Section 11: >>>=20 >>> * 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. >>>=20 >>> Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are >>> possible reasons for a server implementation to violate these SHOULDs? >>>=20 >>> In Section 15: >>>=20 >>> It would be good to be able to bind extension data to shared secret >>> constructed by >>> both parties. >>>=20 >>>=20 >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >=20 > --=20 > =E5=A4=A7=E5=B2=A9 =E5=AF=9B Yutaka OIWA (=E5=9B=BD=E7=A0=94= )=E7=94=A3=E6=A5=AD=E6=8A=80=E8=A1=93=E7=B7=8F=E5=90=88=E7=A0=94=E7=A9=B6=E6= =89=80 =E6=83=85=E5=A0=B1=E6=8A=80=E8=A1=93=E7=A0=94=E7=A9=B6=E9=83=A8=E9=96= =80 > =E3=82=B5=E3=82=A4=E3=83=90=E3=83=BC=E3= =83=95=E3=82=A3=E3=82=B8=E3=82=AB=E3=83=AB=E3=82=A6=E3=82=A7=E3=82=A2=E7=A0=94= =E7=A9=B6=E3=82=B0=E3=83=AB=E3=83=BC=E3=83=97=E9=95=B7 > , = > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B= 5] From nobody Sun Nov 13 17:02:50 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E93129648; Sun, 13 Nov 2016 17:02:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147908536353.5501.6916484964365100315.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 17:02:43 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-11.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:02:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication of the IETF. Title : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-11.txt Pages : 57 Date : 2016-11-13 Abstract: This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 13 17:02:59 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F801295E5; Sun, 13 Nov 2016 17:02:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147908537099.5607.10463750571406533699.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 17:02:50 -0800 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-07.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 01:02:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication of the IETF. Title : Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-algo-07.txt Pages : 16 Date : 2016-11-13 Abstract: This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-algo-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 14 21:07:07 2016 Return-Path: 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 D7DE01298C5; Mon, 14 Nov 2016 21:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 2uOiW0oy8Zyb; Mon, 14 Nov 2016 21:07:04 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 CC713129501; Mon, 14 Nov 2016 21:07:03 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 12so79818380uas.2; Mon, 14 Nov 2016 21:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AoYW1yW6H/lv1DyTOB2etdpbDO+V3KfHBVORePRSpTs=; b=uj7eVf63MmieCir+Uvi0blDZO7WPYeMxVZNZ9d6k8jMoOsJ6mKVPtB3CzZwkSzOteK /enH5tKsifzzFW0vqsGREfPLsM7ZS9Na+DQOG3f4RiwNVxL/9W5ks6xLE5xqfT56y9RL w2HpsMUjmX8neZfJkLhdHWKORkDZCKrfORxp3W+HtsskaNM6ldpiMUcZxTEXIcy8l03H PxKm4cjXnUkmawIKJmL7RVWuRCAI6y+2pk30GFFmpfOUSoYgJD60yRyb+lk3FmsovnVx JIY/3h6SytRiFys6hkyDGSPwQzjNgpGXiQF7Cr0g/G1ibUfT6dKmKUFM+Fu3Paj9SH2b Ts8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AoYW1yW6H/lv1DyTOB2etdpbDO+V3KfHBVORePRSpTs=; b=h9ZkW4xoOKTAAD/l3HsfRiusmOWCPKSEfaC08xTmv8tIgJ5hk2wsUPFgBXktPnRUDT WV/hDCgO0IqDiVqp5vTm3Pp5C82ihV2TNhLnxQ9/PQXsWR+nq2DgWQpFujzkUK0J/iBr nB4G2v1nWS9LmNuymi0cABovsJlyuY2JOoqhPTL0Eg740tHKLcYHkv7bfFzdiWDHtug5 dae7ui2Is7b3CVnFw2eoA5fdPXGOxgz7XGYHqbfZXWhz+9BEBla7iJDA/uuAN3NG5zCo g/Jf7AVD30g7zRadsPkAI4lHVpby3nw6Ty99Ao+ZybmPKujnBGFGuYxXmnUKhWY/hK2V NOVQ== X-Gm-Message-State: ABUngvcMeDi1B+NH36nJTbj8gg6HdIuiMRx5WAAj8o1CzpTKxVNp+i42g2Bbt5Nr/05qXB7S0vc8j96aDSZYSQ== X-Received: by 10.176.0.147 with SMTP id 19mr10152617uaj.20.1479186422761; Mon, 14 Nov 2016 21:07:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Mon, 14 Nov 2016 21:07:02 -0800 (PST) In-Reply-To: <830EE33D-60BC-48BF-BF96-275ACC563CB6@gmail.com> References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> <830EE33D-60BC-48BF-BF96-275ACC563CB6@gmail.com> From: Kathleen Moriarty Date: Tue, 15 Nov 2016 00:07:02 -0500 Message-ID: To: Yutaka OIWA Content-Type: multipart/alternative; boundary=001a113dda6049114805414fedda Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" , httpauth-chairs@ietf.org, The IESG , Alexey Melnikov 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:07:06 -0000 --001a113dda6049114805414fedda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, Can you take a look at the updated draft to see if your concerns are addressed? Thank you, Kathleen On Wed, Nov 9, 2016 at 9:52 AM, wrote: > > > Please excuse typos, sent from handheld device > > > On Nov 9, 2016, at 2:18 AM, Yutaka OIWA 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 submi= t > 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 > > >> 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 th= is > >>> 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 importa= nt > >>> 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" HT= TP > >>> 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-uniqu= e" > >>> (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 on= e > >>> 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 actual= ly > >>> 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 y= ou > >>> 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: toke= ns > >>> (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 SHOU= LD > >>> 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 a= s > >>> 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 Section= s > >>> 3.1 to 3.5 of [RFC4648]). > >>> > >>> 7.1. Applicability notes > >>> > >>> When the client is a Web browser with any scripting capabilities, t= he > >>> > >>> 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 th= e > >>> 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, perfo= rm > >>> 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 > > > > -- > > =E5=A4=A7=E5=B2=A9 =E5=AF=9B Yutaka OIWA (=E5=9B=BD=E7=A0= =94)=E7=94=A3=E6=A5=AD=E6=8A=80=E8=A1=93=E7=B7=8F=E5=90=88=E7=A0=94=E7=A9= =B6=E6=89=80 =E6=83=85=E5=A0=B1=E6=8A=80=E8=A1=93=E7=A0=94=E7=A9=B6=E9=83= =A8=E9=96=80 > > =E3=82=B5=E3=82=A4=E3=83=90=E3=83= =BC=E3=83=95=E3=82=A3=E3=82=B8=E3=82=AB=E3=83=AB=E3=82=A6=E3=82=A7=E3=82=A2= =E7=A0=94=E7=A9=B6=E3=82=B0=E3=83=AB=E3=83=BC=E3=83=97=E9=95=B7 > > , < > yutaka@oiwa.jp> > > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] > --=20 Best regards, Kathleen --001a113dda6049114805414fedda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Can you take a look at the u= pdated draft to see if your concerns are addressed?

Thank you,
Kathleen

<= div class=3D"gmail_quote">On Wed, Nov 9, 2016 at 9:52 AM, <kathleen.moriarty.ietf@gmail.com> wrote:


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.c= om/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.=C2=A0 If you'd like to send in the draft via email an= d 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 c= omments),
>> please respond and discuss these questions and comments.=C2=A0 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<= br> >>> 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.ie= tf.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.or= g/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 s= ignificant
>>> comments.
>>>
>>> 1) As Mirja pointed out, this spec needs need to register &quo= t;Mutual" HTTP
>>> Authentication Schemes with IANA
>>>
>>> 2) In Section 7:
>>>
>>>=C2=A0 =C2=A0If HTTP is used on a non-encrypted channel (TCP an= d SCTP, for
>>>=C2=A0 =C2=A0example), the validation type MUST be "host&q= uot;.=C2=A0 If HTTP/TLS [RFC2818]
>>>=C2=A0 =C2=A0(HTTPS) is used with a server certificate, the val= idation type MUST
>>>=C2=A0 =C2=A0be "tls-server-end-point".=C2=A0 If HTTP= /TLS is used with an anonymous
>>>=C2=A0 =C2=A0Diffie-Hellman key exchange, the validation type M= UST be "tls-unique"
>>>=C2=A0 =C2=A0(see the note below).
>>>
>>>=C2=A0 =C2=A0Implementations supporting Mutual authentication o= ver HTTPS SHOULD
>>>=C2=A0 =C2=A0support the "tls-server-end-point" valid= ation.=C2=A0 Support for
>>>=C2=A0 =C2=A0"tls-unique" validation is OPTIONAL for = both servers and clients.
>>>
>>> I think the two paragraphs are in conflict. For example, the f= irst 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 su= pported.
>>>
>>> If the intent of the first paragraph is to say what should app= ear
>>> 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 pa= ss.
>>>
>>> In Section 1, next to the last paragraph:
>>>
>>>=C2=A0 =C2=A0The Mutual authentication protocol proposed in thi= s document is a
>>>=C2=A0 =C2=A0strong cryptographic solution for password authent= ications.=C2=A0 It
>>>=C2=A0 =C2=A0mainly provides the two key features:
>>>
>>> Exactly the same paragraph appears earlier in the same section= . Did you
>>> forget to delete this instance?
>>>
>>> 3.2.=C2=A0 Values
>>>
>>>=C2=A0 =C2=A0The parameter values contained in challenge/creden= tials MUST be
>>>=C2=A0 =C2=A0parsed strictly conforming to the HTTP semantics (= especially un-
>>>=C2=A0 =C2=A0quoting of the string parameter values).=C2=A0 In = this protocol, those
>>>=C2=A0 =C2=A0values are further categorized into the following = value types: tokens
>>>=C2=A0 =C2=A0(bare-token and extensive-token), string, integer,= hex-fixed-number,
>>>=C2=A0 =C2=A0and base64-fixed-number.
>>>
>>>=C2=A0 =C2=A0For clarity, implementations are RECOMMENDED to us= e the canonical
>>>=C2=A0 =C2=A0representations specified in the following subsect= ions for sending
>>>=C2=A0 =C2=A0values.=C2=A0 Recipients SHOULD accept both quoted= and unquoted
>>>=C2=A0 =C2=A0representations interchangeably as specified in HT= TP.
>>>
>>> I think the last SHOULD must be a MUST, because clients that g= enerate
>>> these values
>>> might be using libraries that automatically quote values. So t= his is
>>> really not
>>> under sender's control.
>>>
>>>
>>> 3.2.2.=C2=A0 Strings
>>>
>>>=C2=A0 =C2=A0All character strings MUST be encoded to octet str= ings using the
>>>=C2=A0 =C2=A0UTF-8 encoding [RFC3629] for the ISO 10646-1 chara= cter set
>>>=C2=A0 =C2=A0[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 ex= ample:
>>>
>>>=C2=A0 =C2=A0When
>>>=C2=A0 =C2=A0these values are generated from any cryptographic = values, they SHOULD
>>>=C2=A0 =C2=A0have their "natural length"; if these ar= e generated from a hash
>>>=C2=A0 =C2=A0function, these lengths SHOULD correspond to the h= ash size;
>>>
>>> Why not a MUST here?
>>>
>>>=C2=A0 =C2=A0if these
>>>=C2=A0 =C2=A0are representing elements of a mathematical set (o= r group), its
>>>=C2=A0 =C2=A0lengths SHOULD be the shortest for representing al= l the elements in
>>>
>>> Again, why not a MUST? Having a unique encoding will improve >>> interoperability.
>>>
>>>=C2=A0 =C2=A0the set.
>>>
>>>=C2=A0 =C2=A0The numbers represented as base64-fixed-number SHA= LL be generated as
>>>=C2=A0 =C2=A0follows: first, the number is converted to a big-e= ndian radix-256
>>>=C2=A0 =C2=A0binary representation as an octet string.=C2=A0 Th= e length of the
>>>=C2=A0 =C2=A0representation is determined in the same way as me= ntioned above.
>>>=C2=A0 =C2=A0Then, the string is encoded using the Base 64 enco= ding [RFC4648]
>>>
>>> I assume you meant Section 4 alphabet and not Section 5 alphab= et from
>>> this
>>> RFC. Please add section reference to the above.
>>>
>>>=C2=A0 =C2=A0without any spaces and newlines.=C2=A0 Implementat= ions decoding base64-
>>>=C2=A0 =C2=A0fixed-number SHOULD reject any input data with inv= alid characters,
>>>=C2=A0 =C2=A0excess/insufficient padding, or non-canonical pad = bits (See Sections
>>>=C2=A0 =C2=A03.1 to 3.5 of [RFC4648]).
>>>
>>> 7.1.=C2=A0 Applicability notes
>>>
>>>=C2=A0 =C2=A0When the client is a Web browser with any scriptin= g capabilities, the
>>>
>>> Can you explain why scripting capabilities are important here?=
>>>
>>>=C2=A0 =C2=A0underlying TLS channel used with HTTP/TLS MUST pro= vide server
>>>=C2=A0 =C2=A0identity verification.=C2=A0 This means (1) anonym= ous Diffie-Hellman key
>>>=C2=A0 =C2=A0exchange cipher suites MUST NOT be used, and (2) v= erification of the
>>>=C2=A0 =C2=A0server certificate provided by the server MUST be = performed.
>>>
>>> In Section 9:
>>>
>>>=C2=A0 =C2=A0In both cases, it is the sender's duty to corr= ectly prepare the
>>>=C2=A0 =C2=A0character strings.=C2=A0 If any non-normalized cha= racter string is
>>>=C2=A0 =C2=A0received from the other peer of the communication,= recipients MAY
>>>=C2=A0 =C2=A0either use it as a bare UTF-8 string without any p= reparation, perform
>>>=C2=A0 =C2=A0any appropriate preparations (which may cause auth= entication
>>>=C2=A0 =C2=A0failure), or reject any ill-prepared inputs from t= he sender and
>>>=C2=A0 =C2=A0respond 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:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 *=C2=A0 Otherwise, send a 200-VFY-S respon= se.=C2=A0 If the session was in
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the "key exchanging"= ; state, the session SHOULD be changed to an
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"authenticated" sta= te.=C2=A0 The maximum nc and nc flags of the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0state SHOULD be updated appro= priate.
>>>
>>> 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 s= ecret
>>> constructed by
>>> both parties.
>>>
>>>
>>> _______________________________________________
>>> http-auth mailing list
>>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listin= fo/http-auth
>
> --
> =E5=A4=A7=E5=B2=A9 =E5=AF=9B=C2=A0 =C2=A0Yutaka OIWA=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(=E5=9B=BD=E7=A0=94)=E7=94=A3=E6=A5=AD=E6=8A= =80=E8=A1=93=E7=B7=8F=E5=90=88=E7=A0=94=E7=A9=B6=E6=89=80 =E6=83=85=E5=A0= =B1=E6=8A=80=E8=A1=93=E7=A0=94=E7=A9=B6=E9=83=A8=E9=96=80
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E3=82=B5=E3= =82=A4=E3=83=90=E3=83=BC=E3=83=95=E3=82=A3=E3=82=B8=E3=82=AB=E3=83=AB=E3=82= =A6=E3=82=A7=E3=82=A2=E7=A0=94=E7=A9=B6=E3=82=B0=E3=83=AB=E3=83=BC=E3=83=97= =E9=95=B7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D=C2=A0 3139 8677 9BD2= 4405 46B5]



--
=

Best regards,
Kathleen
--001a113dda6049114805414fedda-- From nobody Mon Nov 14 21:33:50 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4AA12966C; Mon, 14 Nov 2016 21:33:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147918802854.2301.4275124197627692775.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2016 21:33:48 -0800 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:33:48 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-httpauth-mutual-11: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? In Section 15: It would be good to be able to bind extension data to shared secret constructed by both parties. From nobody Mon Nov 14 21:36:15 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF1129A28; Mon, 14 Nov 2016 21:36:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147918816896.2364.18134421572197872920.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2016 21:36:08 -0800 Archived-At: Cc: httpauth-chairs@ietf.org, http-auth@ietf.org, The IESG , draft-ietf-httpauth-mutual-algo@ietf.org, rfc-editor@rfc-editor.org Subject: [http-auth] Document Action: 'Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms' to Experimental RFC (draft-ietf-httpauth-mutual-algo-07.txt) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:36:09 -0000 The IESG has approved the following document: - 'Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms' (draft-ietf-httpauth-mutual-algo-07.txt) as Experimental RFC This document is the product of the Hypertext Transfer Protocol Authentication Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ Technical Summary This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). Working Group Summary This document is one in a three-part set of documents describing the Mutual-Auth authentication method for HTTP. This part describes the cryptographic algorithms for use with MutualAuth. The algorithms are based on Augmented Password-based Authenticated Key Exchange (Augmented PAKE) techniques. With version -05 it is the consensus of the HTTP-Auth working group that this document is fit to be published as an experimental RFC. The document received a moderate amount of review from the working group. In addition we solicited and received a review from Melinda Shore. Document Quality There are implementations of this protocol written by the authors. They take the form of a modified web server and a fork of the Firefox browser that include this functionality. Personnel Yoav Nir is the document shepherd. Kathleen Moriarty is the responsible Area Director. IANA Note This document defines four new tokens to be added to the "HTTP Mutual authentication algorithms" registry. From nobody Tue Nov 15 17:11:03 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8379612941C; Tue, 15 Nov 2016 17:11:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147925866149.10264.13752808133385644000.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2016 17:11:01 -0800 Archived-At: Cc: httpauth-chairs@ietf.org, http-auth@ietf.org, draft-ietf-httpauth-extension@ietf.org, rfc-editor@rfc-editor.org, The IESG Subject: [http-auth] Document Action: 'HTTP Authentication Extensions for Interactive Clients' to Experimental RFC (draft-ietf-httpauth-extension-09.txt) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:11:01 -0000 The IESG has approved the following document: - 'HTTP Authentication Extensions for Interactive Clients' (draft-ietf-httpauth-extension-09.txt) as Experimental RFC This document is the product of the Hypertext Transfer Protocol Authentication Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ Technical Summary This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. This document is one in a three-part set of documents describing the Mutual-Auth authentication method for HTTP. This part extends the HTTP authentication framework from RFC 7235 to include optional authentication as well as de-authorization (log out) and finer control of redirection depending on authentication status. Working Group Summary With version -07 it is the consensus of the HTTP-Auth working group that this document is fit to be published as an experimental RFC. The document received a moderate amount of review from the working group. In addition we solicited and received a review from Cory Benfield. Document Quality There are implementations of this protocol written by the authors. They take the form of a modified web server and a fork of the Firefox browser that include this functionality. Personnel Yoav Nir is the Document Shepherd and Kathleen Moriarty is the Responsible Area Director IANA Note This document establishes a registry with initial entries for HTTP authentication control parameters. New entries to this registry are by "Specification Required" described in [RFC5226]. The specification must be publicly accessible. This document also defines two new entries for the "Permanent Message Header Field Names" registry From nobody Tue Nov 15 20:51:11 2016 Return-Path: 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 7AAC2129648; Tue, 15 Nov 2016 20:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp 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 SnLcNMMVvUmF; Tue, 15 Nov 2016 20:51:07 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0087.outbound.protection.outlook.com [104.47.92.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49EA129472; Tue, 15 Nov 2016 20:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pu8m253afLEU08g2DY08uMe3o2vGBRuHeNz3rfhts7M=; b=ghjiVt44F2alfxzDhUHIaTeC9j08S23hnMnclFmpgVvf5yTLoixDXBdbOgFcUPMJoL9kEhV8oyTMgMyLQjUX12znoLYJOx/RWAsPTXRwWlveWCzuH4PNR8lUxaPJsgRRXG42so61OgzGcFZ4WAGDpeklI2WiqLd9NBQz7i699t4= Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) by TY1PR01MB0587.jpnprd01.prod.outlook.com (10.167.157.17) 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 TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) by TY1PR01MB0588.jpnprd01.prod.outlook.com ([10.167.157.18]) with mapi id 15.01.0721.015; Wed, 16 Nov 2016 04:50:58 +0000 From: =?utf-8?B?5aSn5bKp5a+b?= 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: <147918802854.2301.4275124197627692775.idtracker@ietfa.amsl.com> In-Reply-To: <147918802854.2301.4275124197627692775.idtracker@ietfa.amsl.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: [31.133.155.150] 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; H:TY1PR01MB0588.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: aist.go.jp 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-OriginatorOrg: aist.go.jp 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: "http-auth@ietf.org" , "draft-ietf-httpauth-mutual@ietf.org" , "httpauth-chairs@ietf.org" Subject: Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-mutual-11: (with COMMENT) X-BeenThere: http-auth@ietf.org 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 RGVhciBBbGV4ZXksDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXdzLg0KDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmsgeW91IGZvciBh ZGRyZXNzaW5nIG15IERJU0NVU1MgcG9pbnRzIGFuZCBtb3N0IG9mIG15IGNvbW1lbnRzIQ0KPiAN Cj4gSSBhZ3JlZSB0aGF0IHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBtaWdodCBuZWVkIGFuIGVk aXRpbmcgcGFzcy4NCj4gDQo+IEluIFNlY3Rpb24gMSwgbmV4dCB0byB0aGUgbGFzdCBwYXJhZ3Jh cGg6DQo+IA0KPiAgICBUaGUgTXV0dWFsIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHByb3Bvc2Vk IGluIHRoaXMgZG9jdW1lbnQgaXMgYQ0KPiAgICBzdHJvbmcgY3J5cHRvZ3JhcGhpYyBzb2x1dGlv biBmb3IgcGFzc3dvcmQgYXV0aGVudGljYXRpb25zLiAgSXQNCj4gICAgbWFpbmx5IHByb3ZpZGVz IHRoZSB0d28ga2V5IGZlYXR1cmVzOg0KPiANCj4gRXhhY3RseSB0aGUgc2FtZSBwYXJhZ3JhcGgg YXBwZWFycyBlYXJsaWVyIGluIHRoZSBzYW1lIHNlY3Rpb24uIERpZCB5b3UgZm9yZ2V0DQo+IHRv IGRlbGV0ZSB0aGlzIGluc3RhbmNlPw0KPiANCj4gSW4gU2VjdGlvbiA5Og0KPiANCj4gICAgSW4g Ym90aCBjYXNlcywgaXQgaXMgdGhlIHNlbmRlcidzIGR1dHkgdG8gY29ycmVjdGx5IHByZXBhcmUg dGhlDQo+ICAgIGNoYXJhY3RlciBzdHJpbmdzLiAgSWYgYW55IG5vbi1ub3JtYWxpemVkIGNoYXJh Y3RlciBzdHJpbmcgaXMNCj4gICAgcmVjZWl2ZWQgZnJvbSB0aGUgb3RoZXIgcGVlciBvZiB0aGUg Y29tbXVuaWNhdGlvbiwgcmVjaXBpZW50cyBNQVkNCj4gICAgZWl0aGVyIHVzZSBpdCBhcyBhIGJh cmUgVVRGLTggc3RyaW5nIHdpdGhvdXQgYW55IHByZXBhcmF0aW9uLCBwZXJmb3JtDQo+ICAgIGFu eSBhcHByb3ByaWF0ZSBwcmVwYXJhdGlvbnMgKHdoaWNoIG1heSBjYXVzZSBhdXRoZW50aWNhdGlv bg0KPiAgICBmYWlsdXJlKSwgb3IgcmVqZWN0IGFueSBpbGwtcHJlcGFyZWQgaW5wdXRzIGZyb20g dGhlIHNlbmRlciBhbmQNCj4gICAgcmVzcG9uZCBhcyBhIGNvbW11bmljYXRpb24gZXJyb3IuDQo+ IA0KPiBJIHRoaW5rIHlvdSBhcmUgZ2l2aW5nIHRvbyBtYW55IGNob2ljZXMgd2hpY2ggbWlnaHQg Y2F1c2UgaW50ZXJvcGVyYWJpbGl0eQ0KPiBpc3N1ZXMuDQo+IEV2ZW4gcmVkdWNpbmcgdGhlIGNo b2ljZXMgZnJvbSAzIHRvIDIgd291bGQgaGVscCBoZXJlLg0KPg0KPiBJbiBTZWN0aW9uIDExOg0K PiANCj4gICAgICAgKiAgT3RoZXJ3aXNlLCBzZW5kIGEgMjAwLVZGWS1TIHJlc3BvbnNlLiAgSWYg dGhlIHNlc3Npb24gd2FzIGluDQo+ICAgICAgICAgIHRoZSAia2V5IGV4Y2hhbmdpbmciIHN0YXRl LCB0aGUgc2Vzc2lvbiBTSE9VTEQgYmUgY2hhbmdlZCB0byBhbg0KPiAgICAgICAgICAiYXV0aGVu dGljYXRlZCIgc3RhdGUuICBUaGUgbWF4aW11bSBuYyBhbmQgbmMgZmxhZ3Mgb2YgdGhlDQo+ICAg ICAgICAgIHN0YXRlIFNIT1VMRCBiZSB1cGRhdGVkIGFwcHJvcHJpYXRlLg0KPiANCj4gQ2FuIHlv dSBleHBsYWluIHdoeSB0aGVzZSAyIFNIT1VMRHMgYXJlIG5vdCBNVVNUcz8gSS5lLiwgd2hhdCBh cmUgcG9zc2libGUNCj4gcmVhc29ucyBmb3IgYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gdG8gdmlv bGF0ZSB0aGVzZSBTSE9VTERzPw0KDQpJIGJlbGlldmUgdGhhdCB0aGVzZSB0aHJlZSBwb2ludHMg YXJlIGFkZHJlc3NlZCBpbiBkcmFmdC0xMS4NCg0KPiBJbiBTZWN0aW9uIDE1Og0KPiANCj4gSXQg d291bGQgYmUgZ29vZCB0byBiZSBhYmxlIHRvIGJpbmQgZXh0ZW5zaW9uIGRhdGEgdG8gc2hhcmVk IHNlY3JldCBjb25zdHJ1Y3RlZA0KPiBieSBib3RoIHBhcnRpZXMuDQoNCkkgdGhpbmsgaXQncyBx dWl0ZSBpbnRlcmVzdGluZy4NCkhvd2V2ZXIsIEkgZG9uJ3QgaGF2ZSBhIGdvb2QgaWRlYSBmb3Ig c3RhYmxlIGVub3VnaCBleHByZXNzaW9uIG9mIHRoaXMNCmZvciBnb29kIGludGVyb3BlcmFiaWxp dHkuDQooSXQncyBzaW1pbGFyIHRvIGhlYWRlciBzaWduaW5nLCBpdCdzIGltcG9ydGFudCBidXQg ZGlmZmljdWx0IHRoaW5nLikNCklmIGl0IHdpbGwgYmVjb21lIGltcG9ydGFudCwgSSdkIGxpa2Ug dG8gYWRkcmVzcyBpdCBpbiBwb3NzaWJsZSBmdXR1cmUNCnJldmlzaW9uIG9mIHRoZSBwcm90b2Nv bC4NCkN1cnJlbnRseSwgaWYgc29tZSBleHRlbnNpb24gaXMgcmVhbGx5IHN0cm9uZ2x5ICJjcml0 aWNhbCIsIHdlIGNhbiBkZWZpbmUNCmEgbmV3IHZhcmlhbnQgb2YgdGhlICJhbGdvcml0aG0iIHRv IG92ZXJjb21lIHRoYXQuDQoNCi0tIA0KWXV0YWthIE9JV0EsIFBoLkQuICAgICAgIExlYWRlciwg Q3liZXIgUGh5c2ljYWwgQXJjaGl0ZWN0dXJlIFJlc2VhcmNoIEdyb3VwDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSW5mb3JtYXRpb24gVGVjaG5vbG9neSBSZXNlYXJjaCBJbnN0 aXR1dGUNCiAgICBOYXRpb25hbCBJbnN0aXR1dGUgb2YgQWR2YW5jZWQgSW5kdXN0cmlhbCBTY2ll bmNlIGFuZCBUZWNobm9sb2d5IChBSVNUKQ0KICAgICAgICAgICAgICAgICAgICAgIE1haWwgYWRk cmVzc2VzOiA8eS5vaXdhQGFpc3QuZ28uanA+LCA8eXV0YWthQG9pd2EuanA+DQpPcGVuUEdQOiBp ZFs0NDA1NDZCNV0gZnBbN0M5RiA3MjNBIDc1NTkgMzI0NiAyMjlEICAzMTM5IDg2NzcgOUJEMiA0 NDA1IDQ2QjVdDQoNCg== From isen@treeboxsolutions.com Sun Nov 27 22:11:50 2016 Return-Path: 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 3781A12944D for ; Sun, 27 Nov 2016 22:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=treeboxsolutions-com.20150623.gappssmtp.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 rvQmpjgs5yjK for ; Sun, 27 Nov 2016 22:11:48 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 44BDC12940C for ; Sun, 27 Nov 2016 22:11:48 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id t125so107137017ywc.1 for ; Sun, 27 Nov 2016 22:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=treeboxsolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BaXgjC99oCTPYzzVrfTMM8y67ZzEgp7vPMaKw+zmYPc=; b=DcNkeFu+nqZSu8e8hHQC4blT3mEgFfo479xtvA2kgAd+Q9GgtlK4SQbr6iz0Lyt85X 7uqaTBxXRTPnsgZPkm0s8Fh3WuEw0VCz6GXtXjAMLu7ygGq5df58pUbBRmTw6nUvKLrN rniZIY6YMvDz8PMuCEZ7/tZBClPYGdLPjk/rrECPnj1mzij1KwCDLwJRNHXcTf6jYESe QJUB0CrGhHq+QBH/wBUt1xky5W8SlyWYyGwQWookQBenPABhAndxiLxfI4VML4sOSjXk rRAMsaHjo4srB4l9zog8VLYsUOAnMjHCALAbFyuaEDpV6sfRsUxT5EpDlrwfr7slDN3C g6sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BaXgjC99oCTPYzzVrfTMM8y67ZzEgp7vPMaKw+zmYPc=; b=PUo8aW0eBJ/bED3SZLScMYoGYRymT6NpMlgWOPjtWBPcb6c/oF/wxPpNKe7AVQn5m7 UMi0DHWbC336o43tN5dBWtf/Lm11TahSlrYYBXftsn3dXDh84sjcKRc10NiPgZ01oYqU +PmXMcnB+vYNFHXMQqUqcb2IV2odKQ3KKZWv/kOkbLzuVOoRCOI7ALmNi2uhIYxaC0R7 RqKZN9h3EjJzKlpyNGm+AAYjs3tdZZFec8l4n0laYeBZcCASt3dgZQJrTZkPCrdH1hIk n4qv+gZFhFAaARbbL6RBTvlC/QNDAokoqvFFsuOiBnYm6gr4vmY7NMVttxyL8wShI6EG flfg== X-Gm-Message-State: AKaTC01sHtmqhj97hDxbn+uy3JoEXR6JK5BIpuMvd6XNPEXPsfyTCKxbmocQN4mCPeJy8IPTCD5fktOIbBTOVd94 X-Received: by 10.129.206.2 with SMTP id t2mr27453875ywi.181.1480313507386; Sun, 27 Nov 2016 22:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.112.137 with HTTP; Sun, 27 Nov 2016 22:11:46 -0800 (PST) From: Isen Ng Date: Mon, 28 Nov 2016 14:11:46 +0800 Message-ID: To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1a0272c3c9ce0542565878 Archived-At: X-Mailman-Approved-At: Sun, 27 Nov 2016 22:45:47 -0800 Subject: [http-auth] RFC 7804 One Round-Trip Reauthentication X-BeenThere: http-auth@ietf.org 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: Mon, 28 Nov 2016 06:12:59 -0000 --94eb2c1a0272c3c9ce0542565878 Content-Type: text/plain; charset=UTF-8 Hi, I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication" ( https://tools.ietf.org/html/rfc7804#page-10). It is said that "If the client has authenticated to the same realm before (i.e., it remembers "i" and "s" attributes for the user from earlier authentication exchanges with the server), it can respond to that with "client-final-message"" And the example give: C: GET /resource HTTP/1.1 C: Host: server.example.com C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX pqZk1IZ3NxbW1pejdBbmRWUT0K C: [...] In this case, there no longer is an attribute named "sid" in this "client-final-message". How does the server know which user's secret to use to calculate the proof for matching? Regards, Isen --94eb2c1a0272c3c9ce0542565878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm looking at RFC 7804, specifically = at "One Round-Trip Reauthentication" (https://tools.ietf.org/html/rfc7804#page-10).

And the example= give:
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm=3D"testrealm@example.com",
          data=3DYz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
           lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
           pqZk1IZ3NxbW1pejdBbmRWUT0K

C: [...]
In this case, there no longer is an attribute named "sid= " in this "client-final-message".
How does th= e server know which user's secret to use to calculate the proof for mat= ching?

Regards,
Isen
--94eb2c1a0272c3c9ce0542565878-- From nobody Wed Nov 30 04:42:50 2016 Return-Path: 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 8132C1297BC for ; Wed, 30 Nov 2016 04:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 DtacRUmpuO3w for ; Wed, 30 Nov 2016 04:42:48 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F15911297A7 for ; Wed, 30 Nov 2016 04:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1480509767; d=isode.com; s=june2016; i=@isode.com; bh=HkkEbO83UFpvRaXDAu7h0JQkVHmOZ+vZY6FyWv7qDsU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=YJ9Q9d66bGvIYTVbhikuiCrPmOHQGzoaz7mKUPA7zEcE2649B60U0+W+Bzc3y4Vrj/L3YF png3mi0H+IYBH1606JcFS8U+F3UA3eSma/1uvJDih/ANRvBoNpyXcUB6LIfkEP3uDyYL2n 1Tz/GfKKG1iJLKqlQc4zyx5EUH/2SRw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 Nov 2016 12:42:46 +0000 To: Isen Ng , http-auth@ietf.org References: From: Alexey Melnikov Message-ID: <81f2ff57-64a1-47cb-49bd-dfa17aaacdc8@isode.com> Date: Wed, 30 Nov 2016 12:42:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AC3D885BB088D20FAD70B337" Archived-At: Subject: Re: [http-auth] RFC 7804 One Round-Trip Reauthentication X-BeenThere: http-auth@ietf.org 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, 30 Nov 2016 12:42:49 -0000 This is a multi-part message in MIME format. --------------AC3D885BB088D20FAD70B337 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Isen, On 28/11/2016 06:11, Isen Ng wrote: > Hi, > > I'm looking at RFC 7804, specifically at "One Round-Trip > Reauthentication" (https://tools.ietf.org/html/rfc7804#page-10). > > It is said that > "If the client has authenticated to the same realm before (i.e., it > remembers "i" and "s" attributes for the user from earlier > authentication exchanges with the server), it can respond to that > with "client-final-message"" > And the example give: > C: GET /resource HTTP/1.1 > C: Host:server.example.com > C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com ", > data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM > lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX > pqZk1IZ3NxbW1pejdBbmRWUT0K > > C: [...] > In this case, there no longer is an attribute named "sid" in this > "client-final-message". > How does the server know which user's secret to use to calculate the > proof for matching? You are right, I messed it up! The client should be sending "n=" somewhere in this response. Are you trying to implement this? Best Regards, Alexey --------------AC3D885BB088D20FAD70B337 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi Isen,


On 28/11/2016 06:11, Isen Ng wrote:
Hi,

I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication" (https://tools.ietf.org/html/rfc7804#page-10).

It is said that
"If the client has authenticated to the same realm before (i.e., it
remembers "i" and "s" attributes for the user from earlier
authentication exchanges with the server), it can respond to that
with "client-final-message""
And the example give:
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com",
          data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM
           lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX
           pqZk1IZ3NxbW1pejdBbmRWUT0K

C: [...]
In this case, there no longer is an attribute named "sid" in this "client-final-message".
How does the server know which user's secret to use to calculate the proof for matching?
You are right, I messed it up! The client should be sending "n=<username>" somewhere in this response.

Are you trying to implement this?

Best Regards,
Alexey


--------------AC3D885BB088D20FAD70B337-- From nobody Wed Nov 30 18:22:17 2016 Return-Path: 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 82301129693 for ; Wed, 30 Nov 2016 18:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=treeboxsolutions-com.20150623.gappssmtp.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 uVKJvwij6SFa for ; Wed, 30 Nov 2016 18:22:09 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 1749B12956B for ; Wed, 30 Nov 2016 18:22:09 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id i145so174781296ywg.2 for ; Wed, 30 Nov 2016 18:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=treeboxsolutions-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h9VvvY4uGlyz0wLmLAtsFN/oW+eq4sHy5gLUp7TIhLw=; b=F2XPVfrRoXn1nRLtjdmX6bxBAWU2qLaRsnVwLO4AQozR9Q+wzQBVkBfxqdat9tJnJW 6IZsUEXNVC7DDwHfxCYHjlgtwoE9W5J6P1VyPG0FkdzgWka5Gho7mDVPln5iWKiAieFb wvXFXKEP7fayms7a6NZbDUE5L5uAsSiVuE1mFUcCSqBlnAkV4yfK5EVDMo/7mnVlovhD M/WZofjKrPnYHaOO3j0J0R4t8Qd3kcqLia4ybpUoj2v61daxXVTRs0Lq+5pz/b2S3Irg OXarxBmENS7H87GzF/x1QiZ04rgyVgUNBSQ/TwN+lSqxs8rDLk1d6dWKPhXs5c/i/3Y0 k81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h9VvvY4uGlyz0wLmLAtsFN/oW+eq4sHy5gLUp7TIhLw=; b=cjmAj+KXehA/QWvqukUW8Zq+O5laAgZ2mOth3Rxx9OtvZJ/5Y+TXvUXOJBEZvB1ru5 2IX3cIBU/Y56T/rJW3oKfgjgdCSnneYOiYRyrkDAh8egyZ4NxyJ6aaTPtp/lsT/lrfPc eeRMtQavazfY+6jP0iu5lVJpYUaepkPLqTmuu1kQza574sozpiNcG00N/4FUgYfpf7iU yh6dtUl0Pj/NPcI302RPKIbaWz0ct6tBjyBOH3kT7Z7vQZfFpFMpt/09D2jHsnCuVDci iEFcHK+h91sAqJQ+urG76Zgn1c6N5eEOIgDoqceuPLTirFEqPeI3M1jJ/UJkn4PUqdMr sNZQ== X-Gm-Message-State: AKaTC026WPJeAtpSw7ZhZLom1iOND55I0rOc2aEoBgTy6O0oGlKqB4ojtQk2Ws9E4FiExaKUI6L3VP40rNoXtfx4 X-Received: by 10.13.219.203 with SMTP id d194mr43115241ywe.305.1480558928243; Wed, 30 Nov 2016 18:22:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.219.70 with HTTP; Wed, 30 Nov 2016 18:22:07 -0800 (PST) In-Reply-To: <81f2ff57-64a1-47cb-49bd-dfa17aaacdc8@isode.com> References: <81f2ff57-64a1-47cb-49bd-dfa17aaacdc8@isode.com> From: Isen Ng Date: Thu, 1 Dec 2016 10:22:07 +0800 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114fbfb8fcda8f05428f7cb1 Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] RFC 7804 One Round-Trip Reauthentication X-BeenThere: http-auth@ietf.org 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: Thu, 01 Dec 2016 02:22:15 -0000 --001a114fbfb8fcda8f05428f7cb1 Content-Type: text/plain; charset=UTF-8 Hi Alexey, Yeah, I have implemented the HTTP SCRAM-SHA256 protocol according to this RFC7804 and is implementing the one round-trip re-authentication at the moment. My colleagues and I have agreed upon a workaround and that is to include the original "sid" in the "client-final-message". The reason we do so is because the server has to keep a cache of the original c-nonce and s-nonce for nonce verification anyway. Instead of trying to maintain a different state for this using a different identifier and then butchering the "client-final-message" with extra variables, we decided to simply reuse the session that is already maintained. This way, the code written to process the "client-final-message" into the "server-final-message" does need to change at all. The same code that was used in an regular 2-round-trip authentication can be used in this 1-trip re-authentication. Regards, Isen *Isen Ng* | Ninja *TreeBox Solutions Pte Ltd* 1 Commonwealth Lane #03-01/02 Singapore 149544 *E:* isen@treeboxsolutions.com website | linkedin | twitter | facebook On Wed, Nov 30, 2016 at 8:42 PM, Alexey Melnikov wrote: > Hi Isen, > > On 28/11/2016 06:11, Isen Ng wrote: > > Hi, > > I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication" > (https://tools.ietf.org/html/rfc7804#page-10). > > It is said that > > "If the client has authenticated to the same realm before (i.e., it > remembers "i" and "s" attributes for the user from earlier > authentication exchanges with the server), it can respond to that > with "client-final-message"" > > And the example give: > > C: GET /resource HTTP/1.1 > C: Host: server.example.com > C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", > data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhM > lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOX > pqZk1IZ3NxbW1pejdBbmRWUT0K > > C: [...] > > In this case, there no longer is an attribute named "sid" in this > "client-final-message". > How does the server know which user's secret to use to calculate the proof > for matching? > > You are right, I messed it up! The client should be sending "n=" > somewhere in this response. > > Are you trying to implement this? > > Best Regards, > Alexey > > > --001a114fbfb8fcda8f05428f7cb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Yeah, I have implemented the HTTP SCRAM-SHA256 protocol according to this = RFC7804 and is implementing the one round-trip re-authentication at the mom= ent.

My colleagues and I have agreed upon a workaround and tha= t is to include the original "sid" in the "client-final-mess= age".
The reason we do so is because the server has to keep a= cache of the original c-nonce and s-nonce for nonce verification anyway. I= nstead of trying to maintain a different state for this using a different i= dentifier and then butchering the "client-final-message" with ext= ra variables, we decided to simply reuse the session that is already mainta= ined.

This way, the code written to process the "client-f= inal-message" into the "server-final-message" does need to c= hange at all.
The same code that was used in an regular 2-round-tr= ip authentication can be used in this 1-trip re-authentication.

Regards,
Isen

=
Isen Ng |=C2=A0 Ninja

TreeBox Solutions Pte Ltd
1 Commonwealth Lane #03-01/02
Singapore 149544
E: isen@treeboxsolutio= ns.com

website | =C2=A0linkedin= =C2=A0=C2=A0| =C2=A0twitter=C2=A0= =C2=A0| =C2=A0faceb= ook

On Wed, Nov 30, 2016 at 8:42 PM, Alexey Meln= ikov <alexey.melnikov@isode.com> wrote:
=20 =20 =20

Hi Isen,


On 28/11/2016 06:11= , Isen Ng wrote:
Hi,

I'm looking at RFC 7804, specifically at "One Round-Trip Reauthentication" (https://tools.ietf.org/html/rfc7804#p= age-10).

It is said that
"If the cl=
ient has authenticated to the same realm before (i.e., it
remembers "i" and "s" attributes for the user from earl=
ier
authentication exchanges with the server), it can respond to that
with "client-final-message""
And the example give:
C: GET /resourc=
e HTTP/1.1
C: Host: server.exa=
mple.com
C: Authorization: SCRAM-SHA-256 realm=3D"testrealm@example.com",
          data=3DYz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2=
WURwV1VhM
           lJhVENBZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFn=
OX
           pqZk1IZ3NxbW1pejdBbmRWUT0K

C: [...]
In this case, there no longer is an attribute named "sid&quo= t; in this "client-final-message".
How does the server know which user's secret to use to calculate the proof for matching?
 You are right, I messed it up! The client should be sending "n=3D<username>" somewhere in this response.

Are you trying to implement this?

Best Regards,
Alexey



--001a114fbfb8fcda8f05428f7cb1--