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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 27 October 2016 22:07 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietf.org>; Thu, 27 Oct 2016 15:07:27 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id 64so34500357uap.3 for <http-auth@ietf.org>; 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: <CAHbuEH4TqQATKtzfb2F5UfrX+RYM6nW=_QQUDaRoY=aNwYh=YQ@mail.gmail.com>
References: <CAHbuEH5YL=WHfqf7xvUfU8gmmYoJ7ZwD0R=BUfoE1+PT5haqJQ@mail.gmail.com> <57E3D237.50001@aist.go.jp> <TY1PR01MB05889A8D2292F5DCAF527C1CA0D80@TY1PR01MB0588.jpnprd01.prod.outlook.com> <CAHbuEH4TqQATKtzfb2F5UfrX+RYM6nW=_QQUDaRoY=aNwYh=YQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 27 Oct 2016 18:07:25 -0400
Message-ID: <CAHbuEH7cFMz-Rre1ZpUwQrywAwCS_q1EYEAmV4wSF9U25uY9EQ@mail.gmail.com>
To: =?UTF-8?B?5aSn5bKp5a+b?= <y.oiwa@aist.go.jp>
Content-Type: multipart/alternative; boundary=94eb2c1255f08684b7053fdff76b
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/AUxasvAs9QeltJvIIAI1Oufw6_c>
Cc: "http-auth@ietf.org" <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 <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2016 22:07:30 -0000

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 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, 大岩寛 <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
>> ________________________________________
>> 差出人: Yutaka OIWA <y.oiwa@aist.go.jp>
>> 送信日時: 2016年9月22日 21:44:39
>> 宛先: Kathleen Moriarty; http-auth@ietf.org
>> 件名: 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: <y.oiwa@aist.go.jp>jp>, <
>> yutaka@oiwa.jp>
>> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405
>> 46B5]
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>



-- 

Best regards,
Kathleen