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

[Kathleen Moriarty <[e-mail]>]

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 <
[e-mail]> 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 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
>



-- 

Best regards,
Kathleen