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