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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 21 September 2016 17:26 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 E297C12BABD for <http-auth@ietfa.amsl.com>; Wed, 21 Sep 2016 10:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 liKhzDw6gZH1 for <http-auth@ietfa.amsl.com>; Wed, 21 Sep 2016 10:26:31 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 6671E12BADA for <http-auth@ietf.org>; Wed, 21 Sep 2016 10:26:30 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id u82so64330881ywc.2 for <http-auth@ietf.org>; Wed, 21 Sep 2016 10:26:30 -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; bh=Y1K3D+uimEiTtM0bwPVPwBXWGFaagDUdaBb2Za9bcnM=; b=i964rCncm8ntUd/grpKpyIKzriYCnY/fxx4469idepHrUVHiuMx4mUkGGDhCnxMo08 AmoKZNQdRzIVcP1uU9ZgOofcsEtHir7c0CzA+Z5qlhHzSUF5TkZS+35RuY2jwdJ581Qb rrfRwbsw69srPfk+eFnFizkr/QN3w/zzUzV7KP2gP9fLdewhUTUk1i2bJ0WfxyWcL1DE 3vitlbjFoOgjS/q1C89ykRGP0MkAj7bT5RUU9mRdWi1kgp3xEp+CjurlllGrCrVUSjCs zvuTfsKaNZ66sxaAkkpiw+iUxWrWC399z8QssQO+ANPuLurF1CVhUrO3XS7afxvCvOIy MdhQ==
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; bh=Y1K3D+uimEiTtM0bwPVPwBXWGFaagDUdaBb2Za9bcnM=; b=KvfBfL6HeXhTK6GCz4WuirFtADfxKijFmKUhlsAYoIdrejbeskTxRkz2f1+pl88X9E Q+tXNX26VyPKHXC+lo2xEjSqOa2Jf8ZEJAbsRnwNLv6MVQ/gpSwa6ssRpHOm3fpejudS MXvDyehi2X6SFRG8X6he6BQp5WaM282sEfkCuUvoaCrzO/T0ee94AAly4elxeab3q/6i Uf/51TsgVOQ4yxC5rIYuNjmBZSPn5H7Alttv4RGa2AWuQJAUQyodTFZb1JsCPsUdaFaN GrU9fd5V3nJ0c/G7lfQ81aD5AHrwD665u39dx/W6lBykM+Jl1cH307Umd2p6CmE5TrJ5 2h+A==
X-Gm-Message-State: AE9vXwPL2c7laJK6TlzZ8pDr6m7PiDyhhTLBTL+am30zYG3JkRiSKLWwkz3fl+XpaYa1W+bhftaLtJ+lmNQpnA==
X-Received: by 10.129.56.85 with SMTP id f82mr37140324ywa.45.1474478789094; Wed, 21 Sep 2016 10:26:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.8 with HTTP; Wed, 21 Sep 2016 10:26:28 -0700 (PDT)
In-Reply-To: <CAHbuEH5YL=WHfqf7xvUfU8gmmYoJ7ZwD0R=BUfoE1+PT5haqJQ@mail.gmail.com>
References: <CAHbuEH5YL=WHfqf7xvUfU8gmmYoJ7ZwD0R=BUfoE1+PT5haqJQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 21 Sep 2016 13:26:28 -0400
Message-ID: <CAHbuEH4LofLjrrxpjfmpxOwGf=yuvBDUFc-CVQg+DNMVNHMbSw@mail.gmail.com>
To: "http-auth@ietf.org" <http-auth@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/UPQGV39sMSIp0LCFaZkoEbXtSKE>
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: Wed, 21 Sep 2016 17:26:34 -0000

Hello,

Is there a response to my comments?  I'd like to progress these 2
drafts into IETF last call once these comments are addressed.

Thank you,
Kathleen

On Thu, Aug 11, 2016 at 10:18 PM, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> 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?
>
> 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.
>
> -----
>
> 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.
>
> -----
> 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.
> -----
> 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.
> -----
> 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.
>
> ----
> 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.
> -----
> 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.
> -----
> 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?
>
> --
>
> Best regards,
> Kathleen



-- 

Best regards,
Kathleen