From nobody Sat Oct 8 21:24:48 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 800C4129457 for ; Sat, 8 Oct 2016 21:24:46 -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 Lo6XfVaosXVT for ; Sat, 8 Oct 2016 21:24:44 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0056.outbound.protection.outlook.com [104.47.93.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C33D129404 for ; Sat, 8 Oct 2016 21:24:43 -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=8qwarvgX36pp/HeJMg7gKXF7eNi5Fke98H8V94tr5Xs=; b=NNrBS1Y08oD01GNJ38TLTe0Yi44Lf7DQb2d+IxHoxg6xyQkapMJudViDBcyf7TdWfckamgLprLiBO0lT0mhmHqj6693twSIPAr9sX6qT7DrR26kdAt3B4jlXQf+izFNb3IpcoLPNRscvYqow3YveopwoMNsChSQNd9+Epew/P+Q= Received: from TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) by TY1PR01MB0588.jpnprd01.prod.outlook.com (10.167.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 9 Oct 2016 04:24:40 +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.0659.018; Sun, 9 Oct 2016 04:24:40 +0000 From: =?iso-2022-jp?B?GyRCQmc0ZDQyGyhC?= To: Kathleen Moriarty , "http-auth@ietf.org" Thread-Topic: [http-auth] AD review of draft-ietf-httpauth-mutual-08 Thread-Index: AQHR9D/IeFxKC981CECMq6g0jH5iNqCGTIqAgBmUpag= Date: Sun, 9 Oct 2016 04:24:40 +0000 Message-ID: References: , <57E3D237.50001@aist.go.jp> In-Reply-To: <57E3D237.50001@aist.go.jp> 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [25.167.153.132] x-ms-office365-filtering-correlation-id: 47fd09e5-8d11-47db-0d23-08d3effc2fef x-microsoft-exchange-diagnostics: 1; TY1PR01MB0588; 6:nOruGM2EnqUIEodX2QOfTIA8Yeo5FAkQzC9JmwDpWdXcZN2ivTWivWj0kQ0aogToUwEE4oZAds1XUJFVnE6FzcZNLI/yYadvXEZ2Gc52GN8PfF/L7RsnLxh2GgmGjg7aZ/khLQriQtrQLGeLG5ZsGGLafYGHjMlt5/qnJD9bedChKdAgsfAnM/b5oEk/LWFxdcFCYuM8ae99w/PkENpOS9Fq63HduvY+O6YtJ2iJa2yLiys3mK6Fa2hJ433d2WfJW06W4KxTYwmTagplXMiDyrGMz7LmUaWjLyrC0+SMgyO84hmPOFpoJBa6np4CKPVwQgTIV9TlLl9nni5zmWwSGn3x+of+zAhfEXb9jR9DaHQ=; 5:pqbAdLBEC/eWGjHPfqVBxyTrMnI8af2guIpQt60FFMLfHfYmsgD/d+5sjHHJc/FSk1PIf4+6ffGmdutsGrqRf735Tr/q9yRJlcEvDVAqh3BCKEyeWd62Ho59UEjnbyC4u8ABADKbaJM8ZG1+/AKMNQ==; 24:I52Yf6C4mgvTJ24e5Xr/kZjI7OAh+vLCTNP07ZtgrjV433xtr7dQ6JKdrCp9I6F+9KZxqnC7f/GGTm2w2p8GmfZFh/Jz/wuw0sKeeFlw+vI=; 7:1OZOCWcB7givirkTXLO0PXtsY+7tZvKzCoBDEemcyDpMRmzboDDeR7fPMzzRSJlKu+/ul1eoLmfvUx6cvqD/I+YqjFsnlm2rA1ffsprkp3fqx/oQoEoc+RRbsTzljwQTLpXHuG83qbzSejlwGGnT5+S133HKoO+ZvD+sQ/FjfZoJsrmf7BBFpYcWPSJCPqGuJvVaO59ckSwBM5VQnb3SzEOb71jHCg+hmvNfAo6VrskHJn++vhC/pkwAPIZw1j321KSt4t7ZSN1YTvoOcHFxrRK81tkfA3dwttlOm+5/MSubQKY2VCX64Hm4ssGJd1CN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0588; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:TY1PR01MB0588; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0588; x-forefront-prvs: 00909363D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(15594002)(199003)(45984002)(189002)(24454002)(551544002)(97736004)(5001770100001)(2906002)(33656002)(305945005)(7846002)(345774005)(7736002)(50986999)(106116001)(76176999)(5660300001)(54356999)(10400500002)(106356001)(105586002)(101416001)(7696004)(74316002)(2501003)(11100500001)(76576001)(66066001)(102836003)(3846002)(5002640100001)(68736007)(8936002)(87936001)(3660700001)(9686002)(42882006)(85182001)(92566002)(3280700002)(77096005)(19580395003)(586003)(6116002)(122556002)(107886002)(189998001)(230783001)(8676002)(2950100002)(2900100001)(86362001)(31430400001)(74482002)(81156014)(81166006)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0588; H:TY1PR01MB0588.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2016 04:24:40.2392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0588 Archived-At: Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 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: Sun, 09 Oct 2016 04:24:46 -0000 Dear Kathleen, I have not seen any response to the previous mail. If we have any problems to solve or actions to take, please let me know. Thanks, Yutaka ________________________________________ =1B$B:9=3DP?M=1B(B: Yutaka OIWA =1B$BAw?.F|;~=1B(B: 2016=1B$BG/=1B(B9=1B$B7n=1B(B22=1B$BF|=1B(B 21:44:39 =1B$B08@h=1B(B: Kathleen Moriarty; http-auth@ietf.org =1B$B7oL>=1B(B: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 Dear Kathleen, I'm sorry I've updated the draft according to your mail, but not responded to the mail itself. # and I found a few typo to submit the draft revision very soon. On 2016/08/12 11:18, Kathleen Moriarty wrote: > Hello, > > Thank you for your work on draft-ietf-httpauth-mutual-08. I will try > to get through my AD review of the accompanying draft tomorrow. > > I read through the draft and have the following questions. > > > ----- > Section 2.1, in the following text: > > o Authenticated key exchange messages: used by both peers to perform > authentication and the sharing of a cryptographic secret. > > * req-KEX-C1 message: a message sent from the client. > > * 401-KEX-S1 message: a message sent from the server in response > to a req-KEX-C1 message. > > 1. What does the response mean? Is there a pass/fail message in the > response or is this just an ack that the message was received by the > server to the client? 401-KEX-S1 will be almost unconditionally sent as a response, as authentication is on-going, not finished yet. There may be a "no-go" for fatal error case (e.g. parameter mismatch), howe= ver. > Then in the following: > * 200-VFY-S message: a client-authentication successful response > used by the server, which also simultaneously asserts to the > client that the server is authentic. > > 2. Maybe this will be clear as I read further through the draft, but > that seems like a lot to assert at once. This note is a placeholder > for me in case I do't feel like there is an adequate answer when I get > deeper into the draft. We tried to make it more clear in the revised draft. > Second bullet on page 7: > > o At this point (5), both peers calculate a shared "session secret" > using the exchanged values in the key exchange messages. Only > when both the server and the client have used secret credentials > generated from the same password will the session secret values > match. This session secret will be used for access authentication > of every individual normal after this point. > > 3. I think a word may be missing in the last sentence, can you > rephrase it? I'm not able to parse it. This seems to be typo, and we fixed. > ----- > In another bullet on page 7: > > o If the authentication verification value from the client was > correct, it means that the client definitely owns the credential > based on the expected password (i.e., the client authentication > succeeded). The server will respond with a successful message > (200-VFY-S) (7). Contrary to the usual one-way authentication > (e.g., HTTP Basic authentication or POP APOP authentication > [RFC1939]), this message also contains a server-side > authentication verification value. > > When the client's verification value is incorrect (e.g., because > the user-supplied password was incorrect), the server will respond > with the 401-INIT message (the same one as used in (2)) instead. > > 4. This last section should specify that the extensive-token > indicating an authentication failure must be included. I would also > recommend that this information be logged and have that stated in this > draft. Since we are pushing for protocols to be encrypted, the use of > sniffers to detect errors will continue to fall off and people will > need to rely on logs more. I think it would be more helpful to have > an accurate log that responds saying the authentication failed > (user/password if you don't want to say which). Encouraging richer > logs will be more helpful going forward. > ----- Thank you very much for the suggestion. We incorporated the idea. > In Section 7, just to make sure I am reading this correctly: > > The valid tokens for the validation parameter and corresponding > values of vh are as follows: > > host: host-name validation: The value vh will be the ASCII > string in the following format: > "://:", where , , > and are the URI components corresponding to the > currently accessing resource. > > 5. By "currently accessing resource", you mean the source system, > correct? It might be better to rephrase that so it is clear since > this is important to developers. > ----- We rephrased it as "server-side resource". It's actually "the URL" being accessed, in short and informally. If there is better phrasing, we'll look for it further. > 6. In Section 8, it is the reason parameter of the INIT that lets you > know if t is 'valid', correct? > Authentication-initializing messages with the > Optional-WWW-Authenticate header are used only where the 401-INIT > response is valid. It will not replace other 401-type messages such > as 401-STALE and 401-KEX-S1. > > I think it would be helpful to explicitly state what is a valid > response unless that is defined already and I missed it? I think it > depends on the token or extensive token set in the reason parameter of > the INIT message. We clarified that the reason will be "initial" (modulo future extensions). > ---- > 7. In section 10.1, if you change "normal responses" to "normal > response", it is easier to fix the grammar in the following sentences: > > This also > holds true for the reception of "normal responses" (responses which > do not contain Mutual authentication-related headers) from HTTP > servers. > change to: > This also > holds true for the reception of a "normal response" (responses which > do not contain Mutual authentication-related headers) from HTTP > servers. > > from: > Any kinds of "normal responses" MUST only be accepted for the very > first request in the sequence. Any "normal responses" returned > for the second or later requests in the sequence SHALL be > considered invalid. > change to: > Any kind of "normal response" MUST only be accepted for the very > first request in the sequence. Any "normal response" returned > for the second or later request in the sequence SHALL be > considered invalid. > 8. Section 10.1, please consider rewording the following sentences to > make it easier to read: > o In the same principle, any responses which refer to or request > changing to an authentication realm different from the client's > request MUST only be accepted for the very first request in the > sequence. Any kind of responses referring to different realms > which are returned for the second or later requests in the > sequence SHALL be considered invalid. > ----- > 9. In section 17.2, it might be helpful to include a reference to the > TLS 1.2 BCP, RFC7525. The bullet might say something like, when TLS > 1.2 is used, follow best practices in RFC7525. > ----- For 7-9: Thank you very much. We did. > 10. Section 17.3 is the first place I see a clear motivation for this > protocol. It might help to have this stated in the introduction. > Although the points about password attacks in section 17.2 leave me > questioning how much of an improvement this really is. How much > analysis was done on this new method? I know the drafts have been > around for a while. I'd have to take another pass at the documents to > dig deeper, but would like to know if this analysis was done. Can you > make the statement that this is more secure? The motivation for HOBA > was clear - getting rid of the use of passwords. > > Passwords are not sent in the clear, but this isn't stated in a > motivation section. It just is part of the protocol and mentioned at > the end of section 17.5. It might be helpful to include this in the > introduction as well in a motivation paragraph. The abstract saying > that, "server truly knows the user's > encrypted password" isn't the same as saying that the password is > encrypted on the wire and doesn't rely on transport encryption. Thank you very much for the precious suggestion. I added some texts to the introduction section. For security, simply said, no off-line attack will ever be possible using data retrieved from eavesdropped/man-in-the-middle traffics. We discussed some detail on on-line attacks in this section, but it's much harder than off-line attacks for attackers, and much easier for servers to detect and perform countermeasures. (Of course, it's a gift from the PAKE.) > ----- > 11. Section 17.3. I'm not clear on this sentence in the last paragraph: > Of course, in such cases, the user interfaces for asking passwords > for this authentication shall be clearly identifiable against > imitation by other insecure password input fields (such as forms). > Common attacks of this nature would be to direct users to a form that > isn't the real form. Is it the mutual authentication that helps here? > If so, explain how. How is it clearly identifiable against > imitation? What we considered and implemented is a authentication interface in browser-chrome (around the address bar), not within the main content are= a. It's common for browsers to have some "secure UI area" not possible to circumvent from the web content itself, whose examples includes address bar= , and padlock icons, as well as the "the other area" controlled by the web page contents. We intended to use the former area for secure authentic= ation. However, we did not want to include any "instructions" on the user interfac= es of web browsers (fearing that it will become "out-of-scope" of the draft), = so we used some "abstract" requirement here. If you have more suggestion on "the extent we should say for user interface= s", it's really appreciated. -- Yutaka OIWA, Ph.D. Leader, Cyber Physical Architecture Research Grou= p Information Technology Research Institut= e 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 Oct 11 09:12:48 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 830D7129496 for ; Tue, 11 Oct 2016 09:12:45 -0700 (PDT) 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, HTML_MESSAGE=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 AGFE30paM150 for ; Tue, 11 Oct 2016 09:12:41 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 777971293E0 for ; Tue, 11 Oct 2016 09:12:41 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 192so24266578vkl.2 for ; Tue, 11 Oct 2016 09:12:41 -0700 (PDT) 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=MFtJ7aqCrnJm+renJKTMHdjcza9QKzew5cax5s+Sn+4=; b=BMw2OOzNr0dE6CbCTX8vsZlCYWqtxIKEcp0m3ZdbuVy7CM2yyCqSLssqavzwQVLkzC eOl+b2dzyQMMHnN+gveN9ehRoMsUcSwNGGrnjo0PaU4lqgZuaLhbfc5N+eUCrbAPzeeo YqtHdv3fhYHdN4bCVfEnKPrcVZdPPNIATlR6BMeOHIIQAo5IqWEenCvK9ImV2yx2ETlS VFDQNuS6AmWx07/XASXU9X3MXEZ5Om6DMIn5oKg53SwcsQWmLO0FI/WRHzqNb97kglhG oK6oHc+TyWzAZgHMx380LMOU7i4SGBluxGMUl93MXadls9DHViEIZetEhP2aq2S0VNA8 UrTQ== 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=MFtJ7aqCrnJm+renJKTMHdjcza9QKzew5cax5s+Sn+4=; b=j15vb+tS5NwHFzMQO5vzmJvykTthS3cjt2A25e2F3/zAm2OopwZ4vnjQ1a/gaI1ZQL MMuMsEoLiuRkO5zsHdkr550twXMn6TjugTn2bBrKnL+IBhEeoI4V38m8tppmEHdAga3F HFiDhaOTxSk2VQIAPmZ+ONYlYixwm9ffq1rPNxsrcXdIG4O4iTmbw8zq+ehRp7PBDYOS nhp4EW26cZB/Qm728KabE73uw9Pz+as/tyWbJzgaIpJiNA/OyJ1m/huqBHnHZBmsIKMo /Ix6VsP3/uqTu0gBdjtQuCuv3KFORq7X/m7vg575FGR6YEV8tkDGO/tWyLfQ51ibe6p9 SETQ== X-Gm-Message-State: AA6/9RnlG/anjA7x+hJRvmH9Mcx3jQk2E1TrDIo1153ApkuOLKO2QaWCpN41LJr6GioT4wdbrutnD9NxTvm+3A== X-Received: by 10.31.69.16 with SMTP id s16mr3961347vka.115.1476202360450; Tue, 11 Oct 2016 09:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Tue, 11 Oct 2016 09:12:39 -0700 (PDT) In-Reply-To: References: <57E3D237.50001@aist.go.jp> From: Kathleen Moriarty Date: Tue, 11 Oct 2016 12:12:39 -0400 Message-ID: To: =?UTF-8?B?5aSn5bKp5a+b?= Content-Type: multipart/alternative; boundary=001a114db3ce4fb1d8053e992578 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 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, 11 Oct 2016 16:12:45 -0000 --001a114db3ce4fb1d8053e992578 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Yutaka, I am sorry for my delay in response. The updates look very good and I think the updated introduction is helpful. I will progress the draft into IETF last call, but an edit pass on the new text is required as there are some grammar issues. Also, you had responded saying you would add something about logging and I am not able to find that text in the diffs from -08. Was it added? Thank you, Kathleen On Sun, Oct 9, 2016 at 12:24 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B wrote: > Dear Kathleen, > > I have not seen any response to the previous mail. > If we have any problems to solve or actions to take, > please let me know. > > Thanks, > > Yutaka > ________________________________________ > =E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5 = 21:44:39 > =E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org > =E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of draft-ietf-httpauth-mutu= al-08 > > Dear Kathleen, > > I'm sorry I've updated the draft according to your mail, > but not responded to the mail itself. > # and I found a few typo to submit the draft revision very soon. > > On 2016/08/12 11:18, Kathleen Moriarty wrote: > > Hello, > > > > Thank you for your work on draft-ietf-httpauth-mutual-08. I will try > > to get through my AD review of the accompanying draft tomorrow. > > > > I read through the draft and have the following questions. > > > > > > ----- > > Section 2.1, in the following text: > > > > o Authenticated key exchange messages: used by both peers to perform > > authentication and the sharing of a cryptographic secret. > > > > * req-KEX-C1 message: a message sent from the client. > > > > * 401-KEX-S1 message: a message sent from the server in response > > to a req-KEX-C1 message. > > > > 1. What does the response mean? Is there a pass/fail message in the > > response or is this just an ack that the message was received by the > > server to the client? > > 401-KEX-S1 will be almost unconditionally sent as a response, > as authentication is on-going, not finished yet. > There may be a "no-go" for fatal error case (e.g. parameter mismatch), > however. > > > Then in the following: > > * 200-VFY-S message: a client-authentication successful response > > used by the server, which also simultaneously asserts to the > > client that the server is authentic. > > > > 2. Maybe this will be clear as I read further through the draft, but > > that seems like a lot to assert at once. This note is a placeholder > > for me in case I do't feel like there is an adequate answer when I get > > deeper into the draft. > > We tried to make it more clear in the revised draft. > > > Second bullet on page 7: > > > > o At this point (5), both peers calculate a shared "session secret" > > using the exchanged values in the key exchange messages. Only > > when both the server and the client have used secret credentials > > generated from the same password will the session secret values > > match. This session secret will be used for access authenticatio= n > > of every individual normal after this point. > > > > 3. I think a word may be missing in the last sentence, can you > > rephrase it? I'm not able to parse it. > > This seems to be typo, and we fixed. > > > ----- > > In another bullet on page 7: > > > > o If the authentication verification value from the client was > > correct, it means that the client definitely owns the credential > > based on the expected password (i.e., the client authentication > > succeeded). The server will respond with a successful message > > (200-VFY-S) (7). Contrary to the usual one-way authentication > > (e.g., HTTP Basic authentication or POP APOP authentication > > [RFC1939]), this message also contains a server-side > > authentication verification value. > > > > When the client's verification value is incorrect (e.g., because > > the user-supplied password was incorrect), the server will respon= d > > with the 401-INIT message (the same one as used in (2)) instead. > > > > 4. This last section should specify that the extensive-token > > indicating an authentication failure must be included. I would also > > recommend that this information be logged and have that stated in this > > draft. Since we are pushing for protocols to be encrypted, the use of > > sniffers to detect errors will continue to fall off and people will > > need to rely on logs more. I think it would be more helpful to have > > an accurate log that responds saying the authentication failed > > (user/password if you don't want to say which). Encouraging richer > > logs will be more helpful going forward. > > ----- > > Thank you very much for the suggestion. We incorporated the idea. > > > In Section 7, just to make sure I am reading this correctly: > > > > The valid tokens for the validation parameter and corresponding > > values of vh are as follows: > > > > host: host-name validation: The value vh will be the ASCII > > string in the following format: > > "://:", where , , > > and are the URI components corresponding to th= e > > currently accessing resource. > > > > 5. By "currently accessing resource", you mean the source system, > > correct? It might be better to rephrase that so it is clear since > > this is important to developers. > > ----- > > We rephrased it as "server-side resource". > It's actually "the URL" being accessed, in short and informally. > If there is better phrasing, we'll look for it further. > > > > 6. In Section 8, it is the reason parameter of the INIT that lets you > > know if t is 'valid', correct? > > Authentication-initializing messages with the > > Optional-WWW-Authenticate header are used only where the 401-INIT > > response is valid. It will not replace other 401-type messages such > > as 401-STALE and 401-KEX-S1. > > > > I think it would be helpful to explicitly state what is a valid > > response unless that is defined already and I missed it? I think it > > depends on the token or extensive token set in the reason parameter of > > the INIT message. > > We clarified that the reason will be "initial" (modulo future extensions)= . > > > ---- > > 7. In section 10.1, if you change "normal responses" to "normal > > response", it is easier to fix the grammar in the following sentences: > > > > This also > > holds true for the reception of "normal responses" (responses which > > do not contain Mutual authentication-related headers) from HTTP > > servers. > > change to: > > This also > > holds true for the reception of a "normal response" (responses which > > do not contain Mutual authentication-related headers) from HTTP > > servers. > > > > from: > > Any kinds of "normal responses" MUST only be accepted for the ver= y > > first request in the sequence. Any "normal responses" returned > > for the second or later requests in the sequence SHALL be > > considered invalid. > > change to: > > Any kind of "normal response" MUST only be accepted for the very > > first request in the sequence. Any "normal response" returned > > for the second or later request in the sequence SHALL be > > considered invalid. > > > 8. Section 10.1, please consider rewording the following sentences to > > make it easier to read: > > o In the same principle, any responses which refer to or request > > changing to an authentication realm different from the client's > > request MUST only be accepted for the very first request in the > > sequence. Any kind of responses referring to different realms > > which are returned for the second or later requests in the > > sequence SHALL be considered invalid. > > ----- > > 9. In section 17.2, it might be helpful to include a reference to the > > TLS 1.2 BCP, RFC7525. The bullet might say something like, when TLS > > 1.2 is used, follow best practices in RFC7525. > > ----- > > For 7-9: Thank you very much. We did. > > > 10. Section 17.3 is the first place I see a clear motivation for this > > protocol. It might help to have this stated in the introduction. > > Although the points about password attacks in section 17.2 leave me > > questioning how much of an improvement this really is. How much > > analysis was done on this new method? I know the drafts have been > > around for a while. I'd have to take another pass at the documents to > > dig deeper, but would like to know if this analysis was done. Can you > > make the statement that this is more secure? The motivation for HOBA > > was clear - getting rid of the use of passwords. > > > > Passwords are not sent in the clear, but this isn't stated in a > > motivation section. It just is part of the protocol and mentioned at > > the end of section 17.5. It might be helpful to include this in the > > introduction as well in a motivation paragraph. The abstract saying > > that, "server truly knows the user's > > encrypted password" isn't the same as saying that the password is > > encrypted on the wire and doesn't rely on transport encryption. > > Thank you very much for the precious suggestion. I added some texts > to the introduction section. > For security, simply said, no off-line attack will ever be possible > using data retrieved from eavesdropped/man-in-the-middle traffics. > We discussed some detail on on-line attacks in this section, > but it's much harder than off-line attacks for attackers, > and much easier for servers to detect and perform countermeasures. > (Of course, it's a gift from the PAKE.) > > > ----- > > 11. Section 17.3. I'm not clear on this sentence in the last paragraph= : > > Of course, in such cases, the user interfaces for asking passwords > > for this authentication shall be clearly identifiable against > > imitation by other insecure password input fields (such as forms). > > Common attacks of this nature would be to direct users to a form that > > isn't the real form. Is it the mutual authentication that helps here? > > If so, explain how. How is it clearly identifiable against > > imitation? > > What we considered and implemented is a authentication interface > in browser-chrome (around the address bar), not within the main content > area. > It's common for browsers to have some "secure UI area" not possible to > circumvent from the web content itself, whose examples includes address > bar, > and padlock icons, as well as the "the other area" controlled by the > web page contents. We intended to use the former area for secure > authentication. > However, we did not want to include any "instructions" on the user > interfaces > of web browsers (fearing that it will become "out-of-scope" of the draft)= , > so > we used some "abstract" requirement here. > If you have more suggestion on "the extent we should say for user > interfaces", > it's really appreciated. > > -- > 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: , < > yutaka@oiwa.jp> > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] > --=20 Best regards, Kathleen --001a114db3ce4fb1d8053e992578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Yutaka,

I am sorry for my delay in= response.=C2=A0 The updates look very good and I think the updated introdu= ction is helpful.=C2=A0 I will progress the draft into IETF last call, but = an edit pass on the new text is required as there are some grammar issues.<= /div>

Also, you had responded saying you would add somet= hing about logging and I am not able to find that text in the diffs from -0= 8.=C2=A0 Was it added?

Thank you,
Kathle= en

On = Sun, Oct 9, 2016 at 12:24 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B <y.oiwa@aist.go.= jp> wrote:
Dear Kathleen,
I have not seen any response to the previous mail.
If we have any problems to solve or actions to take,
please let me know.

Thanks,

Yutaka
________________________________________
=E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA <y.oiwa@aist.go.jp>
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5 21= :44:39
=E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org
=E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of draft-ietf-httpauth-mutual= -08

Dear Kathleen,

I'm sorry I've updated the draft according to your mail,
but not responded to the mail itself.
# and I found a few typo to submit the draft revision very soon.

On 2016/08/12 11:18, Kathleen Moriarty wrote:
> Hello,
>
> Thank you for your work on draft-ietf-httpauth-mutual-08.=C2=A0 I will= try
> to get through my AD review of the accompanying draft tomorrow.
>
> I read through the draft and have the following questions.
>
>
> -----
> Section 2.1, in the following text:
>
>=C2=A0 o=C2=A0 Authenticated key exchange messages: used by both peers = to perform
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication and the sharing of a cryptogr= aphic secret.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 req-KEX-C1 message: a message sent f= rom the client.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 401-KEX-S1 message: a message sent f= rom the server in response
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to a req-KEX-C1 message.
>
> 1. What does the response mean?=C2=A0 Is there a pass/fail message in = the
> response or is this just an ack that the message was received by the > server to the client?

401-KEX-S1 will be almost unconditionally sent as a response,
as authentication is on-going, not finished yet.
There may be a "no-go" for fatal error case (e.g. parameter misma= tch), however.

> Then in the following:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 200-VFY-S message: a client-authenti= cation successful response
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used by the server, which also simul= taneously asserts to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client that the server is authentic.=
>
> 2. Maybe this will be clear as I read further through the draft, but > that seems like a lot to assert at once.=C2=A0 This note is a placehol= der
> for me in case I do't feel like there is an adequate answer when I= get
> deeper into the draft.

We tried to make it more clear in the revised draft.

> Second bullet on page 7:
>
>=C2=A0 o=C2=A0 At this point (5), both peers calculate a shared "s= ession secret"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the exchanged values in the key exchan= ge messages.=C2=A0 Only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when both the server and the client have use= d secret credentials
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated from the same password will the se= ssion secret values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0match.=C2=A0 This session secret will be use= d for access authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of every individual normal after this point.=
>
> 3. I think a word may be missing in the last sentence, can you
> rephrase it?=C2=A0 I'm not able to parse it.

This seems to be typo, and we fixed.

> -----
> In another bullet on page 7:
>
>=C2=A0 o=C2=A0 If the authentication verification value from the client= was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct, it means that the client definitely= owns the credential
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the expected password (i.e., the cl= ient authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded).=C2=A0 The server will respond wi= th a successful message
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(200-VFY-S) (7).=C2=A0 Contrary to the usual= one-way authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., HTTP Basic authentication or POP APOP= authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC1939]), this message also contains a ser= ver-side
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication verification value.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When the client's verification value is = incorrect (e.g., because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the user-supplied password was incorrect), t= he server will respond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the 401-INIT message (the same one as u= sed in (2)) instead.
>
> 4. This last section should specify that the extensive-token
> indicating an authentication failure must be included.=C2=A0 I would a= lso
> recommend that this information be logged and have that stated in this=
> draft.=C2=A0 Since we are pushing for protocols to be encrypted, the u= se of
> sniffers to detect errors will continue to fall off and people will > need to rely on logs more.=C2=A0 I think it would be more helpful to h= ave
> an accurate log that responds saying the authentication failed
> (user/password if you don't want to say which).=C2=A0 Encouraging = richer
> logs will be more helpful going forward.
> -----

Thank you very much for the suggestion. We incorporated the idea.

> In Section 7, just to make sure I am reading this correctly:
>
> The valid tokens for the validation parameter and corresponding
>=C2=A0 =C2=A0 values of vh are as follows:
>
>=C2=A0 =C2=A0 host:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 host-name validat= ion: The value vh will be the ASCII
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st= ring in the following format:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;<scheme>://<host>:<port>", where <scheme>,= <host>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an= d <port> are the URI components corresponding to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cu= rrently accessing resource.
>
> 5. By "currently accessing resource", you mean the source sy= stem,
> correct?=C2=A0 It might be better to rephrase that so it is clear sinc= e
> this is important to developers.
> -----

We rephrased it as "server-side resource".
It's actually "the URL" being accessed, in short and informal= ly.
If there is better phrasing, we'll look for it further.


> 6. In Section 8, it is the reason parameter of the INIT that lets you<= br> > know if t is 'valid', correct?
>=C2=A0 =C2=A0 Authentication-initializing messages with the
>=C2=A0 =C2=A0 Optional-WWW-Authenticate header are used only where the = 401-INIT
>=C2=A0 =C2=A0 response is valid.=C2=A0 It will not replace other 401-ty= pe messages such
>=C2=A0 =C2=A0 as 401-STALE and 401-KEX-S1.
>
> I think it would be helpful to explicitly state what is a valid
> response unless that is defined already and I missed it?=C2=A0 I think= it
> depends on the token or extensive token set in the reason parameter of=
> the INIT message.

We clarified that the reason will be "initial" (modulo future ext= ensions).

> ----
> 7. In section 10.1, if you change "normal responses" to &quo= t;normal
> response", it is easier to fix the grammar in the following sente= nces:
>
>=C2=A0 =C2=A0 This also
>=C2=A0 =C2=A0 holds true for the reception of "normal responses&qu= ot; (responses which
>=C2=A0 =C2=A0 do not contain Mutual authentication-related headers) fro= m HTTP
>=C2=A0 =C2=A0 servers.
> change to:
>=C2=A0 =C2=A0 This also
>=C2=A0 =C2=A0 holds true for the reception of a "normal response&q= uot; (responses which
>=C2=A0 =C2=A0 do not contain Mutual authentication-related headers) fro= m HTTP
>=C2=A0 =C2=A0 servers.
>
> from:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Any kinds of "normal responses" MU= ST only be accepted for the very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0first request in the sequence.=C2=A0 Any &qu= ot;normal responses" returned
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the second or later requests in the sequ= ence SHALL be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considered invalid.
> change to:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Any kind of "normal response" MUST= only be accepted for the very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0first request in the sequence.=C2=A0 Any &qu= ot;normal response" returned
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the second or later request in the seque= nce SHALL be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considered invalid.

> 8. Section 10.1, please consider rewording the following sentences to<= br> > make it easier to read:
>=C2=A0 =C2=A0 o=C2=A0 In the same principle, any responses which refer = to or request
>=C2=A0 =C2=A0 =C2=A0 =C2=A0changing to an authentication realm differen= t from the client's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0request MUST only be accepted for the very f= irst request in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence.=C2=A0 Any kind of responses referr= ing to different realms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0which are returned for the second or later r= equests in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence SHALL be considered invalid.
> -----
> 9. In section 17.2, it might be helpful to include a reference to the<= br> > TLS 1.2 BCP, RFC7525.=C2=A0 The bullet might say something like, when = TLS
> 1.2 is used, follow best practices in RFC7525.
> -----

For 7-9: Thank you very much. We did.

> 10. Section 17.3 is the first place I see a clear motivation for this<= br> > protocol.=C2=A0 It might help to have this stated in the introduction.=
> Although the points about password attacks in section 17.2 leave me > questioning how much of an improvement this really is.=C2=A0 How much<= br> > analysis was done on this new method? I know the drafts have been
> around for a while.=C2=A0 I'd have to take another pass at the doc= uments to
> dig deeper, but would like to know if this analysis was done.=C2=A0 Ca= n you
> make the statement that this is more secure?=C2=A0 The motivation for = HOBA
> was clear - getting rid of the use of passwords.
>
> Passwords are not sent in the clear, but this isn't stated in a > motivation section.=C2=A0 It just is part of the protocol and mentione= d at
> the end of section 17.5.=C2=A0 It might be helpful to include this in = the
> introduction as well in a motivation paragraph.=C2=A0 The abstract say= ing
> that, "server truly knows the user's
> encrypted password" isn't the same as saying that the passwor= d is
> encrypted on the wire and doesn't rely on transport encryption.
Thank you very much for the precious suggestion. I added some texts
to the introduction section.
For security, simply said, no off-line attack will ever be possible
using data retrieved from eavesdropped/man-in-the-middle traffics.
We discussed some detail on on-line attacks in this section,
but it's much harder than off-line attacks for attackers,
and much easier for servers to detect and perform countermeasures.
(Of course, it's a gift from the PAKE.)

> -----
> 11. Section 17.3.=C2=A0 I'm not clear on this sentence in the last= paragraph:
>=C2=A0 =C2=A0 Of course, in such cases, the user interfaces for asking = passwords
>=C2=A0 =C2=A0 for this authentication shall be clearly identifiable aga= inst
>=C2=A0 =C2=A0 imitation by other insecure password input fields (such a= s forms).
> Common attacks of this nature would be to direct users to a form that<= br> > isn't the real form.=C2=A0 Is it the mutual authentication that he= lps here?
>=C2=A0 If so, explain how.=C2=A0 How is it clearly identifiable against=
> imitation?

What we considered and implemented is a authentication interface
in browser-chrome (around the address bar), not within the main content are= a.
It's common for browsers to have some "secure UI area" not po= ssible to
circumvent from the web content itself, whose examples includes address bar= ,
and padlock icons, as well as the "the other area" controlled by = the
web page contents.=C2=A0 We intended to use the former area for secure auth= entication.
However, we did not want to include any "instructions" on the use= r interfaces
of web browsers (fearing that it will become "out-of-scope" of th= e draft), so
we used some "abstract" requirement here.
If you have more suggestion on "the extent we should say for user inte= rfaces",
it's really appreciated.

--
Yutaka OIWA, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leader, Cyber Physical Archit= ecture Research Group
=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=A0Information Technology = Research Institute
=C2=A0 =C2=A0 =C2=A0National Institute of Advanced Industrial Science and T= echnology (AIST)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Mail addresses: <y.oiwa@a= ist.go.jp>, <yutaka@oiwa.jp= >
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D=C2=A0 3139 8677 9BD2 4405= 46B5]



--
=

Best regards,
Kathleen
--001a114db3ce4fb1d8053e992578-- From nobody Tue Oct 11 11:30: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 2D0F4129578; Tue, 11 Oct 2016 11:30:31 -0700 (PDT) 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.34.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147621063114.31943.7035939537400954261.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 11:30:31 -0700 Archived-At: Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org Subject: [http-auth] Last Call: (Mutual Authentication Protocol for HTTP) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:30:31 -0000 The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'Mutual Authentication Protocol for HTTP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/906/ https://datatracker.ietf.org/ipr/2220/ From nobody Tue Oct 11 11:31:06 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 0E23A129670; Tue, 11 Oct 2016 11:31:04 -0700 (PDT) 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.34.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147621066404.31924.12012633104493150512.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 11:31:04 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org Subject: [http-auth] Last Call: (Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:31:04 -0000 The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 19 00:22:21 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 A17EE129450 for ; Wed, 19 Oct 2016 00:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 kHvYxs_n3ssa for ; Wed, 19 Oct 2016 00:22:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 947CA1293D9 for ; Wed, 19 Oct 2016 00:22:17 -0700 (PDT) Received: from [192.168.178.20] ([93.217.104.58]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MILxX-1bx1Fh22P9-004FkW for ; Wed, 19 Oct 2016 09:22:14 +0200 References: To: "http-auth@ietf.org" From: Julian Reschke X-Forwarded-Message-Id: Message-ID: Date: Wed, 19 Oct 2016 09:22:14 +0200 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LVWrxXBgztd5hkN1h4wTL2McevE/im9BEM1gmqGPBOl/vT6UetN +KijjdSmgXF6YDUFnppB1ieJTiJFjsX37sOFZKpxVMQf/jrpvgHlsumUMqhRCAHPrMYiygQ ZTXMnBVZZHgG5/c3iC8R0jjQork+In3aBPuMB5SznPoVWxiuNPj6CisjGgqTxR9kGptxwOd L78H7vFXrBHUY1ttX1DCA== X-UI-Out-Filterresults: notjunk:1;V01:K0:e7Y4TRY/QqA=:xVW56haL9UeQrc/a/0IoXb PxdmS2xHhuZJ0ZKih0YFZV2Z2deLpEnH+I9BoieiD5aGPKPfCo3UYM7UInY36YjsjT7KXQGNy Bf0v9AXREkRGE3r2DIWJyj4X/PGLgx2AUp1aGQRQMTf0AoNWH7e57bUG1FapCNo8032t/07QA dFztCAYgcFDXvSckVkz1R8hp7gST+XLpt/0hzptN6p4BtCIRpICth59nskB86n3Sd6263nG1A /2vEZDcfuply8/2w1uhOt48sz3QglIoMYN1k3kZpdIwQVhaKOS7tZulA7LHkQLGEoGA7WHXiI eoVBl1y4mxNi4nyD7C4GxoJjwe1tIN7XbDhxoAKrkABkJIUE8O1OSXXNrlVbgI0FgbIhNoXVC lxY8aDoFj3T+PloQkAfgn7EnVzwtkm0DoXB8Clyi3G+cy5bzCVhZQebfb34aS0ARSd6xJDUiJ y2oKj6fOM3bGG7vxsxwUS7q48IXnu88o4Jknfw85Sv6UlrBSVaOgjysLA2nn4Fn02yN4tguIu KL5tRo0XL/KY187yrnkfP9FguioIJUm9VsVU/5PJYQYvWkVrvWW7b7NIl7EB5LMfZtDvftqei pN4LLswIFb42JG2C28XK1yestttVDVrb2B53TJrE1PAinBq3q2aKJ+TgZrzPmMHBM8xnI+B9X ow83YpIHMYBkgupqIoA9naIVyucIbruJqTlysMhwaFm1F9ujdHr4lstuxaKrGCi/RJuNGNw+j 1FVjeD7YYM9s/mi1o0nOaB5C5F0HDflGRgfZabY9jjl5MI39gXfWST5cW/Vd7y9SG7pweRkt8 r6dIYks Archived-At: Subject: [http-auth] Fwd: Working Group Last Call: RFC5987bis 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, 19 Oct 2016 07:22:19 -0000 (FYI) ...in particular, it would be good to check whether the currently submitted drafts of this WG are compatible with the changes in this spec (no, I'm not asking for a change, just a sanity check) Best regards, Julian -------- Forwarded Message -------- Subject: Working Group Last Call: RFC5987bis Resent-Date: Thu, 13 Oct 2016 12:16:50 +0000 Resent-From: ietf-http-wg@w3.org Date: Thu, 13 Oct 2016 23:15:13 +1100 From: Mark Nottingham To: HTTP working group mailing list CC: Patrick McManus We don't have any open issues, and Julian has indicated that he believes this document is ready for WGLC. Please have a look at: https://www.ietf.org/id/draft-ietf-httpbis-rfc5987bis-03.txt and direct any feedback to this mailing list and/or the issues list. WGLC will end on 2016-10-27. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 27 15:07:32 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 4305012944D for ; Thu, 27 Oct 2016 15:07:30 -0700 (PDT) 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 m6WYJtmxdiiM for ; Thu, 27 Oct 2016 15:07:27 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 9648112955B for ; Thu, 27 Oct 2016 15:07:27 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 64so34500357uap.3 for ; Thu, 27 Oct 2016 15:07:27 -0700 (PDT) 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=0a3MBHjBt+bOQAWmEqHYcSvq0YecUbo1cY2Mj9/yqBE=; b=Guh84rdd4pZeYAbznPHHNvENOxikkn9st1CFchfZYs+s7U2FpPzLv7SnDN2nTOvipT 0tqTyjf4V18rQlGmQHkmJxULsM8hD4+62q/VVFms/PqiU4eKWQS8r/Mj2WVDku+iw4Kt AJvEO+EEPSGgOUgIWOAxktJg7pMTPMFnrfbMIkBSwDhZ9MHhAsQ151+ee3NFSyuoG2F8 eGgwcOv8TonHAy8E2nSHa/du1qrQLoARJ7ReS4o4lxFnVm7fkwRB09enmjAC2sJahvnR eCPbLuOjCDtxcr32lu8+l5TJgxBAiA52IYFvhyzKSbaSRxv6nRcr8XeUYeUUJkA3O4hn auUA== 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=0a3MBHjBt+bOQAWmEqHYcSvq0YecUbo1cY2Mj9/yqBE=; b=IF90aiHpElwbNE9pnLcnN1uItjUO1G477RUYwe1WjNu18G2PQ4xxJO75sTn5FjDHp8 7erYLEBFUXydOpdNRTOG7wTRjs8Iwnns0kOIPN0XopHAzE7ChnP+nOXKodQmNKmV9bvF y5BGfoofM3L61rcuob4dIwBXhtOCuf9jshUDYZySmu+TV1CZCPBnMHgZilt6Ktq3mSwI Hjrx6ezIoGl6rAgzVbusK/MebZYfu/ZklfXgQvA6GXL4s8Hv1fmnudS70w/SV54IxR9P x6njBniNBKMZHxVBg7mAtZLGurBIwdIkNftPrJOucEwA6YizDNwrOwnqjKVokwYc0OXL HEhA== X-Gm-Message-State: ABUngvfIzA6nV9pPQ8O4ou6vScvHQIp7cdLvGHDYg/fxppz9PfdICO1reRxGufRY2++vhE8cRb31iEJbYOQBag== X-Received: by 10.176.4.196 with SMTP id 62mr9458842uaw.3.1477606046596; Thu, 27 Oct 2016 15:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Thu, 27 Oct 2016 15:07:25 -0700 (PDT) In-Reply-To: References: <57E3D237.50001@aist.go.jp> From: Kathleen Moriarty Date: Thu, 27 Oct 2016 18:07:25 -0400 Message-ID: To: =?UTF-8?B?5aSn5bKp5a+b?= Content-Type: multipart/alternative; boundary=94eb2c1255f08684b7053fdff76b Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 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, 27 Oct 2016 22:07:30 -0000 --94eb2c1255f08684b7053fdff76b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Just a quick question as I fill out the ballot text for next week's telechat. For the IANA section, as I read it both registries require expert review and a specification, is that right? I'm asking as the language could be clearer and I need to make sure it is clear in the ballot= . Thank you, Kathleen On Tue, Oct 11, 2016 at 12:12 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Dear Yutaka, > > I am sorry for my delay in response. The updates look very good and I > think the updated introduction is helpful. I will progress the draft int= o > IETF last call, but an edit pass on the new text is required as there are > some grammar issues. > > Also, you had responded saying you would add something about logging and = I > am not able to find that text in the diffs from -08. Was it added? > > Thank you, > Kathleen > > On Sun, Oct 9, 2016 at 12:24 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B wrote: > >> Dear Kathleen, >> >> I have not seen any response to the previous mail. >> If we have any problems to solve or actions to take, >> please let me know. >> >> Thanks, >> >> Yutaka >> ________________________________________ >> =E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA >> =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5= 21:44:39 >> =E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org >> =E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of draft-ietf-httpauth-mut= ual-08 >> >> Dear Kathleen, >> >> I'm sorry I've updated the draft according to your mail, >> but not responded to the mail itself. >> # and I found a few typo to submit the draft revision very soon. >> >> On 2016/08/12 11:18, Kathleen Moriarty wrote: >> > Hello, >> > >> > Thank you for your work on draft-ietf-httpauth-mutual-08. I will try >> > to get through my AD review of the accompanying draft tomorrow. >> > >> > I read through the draft and have the following questions. >> > >> > >> > ----- >> > Section 2.1, in the following text: >> > >> > o Authenticated key exchange messages: used by both peers to perform >> > authentication and the sharing of a cryptographic secret. >> > >> > * req-KEX-C1 message: a message sent from the client. >> > >> > * 401-KEX-S1 message: a message sent from the server in respons= e >> > to a req-KEX-C1 message. >> > >> > 1. What does the response mean? Is there a pass/fail message in the >> > response or is this just an ack that the message was received by the >> > server to the client? >> >> 401-KEX-S1 will be almost unconditionally sent as a response, >> as authentication is on-going, not finished yet. >> There may be a "no-go" for fatal error case (e.g. parameter mismatch), >> however. >> >> > Then in the following: >> > * 200-VFY-S message: a client-authentication successful respons= e >> > used by the server, which also simultaneously asserts to the >> > client that the server is authentic. >> > >> > 2. Maybe this will be clear as I read further through the draft, but >> > that seems like a lot to assert at once. This note is a placeholder >> > for me in case I do't feel like there is an adequate answer when I get >> > deeper into the draft. >> >> We tried to make it more clear in the revised draft. >> >> > Second bullet on page 7: >> > >> > o At this point (5), both peers calculate a shared "session secret" >> > using the exchanged values in the key exchange messages. Only >> > when both the server and the client have used secret credentials >> > generated from the same password will the session secret values >> > match. This session secret will be used for access authenticati= on >> > of every individual normal after this point. >> > >> > 3. I think a word may be missing in the last sentence, can you >> > rephrase it? I'm not able to parse it. >> >> This seems to be typo, and we fixed. >> >> > ----- >> > In another bullet on page 7: >> > >> > o If the authentication verification value from the client was >> > correct, it means that the client definitely owns the credential >> > based on the expected password (i.e., the client authentication >> > succeeded). The server will respond with a successful message >> > (200-VFY-S) (7). Contrary to the usual one-way authentication >> > (e.g., HTTP Basic authentication or POP APOP authentication >> > [RFC1939]), this message also contains a server-side >> > authentication verification value. >> > >> > When the client's verification value is incorrect (e.g., because >> > the user-supplied password was incorrect), the server will respo= nd >> > with the 401-INIT message (the same one as used in (2)) instead. >> > >> > 4. This last section should specify that the extensive-token >> > indicating an authentication failure must be included. I would also >> > recommend that this information be logged and have that stated in this >> > draft. Since we are pushing for protocols to be encrypted, the use of >> > sniffers to detect errors will continue to fall off and people will >> > need to rely on logs more. I think it would be more helpful to have >> > an accurate log that responds saying the authentication failed >> > (user/password if you don't want to say which). Encouraging richer >> > logs will be more helpful going forward. >> > ----- >> >> Thank you very much for the suggestion. We incorporated the idea. >> >> > In Section 7, just to make sure I am reading this correctly: >> > >> > The valid tokens for the validation parameter and corresponding >> > values of vh are as follows: >> > >> > host: host-name validation: The value vh will be the ASCII >> > string in the following format: >> > "://:", where , , >> > and are the URI components corresponding to t= he >> > currently accessing resource. >> > >> > 5. By "currently accessing resource", you mean the source system, >> > correct? It might be better to rephrase that so it is clear since >> > this is important to developers. >> > ----- >> >> We rephrased it as "server-side resource". >> It's actually "the URL" being accessed, in short and informally. >> If there is better phrasing, we'll look for it further. >> >> >> > 6. In Section 8, it is the reason parameter of the INIT that lets you >> > know if t is 'valid', correct? >> > Authentication-initializing messages with the >> > Optional-WWW-Authenticate header are used only where the 401-INIT >> > response is valid. It will not replace other 401-type messages suc= h >> > as 401-STALE and 401-KEX-S1. >> > >> > I think it would be helpful to explicitly state what is a valid >> > response unless that is defined already and I missed it? I think it >> > depends on the token or extensive token set in the reason parameter of >> > the INIT message. >> >> We clarified that the reason will be "initial" (modulo future extensions= ). >> >> > ---- >> > 7. In section 10.1, if you change "normal responses" to "normal >> > response", it is easier to fix the grammar in the following sentences: >> > >> > This also >> > holds true for the reception of "normal responses" (responses which >> > do not contain Mutual authentication-related headers) from HTTP >> > servers. >> > change to: >> > This also >> > holds true for the reception of a "normal response" (responses whic= h >> > do not contain Mutual authentication-related headers) from HTTP >> > servers. >> > >> > from: >> > Any kinds of "normal responses" MUST only be accepted for the ve= ry >> > first request in the sequence. Any "normal responses" returned >> > for the second or later requests in the sequence SHALL be >> > considered invalid. >> > change to: >> > Any kind of "normal response" MUST only be accepted for the very >> > first request in the sequence. Any "normal response" returned >> > for the second or later request in the sequence SHALL be >> > considered invalid. >> >> > 8. Section 10.1, please consider rewording the following sentences to >> > make it easier to read: >> > o In the same principle, any responses which refer to or request >> > changing to an authentication realm different from the client's >> > request MUST only be accepted for the very first request in the >> > sequence. Any kind of responses referring to different realms >> > which are returned for the second or later requests in the >> > sequence SHALL be considered invalid. >> > ----- >> > 9. In section 17.2, it might be helpful to include a reference to the >> > TLS 1.2 BCP, RFC7525. The bullet might say something like, when TLS >> > 1.2 is used, follow best practices in RFC7525. >> > ----- >> >> For 7-9: Thank you very much. We did. >> >> > 10. Section 17.3 is the first place I see a clear motivation for this >> > protocol. It might help to have this stated in the introduction. >> > Although the points about password attacks in section 17.2 leave me >> > questioning how much of an improvement this really is. How much >> > analysis was done on this new method? I know the drafts have been >> > around for a while. I'd have to take another pass at the documents to >> > dig deeper, but would like to know if this analysis was done. Can you >> > make the statement that this is more secure? The motivation for HOBA >> > was clear - getting rid of the use of passwords. >> > >> > Passwords are not sent in the clear, but this isn't stated in a >> > motivation section. It just is part of the protocol and mentioned at >> > the end of section 17.5. It might be helpful to include this in the >> > introduction as well in a motivation paragraph. The abstract saying >> > that, "server truly knows the user's >> > encrypted password" isn't the same as saying that the password is >> > encrypted on the wire and doesn't rely on transport encryption. >> >> Thank you very much for the precious suggestion. I added some texts >> to the introduction section. >> For security, simply said, no off-line attack will ever be possible >> using data retrieved from eavesdropped/man-in-the-middle traffics. >> We discussed some detail on on-line attacks in this section, >> but it's much harder than off-line attacks for attackers, >> and much easier for servers to detect and perform countermeasures. >> (Of course, it's a gift from the PAKE.) >> >> > ----- >> > 11. Section 17.3. I'm not clear on this sentence in the last paragrap= h: >> > Of course, in such cases, the user interfaces for asking passwords >> > for this authentication shall be clearly identifiable against >> > imitation by other insecure password input fields (such as forms). >> > Common attacks of this nature would be to direct users to a form that >> > isn't the real form. Is it the mutual authentication that helps here? >> > If so, explain how. How is it clearly identifiable against >> > imitation? >> >> What we considered and implemented is a authentication interface >> in browser-chrome (around the address bar), not within the main content >> area. >> It's common for browsers to have some "secure UI area" not possible to >> circumvent from the web content itself, whose examples includes address >> bar, >> and padlock icons, as well as the "the other area" controlled by the >> web page contents. We intended to use the former area for secure >> authentication. >> However, we did not want to include any "instructions" on the user >> interfaces >> of web browsers (fearing that it will become "out-of-scope" of the >> draft), so >> we used some "abstract" requirement here. >> If you have more suggestion on "the extent we should say for user >> interfaces", >> it's really appreciated. >> >> -- >> 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: , < >> yutaka@oiwa.jp> >> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 >> 46B5] >> > > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --94eb2c1255f08684b7053fdff76b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Just a quick question as I fill = out the ballot text for next week's telechat.=C2=A0 For the IANA sectio= n, as I read it both registries require expert review and a specification, = is that right?=C2=A0 I'm asking as the language could be clearer and I = need to make sure it is clear in the ballot.

Thank= you,
Kathleen

On Tue, Oct 11, 2016 at 12:12 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Dear Yutaka,

I am sorry for my delay in response.=C2=A0 The updates look very good and = I think the updated introduction is helpful.=C2=A0 I will progress the draf= t into IETF last call, but an edit pass on the new text is required as ther= e are some grammar issues.

Also, you had responded= saying you would add something about logging and I am not able to find tha= t text in the diffs from -08.=C2=A0 Was it added?

= Thank you,
Kathleen

On Sun, Oct 9, 2016 at 12:24= AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B <y.oiwa@aist.go.jp> wrote:<= br>
Dear Kathleen,

I have not seen any response to the previous mail.
If we have any problems to solve or actions to take,
please let me know.

Thanks,

Yutaka
________________________________________
=E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA <y.oiwa@aist.go.jp>
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5 21= :44:39
=E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org
=E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of draft-ietf-httpauth-mutual= -08

Dear Kathleen,

I'm sorry I've updated the draft according to your mail,
but not responded to the mail itself.
# and I found a few typo to submit the draft revision very soon.

On 2016/08/12 11:18, Kathleen Moriarty wrote:
> Hello,
>
> Thank you for your work on draft-ietf-httpauth-mutual-08.=C2=A0 I= will try
> to get through my AD review of the accompanying draft tomorrow.
>
> I read through the draft and have the following questions.
>
>
> -----
> Section 2.1, in the following text:
>
>=C2=A0 o=C2=A0 Authenticated key exchange messages: used by both peers = to perform
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication and the sharing of a cryptogr= aphic secret.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 req-KEX-C1 message: a message sent f= rom the client.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 401-KEX-S1 message: a message sent f= rom the server in response
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to a req-KEX-C1 message.
>
> 1. What does the response mean?=C2=A0 Is there a pass/fail message in = the
> response or is this just an ack that the message was received by the > server to the client?

401-KEX-S1 will be almost unconditionally sent as a response,
as authentication is on-going, not finished yet.
There may be a "no-go" for fatal error case (e.g. parameter misma= tch), however.

> Then in the following:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 200-VFY-S message: a client-authenti= cation successful response
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used by the server, which also simul= taneously asserts to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client that the server is authentic.=
>
> 2. Maybe this will be clear as I read further through the draft, but > that seems like a lot to assert at once.=C2=A0 This note is a placehol= der
> for me in case I do't feel like there is an adequate answer when I= get
> deeper into the draft.

We tried to make it more clear in the revised draft.

> Second bullet on page 7:
>
>=C2=A0 o=C2=A0 At this point (5), both peers calculate a shared "s= ession secret"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the exchanged values in the key exchan= ge messages.=C2=A0 Only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when both the server and the client have use= d secret credentials
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated from the same password will the se= ssion secret values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0match.=C2=A0 This session secret will be use= d for access authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of every individual normal after this point.=
>
> 3. I think a word may be missing in the last sentence, can you
> rephrase it?=C2=A0 I'm not able to parse it.

This seems to be typo, and we fixed.

> -----
> In another bullet on page 7:
>
>=C2=A0 o=C2=A0 If the authentication verification value from the client= was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct, it means that the client definitely= owns the credential
>=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the expected password (i.e., the cl= ient authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0succeeded).=C2=A0 The server will respond wi= th a successful message
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(200-VFY-S) (7).=C2=A0 Contrary to the usual= one-way authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., HTTP Basic authentication or POP APOP= authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC1939]), this message also contains a ser= ver-side
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication verification value.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When the client's verification value is = incorrect (e.g., because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the user-supplied password was incorrect), t= he server will respond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the 401-INIT message (the same one as u= sed in (2)) instead.
>
> 4. This last section should specify that the extensive-token
> indicating an authentication failure must be included.=C2=A0 I would a= lso
> recommend that this information be logged and have that stated in this=
> draft.=C2=A0 Since we are pushing for protocols to be encrypted, the u= se of
> sniffers to detect errors will continue to fall off and people will > need to rely on logs more.=C2=A0 I think it would be more helpful to h= ave
> an accurate log that responds saying the authentication failed
> (user/password if you don't want to say which).=C2=A0 Encouraging = richer
> logs will be more helpful going forward.
> -----

Thank you very much for the suggestion. We incorporated the idea.

> In Section 7, just to make sure I am reading this correctly:
>
> The valid tokens for the validation parameter and corresponding
>=C2=A0 =C2=A0 values of vh are as follows:
>
>=C2=A0 =C2=A0 host:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 host-name validat= ion: The value vh will be the ASCII
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st= ring in the following format:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;<scheme>://<host>:<port>", where <scheme>,= <host>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an= d <port> are the URI components corresponding to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cu= rrently accessing resource.
>
> 5. By "currently accessing resource", you mean the source sy= stem,
> correct?=C2=A0 It might be better to rephrase that so it is clear sinc= e
> this is important to developers.
> -----

We rephrased it as "server-side resource".
It's actually "the URL" being accessed, in short and informal= ly.
If there is better phrasing, we'll look for it further.


> 6. In Section 8, it is the reason parameter of the INIT that lets you<= br> > know if t is 'valid', correct?
>=C2=A0 =C2=A0 Authentication-initializing messages with the
>=C2=A0 =C2=A0 Optional-WWW-Authenticate header are used only where the = 401-INIT
>=C2=A0 =C2=A0 response is valid.=C2=A0 It will not replace other 401-ty= pe messages such
>=C2=A0 =C2=A0 as 401-STALE and 401-KEX-S1.
>
> I think it would be helpful to explicitly state what is a valid
> response unless that is defined already and I missed it?=C2=A0 I think= it
> depends on the token or extensive token set in the reason parameter of=
> the INIT message.

We clarified that the reason will be "initial" (modulo future ext= ensions).

> ----
> 7. In section 10.1, if you change "normal responses" to &quo= t;normal
> response", it is easier to fix the grammar in the following sente= nces:
>
>=C2=A0 =C2=A0 This also
>=C2=A0 =C2=A0 holds true for the reception of "normal responses&qu= ot; (responses which
>=C2=A0 =C2=A0 do not contain Mutual authentication-related headers) fro= m HTTP
>=C2=A0 =C2=A0 servers.
> change to:
>=C2=A0 =C2=A0 This also
>=C2=A0 =C2=A0 holds true for the reception of a "normal response&q= uot; (responses which
>=C2=A0 =C2=A0 do not contain Mutual authentication-related headers) fro= m HTTP
>=C2=A0 =C2=A0 servers.
>
> from:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Any kinds of "normal responses" MU= ST only be accepted for the very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0first request in the sequence.=C2=A0 Any &qu= ot;normal responses" returned
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the second or later requests in the sequ= ence SHALL be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considered invalid.
> change to:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Any kind of "normal response" MUST= only be accepted for the very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0first request in the sequence.=C2=A0 Any &qu= ot;normal response" returned
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the second or later request in the seque= nce SHALL be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considered invalid.

> 8. Section 10.1, please consider rewording the following sentences to<= br> > make it easier to read:
>=C2=A0 =C2=A0 o=C2=A0 In the same principle, any responses which refer = to or request
>=C2=A0 =C2=A0 =C2=A0 =C2=A0changing to an authentication realm differen= t from the client's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0request MUST only be accepted for the very f= irst request in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence.=C2=A0 Any kind of responses referr= ing to different realms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0which are returned for the second or later r= equests in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence SHALL be considered invalid.
> -----
> 9. In section 17.2, it might be helpful to include a reference to the<= br> > TLS 1.2 BCP, RFC7525.=C2=A0 The bullet might say something like, when = TLS
> 1.2 is used, follow best practices in RFC7525.
> -----

For 7-9: Thank you very much. We did.

> 10. Section 17.3 is the first place I see a clear motivation for this<= br> > protocol.=C2=A0 It might help to have this stated in the introduction.=
> Although the points about password attacks in section 17.2 leave me > questioning how much of an improvement this really is.=C2=A0 How much<= br> > analysis was done on this new method? I know the drafts have been
> around for a while.=C2=A0 I'd have to take another pass at the doc= uments to
> dig deeper, but would like to know if this analysis was done.=C2=A0 Ca= n you
> make the statement that this is more secure?=C2=A0 The motivation for = HOBA
> was clear - getting rid of the use of passwords.
>
> Passwords are not sent in the clear, but this isn't stated in a > motivation section.=C2=A0 It just is part of the protocol and mentione= d at
> the end of section 17.5.=C2=A0 It might be helpful to include this in = the
> introduction as well in a motivation paragraph.=C2=A0 The abstract say= ing
> that, "server truly knows the user's
> encrypted password" isn't the same as saying that the passwor= d is
> encrypted on the wire and doesn't rely on transport encryption.
Thank you very much for the precious suggestion. I added some texts
to the introduction section.
For security, simply said, no off-line attack will ever be possible
using data retrieved from eavesdropped/man-in-the-middle traffics.
We discussed some detail on on-line attacks in this section,
but it's much harder than off-line attacks for attackers,
and much easier for servers to detect and perform countermeasures.
(Of course, it's a gift from the PAKE.)

> -----
> 11. Section 17.3.=C2=A0 I'm not clear on this sentence in the last= paragraph:
>=C2=A0 =C2=A0 Of course, in such cases, the user interfaces for asking = passwords
>=C2=A0 =C2=A0 for this authentication shall be clearly identifiable aga= inst
>=C2=A0 =C2=A0 imitation by other insecure password input fields (such a= s forms).
> Common attacks of this nature would be to direct users to a form that<= br> > isn't the real form.=C2=A0 Is it the mutual authentication that he= lps here?
>=C2=A0 If so, explain how.=C2=A0 How is it clearly identifiable against=
> imitation?

What we considered and implemented is a authentication interface
in browser-chrome (around the address bar), not within the main content are= a.
It's common for browsers to have some "secure UI area" not po= ssible to
circumvent from the web content itself, whose examples includes address bar= ,
and padlock icons, as well as the "the other area" controlled by = the
web page contents.=C2=A0 We intended to use the former area for secure auth= entication.
However, we did not want to include any "instructions" on the use= r interfaces
of web browsers (fearing that it will become "out-of-scope" of th= e draft), so
we used some "abstract" requirement here.
If you have more suggestion on "the extent we should say for user inte= rfaces",
it's really appreciated.

--
Yutaka OIWA, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 Leader, Cyber Physical Archit= ecture Research Group
=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=A0Information Technology = Research Institute
=C2=A0 =C2=A0 =C2=A0National Institute of Advanced Industrial Science and T= echnology (AIST)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D=C2=A0 3139 8677 9BD2 4405= 46B5]



<= /div>--

Best regards,
Kathleen



--
Best regards,
Kathleen
--94eb2c1255f08684b7053fdff76b-- From nobody Thu Oct 27 18:34:35 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 28CF912999E; Thu, 27 Oct 2016 18:34:29 -0700 (PDT) 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, HTML_MESSAGE=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 IKpDAlUJm_37; Thu, 27 Oct 2016 18:34:27 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 2C84D129476; Thu, 27 Oct 2016 18:34:23 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id q126so43485939vkd.2; Thu, 27 Oct 2016 18:34:23 -0700 (PDT) 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=AMVScwUt6wZzoDEoX3DsCvONefXl2FqMNu/WPEQ4a9I=; b=xeiX9zQYTWp37MjxXLKA3axJAxR7WVrPGyO9wulMdZF9RucqulFT0NgaaN4YCZUqlq 3h3T8SD7zn837X8CK+IiBba8T6+QnaNsFG1tY6uxIU9JGsaP9ZTaW9s0PhCG4W6glZr1 ckXM4VLje2441CJXQJg94EAsTVotVL69PJf0lTvG5JZA9eBgiP1KQtphtAtgubzMRqWo kNgZ9btNin4EgyX5ysCfkkkHe11hcUfFXF8MS8KVjinI0HshbOjsj7k3/hU0UFa2yPN/ pCk21DiOkV4uCXk6KX89RfDBThc5PaTkwfWytCYY1ZwIHKiTxHcodXQgOXtIVhUXGfDB Z//g== 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=AMVScwUt6wZzoDEoX3DsCvONefXl2FqMNu/WPEQ4a9I=; b=mUujAOQ72qwuaz2UhPzU9Fbw9avU7nLPo0Xo/EJjin4NCy4LgZ2wLO30SZdykUckJJ toFzjsR2YhDIalK7oRAyO5K5+bifEpiZhT8f9u1iKntzdy5344InsfwQBCiWSlonKPJm 5myPmQy9jz2v1BmG0Ciso8cLkEFmELYPfwZaSxiHqQBW3Yr+A19B8tpP/hQGUBZcS5NK 8kv9mECO2t21/dhp74vJ1Jn5NUKPmYagkrs7N3R/Im20ffktqRQ5NKiEpAFSdCp3ueLT ZVm7Tyu3GCzmIu1ze0RyR+VSpM12TsPQGDcxpFGeA084KLazbaswMasu1xXWE2EHBvpG gpVg== X-Gm-Message-State: ABUngvfVZ6ErwpT0xaJvl3PTYrFQUwHRXxPzwrCLMFJ18U3oiWpvp6SWZnufzWLcCZWF3yyMh9VssvWKPtShAQ== X-Received: by 10.31.183.134 with SMTP id h128mr10288151vkf.124.1477618462257; Thu, 27 Oct 2016 18:34:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Thu, 27 Oct 2016 18:34:21 -0700 (PDT) In-Reply-To: References: <147621063154.31943.11848350290741726768.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 27 Oct 2016 21:34:21 -0400 Message-ID: To: drafts-lastcall-comment@iana.org, "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a113bee228e7d57053fe2dbb2 Archived-At: Cc: draft-ietf-httpauth-mutual.all@ietf.org, "iesg@ietf.org" Subject: Re: [http-auth] [IANA #931553] Last Call: (Mutual Authentication Protocol for HTTP) to Experimental RFC 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: Fri, 28 Oct 2016 01:34:29 -0000 --001a113bee228e7d57053fe2dbb2 Content-Type: text/plain; charset=UTF-8 Forwarding to the httpauth working group. I haven't seen a response on the IANA review yet. Thanks, Kathleen On Tue, Oct 25, 2016 at 2:33 PM, Sabrina Tanamal via RT < drafts-lastcall-comment@iana.org> wrote: > (BEGIN IANA COMMENTS) > > IESG/Authors/WG Chairs: > > The IANA Services Operator has completed its review of > draft-ietf-httpauth-mutual-10.txt. If any part of this review is > inaccurate, please let us know. > > We have a question about one of the actions requested in the IANA > Considerations section of this document. > > Upon approval of this document, we understand that there are two registry > actions to complete. > > First, a new registry is to be created called the HTTP Mutual > authentication algorithms registry. We note that the registrations in this > new registry will consist of a Token, a Description and a Reference. > > QUESTION -> Where should this new registry be located? Is it a new > registry on the List of all IANA maintained protocol parameter registries > or is it a subregistry of an existing registry? If it is a subregistry of > an existing registry, in which registry will it be contained? > > We understand that the registry is to be managed through Expert Review as > defined in RFC 5226. > > While this document provides no initial values for the new registry, we > understand that another document ietf-httpauth-mutual-algo is dependent > upon the actions in this IANA Considerations section being completed. When > they are, the document ietf-httpauth-mutual-algo will provide new > registrations for the new registry. > > Second, another new registry is to be created called the HTTP Mutual > authentication host validation methods registry. We note that the > registrations in this new registry will consist of a Token, a Description > and a Reference. > > QUESTION -> Where should this new registry be located? Is it a new > registry on the List of all IANA maintained protocol parameter registries > or is it a subregistry of an existing registry? If it is a subregistry of > an existing registry, in which registry will it be contained? > > We understand that the registry is to be managed through Expert Review as > defined in RFC 5226. > > There are initial registrations in this new registry as follows: > > +----------------------+----------------------------+------- > ---------------------+ > | Token | Description | Reference | > +----------------------+----------------------------+------- > ---------------------+ > | host | Host name verification | [ RFC-to-be Section 7 ] | > | | only | | > | tls-server-end-point | TLS certificate-based | [ RFC-to-be Section 7 ] | > | tls-unique | TLS unique key-based | [ RFC-to-be Section 7 ] | > +----------------------+----------------------------+------- > ---------------------+ > > We understand that these are the only actions required to be completed > upon approval of this document. > > Note: The actions requested in this document will not be completed until > the document has been approved for publication as an RFC. This message is > only to confirm what actions will be performed. > > Thank you, > > Sabrina Tanamal > IANA Services Specialist > PTI > > (END IANA COMMENTS) > > -- Best regards, Kathleen --001a113bee228e7d57053fe2dbb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forwarding to the httpauth working group.=C2=A0 I haven= 9;t seen a response on the IANA review yet.

Thanks,
Kathleen

On Tue, Oct 25, 2016 at 2:33 PM, Sabrina Tanamal via RT <drafts-lastcall-comment@iana.org> wrote:
(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpauth-= mutual-10.txt. If any part of this review is inaccurate, please let us= know.

We have a question about one of the actions requested in the IANA Considera= tions section of this document.

Upon approval of this document, we understand that there are two registry a= ctions to complete.

First, a new registry is to be created called the HTTP Mutual authenticatio= n algorithms registry. We note that the registrations in this new registry = will consist of a Token, a Description and a Reference.

QUESTION -> Where should this new registry be located? Is it a new regis= try on the List of all IANA maintained protocol parameter registries or is = it a subregistry of an existing registry? If it is a subregistry of an exis= ting registry, in which registry will it be contained?

We understand that the registry is to be managed through Expert Review as d= efined in RFC 5226.

While this document provides no initial values for the new registry, we und= erstand that another document ietf-httpauth-mutual-algo is dependent upon t= he actions in this IANA Considerations section being completed. When they a= re, the document ietf-httpauth-mutual-algo will provide new registrations f= or the new registry.

Second, another new registry is to be created called the HTTP Mutual authen= tication host validation methods registry. We note that the registrations i= n this new registry will consist of a Token, a Description and a Reference.=

QUESTION -> Where should this new registry be located? Is it a new regis= try on the List of all IANA maintained protocol parameter registries or is = it a subregistry of an existing registry? If it is a subregistry of an exis= ting registry, in which registry will it be contained?

We understand that the registry is to be managed through Expert Review as d= efined in RFC 5226.

There are initial registrations in this new registry as follows:

+----------------------+----------------------------+------------= ----------------+
| Token | Description | Reference |
+----------------------+----------------------------+------------= ----------------+
| host | Host name verification | [ RFC-to-be Section 7 ] |
| | only | |
| tls-server-end-point | TLS certificate-based | [ RFC-to-be Section 7 ] |<= br> | tls-unique | TLS unique key-based | [ RFC-to-be Section 7 ] |
+----------------------+----------------------------+------------= ----------------+

We understand that these are the only actions required to be completed upon= approval of this document.

Note:=C2=A0 The actions requested in this document will not be completed un= til the document has been approved for publication as an RFC. This message = is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

(END IANA COMMENTS)




--
Best regards,
Kathleen
--001a113bee228e7d57053fe2dbb2-- From nobody Thu Oct 27 22:59:52 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 B81D912950A for ; Thu, 27 Oct 2016 22:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 7Ty84sq0XoQs for ; Thu, 27 Oct 2016 22:59:47 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0048.outbound.protection.outlook.com [104.47.93.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 C6C39129628 for ; Thu, 27 Oct 2016 22:59:45 -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=w2VFJdn7favAZBLoKcOAWtPrYzhC3BC1qywjaT1P3dw=; b=U8/ukaQfEJzFOemPlve1ch/NBXQWNC4JLQi/lTTJmwwUsYw1XlV0E2Yw+v9P6ByWfZgHYzwa5GbwstOAa9xAVlLuR/oxyvz7XLhQvH8fCMwxUz6wuU1jbJhrLZ9Oc3F0bocJKLU1o27/QizvVTV5upjolOSed8g9jngAGfikpSk= 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.679.12; Fri, 28 Oct 2016 05:59:42 +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.0679.015; Fri, 28 Oct 2016 05:59:42 +0000 From: =?utf-8?B?5aSn5bKp5a+b?= To: Kathleen Moriarty Thread-Topic: [http-auth] AD review of draft-ietf-httpauth-mutual-08 Thread-Index: AQHR9D/IeFxKC981CECMq6g0jH5iNqCGTIqAgBmUpaiAA+rkgIAZiGyAgACC1FA= Date: Fri, 28 Oct 2016 05:59:42 +0000 Message-ID: References: <57E3D237.50001@aist.go.jp> In-Reply-To: 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.25.177] x-ms-office365-filtering-correlation-id: 567e8c41-e753-4733-b821-08d3fef79c89 x-microsoft-exchange-diagnostics: 1; TY1PR01MB0586; 7:1+s19vrlIIEXCoRHMVyP6xXWI820/c+GZ/PDe52AhdPI5XdSeXmdWq+nohU53uJXgeL1d2fJbmglXt0m4wHGw30NBkK3IuoSy3fcrPRtNqovxFnFBfOjbQi/633RuG3V3k9AuvRD7MMbeyzqKU8tl2zO1CwJu8lkXqaw53TM/cmIfj/nEX85eBRCVqMZ1UupABsIiTS+hKCK6JwgU+UkikbrgpjP+7bVzumdj04k6nyKRVlXng8m9PJr6UG87R4A8hzdz1bELsn1z06VzaKHZ6xZKO59HU42g0lxcjKctQUNtF+BGyvnicTQ2V2xetnir0iL+J7sjorQPEcbvWoI6LHgnAilBWCR8V+nJP2eelc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0586; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089)(100405760836317)(21748063052155); 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: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(15594002)(45984002)(189002)(24454002)(199003)(2906002)(2900100001)(5002640100001)(93886004)(66066001)(2950100002)(42882006)(101416001)(4326007)(81156014)(15975445007)(86362001)(77096005)(6916009)(7736002)(106356001)(8676002)(105586002)(106116001)(230783001)(31430400001)(68736007)(76576001)(9686002)(7846002)(81166006)(11100500001)(74482002)(551544002)(10400500002)(85182001)(122556002)(74316002)(8936002)(6116002)(3846002)(110136003)(102836003)(586003)(7696004)(3280700002)(97736004)(19625215002)(33656002)(54356999)(92566002)(16236675004)(76176999)(19580395003)(19300405004)(5660300001)(3660700001)(345774005)(19580405001)(87936001)(189998001)(50986999); 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: multipart/alternative; boundary="_000_TY1PR01MB0588C4D767B3FF7D81546321A0AD0TY1PR01MB0588jpnp_" MIME-Version: 1.0 X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2016 05:59:42.4989 (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" Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 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: Fri, 28 Oct 2016 05:59:52 -0000 --_000_TY1PR01MB0588C4D767B3FF7D81546321A0AD0TY1PR01MB0588jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBLYXRobGVlbiwNCg0KVGhlIHJlZ2lzdHJpZXMgcmVxdWlyZSBleHBlcnQgcmV2aWV3IHBy b2Nlc3MgYXMgZGVmaW5lZCBpbiBSRkM1MjI2Lg0KKGEgY29uc2Vuc3VzIG9uIFdHIGRpc2N1c3Np b25zLikNClRoZSBleGlzdGVuY2Ugb2Ygc3BlY2lmaWNhdGlvbiBpcyBub3QgZXhwbGljaXRseSBu ZWVkZWQgaWYgdGhlIHRleHQgbWFrZXMgY29uZnVzaW9ucy4NCkkgYXNzdW1lIHRoYXQgaXQgd2ls bCBiZSBhbnl3YXkgcmVxdWlyZWQgKGluIG1vc3QgY2FzZXMpIGZvciBleHBlcnQgcmV2aWV3IHBy b2Nlc3Nlcy4NCg0KDQpUaGFua3MsDQpZdXRha2ENCg0KLS0NCll1dGFrYSBPSVdBLCBQaC5ELiAg ICAgICBMZWFkZXIsIEN5YmVyIFBoeXNpY2FsIEFyY2hpdGVjdHVyZSBSZXNlYXJjaCBHcm91cA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kg UmVzZWFyY2ggSW5zdGl0dXRlDQogICAgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIEFkdmFuY2VkIElu ZHVzdHJpYWwgU2NpZW5jZSBhbmQgVGVjaG5vbG9neSAoQUlTVCkNCiAgICAgICAgICAgICAgICAg ICAgICBNYWlsIGFkZHJlc3NlczogPHkub2l3YUBhaXN0LmdvLmpwPiwgPHl1dGFrYUBvaXdhLmpw Pg0KT3BlblBHUDogaWRbNDQwNTQ2QjVdIGZwWzdDOUYgNzIzQSA3NTU5IDMyNDYgMjI5RCAgMzEz OSA4Njc3IDlCRDIgNDQwNSA0NkI1XQ0KDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRv OmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVy IDI4LCAyMDE2IDc6MDcgQU0NClRvOiDlpKflsqnlr5sgPHkub2l3YUBhaXN0LmdvLmpwPg0KQ2M6 IGh0dHAtYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtodHRwLWF1dGhdIEFEIHJldmlldyBv ZiBkcmFmdC1pZXRmLWh0dHBhdXRoLW11dHVhbC0wOA0KDQpIZWxsbywNCg0KSnVzdCBhIHF1aWNr IHF1ZXN0aW9uIGFzIEkgZmlsbCBvdXQgdGhlIGJhbGxvdCB0ZXh0IGZvciBuZXh0IHdlZWsncyB0 ZWxlY2hhdC4gIEZvciB0aGUgSUFOQSBzZWN0aW9uLCBhcyBJIHJlYWQgaXQgYm90aCByZWdpc3Ry aWVzIHJlcXVpcmUgZXhwZXJ0IHJldmlldyBhbmQgYSBzcGVjaWZpY2F0aW9uLCBpcyB0aGF0IHJp Z2h0PyAgSSdtIGFza2luZyBhcyB0aGUgbGFuZ3VhZ2UgY291bGQgYmUgY2xlYXJlciBhbmQgSSBu ZWVkIHRvIG1ha2Ugc3VyZSBpdCBpcyBjbGVhciBpbiB0aGUgYmFsbG90Lg0KDQpUaGFuayB5b3Us DQpLYXRobGVlbg0KDQpPbiBUdWUsIE9jdCAxMSwgMjAxNiBhdCAxMjoxMiBQTSwgS2F0aGxlZW4g TW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVl bi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KRGVhciBZdXRha2EsDQoNCkkgYW0g c29ycnkgZm9yIG15IGRlbGF5IGluIHJlc3BvbnNlLiAgVGhlIHVwZGF0ZXMgbG9vayB2ZXJ5IGdv b2QgYW5kIEkgdGhpbmsgdGhlIHVwZGF0ZWQgaW50cm9kdWN0aW9uIGlzIGhlbHBmdWwuICBJIHdp bGwgcHJvZ3Jlc3MgdGhlIGRyYWZ0IGludG8gSUVURiBsYXN0IGNhbGwsIGJ1dCBhbiBlZGl0IHBh c3Mgb24gdGhlIG5ldyB0ZXh0IGlzIHJlcXVpcmVkIGFzIHRoZXJlIGFyZSBzb21lIGdyYW1tYXIg aXNzdWVzLg0KDQpBbHNvLCB5b3UgaGFkIHJlc3BvbmRlZCBzYXlpbmcgeW91IHdvdWxkIGFkZCBz b21ldGhpbmcgYWJvdXQgbG9nZ2luZyBhbmQgSSBhbSBub3QgYWJsZSB0byBmaW5kIHRoYXQgdGV4 dCBpbiB0aGUgZGlmZnMgZnJvbSAtMDguICBXYXMgaXQgYWRkZWQ/DQoNClRoYW5rIHlvdSwNCkth dGhsZWVuDQoNCk9uIFN1biwgT2N0IDksIDIwMTYgYXQgMTI6MjQgQU0sIOWkp+WyqeWvmyA8eS5v aXdhQGFpc3QuZ28uanA8bWFpbHRvOnkub2l3YUBhaXN0LmdvLmpwPj4gd3JvdGU6DQpEZWFyIEth dGhsZWVuLA0KDQpJIGhhdmUgbm90IHNlZW4gYW55IHJlc3BvbnNlIHRvIHRoZSBwcmV2aW91cyBt YWlsLg0KSWYgd2UgaGF2ZSBhbnkgcHJvYmxlbXMgdG8gc29sdmUgb3IgYWN0aW9ucyB0byB0YWtl LA0KcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpUaGFua3MsDQoNCll1dGFrYQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5beu5Ye65Lq6OiBZdXRha2EgT0lXQSA8eS5v aXdhQGFpc3QuZ28uanA8bWFpbHRvOnkub2l3YUBhaXN0LmdvLmpwPj4NCumAgeS/oeaXpeaZgjog MjAxNuW5tDnmnIgyMuaXpSAyMTo0NDozOQ0K5a6b5YWIOiBLYXRobGVlbiBNb3JpYXJ0eTsgaHR0 cC1hdXRoQGlldGYub3JnPG1haWx0bzpodHRwLWF1dGhAaWV0Zi5vcmc+DQrku7blkI06IFJlOiBb aHR0cC1hdXRoXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1odHRwYXV0aC1tdXR1YWwtMDgNCg0K RGVhciBLYXRobGVlbiwNCg0KSSdtIHNvcnJ5IEkndmUgdXBkYXRlZCB0aGUgZHJhZnQgYWNjb3Jk aW5nIHRvIHlvdXIgbWFpbCwNCmJ1dCBub3QgcmVzcG9uZGVkIHRvIHRoZSBtYWlsIGl0c2VsZi4N CiMgYW5kIEkgZm91bmQgYSBmZXcgdHlwbyB0byBzdWJtaXQgdGhlIGRyYWZ0IHJldmlzaW9uIHZl cnkgc29vbi4NCg0KT24gMjAxNi8wOC8xMiAxMToxOCwgS2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6 DQo+IEhlbGxvLA0KPg0KPiBUaGFuayB5b3UgZm9yIHlvdXIgd29yayBvbiBkcmFmdC1pZXRmLWh0 dHBhdXRoLW11dHVhbC0wOC4gIEkgd2lsbCB0cnkNCj4gdG8gZ2V0IHRocm91Z2ggbXkgQUQgcmV2 aWV3IG9mIHRoZSBhY2NvbXBhbnlpbmcgZHJhZnQgdG9tb3Jyb3cuDQo+DQo+IEkgcmVhZCB0aHJv dWdoIHRoZSBkcmFmdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucy4NCj4NCj4NCj4g LS0tLS0NCj4gU2VjdGlvbiAyLjEsIGluIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4NCj4gIG8gIEF1 dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIG1lc3NhZ2VzOiB1c2VkIGJ5IGJvdGggcGVlcnMgdG8g cGVyZm9ybQ0KPiAgICAgICBhdXRoZW50aWNhdGlvbiBhbmQgdGhlIHNoYXJpbmcgb2YgYSBjcnlw dG9ncmFwaGljIHNlY3JldC4NCj4NCj4gICAgICAgKiAgcmVxLUtFWC1DMSBtZXNzYWdlOiBhIG1l c3NhZ2Ugc2VudCBmcm9tIHRoZSBjbGllbnQuDQo+DQo+ICAgICAgICogIDQwMS1LRVgtUzEgbWVz c2FnZTogYSBtZXNzYWdlIHNlbnQgZnJvbSB0aGUgc2VydmVyIGluIHJlc3BvbnNlDQo+ICAgICAg ICAgIHRvIGEgcmVxLUtFWC1DMSBtZXNzYWdlLg0KPg0KPiAxLiBXaGF0IGRvZXMgdGhlIHJlc3Bv bnNlIG1lYW4/ICBJcyB0aGVyZSBhIHBhc3MvZmFpbCBtZXNzYWdlIGluIHRoZQ0KPiByZXNwb25z ZSBvciBpcyB0aGlzIGp1c3QgYW4gYWNrIHRoYXQgdGhlIG1lc3NhZ2Ugd2FzIHJlY2VpdmVkIGJ5 IHRoZQ0KPiBzZXJ2ZXIgdG8gdGhlIGNsaWVudD8NCg0KNDAxLUtFWC1TMSB3aWxsIGJlIGFsbW9z dCB1bmNvbmRpdGlvbmFsbHkgc2VudCBhcyBhIHJlc3BvbnNlLA0KYXMgYXV0aGVudGljYXRpb24g aXMgb24tZ29pbmcsIG5vdCBmaW5pc2hlZCB5ZXQuDQpUaGVyZSBtYXkgYmUgYSAibm8tZ28iIGZv ciBmYXRhbCBlcnJvciBjYXNlIChlLmcuIHBhcmFtZXRlciBtaXNtYXRjaCksIGhvd2V2ZXIuDQoN Cj4gVGhlbiBpbiB0aGUgZm9sbG93aW5nOg0KPiAgICAgICAqICAyMDAtVkZZLVMgbWVzc2FnZTog YSBjbGllbnQtYXV0aGVudGljYXRpb24gc3VjY2Vzc2Z1bCByZXNwb25zZQ0KPiAgICAgICAgICB1 c2VkIGJ5IHRoZSBzZXJ2ZXIsIHdoaWNoIGFsc28gc2ltdWx0YW5lb3VzbHkgYXNzZXJ0cyB0byB0 aGUNCj4gICAgICAgICAgY2xpZW50IHRoYXQgdGhlIHNlcnZlciBpcyBhdXRoZW50aWMuDQo+DQo+ IDIuIE1heWJlIHRoaXMgd2lsbCBiZSBjbGVhciBhcyBJIHJlYWQgZnVydGhlciB0aHJvdWdoIHRo ZSBkcmFmdCwgYnV0DQo+IHRoYXQgc2VlbXMgbGlrZSBhIGxvdCB0byBhc3NlcnQgYXQgb25jZS4g IFRoaXMgbm90ZSBpcyBhIHBsYWNlaG9sZGVyDQo+IGZvciBtZSBpbiBjYXNlIEkgZG8ndCBmZWVs IGxpa2UgdGhlcmUgaXMgYW4gYWRlcXVhdGUgYW5zd2VyIHdoZW4gSSBnZXQNCj4gZGVlcGVyIGlu dG8gdGhlIGRyYWZ0Lg0KDQpXZSB0cmllZCB0byBtYWtlIGl0IG1vcmUgY2xlYXIgaW4gdGhlIHJl dmlzZWQgZHJhZnQuDQoNCj4gU2Vjb25kIGJ1bGxldCBvbiBwYWdlIDc6DQo+DQo+ICBvICBBdCB0 aGlzIHBvaW50ICg1KSwgYm90aCBwZWVycyBjYWxjdWxhdGUgYSBzaGFyZWQgInNlc3Npb24gc2Vj cmV0Ig0KPiAgICAgICB1c2luZyB0aGUgZXhjaGFuZ2VkIHZhbHVlcyBpbiB0aGUga2V5IGV4Y2hh bmdlIG1lc3NhZ2VzLiAgT25seQ0KPiAgICAgICB3aGVuIGJvdGggdGhlIHNlcnZlciBhbmQgdGhl IGNsaWVudCBoYXZlIHVzZWQgc2VjcmV0IGNyZWRlbnRpYWxzDQo+ICAgICAgIGdlbmVyYXRlZCBm cm9tIHRoZSBzYW1lIHBhc3N3b3JkIHdpbGwgdGhlIHNlc3Npb24gc2VjcmV0IHZhbHVlcw0KPiAg ICAgICBtYXRjaC4gIFRoaXMgc2Vzc2lvbiBzZWNyZXQgd2lsbCBiZSB1c2VkIGZvciBhY2Nlc3Mg YXV0aGVudGljYXRpb24NCj4gICAgICAgb2YgZXZlcnkgaW5kaXZpZHVhbCBub3JtYWwgYWZ0ZXIg dGhpcyBwb2ludC4NCj4NCj4gMy4gSSB0aGluayBhIHdvcmQgbWF5IGJlIG1pc3NpbmcgaW4gdGhl IGxhc3Qgc2VudGVuY2UsIGNhbiB5b3UNCj4gcmVwaHJhc2UgaXQ/ICBJJ20gbm90IGFibGUgdG8g cGFyc2UgaXQuDQoNClRoaXMgc2VlbXMgdG8gYmUgdHlwbywgYW5kIHdlIGZpeGVkLg0KDQo+IC0t LS0tDQo+IEluIGFub3RoZXIgYnVsbGV0IG9uIHBhZ2UgNzoNCj4NCj4gIG8gIElmIHRoZSBhdXRo ZW50aWNhdGlvbiB2ZXJpZmljYXRpb24gdmFsdWUgZnJvbSB0aGUgY2xpZW50IHdhcw0KPiAgICAg ICBjb3JyZWN0LCBpdCBtZWFucyB0aGF0IHRoZSBjbGllbnQgZGVmaW5pdGVseSBvd25zIHRoZSBj cmVkZW50aWFsDQo+ICAgICAgIGJhc2VkIG9uIHRoZSBleHBlY3RlZCBwYXNzd29yZCAoaS5lLiwg dGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KPiAgICAgICBzdWNjZWVkZWQpLiAgVGhlIHNlcnZl ciB3aWxsIHJlc3BvbmQgd2l0aCBhIHN1Y2Nlc3NmdWwgbWVzc2FnZQ0KPiAgICAgICAoMjAwLVZG WS1TKSAoNykuICBDb250cmFyeSB0byB0aGUgdXN1YWwgb25lLXdheSBhdXRoZW50aWNhdGlvbg0K PiAgICAgICAoZS5nLiwgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBvciBQT1AgQVBPUCBhdXRo ZW50aWNhdGlvbg0KPiAgICAgICBbUkZDMTkzOV0pLCB0aGlzIG1lc3NhZ2UgYWxzbyBjb250YWlu cyBhIHNlcnZlci1zaWRlDQo+ICAgICAgIGF1dGhlbnRpY2F0aW9uIHZlcmlmaWNhdGlvbiB2YWx1 ZS4NCj4NCj4gICAgICAgV2hlbiB0aGUgY2xpZW50J3MgdmVyaWZpY2F0aW9uIHZhbHVlIGlzIGlu Y29ycmVjdCAoZS5nLiwgYmVjYXVzZQ0KPiAgICAgICB0aGUgdXNlci1zdXBwbGllZCBwYXNzd29y ZCB3YXMgaW5jb3JyZWN0KSwgdGhlIHNlcnZlciB3aWxsIHJlc3BvbmQNCj4gICAgICAgd2l0aCB0 aGUgNDAxLUlOSVQgbWVzc2FnZSAodGhlIHNhbWUgb25lIGFzIHVzZWQgaW4gKDIpKSBpbnN0ZWFk Lg0KPg0KPiA0LiBUaGlzIGxhc3Qgc2VjdGlvbiBzaG91bGQgc3BlY2lmeSB0aGF0IHRoZSBleHRl bnNpdmUtdG9rZW4NCj4gaW5kaWNhdGluZyBhbiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlIG11c3Qg YmUgaW5jbHVkZWQuICBJIHdvdWxkIGFsc28NCj4gcmVjb21tZW5kIHRoYXQgdGhpcyBpbmZvcm1h dGlvbiBiZSBsb2dnZWQgYW5kIGhhdmUgdGhhdCBzdGF0ZWQgaW4gdGhpcw0KPiBkcmFmdC4gIFNp bmNlIHdlIGFyZSBwdXNoaW5nIGZvciBwcm90b2NvbHMgdG8gYmUgZW5jcnlwdGVkLCB0aGUgdXNl IG9mDQo+IHNuaWZmZXJzIHRvIGRldGVjdCBlcnJvcnMgd2lsbCBjb250aW51ZSB0byBmYWxsIG9m ZiBhbmQgcGVvcGxlIHdpbGwNCj4gbmVlZCB0byByZWx5IG9uIGxvZ3MgbW9yZS4gIEkgdGhpbmsg aXQgd291bGQgYmUgbW9yZSBoZWxwZnVsIHRvIGhhdmUNCj4gYW4gYWNjdXJhdGUgbG9nIHRoYXQg cmVzcG9uZHMgc2F5aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBmYWlsZWQNCj4gKHVzZXIvcGFzc3dv cmQgaWYgeW91IGRvbid0IHdhbnQgdG8gc2F5IHdoaWNoKS4gIEVuY291cmFnaW5nIHJpY2hlcg0K PiBsb2dzIHdpbGwgYmUgbW9yZSBoZWxwZnVsIGdvaW5nIGZvcndhcmQuDQo+IC0tLS0tDQoNClRo YW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBzdWdnZXN0aW9uLiBXZSBpbmNvcnBvcmF0ZWQgdGhl IGlkZWEuDQoNCj4gSW4gU2VjdGlvbiA3LCBqdXN0IHRvIG1ha2Ugc3VyZSBJIGFtIHJlYWRpbmcg dGhpcyBjb3JyZWN0bHk6DQo+DQo+IFRoZSB2YWxpZCB0b2tlbnMgZm9yIHRoZSB2YWxpZGF0aW9u IHBhcmFtZXRlciBhbmQgY29ycmVzcG9uZGluZw0KPiAgICB2YWx1ZXMgb2YgdmggYXJlIGFzIGZv bGxvd3M6DQo+DQo+ICAgIGhvc3Q6ICAgICAgICAgIGhvc3QtbmFtZSB2YWxpZGF0aW9uOiBUaGUg dmFsdWUgdmggd2lsbCBiZSB0aGUgQVNDSUkNCj4gICAgICAgICAgICAgICAgICAgc3RyaW5nIGlu IHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KPiAgICAgICAgICAgICAgICAgICAiPHNjaGVtZT46Ly88 aG9zdD46PHBvcnQ+Iiwgd2hlcmUgPHNjaGVtZT4sIDxob3N0PiwNCj4gICAgICAgICAgICAgICAg ICAgYW5kIDxwb3J0PiBhcmUgdGhlIFVSSSBjb21wb25lbnRzIGNvcnJlc3BvbmRpbmcgdG8gdGhl DQo+ICAgICAgICAgICAgICAgICAgIGN1cnJlbnRseSBhY2Nlc3NpbmcgcmVzb3VyY2UuDQo+DQo+ IDUuIEJ5ICJjdXJyZW50bHkgYWNjZXNzaW5nIHJlc291cmNlIiwgeW91IG1lYW4gdGhlIHNvdXJj ZSBzeXN0ZW0sDQo+IGNvcnJlY3Q/ICBJdCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVwaHJhc2UgdGhh dCBzbyBpdCBpcyBjbGVhciBzaW5jZQ0KPiB0aGlzIGlzIGltcG9ydGFudCB0byBkZXZlbG9wZXJz Lg0KPiAtLS0tLQ0KDQpXZSByZXBocmFzZWQgaXQgYXMgInNlcnZlci1zaWRlIHJlc291cmNlIi4N Ckl0J3MgYWN0dWFsbHkgInRoZSBVUkwiIGJlaW5nIGFjY2Vzc2VkLCBpbiBzaG9ydCBhbmQgaW5m b3JtYWxseS4NCklmIHRoZXJlIGlzIGJldHRlciBwaHJhc2luZywgd2UnbGwgbG9vayBmb3IgaXQg ZnVydGhlci4NCg0KDQo+IDYuIEluIFNlY3Rpb24gOCwgaXQgaXMgdGhlIHJlYXNvbiBwYXJhbWV0 ZXIgb2YgdGhlIElOSVQgdGhhdCBsZXRzIHlvdQ0KPiBrbm93IGlmIHQgaXMgJ3ZhbGlkJywgY29y cmVjdD8NCj4gICAgQXV0aGVudGljYXRpb24taW5pdGlhbGl6aW5nIG1lc3NhZ2VzIHdpdGggdGhl DQo+ICAgIE9wdGlvbmFsLVdXVy1BdXRoZW50aWNhdGUgaGVhZGVyIGFyZSB1c2VkIG9ubHkgd2hl cmUgdGhlIDQwMS1JTklUDQo+ICAgIHJlc3BvbnNlIGlzIHZhbGlkLiAgSXQgd2lsbCBub3QgcmVw bGFjZSBvdGhlciA0MDEtdHlwZSBtZXNzYWdlcyBzdWNoDQo+ICAgIGFzIDQwMS1TVEFMRSBhbmQg NDAxLUtFWC1TMS4NCj4NCj4gSSB0aGluayBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGV4cGxpY2l0 bHkgc3RhdGUgd2hhdCBpcyBhIHZhbGlkDQo+IHJlc3BvbnNlIHVubGVzcyB0aGF0IGlzIGRlZmlu ZWQgYWxyZWFkeSBhbmQgSSBtaXNzZWQgaXQ/ICBJIHRoaW5rIGl0DQo+IGRlcGVuZHMgb24gdGhl IHRva2VuIG9yIGV4dGVuc2l2ZSB0b2tlbiBzZXQgaW4gdGhlIHJlYXNvbiBwYXJhbWV0ZXIgb2YN Cj4gdGhlIElOSVQgbWVzc2FnZS4NCg0KV2UgY2xhcmlmaWVkIHRoYXQgdGhlIHJlYXNvbiB3aWxs IGJlICJpbml0aWFsIiAobW9kdWxvIGZ1dHVyZSBleHRlbnNpb25zKS4NCg0KPiAtLS0tDQo+IDcu IEluIHNlY3Rpb24gMTAuMSwgaWYgeW91IGNoYW5nZSAibm9ybWFsIHJlc3BvbnNlcyIgdG8gIm5v cm1hbA0KPiByZXNwb25zZSIsIGl0IGlzIGVhc2llciB0byBmaXggdGhlIGdyYW1tYXIgaW4gdGhl IGZvbGxvd2luZyBzZW50ZW5jZXM6DQo+DQo+ICAgIFRoaXMgYWxzbw0KPiAgICBob2xkcyB0cnVl IGZvciB0aGUgcmVjZXB0aW9uIG9mICJub3JtYWwgcmVzcG9uc2VzIiAocmVzcG9uc2VzIHdoaWNo DQo+ICAgIGRvIG5vdCBjb250YWluIE11dHVhbCBhdXRoZW50aWNhdGlvbi1yZWxhdGVkIGhlYWRl cnMpIGZyb20gSFRUUA0KPiAgICBzZXJ2ZXJzLg0KPiBjaGFuZ2UgdG86DQo+ICAgIFRoaXMgYWxz bw0KPiAgICBob2xkcyB0cnVlIGZvciB0aGUgcmVjZXB0aW9uIG9mIGEgIm5vcm1hbCByZXNwb25z ZSIgKHJlc3BvbnNlcyB3aGljaA0KPiAgICBkbyBub3QgY29udGFpbiBNdXR1YWwgYXV0aGVudGlj YXRpb24tcmVsYXRlZCBoZWFkZXJzKSBmcm9tIEhUVFANCj4gICAgc2VydmVycy4NCj4NCj4gZnJv bToNCj4gICAgICAgQW55IGtpbmRzIG9mICJub3JtYWwgcmVzcG9uc2VzIiBNVVNUIG9ubHkgYmUg YWNjZXB0ZWQgZm9yIHRoZSB2ZXJ5DQo+ICAgICAgIGZpcnN0IHJlcXVlc3QgaW4gdGhlIHNlcXVl bmNlLiAgQW55ICJub3JtYWwgcmVzcG9uc2VzIiByZXR1cm5lZA0KPiAgICAgICBmb3IgdGhlIHNl Y29uZCBvciBsYXRlciByZXF1ZXN0cyBpbiB0aGUgc2VxdWVuY2UgU0hBTEwgYmUNCj4gICAgICAg Y29uc2lkZXJlZCBpbnZhbGlkLg0KPiBjaGFuZ2UgdG86DQo+ICAgICAgIEFueSBraW5kIG9mICJu b3JtYWwgcmVzcG9uc2UiIE1VU1Qgb25seSBiZSBhY2NlcHRlZCBmb3IgdGhlIHZlcnkNCj4gICAg ICAgZmlyc3QgcmVxdWVzdCBpbiB0aGUgc2VxdWVuY2UuICBBbnkgIm5vcm1hbCByZXNwb25zZSIg cmV0dXJuZWQNCj4gICAgICAgZm9yIHRoZSBzZWNvbmQgb3IgbGF0ZXIgcmVxdWVzdCBpbiB0aGUg c2VxdWVuY2UgU0hBTEwgYmUNCj4gICAgICAgY29uc2lkZXJlZCBpbnZhbGlkLg0KDQo+IDguIFNl Y3Rpb24gMTAuMSwgcGxlYXNlIGNvbnNpZGVyIHJld29yZGluZyB0aGUgZm9sbG93aW5nIHNlbnRl bmNlcyB0bw0KPiBtYWtlIGl0IGVhc2llciB0byByZWFkOg0KPiAgICBvICBJbiB0aGUgc2FtZSBw cmluY2lwbGUsIGFueSByZXNwb25zZXMgd2hpY2ggcmVmZXIgdG8gb3IgcmVxdWVzdA0KPiAgICAg ICBjaGFuZ2luZyB0byBhbiBhdXRoZW50aWNhdGlvbiByZWFsbSBkaWZmZXJlbnQgZnJvbSB0aGUg Y2xpZW50J3MNCj4gICAgICAgcmVxdWVzdCBNVVNUIG9ubHkgYmUgYWNjZXB0ZWQgZm9yIHRoZSB2 ZXJ5IGZpcnN0IHJlcXVlc3QgaW4gdGhlDQo+ICAgICAgIHNlcXVlbmNlLiAgQW55IGtpbmQgb2Yg cmVzcG9uc2VzIHJlZmVycmluZyB0byBkaWZmZXJlbnQgcmVhbG1zDQo+ICAgICAgIHdoaWNoIGFy ZSByZXR1cm5lZCBmb3IgdGhlIHNlY29uZCBvciBsYXRlciByZXF1ZXN0cyBpbiB0aGUNCj4gICAg ICAgc2VxdWVuY2UgU0hBTEwgYmUgY29uc2lkZXJlZCBpbnZhbGlkLg0KPiAtLS0tLQ0KPiA5LiBJ biBzZWN0aW9uIDE3LjIsIGl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gaW5jbHVkZSBhIHJlZmVyZW5j ZSB0byB0aGUNCj4gVExTIDEuMiBCQ1AsIFJGQzc1MjUuICBUaGUgYnVsbGV0IG1pZ2h0IHNheSBz b21ldGhpbmcgbGlrZSwgd2hlbiBUTFMNCj4gMS4yIGlzIHVzZWQsIGZvbGxvdyBiZXN0IHByYWN0 aWNlcyBpbiBSRkM3NTI1Lg0KPiAtLS0tLQ0KDQpGb3IgNy05OiBUaGFuayB5b3UgdmVyeSBtdWNo LiBXZSBkaWQuDQoNCj4gMTAuIFNlY3Rpb24gMTcuMyBpcyB0aGUgZmlyc3QgcGxhY2UgSSBzZWUg YSBjbGVhciBtb3RpdmF0aW9uIGZvciB0aGlzDQo+IHByb3RvY29sLiAgSXQgbWlnaHQgaGVscCB0 byBoYXZlIHRoaXMgc3RhdGVkIGluIHRoZSBpbnRyb2R1Y3Rpb24uDQo+IEFsdGhvdWdoIHRoZSBw b2ludHMgYWJvdXQgcGFzc3dvcmQgYXR0YWNrcyBpbiBzZWN0aW9uIDE3LjIgbGVhdmUgbWUNCj4g cXVlc3Rpb25pbmcgaG93IG11Y2ggb2YgYW4gaW1wcm92ZW1lbnQgdGhpcyByZWFsbHkgaXMuICBI b3cgbXVjaA0KPiBhbmFseXNpcyB3YXMgZG9uZSBvbiB0aGlzIG5ldyBtZXRob2Q/IEkga25vdyB0 aGUgZHJhZnRzIGhhdmUgYmVlbg0KPiBhcm91bmQgZm9yIGEgd2hpbGUuICBJJ2QgaGF2ZSB0byB0 YWtlIGFub3RoZXIgcGFzcyBhdCB0aGUgZG9jdW1lbnRzIHRvDQo+IGRpZyBkZWVwZXIsIGJ1dCB3 b3VsZCBsaWtlIHRvIGtub3cgaWYgdGhpcyBhbmFseXNpcyB3YXMgZG9uZS4gIENhbiB5b3UNCj4g bWFrZSB0aGUgc3RhdGVtZW50IHRoYXQgdGhpcyBpcyBtb3JlIHNlY3VyZT8gIFRoZSBtb3RpdmF0 aW9uIGZvciBIT0JBDQo+IHdhcyBjbGVhciAtIGdldHRpbmcgcmlkIG9mIHRoZSB1c2Ugb2YgcGFz c3dvcmRzLg0KPg0KPiBQYXNzd29yZHMgYXJlIG5vdCBzZW50IGluIHRoZSBjbGVhciwgYnV0IHRo aXMgaXNuJ3Qgc3RhdGVkIGluIGENCj4gbW90aXZhdGlvbiBzZWN0aW9uLiAgSXQganVzdCBpcyBw YXJ0IG9mIHRoZSBwcm90b2NvbCBhbmQgbWVudGlvbmVkIGF0DQo+IHRoZSBlbmQgb2Ygc2VjdGlv biAxNy41LiAgSXQgbWlnaHQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIHRoaXMgaW4gdGhlDQo+IGlu dHJvZHVjdGlvbiBhcyB3ZWxsIGluIGEgbW90aXZhdGlvbiBwYXJhZ3JhcGguICBUaGUgYWJzdHJh Y3Qgc2F5aW5nDQo+IHRoYXQsICJzZXJ2ZXIgdHJ1bHkga25vd3MgdGhlIHVzZXIncw0KPiBlbmNy eXB0ZWQgcGFzc3dvcmQiIGlzbid0IHRoZSBzYW1lIGFzIHNheWluZyB0aGF0IHRoZSBwYXNzd29y ZCBpcw0KPiBlbmNyeXB0ZWQgb24gdGhlIHdpcmUgYW5kIGRvZXNuJ3QgcmVseSBvbiB0cmFuc3Bv cnQgZW5jcnlwdGlvbi4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHByZWNpb3VzIHN1 Z2dlc3Rpb24uIEkgYWRkZWQgc29tZSB0ZXh0cw0KdG8gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9u Lg0KRm9yIHNlY3VyaXR5LCBzaW1wbHkgc2FpZCwgbm8gb2ZmLWxpbmUgYXR0YWNrIHdpbGwgZXZl ciBiZSBwb3NzaWJsZQ0KdXNpbmcgZGF0YSByZXRyaWV2ZWQgZnJvbSBlYXZlc2Ryb3BwZWQvbWFu LWluLXRoZS1taWRkbGUgdHJhZmZpY3MuDQpXZSBkaXNjdXNzZWQgc29tZSBkZXRhaWwgb24gb24t bGluZSBhdHRhY2tzIGluIHRoaXMgc2VjdGlvbiwNCmJ1dCBpdCdzIG11Y2ggaGFyZGVyIHRoYW4g b2ZmLWxpbmUgYXR0YWNrcyBmb3IgYXR0YWNrZXJzLA0KYW5kIG11Y2ggZWFzaWVyIGZvciBzZXJ2 ZXJzIHRvIGRldGVjdCBhbmQgcGVyZm9ybSBjb3VudGVybWVhc3VyZXMuDQooT2YgY291cnNlLCBp dCdzIGEgZ2lmdCBmcm9tIHRoZSBQQUtFLikNCg0KPiAtLS0tLQ0KPiAxMS4gU2VjdGlvbiAxNy4z LiAgSSdtIG5vdCBjbGVhciBvbiB0aGlzIHNlbnRlbmNlIGluIHRoZSBsYXN0IHBhcmFncmFwaDoN Cj4gICAgT2YgY291cnNlLCBpbiBzdWNoIGNhc2VzLCB0aGUgdXNlciBpbnRlcmZhY2VzIGZvciBh c2tpbmcgcGFzc3dvcmRzDQo+ICAgIGZvciB0aGlzIGF1dGhlbnRpY2F0aW9uIHNoYWxsIGJlIGNs ZWFybHkgaWRlbnRpZmlhYmxlIGFnYWluc3QNCj4gICAgaW1pdGF0aW9uIGJ5IG90aGVyIGluc2Vj dXJlIHBhc3N3b3JkIGlucHV0IGZpZWxkcyAoc3VjaCBhcyBmb3JtcykuDQo+IENvbW1vbiBhdHRh Y2tzIG9mIHRoaXMgbmF0dXJlIHdvdWxkIGJlIHRvIGRpcmVjdCB1c2VycyB0byBhIGZvcm0gdGhh dA0KPiBpc24ndCB0aGUgcmVhbCBmb3JtLiAgSXMgaXQgdGhlIG11dHVhbCBhdXRoZW50aWNhdGlv biB0aGF0IGhlbHBzIGhlcmU/DQo+ICBJZiBzbywgZXhwbGFpbiBob3cuICBIb3cgaXMgaXQgY2xl YXJseSBpZGVudGlmaWFibGUgYWdhaW5zdA0KPiBpbWl0YXRpb24/DQoNCldoYXQgd2UgY29uc2lk ZXJlZCBhbmQgaW1wbGVtZW50ZWQgaXMgYSBhdXRoZW50aWNhdGlvbiBpbnRlcmZhY2UNCmluIGJy b3dzZXItY2hyb21lIChhcm91bmQgdGhlIGFkZHJlc3MgYmFyKSwgbm90IHdpdGhpbiB0aGUgbWFp biBjb250ZW50IGFyZWEuDQpJdCdzIGNvbW1vbiBmb3IgYnJvd3NlcnMgdG8gaGF2ZSBzb21lICJz ZWN1cmUgVUkgYXJlYSIgbm90IHBvc3NpYmxlIHRvDQpjaXJjdW12ZW50IGZyb20gdGhlIHdlYiBj b250ZW50IGl0c2VsZiwgd2hvc2UgZXhhbXBsZXMgaW5jbHVkZXMgYWRkcmVzcyBiYXIsDQphbmQg cGFkbG9jayBpY29ucywgYXMgd2VsbCBhcyB0aGUgInRoZSBvdGhlciBhcmVhIiBjb250cm9sbGVk IGJ5IHRoZQ0Kd2ViIHBhZ2UgY29udGVudHMuICBXZSBpbnRlbmRlZCB0byB1c2UgdGhlIGZvcm1l ciBhcmVhIGZvciBzZWN1cmUgYXV0aGVudGljYXRpb24uDQpIb3dldmVyLCB3ZSBkaWQgbm90IHdh bnQgdG8gaW5jbHVkZSBhbnkgImluc3RydWN0aW9ucyIgb24gdGhlIHVzZXIgaW50ZXJmYWNlcw0K b2Ygd2ViIGJyb3dzZXJzIChmZWFyaW5nIHRoYXQgaXQgd2lsbCBiZWNvbWUgIm91dC1vZi1zY29w ZSIgb2YgdGhlIGRyYWZ0KSwgc28NCndlIHVzZWQgc29tZSAiYWJzdHJhY3QiIHJlcXVpcmVtZW50 IGhlcmUuDQpJZiB5b3UgaGF2ZSBtb3JlIHN1Z2dlc3Rpb24gb24gInRoZSBleHRlbnQgd2Ugc2hv dWxkIHNheSBmb3IgdXNlciBpbnRlcmZhY2VzIiwNCml0J3MgcmVhbGx5IGFwcHJlY2lhdGVkLg0K DQotLQ0KWXV0YWthIE9JV0EsIFBoLkQuICAgICAgICBMZWFkZXIsIEN5YmVyIFBoeXNpY2FsIEFy Y2hpdGVjdHVyZSBSZXNlYXJjaCBHcm91cA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJbmZvcm1hdGlvbiBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZQ0KICAgICBOYXRp b25hbCBJbnN0aXR1dGUgb2YgQWR2YW5jZWQgSW5kdXN0cmlhbCBTY2llbmNlIGFuZCBUZWNobm9s b2d5IChBSVNUKQ0KICAgICAgICAgICAgICAgICAgICAgICBNYWlsIGFkZHJlc3NlczogPHkub2l3 YUBhaXN0LmdvLmpwPG1haWx0bzp5Lm9pd2FAYWlzdC5nby5qcD4+LCA8eXV0YWthQG9pd2EuanA8 bWFpbHRvOnl1dGFrYUBvaXdhLmpwPj4NCk9wZW5QR1A6IGlkWzQ0MDU0NkI1XSBmcFs3QzlGIDcy M0EgNzU1OSAzMjQ2IDIyOUQgIDMxMzkgODY3NyA5QkQyIDQ0MDUgNDZCNV0NCg0KDQoNCi0tDQoN CkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRo bGVlbg0K --_000_TY1PR01MB0588C4D767B3FF7D81546321A0AD0TY1PR01MB0588jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDvvK3vvLMg44K044K344OD44KvIjsN CglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQO+8re+8syDvvLDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1 IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfjg4Pj gq8iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJ e21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLjE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjk5LjI1cHQgMzAuMG1tIDMwLjBtbSAzMC4wbW07 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdwdCw1Ljg1cHQsLjdwdCIg Lz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZWFy IEthdGhsZWVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgcmVnaXN0cmllcyByZXF1aXJlIGV4cGVydCByZXZp ZXcgcHJvY2VzcyBhcyBkZWZpbmVkIGluIFJGQzUyMjYuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+KGEgY29uc2Vuc3VzIG9uIFdHIGRpc2N1c3Npb25zLik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGUgZXhpc3RlbmNlIG9mIHNwZWNpZmljYXRpb24gaXMgbm90IGV4cGxpY2l0 bHkgbmVlZGVkIGlmIHRoZSB0ZXh0IG1ha2VzIGNvbmZ1c2lvbnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSBhc3N1bWUgdGhhdCBpdCB3aWxsIGJlIGFueXdheSByZXF1aXJlZCAoaW4g bW9zdCBjYXNlcykgZm9yIGV4cGVydCByZXZpZXcgcHJvY2Vzc2VzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5ZdXRha2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpq dXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPll1 dGFrYSBPSVdBLCBQaC5ELiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMZWFk ZXIsIEN5YmVyIFBoeXNpY2FsIEFyY2hpdGVjdHVyZSBSZXNlYXJjaCBHcm91cDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3Rp Znk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luZm9ybWF0aW9u IFRlY2hub2xvZ3kgUmVzZWFyY2ggSW5zdGl0dXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTmF0aW9uYWwgSW5zdGl0dXRlIG9mIEFkdmFuY2VkIEluZHVz dHJpYWwgU2NpZW5jZSBhbmQgVGVjaG5vbG9neSAoQUlTVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBNYWlsIGFkZHJlc3NlczogJmx0O3kub2l3YUBhaXN0LmdvLmpw Jmd0OywgJmx0O3l1dGFrYUBvaXdhLmpwJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Omlu dGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ T3BlblBHUDogaWRbNDQwNTQ2QjVdIGZwWzdDOUYgNzIzQSA3NTU5IDMyNDYgMjI5RCZuYnNwOyAz MTM5IDg2NzcgOUJEMiA0NDA1IDQ2QjVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDI4 LCAyMDE2IDc6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+5aSn5bKp5a+bPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiAmbHQ7eS5vaXdhQGFpc3QuZ28uanAmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBodHRwLWF1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtodHRwLWF1dGhdIEFEIHJldmlldyBvZiBk cmFmdC1pZXRmLWh0dHBhdXRoLW11dHVhbC0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5KdXN0IGEgcXVpY2sgcXVlc3Rpb24gYXMgSSBmaWxsIG91dCB0aGUgYmFsbG90IHRleHQg Zm9yIG5leHQgd2VlaydzIHRlbGVjaGF0LiZuYnNwOyBGb3IgdGhlIElBTkEgc2VjdGlvbiwgYXMg SSByZWFkIGl0IGJvdGggcmVnaXN0cmllcyByZXF1aXJlIGV4cGVydCByZXZpZXcgYW5kIGEgc3Bl Y2lmaWNhdGlvbiwgaXMgdGhhdCByaWdodD8mbmJzcDsgSSdtIGFza2luZyBhcyB0aGUgbGFuZ3Vh Z2UgY291bGQNCiBiZSBjbGVhcmVyIGFuZCBJIG5lZWQgdG8gbWFrZSBzdXJlIGl0IGlzIGNsZWFy IGluIHRoZSBiYWxsb3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkthdGhsZWVuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIE9jdCAxMSwg MjAxNiBhdCAxMjoxMiBQTSwgS2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9Im1haWx0bzpr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MG1tIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+RGVhciBZdXRha2EsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSBhbSBzb3JyeSBmb3IgbXkgZGVsYXkgaW4gcmVzcG9uc2UuJm5ic3A7IFRoZSB1cGRh dGVzIGxvb2sgdmVyeSBnb29kIGFuZCBJIHRoaW5rIHRoZSB1cGRhdGVkIGludHJvZHVjdGlvbiBp cyBoZWxwZnVsLiZuYnNwOyBJIHdpbGwgcHJvZ3Jlc3MgdGhlIGRyYWZ0IGludG8gSUVURiBsYXN0 IGNhbGwsIGJ1dCBhbiBlZGl0IHBhc3Mgb24gdGhlIG5ldyB0ZXh0IGlzIHJlcXVpcmVkIGFzIHRo ZXJlIGFyZQ0KIHNvbWUgZ3JhbW1hciBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHNvLCB5b3UgaGFkIHJlc3BvbmRlZCBzYXlpbmcgeW91 IHdvdWxkIGFkZCBzb21ldGhpbmcgYWJvdXQgbG9nZ2luZyBhbmQgSSBhbSBub3QgYWJsZSB0byBm aW5kIHRoYXQgdGV4dCBpbiB0aGUgZGlmZnMgZnJvbSAtMDguJm5ic3A7IFdhcyBpdCBhZGRlZD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlv dSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gU3VuLCBPY3QgOSwgMjAx NiBhdCAxMjoyNCBBTSwgPC9zcGFuPuWkp+WyqeWvmzxzcGFuIGxhbmc9IkVOLVVTIj4gJmx0Ozxh IGhyZWY9Im1haWx0bzp5Lm9pd2FAYWlzdC5nby5qcCIgdGFyZ2V0PSJfYmxhbmsiPnkub2l3YUBh aXN0LmdvLmpwPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1t Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIEthdGhsZWVu LDxicj4NCjxicj4NCkkgaGF2ZSBub3Qgc2VlbiBhbnkgcmVzcG9uc2UgdG8gdGhlIHByZXZpb3Vz IG1haWwuPGJyPg0KSWYgd2UgaGF2ZSBhbnkgcHJvYmxlbXMgdG8gc29sdmUgb3IgYWN0aW9ucyB0 byB0YWtlLDxicj4NCnBsZWFzZSBsZXQgbWUga25vdy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K PGJyPg0KWXV0YWthPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCjwvc3Bhbj7lt67lh7rkuro8c3BhbiBsYW5nPSJFTi1VUyI+OiBZdXRha2EgT0lXQSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnkub2l3YUBhaXN0LmdvLmpwIiB0YXJnZXQ9Il9ibGFuayI+eS5v aXdhQGFpc3QuZ28uanA8L2E+Jmd0Ozxicj4NCjwvc3Bhbj7pgIHkv6Hml6XmmYI8c3BhbiBsYW5n PSJFTi1VUyI+OiAyMDE2PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuaciDxz cGFuIGxhbmc9IkVOLVVTIj4yMjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDIxOjQ0OjM5 PGJyPg0KPC9zcGFuPuWum+WFiDxzcGFuIGxhbmc9IkVOLVVTIj46IEthdGhsZWVuIE1vcmlhcnR5 OyA8YSBocmVmPSJtYWlsdG86aHR0cC1hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwLWF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPuS7tuWQjTxzcGFuIGxhbmc9IkVOLVVT Ij46IFJlOiBbaHR0cC1hdXRoXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1odHRwYXV0aC1tdXR1 YWwtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpEZWFyIEthdGhsZWVuLDxicj4NCjxicj4N CkknbSBzb3JyeSBJJ3ZlIHVwZGF0ZWQgdGhlIGRyYWZ0IGFjY29yZGluZyB0byB5b3VyIG1haWws PGJyPg0KYnV0IG5vdCByZXNwb25kZWQgdG8gdGhlIG1haWwgaXRzZWxmLjxicj4NCiMgYW5kIEkg Zm91bmQgYSBmZXcgdHlwbyB0byBzdWJtaXQgdGhlIGRyYWZ0IHJldmlzaW9uIHZlcnkgc29vbi48 YnI+DQo8YnI+DQpPbiAyMDE2LzA4LzEyIDExOjE4LCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZTo8 YnI+DQomZ3Q7IEhlbGxvLDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rIHlvdSBmb3IgeW91ciB3 b3JrIG9uIGRyYWZ0LWlldGYtaHR0cGF1dGgtbXV0dWFsLTA4LiZuYnNwOyBJIHdpbGwgdHJ5PGJy Pg0KJmd0OyB0byBnZXQgdGhyb3VnaCBteSBBRCByZXZpZXcgb2YgdGhlIGFjY29tcGFueWluZyBk cmFmdCB0b21vcnJvdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHJlYWQgdGhyb3VnaCB0aGUgZHJh ZnQgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IC0tLS0tPGJyPg0KJmd0OyBTZWN0aW9uIDIuMSwgaW4gdGhlIGZvbGxvd2luZyB0 ZXh0Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IG8mbmJzcDsgQXV0aGVudGljYXRlZCBrZXkg ZXhjaGFuZ2UgbWVzc2FnZXM6IHVzZWQgYnkgYm90aCBwZWVycyB0byBwZXJmb3JtPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2F1dGhlbnRpY2F0aW9uIGFuZCB0aGUgc2hhcmlu ZyBvZiBhIGNyeXB0b2dyYXBoaWMgc2VjcmV0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7KiZuYnNwOyByZXEtS0VYLUMxIG1lc3NhZ2U6IGEgbWVzc2FnZSBz ZW50IGZyb20gdGhlIGNsaWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyombmJzcDsgNDAxLUtFWC1TMSBtZXNzYWdlOiBhIG1lc3NhZ2Ugc2VudCBmcm9t IHRoZSBzZXJ2ZXIgaW4gcmVzcG9uc2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0byBhIHJlcS1LRVgtQzEgbWVzc2FnZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAx LiBXaGF0IGRvZXMgdGhlIHJlc3BvbnNlIG1lYW4/Jm5ic3A7IElzIHRoZXJlIGEgcGFzcy9mYWls IG1lc3NhZ2UgaW4gdGhlPGJyPg0KJmd0OyByZXNwb25zZSBvciBpcyB0aGlzIGp1c3QgYW4gYWNr IHRoYXQgdGhlIG1lc3NhZ2Ugd2FzIHJlY2VpdmVkIGJ5IHRoZTxicj4NCiZndDsgc2VydmVyIHRv IHRoZSBjbGllbnQ/PGJyPg0KPGJyPg0KNDAxLUtFWC1TMSB3aWxsIGJlIGFsbW9zdCB1bmNvbmRp dGlvbmFsbHkgc2VudCBhcyBhIHJlc3BvbnNlLDxicj4NCmFzIGF1dGhlbnRpY2F0aW9uIGlzIG9u LWdvaW5nLCBub3QgZmluaXNoZWQgeWV0Ljxicj4NClRoZXJlIG1heSBiZSBhICZxdW90O25vLWdv JnF1b3Q7IGZvciBmYXRhbCBlcnJvciBjYXNlIChlLmcuIHBhcmFtZXRlciBtaXNtYXRjaCksIGhv d2V2ZXIuPGJyPg0KPGJyPg0KJmd0OyBUaGVuIGluIHRoZSBmb2xsb3dpbmc6PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyombmJzcDsgMjAwLVZGWS1TIG1lc3NhZ2U6IGEgY2xp ZW50LWF1dGhlbnRpY2F0aW9uIHN1Y2Nlc3NmdWwgcmVzcG9uc2U8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1c2VkIGJ5IHRoZSBzZXJ2ZXIsIHdoaWNoIGFsc28g c2ltdWx0YW5lb3VzbHkgYXNzZXJ0cyB0byB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBjbGllbnQgdGhhdCB0aGUgc2VydmVyIGlzIGF1dGhlbnRpYy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyAyLiBNYXliZSB0aGlzIHdpbGwgYmUgY2xlYXIgYXMgSSByZWFkIGZ1 cnRoZXIgdGhyb3VnaCB0aGUgZHJhZnQsIGJ1dDxicj4NCiZndDsgdGhhdCBzZWVtcyBsaWtlIGEg bG90IHRvIGFzc2VydCBhdCBvbmNlLiZuYnNwOyBUaGlzIG5vdGUgaXMgYSBwbGFjZWhvbGRlcjxi cj4NCiZndDsgZm9yIG1lIGluIGNhc2UgSSBkbyd0IGZlZWwgbGlrZSB0aGVyZSBpcyBhbiBhZGVx dWF0ZSBhbnN3ZXIgd2hlbiBJIGdldDxicj4NCiZndDsgZGVlcGVyIGludG8gdGhlIGRyYWZ0Ljxi cj4NCjxicj4NCldlIHRyaWVkIHRvIG1ha2UgaXQgbW9yZSBjbGVhciBpbiB0aGUgcmV2aXNlZCBk cmFmdC48YnI+DQo8YnI+DQomZ3Q7IFNlY29uZCBidWxsZXQgb24gcGFnZSA3Ojxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7IG8mbmJzcDsgQXQgdGhpcyBwb2ludCAoNSksIGJvdGggcGVlcnMgY2Fs Y3VsYXRlIGEgc2hhcmVkICZxdW90O3Nlc3Npb24gc2VjcmV0JnF1b3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzaW5nIHRoZSBleGNoYW5nZWQgdmFsdWVzIGluIHRoZSBr ZXkgZXhjaGFuZ2UgbWVzc2FnZXMuJm5ic3A7IE9ubHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7d2hlbiBib3RoIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgaGF2ZSB1c2Vk IHNlY3JldCBjcmVkZW50aWFsczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtn ZW5lcmF0ZWQgZnJvbSB0aGUgc2FtZSBwYXNzd29yZCB3aWxsIHRoZSBzZXNzaW9uIHNlY3JldCB2 YWx1ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWF0Y2guJm5ic3A7IFRo aXMgc2Vzc2lvbiBzZWNyZXQgd2lsbCBiZSB1c2VkIGZvciBhY2Nlc3MgYXV0aGVudGljYXRpb248 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2YgZXZlcnkgaW5kaXZpZHVhbCBu b3JtYWwgYWZ0ZXIgdGhpcyBwb2ludC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAzLiBJIHRoaW5rIGEg d29yZCBtYXkgYmUgbWlzc2luZyBpbiB0aGUgbGFzdCBzZW50ZW5jZSwgY2FuIHlvdTxicj4NCiZn dDsgcmVwaHJhc2UgaXQ/Jm5ic3A7IEknbSBub3QgYWJsZSB0byBwYXJzZSBpdC48YnI+DQo8YnI+ DQpUaGlzIHNlZW1zIHRvIGJlIHR5cG8sIGFuZCB3ZSBmaXhlZC48YnI+DQo8YnI+DQomZ3Q7IC0t LS0tPGJyPg0KJmd0OyBJbiBhbm90aGVyIGJ1bGxldCBvbiBwYWdlIDc6PGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgbyZuYnNwOyBJZiB0aGUgYXV0aGVudGljYXRpb24gdmVyaWZpY2F0aW9uIHZh bHVlIGZyb20gdGhlIGNsaWVudCB3YXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Y29ycmVjdCwgaXQgbWVhbnMgdGhhdCB0aGUgY2xpZW50IGRlZmluaXRlbHkgb3ducyB0aGUg Y3JlZGVudGlhbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiYXNlZCBvbiB0 aGUgZXhwZWN0ZWQgcGFzc3dvcmQgKGkuZS4sIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb248YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3VjY2VlZGVkKS4mbmJzcDsgVGhlIHNl cnZlciB3aWxsIHJlc3BvbmQgd2l0aCBhIHN1Y2Nlc3NmdWwgbWVzc2FnZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoMjAwLVZGWS1TKSAoNykuJm5ic3A7IENvbnRyYXJ5IHRv IHRoZSB1c3VhbCBvbmUtd2F5IGF1dGhlbnRpY2F0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyhlLmcuLCBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIG9yIFBPUCBBUE9Q IGF1dGhlbnRpY2F0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tSRkMx OTM5XSksIHRoaXMgbWVzc2FnZSBhbHNvIGNvbnRhaW5zIGEgc2VydmVyLXNpZGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXV0aGVudGljYXRpb24gdmVyaWZpY2F0aW9uIHZh bHVlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hlbiB0 aGUgY2xpZW50J3MgdmVyaWZpY2F0aW9uIHZhbHVlIGlzIGluY29ycmVjdCAoZS5nLiwgYmVjYXVz ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgdXNlci1zdXBwbGllZCBw YXNzd29yZCB3YXMgaW5jb3JyZWN0KSwgdGhlIHNlcnZlciB3aWxsIHJlc3BvbmQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2l0aCB0aGUgNDAxLUlOSVQgbWVzc2FnZSAodGhl IHNhbWUgb25lIGFzIHVzZWQgaW4gKDIpKSBpbnN0ZWFkLjxicj4NCiZndDs8YnI+DQomZ3Q7IDQu IFRoaXMgbGFzdCBzZWN0aW9uIHNob3VsZCBzcGVjaWZ5IHRoYXQgdGhlIGV4dGVuc2l2ZS10b2tl bjxicj4NCiZndDsgaW5kaWNhdGluZyBhbiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlIG11c3QgYmUg aW5jbHVkZWQuJm5ic3A7IEkgd291bGQgYWxzbzxicj4NCiZndDsgcmVjb21tZW5kIHRoYXQgdGhp cyBpbmZvcm1hdGlvbiBiZSBsb2dnZWQgYW5kIGhhdmUgdGhhdCBzdGF0ZWQgaW4gdGhpczxicj4N CiZndDsgZHJhZnQuJm5ic3A7IFNpbmNlIHdlIGFyZSBwdXNoaW5nIGZvciBwcm90b2NvbHMgdG8g YmUgZW5jcnlwdGVkLCB0aGUgdXNlIG9mPGJyPg0KJmd0OyBzbmlmZmVycyB0byBkZXRlY3QgZXJy b3JzIHdpbGwgY29udGludWUgdG8gZmFsbCBvZmYgYW5kIHBlb3BsZSB3aWxsPGJyPg0KJmd0OyBu ZWVkIHRvIHJlbHkgb24gbG9ncyBtb3JlLiZuYnNwOyBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUg aGVscGZ1bCB0byBoYXZlPGJyPg0KJmd0OyBhbiBhY2N1cmF0ZSBsb2cgdGhhdCByZXNwb25kcyBz YXlpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIGZhaWxlZDxicj4NCiZndDsgKHVzZXIvcGFzc3dvcmQg aWYgeW91IGRvbid0IHdhbnQgdG8gc2F5IHdoaWNoKS4mbmJzcDsgRW5jb3VyYWdpbmcgcmljaGVy PGJyPg0KJmd0OyBsb2dzIHdpbGwgYmUgbW9yZSBoZWxwZnVsIGdvaW5nIGZvcndhcmQuPGJyPg0K Jmd0OyAtLS0tLTxicj4NCjxicj4NClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBzdWdnZXN0 aW9uLiBXZSBpbmNvcnBvcmF0ZWQgdGhlIGlkZWEuPGJyPg0KPGJyPg0KJmd0OyBJbiBTZWN0aW9u IDcsIGp1c3QgdG8gbWFrZSBzdXJlIEkgYW0gcmVhZGluZyB0aGlzIGNvcnJlY3RseTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgdmFsaWQgdG9rZW5zIGZvciB0aGUgdmFsaWRhdGlvbiBwYXJhbWV0 ZXIgYW5kIGNvcnJlc3BvbmRpbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB2YWx1ZXMgb2Ygdmgg YXJlIGFzIGZvbGxvd3M6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGhvc3Q6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBob3N0LW5hbWUgdmFsaWRhdGlvbjogVGhl IHZhbHVlIHZoIHdpbGwgYmUgdGhlIEFTQ0lJPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0cmluZyBp biB0aGUgZm9sbG93aW5nIGZvcm1hdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7Jmx0O3Nj aGVtZSZndDs6Ly8mbHQ7aG9zdCZndDs6Jmx0O3BvcnQmZ3Q7JnF1b3Q7LCB3aGVyZSAmbHQ7c2No ZW1lJmd0OywgJmx0O2hvc3QmZ3Q7LDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmQgJmx0O3BvcnQm Z3Q7IGFyZSB0aGUgVVJJIGNvbXBvbmVudHMgY29ycmVzcG9uZGluZyB0byB0aGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Y3VycmVudGx5IGFjY2Vzc2luZyByZXNvdXJjZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyA1LiBCeSAmcXVvdDtjdXJyZW50bHkgYWNjZXNzaW5nIHJlc291cmNlJnF1b3Q7LCB5b3Ug bWVhbiB0aGUgc291cmNlIHN5c3RlbSw8YnI+DQomZ3Q7IGNvcnJlY3Q/Jm5ic3A7IEl0IG1pZ2h0 IGJlIGJldHRlciB0byByZXBocmFzZSB0aGF0IHNvIGl0IGlzIGNsZWFyIHNpbmNlPGJyPg0KJmd0 OyB0aGlzIGlzIGltcG9ydGFudCB0byBkZXZlbG9wZXJzLjxicj4NCiZndDsgLS0tLS08YnI+DQo8 YnI+DQpXZSByZXBocmFzZWQgaXQgYXMgJnF1b3Q7c2VydmVyLXNpZGUgcmVzb3VyY2UmcXVvdDsu PGJyPg0KSXQncyBhY3R1YWxseSAmcXVvdDt0aGUgVVJMJnF1b3Q7IGJlaW5nIGFjY2Vzc2VkLCBp biBzaG9ydCBhbmQgaW5mb3JtYWxseS48YnI+DQpJZiB0aGVyZSBpcyBiZXR0ZXIgcGhyYXNpbmcs IHdlJ2xsIGxvb2sgZm9yIGl0IGZ1cnRoZXIuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyA2LiBJbiBT ZWN0aW9uIDgsIGl0IGlzIHRoZSByZWFzb24gcGFyYW1ldGVyIG9mIHRoZSBJTklUIHRoYXQgbGV0 cyB5b3U8YnI+DQomZ3Q7IGtub3cgaWYgdCBpcyAndmFsaWQnLCBjb3JyZWN0Pzxicj4NCiZndDsm bmJzcDsgJm5ic3A7IEF1dGhlbnRpY2F0aW9uLWluaXRpYWxpemluZyBtZXNzYWdlcyB3aXRoIHRo ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE9wdGlvbmFsLVdXVy1BdXRoZW50aWNhdGUgaGVhZGVy IGFyZSB1c2VkIG9ubHkgd2hlcmUgdGhlIDQwMS1JTklUPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg cmVzcG9uc2UgaXMgdmFsaWQuJm5ic3A7IEl0IHdpbGwgbm90IHJlcGxhY2Ugb3RoZXIgNDAxLXR5 cGUgbWVzc2FnZXMgc3VjaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGFzIDQwMS1TVEFMRSBhbmQg NDAxLUtFWC1TMS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gZXhwbGljaXRseSBzdGF0ZSB3aGF0IGlzIGEgdmFsaWQ8YnI+DQomZ3Q7IHJlc3BvbnNl IHVubGVzcyB0aGF0IGlzIGRlZmluZWQgYWxyZWFkeSBhbmQgSSBtaXNzZWQgaXQ/Jm5ic3A7IEkg dGhpbmsgaXQ8YnI+DQomZ3Q7IGRlcGVuZHMgb24gdGhlIHRva2VuIG9yIGV4dGVuc2l2ZSB0b2tl biBzZXQgaW4gdGhlIHJlYXNvbiBwYXJhbWV0ZXIgb2Y8YnI+DQomZ3Q7IHRoZSBJTklUIG1lc3Nh Z2UuPGJyPg0KPGJyPg0KV2UgY2xhcmlmaWVkIHRoYXQgdGhlIHJlYXNvbiB3aWxsIGJlICZxdW90 O2luaXRpYWwmcXVvdDsgKG1vZHVsbyBmdXR1cmUgZXh0ZW5zaW9ucykuPGJyPg0KPGJyPg0KJmd0 OyAtLS0tPGJyPg0KJmd0OyA3LiBJbiBzZWN0aW9uIDEwLjEsIGlmIHlvdSBjaGFuZ2UgJnF1b3Q7 bm9ybWFsIHJlc3BvbnNlcyZxdW90OyB0byAmcXVvdDtub3JtYWw8YnI+DQomZ3Q7IHJlc3BvbnNl JnF1b3Q7LCBpdCBpcyBlYXNpZXIgdG8gZml4IHRoZSBncmFtbWFyIGluIHRoZSBmb2xsb3dpbmcg c2VudGVuY2VzOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIGFsc288YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBob2xkcyB0cnVlIGZvciB0aGUgcmVjZXB0aW9uIG9mICZxdW90 O25vcm1hbCByZXNwb25zZXMmcXVvdDsgKHJlc3BvbnNlcyB3aGljaDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IGRvIG5vdCBjb250YWluIE11dHVhbCBhdXRoZW50aWNhdGlvbi1yZWxhdGVkIGhlYWRl cnMpIGZyb20gSFRUUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHNlcnZlcnMuPGJyPg0KJmd0OyBj aGFuZ2UgdG86PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBhbHNvPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgaG9sZHMgdHJ1ZSBmb3IgdGhlIHJlY2VwdGlvbiBvZiBhICZxdW90O25vcm1hbCBy ZXNwb25zZSZxdW90OyAocmVzcG9uc2VzIHdoaWNoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZG8g bm90IGNvbnRhaW4gTXV0dWFsIGF1dGhlbnRpY2F0aW9uLXJlbGF0ZWQgaGVhZGVycykgZnJvbSBI VFRQPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2VydmVycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBm cm9tOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbnkga2luZHMgb2YgJnF1 b3Q7bm9ybWFsIHJlc3BvbnNlcyZxdW90OyBNVVNUIG9ubHkgYmUgYWNjZXB0ZWQgZm9yIHRoZSB2 ZXJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZpcnN0IHJlcXVlc3QgaW4g dGhlIHNlcXVlbmNlLiZuYnNwOyBBbnkgJnF1b3Q7bm9ybWFsIHJlc3BvbnNlcyZxdW90OyByZXR1 cm5lZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgdGhlIHNlY29uZCBv ciBsYXRlciByZXF1ZXN0cyBpbiB0aGUgc2VxdWVuY2UgU0hBTEwgYmU8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uc2lkZXJlZCBpbnZhbGlkLjxicj4NCiZndDsgY2hhbmdl IHRvOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbnkga2luZCBvZiAmcXVv dDtub3JtYWwgcmVzcG9uc2UmcXVvdDsgTVVTVCBvbmx5IGJlIGFjY2VwdGVkIGZvciB0aGUgdmVy eTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmaXJzdCByZXF1ZXN0IGluIHRo ZSBzZXF1ZW5jZS4mbmJzcDsgQW55ICZxdW90O25vcm1hbCByZXNwb25zZSZxdW90OyByZXR1cm5l ZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgdGhlIHNlY29uZCBvciBs YXRlciByZXF1ZXN0IGluIHRoZSBzZXF1ZW5jZSBTSEFMTCBiZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjb25zaWRlcmVkIGludmFsaWQuPGJyPg0KPGJyPg0KJmd0OyA4LiBT ZWN0aW9uIDEwLjEsIHBsZWFzZSBjb25zaWRlciByZXdvcmRpbmcgdGhlIGZvbGxvd2luZyBzZW50 ZW5jZXMgdG88YnI+DQomZ3Q7IG1ha2UgaXQgZWFzaWVyIHRvIHJlYWQ6PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgbyZuYnNwOyBJbiB0aGUgc2FtZSBwcmluY2lwbGUsIGFueSByZXNwb25zZXMgd2hp Y2ggcmVmZXIgdG8gb3IgcmVxdWVzdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtjaGFuZ2luZyB0byBhbiBhdXRoZW50aWNhdGlvbiByZWFsbSBkaWZmZXJlbnQgZnJvbSB0aGUg Y2xpZW50J3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVxdWVzdCBNVVNU IG9ubHkgYmUgYWNjZXB0ZWQgZm9yIHRoZSB2ZXJ5IGZpcnN0IHJlcXVlc3QgaW4gdGhlPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlcXVlbmNlLiZuYnNwOyBBbnkga2luZCBv ZiByZXNwb25zZXMgcmVmZXJyaW5nIHRvIGRpZmZlcmVudCByZWFsbXM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hpY2ggYXJlIHJldHVybmVkIGZvciB0aGUgc2Vjb25kIG9y IGxhdGVyIHJlcXVlc3RzIGluIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtzZXF1ZW5jZSBTSEFMTCBiZSBjb25zaWRlcmVkIGludmFsaWQuPGJyPg0KJmd0OyAtLS0tLTxi cj4NCiZndDsgOS4gSW4gc2VjdGlvbiAxNy4yLCBpdCBtaWdodCBiZSBoZWxwZnVsIHRvIGluY2x1 ZGUgYSByZWZlcmVuY2UgdG8gdGhlPGJyPg0KJmd0OyBUTFMgMS4yIEJDUCwgUkZDNzUyNS4mbmJz cDsgVGhlIGJ1bGxldCBtaWdodCBzYXkgc29tZXRoaW5nIGxpa2UsIHdoZW4gVExTPGJyPg0KJmd0 OyAxLjIgaXMgdXNlZCwgZm9sbG93IGJlc3QgcHJhY3RpY2VzIGluIFJGQzc1MjUuPGJyPg0KJmd0 OyAtLS0tLTxicj4NCjxicj4NCkZvciA3LTk6IFRoYW5rIHlvdSB2ZXJ5IG11Y2guIFdlIGRpZC48 YnI+DQo8YnI+DQomZ3Q7IDEwLiBTZWN0aW9uIDE3LjMgaXMgdGhlIGZpcnN0IHBsYWNlIEkgc2Vl IGEgY2xlYXIgbW90aXZhdGlvbiBmb3IgdGhpczxicj4NCiZndDsgcHJvdG9jb2wuJm5ic3A7IEl0 IG1pZ2h0IGhlbHAgdG8gaGF2ZSB0aGlzIHN0YXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uLjxicj4N CiZndDsgQWx0aG91Z2ggdGhlIHBvaW50cyBhYm91dCBwYXNzd29yZCBhdHRhY2tzIGluIHNlY3Rp b24gMTcuMiBsZWF2ZSBtZTxicj4NCiZndDsgcXVlc3Rpb25pbmcgaG93IG11Y2ggb2YgYW4gaW1w cm92ZW1lbnQgdGhpcyByZWFsbHkgaXMuJm5ic3A7IEhvdyBtdWNoPGJyPg0KJmd0OyBhbmFseXNp cyB3YXMgZG9uZSBvbiB0aGlzIG5ldyBtZXRob2Q/IEkga25vdyB0aGUgZHJhZnRzIGhhdmUgYmVl bjxicj4NCiZndDsgYXJvdW5kIGZvciBhIHdoaWxlLiZuYnNwOyBJJ2QgaGF2ZSB0byB0YWtlIGFu b3RoZXIgcGFzcyBhdCB0aGUgZG9jdW1lbnRzIHRvPGJyPg0KJmd0OyBkaWcgZGVlcGVyLCBidXQg d291bGQgbGlrZSB0byBrbm93IGlmIHRoaXMgYW5hbHlzaXMgd2FzIGRvbmUuJm5ic3A7IENhbiB5 b3U8YnI+DQomZ3Q7IG1ha2UgdGhlIHN0YXRlbWVudCB0aGF0IHRoaXMgaXMgbW9yZSBzZWN1cmU/ Jm5ic3A7IFRoZSBtb3RpdmF0aW9uIGZvciBIT0JBPGJyPg0KJmd0OyB3YXMgY2xlYXIgLSBnZXR0 aW5nIHJpZCBvZiB0aGUgdXNlIG9mIHBhc3N3b3Jkcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQYXNz d29yZHMgYXJlIG5vdCBzZW50IGluIHRoZSBjbGVhciwgYnV0IHRoaXMgaXNuJ3Qgc3RhdGVkIGlu IGE8YnI+DQomZ3Q7IG1vdGl2YXRpb24gc2VjdGlvbi4mbmJzcDsgSXQganVzdCBpcyBwYXJ0IG9m IHRoZSBwcm90b2NvbCBhbmQgbWVudGlvbmVkIGF0PGJyPg0KJmd0OyB0aGUgZW5kIG9mIHNlY3Rp b24gMTcuNS4mbmJzcDsgSXQgbWlnaHQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIHRoaXMgaW4gdGhl PGJyPg0KJmd0OyBpbnRyb2R1Y3Rpb24gYXMgd2VsbCBpbiBhIG1vdGl2YXRpb24gcGFyYWdyYXBo LiZuYnNwOyBUaGUgYWJzdHJhY3Qgc2F5aW5nPGJyPg0KJmd0OyB0aGF0LCAmcXVvdDtzZXJ2ZXIg dHJ1bHkga25vd3MgdGhlIHVzZXInczxicj4NCiZndDsgZW5jcnlwdGVkIHBhc3N3b3JkJnF1b3Q7 IGlzbid0IHRoZSBzYW1lIGFzIHNheWluZyB0aGF0IHRoZSBwYXNzd29yZCBpczxicj4NCiZndDsg ZW5jcnlwdGVkIG9uIHRoZSB3aXJlIGFuZCBkb2Vzbid0IHJlbHkgb24gdHJhbnNwb3J0IGVuY3J5 cHRpb24uPGJyPg0KPGJyPg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHByZWNpb3VzIHN1 Z2dlc3Rpb24uIEkgYWRkZWQgc29tZSB0ZXh0czxicj4NCnRvIHRoZSBpbnRyb2R1Y3Rpb24gc2Vj dGlvbi48YnI+DQpGb3Igc2VjdXJpdHksIHNpbXBseSBzYWlkLCBubyBvZmYtbGluZSBhdHRhY2sg d2lsbCBldmVyIGJlIHBvc3NpYmxlPGJyPg0KdXNpbmcgZGF0YSByZXRyaWV2ZWQgZnJvbSBlYXZl c2Ryb3BwZWQvbWFuLWluLXRoZS1taWRkbGUgdHJhZmZpY3MuPGJyPg0KV2UgZGlzY3Vzc2VkIHNv bWUgZGV0YWlsIG9uIG9uLWxpbmUgYXR0YWNrcyBpbiB0aGlzIHNlY3Rpb24sPGJyPg0KYnV0IGl0 J3MgbXVjaCBoYXJkZXIgdGhhbiBvZmYtbGluZSBhdHRhY2tzIGZvciBhdHRhY2tlcnMsPGJyPg0K YW5kIG11Y2ggZWFzaWVyIGZvciBzZXJ2ZXJzIHRvIGRldGVjdCBhbmQgcGVyZm9ybSBjb3VudGVy bWVhc3VyZXMuPGJyPg0KKE9mIGNvdXJzZSwgaXQncyBhIGdpZnQgZnJvbSB0aGUgUEFLRS4pPGJy Pg0KPGJyPg0KJmd0OyAtLS0tLTxicj4NCiZndDsgMTEuIFNlY3Rpb24gMTcuMy4mbmJzcDsgSSdt IG5vdCBjbGVhciBvbiB0aGlzIHNlbnRlbmNlIGluIHRoZSBsYXN0IHBhcmFncmFwaDo8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBPZiBjb3Vyc2UsIGluIHN1Y2ggY2FzZXMsIHRoZSB1c2VyIGludGVy ZmFjZXMgZm9yIGFza2luZyBwYXNzd29yZHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBmb3IgdGhp cyBhdXRoZW50aWNhdGlvbiBzaGFsbCBiZSBjbGVhcmx5IGlkZW50aWZpYWJsZSBhZ2FpbnN0PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgaW1pdGF0aW9uIGJ5IG90aGVyIGluc2VjdXJlIHBhc3N3b3Jk IGlucHV0IGZpZWxkcyAoc3VjaCBhcyBmb3JtcykuPGJyPg0KJmd0OyBDb21tb24gYXR0YWNrcyBv ZiB0aGlzIG5hdHVyZSB3b3VsZCBiZSB0byBkaXJlY3QgdXNlcnMgdG8gYSBmb3JtIHRoYXQ8YnI+ DQomZ3Q7IGlzbid0IHRoZSByZWFsIGZvcm0uJm5ic3A7IElzIGl0IHRoZSBtdXR1YWwgYXV0aGVu dGljYXRpb24gdGhhdCBoZWxwcyBoZXJlPzxicj4NCiZndDsmbmJzcDsgSWYgc28sIGV4cGxhaW4g aG93LiZuYnNwOyBIb3cgaXMgaXQgY2xlYXJseSBpZGVudGlmaWFibGUgYWdhaW5zdDxicj4NCiZn dDsgaW1pdGF0aW9uPzxicj4NCjxicj4NCldoYXQgd2UgY29uc2lkZXJlZCBhbmQgaW1wbGVtZW50 ZWQgaXMgYSBhdXRoZW50aWNhdGlvbiBpbnRlcmZhY2U8YnI+DQppbiBicm93c2VyLWNocm9tZSAo YXJvdW5kIHRoZSBhZGRyZXNzIGJhciksIG5vdCB3aXRoaW4gdGhlIG1haW4gY29udGVudCBhcmVh Ljxicj4NCkl0J3MgY29tbW9uIGZvciBicm93c2VycyB0byBoYXZlIHNvbWUgJnF1b3Q7c2VjdXJl IFVJIGFyZWEmcXVvdDsgbm90IHBvc3NpYmxlIHRvPGJyPg0KY2lyY3VtdmVudCBmcm9tIHRoZSB3 ZWIgY29udGVudCBpdHNlbGYsIHdob3NlIGV4YW1wbGVzIGluY2x1ZGVzIGFkZHJlc3MgYmFyLDxi cj4NCmFuZCBwYWRsb2NrIGljb25zLCBhcyB3ZWxsIGFzIHRoZSAmcXVvdDt0aGUgb3RoZXIgYXJl YSZxdW90OyBjb250cm9sbGVkIGJ5IHRoZTxicj4NCndlYiBwYWdlIGNvbnRlbnRzLiZuYnNwOyBX ZSBpbnRlbmRlZCB0byB1c2UgdGhlIGZvcm1lciBhcmVhIGZvciBzZWN1cmUgYXV0aGVudGljYXRp b24uPGJyPg0KSG93ZXZlciwgd2UgZGlkIG5vdCB3YW50IHRvIGluY2x1ZGUgYW55ICZxdW90O2lu c3RydWN0aW9ucyZxdW90OyBvbiB0aGUgdXNlciBpbnRlcmZhY2VzPGJyPg0Kb2Ygd2ViIGJyb3dz ZXJzIChmZWFyaW5nIHRoYXQgaXQgd2lsbCBiZWNvbWUgJnF1b3Q7b3V0LW9mLXNjb3BlJnF1b3Q7 IG9mIHRoZSBkcmFmdCksIHNvPGJyPg0Kd2UgdXNlZCBzb21lICZxdW90O2Fic3RyYWN0JnF1b3Q7 IHJlcXVpcmVtZW50IGhlcmUuPGJyPg0KSWYgeW91IGhhdmUgbW9yZSBzdWdnZXN0aW9uIG9uICZx dW90O3RoZSBleHRlbnQgd2Ugc2hvdWxkIHNheSBmb3IgdXNlciBpbnRlcmZhY2VzJnF1b3Q7LDxi cj4NCml0J3MgcmVhbGx5IGFwcHJlY2lhdGVkLjxicj4NCjxicj4NCi0tPGJyPg0KWXV0YWthIE9J V0EsIFBoLkQuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IExlYWRlciwgQ3liZXIgUGh5c2lj YWwgQXJjaGl0ZWN0dXJlIFJlc2VhcmNoIEdyb3VwPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmZvcm1hdGlv biBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 TmF0aW9uYWwgSW5zdGl0dXRlIG9mIEFkdmFuY2VkIEluZHVzdHJpYWwgU2NpZW5jZSBhbmQgVGVj aG5vbG9neSAoQUlTVCk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01haWwgYWRkcmVz c2VzOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnkub2l3YUBhaXN0LmdvLmpwIiB0YXJnZXQ9Il9ibGFu ayI+eS5vaXdhQGFpc3QuZ28uanA8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzp5dXRha2FA b2l3YS5qcCIgdGFyZ2V0PSJfYmxhbmsiPnl1dGFrYUBvaXdhLmpwPC9hPiZndDs8YnI+DQpPcGVu UEdQOiBpZFs0NDA1NDZCNV0gZnBbN0M5RiA3MjNBIDc1NTkgMzI0NiAyMjlEJm5ic3A7IDMxMzkg ODY3NyA5QkQyIDQ0MDUgNDZCNV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiM4ODg4ODgiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkthdGhsZWVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_TY1PR01MB0588C4D767B3FF7D81546321A0AD0TY1PR01MB0588jpnp_-- From nobody Fri Oct 28 06:43:03 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 72FC012961D for ; Fri, 28 Oct 2016 06:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 FoTi8n55xpex for ; Fri, 28 Oct 2016 06:42:59 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 3F2361294E3 for ; Fri, 28 Oct 2016 06:42:59 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id z190so86145806qkc.2 for ; Fri, 28 Oct 2016 06:42:59 -0700 (PDT) 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=T11ZCoBXwVLvkOjA4QgsEfb+Zf362QPOIb60a4TE3Ts=; b=brdlDYwYgR6iePEYUvOAHbGs6xPND+HIZ96nyH4Cjjax2ZHQR4+qF8D5MdijONgm6a UMRxM6NYdjIHHnYhF7ODrURmSl+uMVGqgqy2EhHpyEsrD+CA3I4XKAKNQ2Eqc0P3QjNL CZyJAhqtnxVG/xUl3gHMh3XwtC6M4hadiz+v/wzoe2dTqRvshCy3ozr9PpAAGu7VWGB1 p27IEtI2FEPuu04AGD7E1WOqLJDCXHKGeQnMBGp2bvnT5eMfr1NA94Fs8NAIO06bW4zb cKwIQytmkO5vAo1cK1xMpie40w4MU1Md4TDbJyMmNapN+WOfINnckIkYJQK1hyFHZhpj saaA== 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=T11ZCoBXwVLvkOjA4QgsEfb+Zf362QPOIb60a4TE3Ts=; b=lJFN036JjMZImKGkYwsKPZjPP1E5vVfEpzUR9WGiUHnZ+TLe4wVo6ru7wLqskA6sRI Wk3JeaQUabah4jo57ib+fP2PgdQ9gG/bLwnpNK+CXPhLy91kFmjM6PuHI8t3F7vNPVQ3 oNIx2FsTGHfb9hZyPg/I0h/MjiVKaa6BON5jtPB0lR6fSFhFYsi7dVuO/Wph7vH5HnAL hZu5zkPGnUPYvGMPQAW2JTY874wCNoTTumYRi85ACsacPCfG/fXa2yZqodarJb65+MEQ jHiZWcikgrUlw0iNzZdsL7hZ6F1nGIVaQZR0Dgp07QuUOT6BAC8IyYxyfDWc7uSC+igR 1Ong== X-Gm-Message-State: ABUngvfWxx0gPySPWXpRq718zWe+0hlRLcs+G/lTtugI/sju8HsbuEQAqjkkhhCU4+5OiA== X-Received: by 10.55.6.14 with SMTP id 14mr7118389qkg.167.1477662178323; Fri, 28 Oct 2016 06:42:58 -0700 (PDT) Received: from [10.0.1.5] (ool-457c4d63.dyn.optonline.net. [69.124.77.99]) by smtp.gmail.com with ESMTPSA id q21sm5062776qkq.8.2016.10.28.06.42.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Oct 2016 06:42:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EB445B09-4D63-4CD9-9110-26A791A09D5D Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Fri, 28 Oct 2016 09:42:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: <318CD048-5CBF-4D7F-AAD7-0AD9CDFB642D@gmail.com> References: <57E3D237.50001@aist.go.jp> To: =?utf-8?B?5aSn5bKp5a+b?= Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 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: Fri, 28 Oct 2016 13:43:02 -0000 --Apple-Mail-EB445B09-4D63-4CD9-9110-26A791A09D5D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Yutaka. I updated the ballot text. I did find the text a little= confusing in the IANA section, so that may come up during IESG if others th= ink it is confusing. The introduction in 16.1 says, "a specification for th= e use of such tokens MUST be reviewed by a designated expert". If a specification is not required, the language should be changed. If it's= not required, email would suffice. How about, "to acquire registered tokens, they MUST be reviewed by a designa= ted expert," If this is what is intended and you can post an update quickly, that would b= e good. Thank you, Kathleen =20 Please excuse typos, sent from handheld device=20 > On Oct 28, 2016, at 1:59 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B wrote: >=20 > Dear Kathleen, > =20 > The registries require expert review process as defined in RFC5226. > (a consensus on WG discussions.) > The existence of specification is not explicitly needed if the text makes c= onfusions. > I assume that it will be anyway required (in most cases) for expert review= processes. > =20 > =20 > Thanks, > Yutaka > =20 > -- > Yutaka OIWA, Ph.D. Leader, Cyber Physical Architecture Research Grou= p > Information Technology Research Institut= e > National Institute of Advanced Industrial Science and Technology (AIST= ) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B= 5] > =20 > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Friday, October 28, 2016 7:07 AM > To: =E5=A4=A7=E5=B2=A9=E5=AF=9B > Cc: http-auth@ietf.org > Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08 > =20 > Hello, > =20 > Just a quick question as I fill out the ballot text for next week's telech= at. For the IANA section, as I read it both registries require expert revie= w and a specification, is that right? I'm asking as the language could be c= learer and I need to make sure it is clear in the ballot. > =20 > Thank you, > Kathleen > =20 > On Tue, Oct 11, 2016 at 12:12 PM, Kathleen Moriarty wrote: > Dear Yutaka, > =20 > I am sorry for my delay in response. The updates look very good and I thi= nk the updated introduction is helpful. I will progress the draft into IETF= last call, but an edit pass on the new text is required as there are some g= rammar issues. > =20 > Also, you had responded saying you would add something about logging and I= am not able to find that text in the diffs from -08. Was it added? > =20 > Thank you, > Kathleen > =20 > On Sun, Oct 9, 2016 at 12:24 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B wrote: > Dear Kathleen, >=20 > I have not seen any response to the previous mail. > If we have any problems to solve or actions to take, > please let me know. >=20 > Thanks, >=20 > Yutaka > ________________________________________ > =E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5 2= 1:44:39 > =E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org > =E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of draft-ietf-httpauth-mutua= l-08 >=20 > Dear Kathleen, >=20 > I'm sorry I've updated the draft according to your mail, > but not responded to the mail itself. > # and I found a few typo to submit the draft revision very soon. >=20 > On 2016/08/12 11:18, Kathleen Moriarty wrote: > > Hello, > > > > Thank you for your work on draft-ietf-httpauth-mutual-08. I will try > > to get through my AD review of the accompanying draft tomorrow. > > > > I read through the draft and have the following questions. > > > > > > ----- > > Section 2.1, in the following text: > > > > o Authenticated key exchange messages: used by both peers to perform > > authentication and the sharing of a cryptographic secret. > > > > * req-KEX-C1 message: a message sent from the client. > > > > * 401-KEX-S1 message: a message sent from the server in response > > to a req-KEX-C1 message. > > > > 1. What does the response mean? Is there a pass/fail message in the > > response or is this just an ack that the message was received by the > > server to the client? >=20 > 401-KEX-S1 will be almost unconditionally sent as a response, > as authentication is on-going, not finished yet. > There may be a "no-go" for fatal error case (e.g. parameter mismatch), how= ever. >=20 > > Then in the following: > > * 200-VFY-S message: a client-authentication successful response > > used by the server, which also simultaneously asserts to the > > client that the server is authentic. > > > > 2. Maybe this will be clear as I read further through the draft, but > > that seems like a lot to assert at once. This note is a placeholder > > for me in case I do't feel like there is an adequate answer when I get > > deeper into the draft. >=20 > We tried to make it more clear in the revised draft. >=20 > > Second bullet on page 7: > > > > o At this point (5), both peers calculate a shared "session secret" > > using the exchanged values in the key exchange messages. Only > > when both the server and the client have used secret credentials > > generated from the same password will the session secret values > > match. This session secret will be used for access authentication= > > of every individual normal after this point. > > > > 3. I think a word may be missing in the last sentence, can you > > rephrase it? I'm not able to parse it. >=20 > This seems to be typo, and we fixed. >=20 > > ----- > > In another bullet on page 7: > > > > o If the authentication verification value from the client was > > correct, it means that the client definitely owns the credential > > based on the expected password (i.e., the client authentication > > succeeded). The server will respond with a successful message > > (200-VFY-S) (7). Contrary to the usual one-way authentication > > (e.g., HTTP Basic authentication or POP APOP authentication > > [RFC1939]), this message also contains a server-side > > authentication verification value. > > > > When the client's verification value is incorrect (e.g., because > > the user-supplied password was incorrect), the server will respond= > > with the 401-INIT message (the same one as used in (2)) instead. > > > > 4. This last section should specify that the extensive-token > > indicating an authentication failure must be included. I would also > > recommend that this information be logged and have that stated in this > > draft. Since we are pushing for protocols to be encrypted, the use of > > sniffers to detect errors will continue to fall off and people will > > need to rely on logs more. I think it would be more helpful to have > > an accurate log that responds saying the authentication failed > > (user/password if you don't want to say which). Encouraging richer > > logs will be more helpful going forward. > > ----- >=20 > Thank you very much for the suggestion. We incorporated the idea. >=20 > > In Section 7, just to make sure I am reading this correctly: > > > > The valid tokens for the validation parameter and corresponding > > values of vh are as follows: > > > > host: host-name validation: The value vh will be the ASCII > > string in the following format: > > "://:", where , , > > and are the URI components corresponding to the= > > currently accessing resource. > > > > 5. By "currently accessing resource", you mean the source system, > > correct? It might be better to rephrase that so it is clear since > > this is important to developers. > > ----- >=20 > We rephrased it as "server-side resource". > It's actually "the URL" being accessed, in short and informally. > If there is better phrasing, we'll look for it further. >=20 >=20 > > 6. In Section 8, it is the reason parameter of the INIT that lets you > > know if t is 'valid', correct? > > Authentication-initializing messages with the > > Optional-WWW-Authenticate header are used only where the 401-INIT > > response is valid. It will not replace other 401-type messages such > > as 401-STALE and 401-KEX-S1. > > > > I think it would be helpful to explicitly state what is a valid > > response unless that is defined already and I missed it? I think it > > depends on the token or extensive token set in the reason parameter of > > the INIT message. >=20 > We clarified that the reason will be "initial" (modulo future extensions).= >=20 > > ---- > > 7. In section 10.1, if you change "normal responses" to "normal > > response", it is easier to fix the grammar in the following sentences: > > > > This also > > holds true for the reception of "normal responses" (responses which > > do not contain Mutual authentication-related headers) from HTTP > > servers. > > change to: > > This also > > holds true for the reception of a "normal response" (responses which > > do not contain Mutual authentication-related headers) from HTTP > > servers. > > > > from: > > Any kinds of "normal responses" MUST only be accepted for the very= > > first request in the sequence. Any "normal responses" returned > > for the second or later requests in the sequence SHALL be > > considered invalid. > > change to: > > Any kind of "normal response" MUST only be accepted for the very > > first request in the sequence. Any "normal response" returned > > for the second or later request in the sequence SHALL be > > considered invalid. >=20 > > 8. Section 10.1, please consider rewording the following sentences to > > make it easier to read: > > o In the same principle, any responses which refer to or request > > changing to an authentication realm different from the client's > > request MUST only be accepted for the very first request in the > > sequence. Any kind of responses referring to different realms > > which are returned for the second or later requests in the > > sequence SHALL be considered invalid. > > ----- > > 9. In section 17.2, it might be helpful to include a reference to the > > TLS 1.2 BCP, RFC7525. The bullet might say something like, when TLS > > 1.2 is used, follow best practices in RFC7525. > > ----- >=20 > For 7-9: Thank you very much. We did. >=20 > > 10. Section 17.3 is the first place I see a clear motivation for this > > protocol. It might help to have this stated in the introduction. > > Although the points about password attacks in section 17.2 leave me > > questioning how much of an improvement this really is. How much > > analysis was done on this new method? I know the drafts have been > > around for a while. I'd have to take another pass at the documents to > > dig deeper, but would like to know if this analysis was done. Can you > > make the statement that this is more secure? The motivation for HOBA > > was clear - getting rid of the use of passwords. > > > > Passwords are not sent in the clear, but this isn't stated in a > > motivation section. It just is part of the protocol and mentioned at > > the end of section 17.5. It might be helpful to include this in the > > introduction as well in a motivation paragraph. The abstract saying > > that, "server truly knows the user's > > encrypted password" isn't the same as saying that the password is > > encrypted on the wire and doesn't rely on transport encryption. >=20 > Thank you very much for the precious suggestion. I added some texts > to the introduction section. > For security, simply said, no off-line attack will ever be possible > using data retrieved from eavesdropped/man-in-the-middle traffics. > We discussed some detail on on-line attacks in this section, > but it's much harder than off-line attacks for attackers, > and much easier for servers to detect and perform countermeasures. > (Of course, it's a gift from the PAKE.) >=20 > > ----- > > 11. Section 17.3. I'm not clear on this sentence in the last paragraph:= > > Of course, in such cases, the user interfaces for asking passwords > > for this authentication shall be clearly identifiable against > > imitation by other insecure password input fields (such as forms). > > Common attacks of this nature would be to direct users to a form that > > isn't the real form. Is it the mutual authentication that helps here? > > If so, explain how. How is it clearly identifiable against > > imitation? >=20 > What we considered and implemented is a authentication interface > in browser-chrome (around the address bar), not within the main content ar= ea. > It's common for browsers to have some "secure UI area" not possible to > circumvent from the web content itself, whose examples includes address ba= r, > and padlock icons, as well as the "the other area" controlled by the > web page contents. We intended to use the former area for secure authenti= cation. > However, we did not want to include any "instructions" on the user interfa= ces > of web browsers (fearing that it will become "out-of-scope" of the draft),= so > we used some "abstract" requirement here. > If you have more suggestion on "the extent we should say for user interfac= es", > it's really appreciated. >=20 > -- > Yutaka OIWA, Ph.D. Leader, Cyber Physical Architecture Research Gro= up > Information Technology Research Institu= te > National Institute of Advanced Industrial Science and Technology (AIS= T) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B= 5] >=20 >=20 > =20 > -- > =20 > Best regards, > Kathleen >=20 >=20 > =20 > -- > =20 > Best regards, > Kathleen --Apple-Mail-EB445B09-4D63-4CD9-9110-26A791A09D5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thank you, Yutaka.  I updated the= ballot text.  I did find the text a little confusing in the IANA secti= on, so that may come up during IESG if others think it is confusing.  T= he introduction in 16.1 says, "a specification for the use of such tokens MU= ST be reviewed by a designated expert".
=
If a specification is not required,= the language should be changed.  If it's not required, email would suf= fice.

How about, "to acquire registered tokens, they MUST be reviewed by a d= esignated expert,"

If this is what is intended and you can post an update q= uickly, that would be good.

Thank you,
= Kathleen  

Please excuse typos, sent from handheld device <= /div>

On Oct 28, 2016, at 1:59 AM, =E5=A4=A7=E5=B2=A9=E5=AF=9B <<= a href=3D"mailto:y.oiwa@aist.go.jp">y.oiwa@aist.go.jp> wrote:

=

Dear Kathleen,

 

The registries require exp= ert review process as defined in RFC5226.

(a consensus on WG discuss= ions.)

The existence of specifica= tion is not explicitly needed if the text makes confusions.

I assume that it will be a= nyway required (in most cases) for expert review processes.

 

 

Thanks,<= /p>

Yutaka

 

--

Yutaka OIWA, Ph.D.    &n= bsp;  Leader, Cyber Physical Architecture Research Group

       &n= bsp;             = ;            &nb= sp;Information Technology Research Institute

    National Institute of Adv= anced Industrial Science and Technology (AIST)

       &n= bsp;            =   Mail addresses: <y.oiwa@aist.= go.jp>, <yutaka@oiwa.jp><= o:p>

OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246= 229D  3139 8677 9BD2 4405 46B5]

 

From: Kat= hleen Moriarty [mailto:k= athleen.moriarty.ietf@gmail.com]
Sent: Friday, October 28, 2016 7:07 AM
To: =E5=A4=A7=E5=B2=A9=E5=AF=9B= <y.oiwa@aist.= go.jp>
Cc: http-auth@ietf.org
Subject: Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08

 

Hello,

 

Just a quick question as I fill o= ut the ballot text for next week's telechat.  For the IANA section, as I= read it both registries require expert review and a specification, is that r= ight?  I'm asking as the language could be clearer and I need to make sure it is clear in the ballot.

 

Thank you,

=

Kathleen

 

On Tue, Oct 11, 2016 at 12:12 PM= , Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:<= /span>

Dear Yutaka,

 

I am sorry for my delay in respo= nse.  The updates look very good and I think the updated introduction i= s helpful.  I will progress the draft into IETF last call, but an edit p= ass on the new text is required as there are some grammar issues.

 

Also, you had responded saying y= ou would add something about logging and I am not able to find that text in t= he diffs from -08.  Was it added?

 

Thank you,

=

Kathleen

 

On Sun, Oct 9, 2016 at 12:24 AM,= =E5=A4=A7=E5=B2=A9=E5=AF=9B <y.oiwa@aist.go.jp> wrote:

Dear Kathleen,

I have not seen any response to the previous mail.
If we have any problems to solve or actions to take,
please let me know.

Thanks,

Yutaka
________________________________________
=E5=B7=AE=E5=87=BA=E4=BA=BA: Yutaka OIWA <y.oiwa@aist.go.jp>=
=E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82: 2016=E5=B9=B49=E6=9C=8822=E6=97=A5 21:44:39
=E5=AE=9B=E5=85=88: Kathleen Moriarty; http-auth@ietf.org
=E4=BB=B6=E5=90=8D: Re: [http-auth] AD review of= draft-ietf-httpauth-mutual-08


Dear Kathleen,

I'm sorry I've updated the draft according to your mail,
but not responded to the mail itself.
# and I found a few typo to submit the draft revision very soon.

On 2016/08/12 11:18, Kathleen Moriarty wrote:
> Hello,
>
> Thank you for your work on draft-ietf-httpauth-mutual-08.  I will t= ry
> to get through my AD review of the accompanying draft tomorrow.
>
> I read through the draft and have the following questions.
>
>
> -----
> Section 2.1, in the following text:
>
>  o  Authenticated key exchange messages: used by both peers t= o perform
>       authentication and the sharing of a cryptogra= phic secret.
>
>       *  req-KEX-C1 message: a message sent fr= om the client.
>
>       *  401-KEX-S1 message: a message sent fr= om the server in response
>          to a req-KEX-C1 message.
>
> 1. What does the response mean?  Is there a pass/fail message in t= he
> response or is this just an ack that the message was received by the > server to the client?

401-KEX-S1 will be almost unconditionally sent as a response,
as authentication is on-going, not finished yet.
There may be a "no-go" for fatal error case (e.g. parameter mismatch), howev= er.

> Then in the following:
>       *  200-VFY-S message: a client-authentic= ation successful response
>          used by the server, which also simult= aneously asserts to the
>          client that the server is authentic.<= br> >
> 2. Maybe this will be clear as I read further through the draft, but > that seems like a lot to assert at once.  This note is a placehold= er
> for me in case I do't feel like there is an adequate answer when I get<= br> > deeper into the draft.

We tried to make it more clear in the revised draft.

> Second bullet on page 7:
>
>  o  At this point (5), both peers calculate a shared "session= secret"
>       using the exchanged values in the key exchang= e messages.  Only
>       when both the server and the client have used= secret credentials
>       generated from the same password will the ses= sion secret values
>       match.  This session secret will be used= for access authentication
>       of every individual normal after this point.<= br> >
> 3. I think a word may be missing in the last sentence, can you
> rephrase it?  I'm not able to parse it.

This seems to be typo, and we fixed.

> -----
> In another bullet on page 7:
>
>  o  If the authentication verification value from the client w= as
>       correct, it means that the client definitely o= wns the credential
>       based on the expected password (i.e., the cli= ent authentication
>       succeeded).  The server will respond wit= h a successful message
>       (200-VFY-S) (7).  Contrary to the usual o= ne-way authentication
>       (e.g., HTTP Basic authentication or POP APOP a= uthentication
>       [RFC1939]), this message also contains a serv= er-side
>       authentication verification value.
>
>       When the client's verification value is incor= rect (e.g., because
>       the user-supplied password was incorrect), th= e server will respond
>       with the 401-INIT message (the same one as us= ed in (2)) instead.
>
> 4. This last section should specify that the extensive-token
> indicating an authentication failure must be included.  I would al= so
> recommend that this information be logged and have that stated in this<= br> > draft.  Since we are pushing for protocols to be encrypted, the us= e of
> sniffers to detect errors will continue to fall off and people will
= > need to rely on logs more.  I think it would be more helpful to ha= ve
> an accurate log that responds saying the authentication failed
> (user/password if you don't want to say which).  Encouraging riche= r
> logs will be more helpful going forward.
> -----

Thank you very much for the suggestion. We incorporated the idea.

> In Section 7, just to make sure I am reading this correctly:
>
> The valid tokens for the validation parameter and corresponding
>    values of vh are as follows:
>
>    host:          host-name validati= on: The value vh will be the ASCII
>                   str= ing in the following format:
>                   "&l= t;scheme>://<host>:<port>", where <scheme>, <host>= ;,
>                   and= <port> are the URI components corresponding to the
>                   cur= rently accessing resource.
>
> 5. By "currently accessing resource", you mean the source system,
> correct?  It might be better to rephrase that so it is clear since=
> this is important to developers.
> -----

We rephrased it as "server-side resource".
It's actually "the URL" being accessed, in short and informally.
If there is better phrasing, we'll look for it further.


> 6. In Section 8, it is the reason parameter of the INIT that lets you > know if t is 'valid', correct?
>    Authentication-initializing messages with the
>    Optional-WWW-Authenticate header are used only where the 4= 01-INIT
>    response is valid.  It will not replace other 401-typ= e messages such
>    as 401-STALE and 401-KEX-S1.
>
> I think it would be helpful to explicitly state what is a valid
> response unless that is defined already and I missed it?  I think i= t
> depends on the token or extensive token set in the reason parameter of<= br> > the INIT message.

We clarified that the reason will be "initial" (modulo future extensions).
> ----
> 7. In section 10.1, if you change "normal responses" to "normal
> response", it is easier to fix the grammar in the following sentences:<= br> >
>    This also
>    holds true for the reception of "normal responses" (respon= ses which
>    do not contain Mutual authentication-related headers) from= HTTP
>    servers.
> change to:
>    This also
>    holds true for the reception of a "normal response" (respo= nses which
>    do not contain Mutual authentication-related headers) from= HTTP
>    servers.
>
> from:
>       Any kinds of "normal responses" MUST only be a= ccepted for the very
>       first request in the sequence.  Any "nor= mal responses" returned
>       for the second or later requests in the seque= nce SHALL be
>       considered invalid.
> change to:
>       Any kind of "normal response" MUST only be ac= cepted for the very
>       first request in the sequence.  Any "nor= mal response" returned
>       for the second or later request in the sequen= ce SHALL be
>       considered invalid.

> 8. Section 10.1, please consider rewording the following sentences to > make it easier to read:
>    o  In the same principle, any responses which refer t= o or request
>       changing to an authentication realm different= from the client's
>       request MUST only be accepted for the very fi= rst request in the
>       sequence.  Any kind of responses referri= ng to different realms
>       which are returned for the second or later re= quests in the
>       sequence SHALL be considered invalid.
> -----
> 9. In section 17.2, it might be helpful to include a reference to the > TLS 1.2 BCP, RFC7525.  The bullet might say something like, when T= LS
> 1.2 is used, follow best practices in RFC7525.
> -----

For 7-9: Thank you very much. We did.

> 10. Section 17.3 is the first place I see a clear motivation for this > protocol.  It might help to have this stated in the introduction.<= br> > Although the points about password attacks in section 17.2 leave me
= > questioning how much of an improvement this really is.  How much > analysis was done on this new method? I know the drafts have been
> around for a while.  I'd have to take another pass at the document= s to
> dig deeper, but would like to know if this analysis was done.  Can= you
> make the statement that this is more secure?  The motivation for H= OBA
> was clear - getting rid of the use of passwords.
>
> Passwords are not sent in the clear, but this isn't stated in a
> motivation section.  It just is part of the protocol and mentioned= at
> the end of section 17.5.  It might be helpful to include this in t= he
> introduction as well in a motivation paragraph.  The abstract sayi= ng
> that, "server truly knows the user's
> encrypted password" isn't the same as saying that the password is
> encrypted on the wire and doesn't rely on transport encryption.

Thank you very much for the precious suggestion. I added some texts
to the introduction section.
For security, simply said, no off-line attack will ever be possible
using data retrieved from eavesdropped/man-in-the-middle traffics.
We discussed some detail on on-line attacks in this section,
but it's much harder than off-line attacks for attackers,
and much easier for servers to detect and perform countermeasures.
(Of course, it's a gift from the PAKE.)

> -----
> 11. Section 17.3.  I'm not clear on this sentence in the last para= graph:
>    Of course, in such cases, the user interfaces for asking p= asswords
>    for this authentication shall be clearly identifiable agai= nst
>    imitation by other insecure password input fields (such as= forms).
> Common attacks of this nature would be to direct users to a form that > isn't the real form.  Is it the mutual authentication that helps h= ere?
>  If so, explain how.  How is it clearly identifiable against<= br> > imitation?

What we considered and implemented is a authentication interface
in browser-chrome (around the address bar), not within the main content area= .
It's common for browsers to have some "secure UI area" not possible to
circumvent from the web content itself, whose examples includes address bar,=
and padlock icons, as well as the "the other area" controlled by the
web page contents.  We intended to use the former area for secure authe= ntication.
However, we did not want to include any "instructions" on the user interface= s
of web browsers (fearing that it will become "out-of-scope" of the draft), s= o
we used some "abstract" requirement here.
If you have more suggestion on "the extent we should say for user interfaces= ",
it's really appreciated.

--
Yutaka OIWA, Ph.D.        Leader, Cyber Physical Archite= cture Research Group
                     =              Information Technology Rese= arch Institute
     National Institute of Advanced Industrial Science and Te= chnology (AIST)
                     =  Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 4= 6B5]



 

--

 

Best reg= ards,

Kathleen=



 

--

 

Best regards,<= /p>

Kathleen

= --Apple-Mail-EB445B09-4D63-4CD9-9110-26A791A09D5D--