Re: [http-auth] AD review of draft-ietf-httpauth-mutual-08

[Kathleen Moriarty <[e-mail]>]

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, 大岩寛 <[e-mail]> 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
> ________________________________________
> 差出人: Yutaka OIWA <[e-mail]>
> 送信日時: 2016年9月22日 21:44:39
> 宛先: Kathleen Moriarty; [e-mail]
> 件名: 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),
> 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 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:
> >                   "<scheme>://<host>:<port>", where <scheme>, <host>,
> >                   and <port> 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
> 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: <[e-mail]>, <
> [e-mail]>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405
> 46B5]
>



-- 

Best regards,
Kathleen