Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 November 2016 01:44 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 546FD1295CB; Mon, 7 Nov 2016 17:44:36 -0800 (PST)
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 Fwa6ox6lKYl1; Mon, 7 Nov 2016 17:44:33 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 78CF11295BD; Mon, 7 Nov 2016 17:44:33 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id b35so135378572uaa.3; Mon, 07 Nov 2016 17:44:33 -0800 (PST)
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=+sQ7ahZGhCePkvBA3bGOOZ1qmeWtB/0IvnrrvQYiVkk=; b=E5RPrMFEsxJvAzixzdlhpKYJQ7UKYymzqFNJY7djpvxA3V4HXO5PFPPFUZnxXWaD7k W7m3FOJm2z5GPAQO0tXTkkmpuRgM2bq2lxuEX17ZgNY79hQ44rBfUpm5zr3GBGDHJZY7 l7rf6XwAiOhyFSqD+nPMzAefp7YBgTEhKyn+6dTkI4R3mDs0Pc8QdGk07+v6ufvrs1kQ UysFcUJc6rToufemHHx6uQEbhWHEqHA3urGsC80i/Ndl/XTt97r77ZoFdQl5h+ZKoRPt 5pwPZu9W4f+Wlg8eoKUQBCbbV3FiJluKFX9Qc+BUscWS3vztEQD+U6HyDY6u4FutFKDj e2tw==
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=+sQ7ahZGhCePkvBA3bGOOZ1qmeWtB/0IvnrrvQYiVkk=; b=kXx/vfAYZYyepunCO6hCin0Y3U6HsxlMvXC8FEmuxltAXxStdMCzlBozKrPsBl6q2V rr+wuiHKbd2BOlECn7s5+LMirb0U75xcNQg7eVNS09P1C0xMh8JswWoTA8vnAcEVqITQ Nv5v84FtZr6qGwfMQdbrNFt6qBScWXekHsISeUFagb6s0M1e3aN90NXawco2JphKu0Kn epdMG8+87AFS50B+ibQm5MvHPcE5xE2YO6Aq5m32CZXJcRdAbE0QzxR1bHWY2visRYT9 QE3nftSb6nd9QPK0MP8eJ9S0feJskIKpFWipKiobuNlFcq6FqDlOQ4ft83BGQeeDbSsb 5pGA==
X-Gm-Message-State: ABUngvdqfHJEF7L+XO/IuMuGAYZtkQXnTbtQ0ptL86HX+gHfarw6vENywD9hgeuqQc+0o10k1oErxK9rJd1wng==
X-Received: by 10.176.85.24 with SMTP id t24mr6842297uaa.21.1478569472608; Mon, 07 Nov 2016 17:44:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.82.143 with HTTP; Mon, 7 Nov 2016 17:44:32 -0800 (PST)
In-Reply-To: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com>
References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 7 Nov 2016 20:44:32 -0500
Message-ID: <CAHbuEH6VfOOG3+nzAfje=TiNVpfC0Eqmxwnj6gO3bE1Q4oZ6oQ@mail.gmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Type: multipart/alternative; boundary=f403045dd96030cec20540c0483a
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/NWR8udz_U6YESaHlwLCHPutC438>
Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" <http-auth@ietf.org>, The IESG <iesg@ietf.org>, httpauth-chairs@ietf.org
Subject: Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)
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: Tue, 08 Nov 2016 01:44:36 -0000

Hello,

I have not seen a response to this discuss (or some of the other comments),
please respond and discuss these questions and comments.  It would be good
to wrap up these last 2 drafts soon.

Thank you,
Kathleen

On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <aamelnikov@fastmail.fm>
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-httpauth-mutual-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is generally a well written document. I have a couple of important
> comments that I would like to see addressed and several less significant
> comments.
>
> 1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP
> Authentication Schemes with IANA
>
> 2) In Section 7:
>
>    If HTTP is used on a non-encrypted channel (TCP and SCTP, for
>    example), the validation type MUST be "host".  If HTTP/TLS [RFC2818]
>    (HTTPS) is used with a server certificate, the validation type MUST
>    be "tls-server-end-point".  If HTTP/TLS is used with an anonymous
>    Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
>    (see the note below).
>
>    Implementations supporting Mutual authentication over HTTPS SHOULD
>    support the "tls-server-end-point" validation.  Support for
>    "tls-unique" validation is OPTIONAL for both servers and clients.
>
> I think the two paragraphs are in conflict. For example, the first one
> says that if TLS with server certificate is used, then
> "tls-server-end-point"
> MUST be supported. But the second says that it is SHOULD be supported.
>
> If the intent of the first paragraph is to say what should appear
> syntactically,
> while the second paragraph explains what kind of validation is actually
> required,
> I think this still can be made clearer.
>
> I suggest you either delete the second of these 2 paragraphs, or you
> need to reword text in the first (and possibly the second) to specify
> a non conflicting set of requirements.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> I agree that the Introduction section might need an editing pass.
>
> In Section 1, next to the last paragraph:
>
>    The Mutual authentication protocol proposed in this document is a
>    strong cryptographic solution for password authentications.  It
>    mainly provides the two key features:
>
> Exactly the same paragraph appears earlier in the same section. Did you
> forget to delete this instance?
>
> 3.2.  Values
>
>    The parameter values contained in challenge/credentials MUST be
>    parsed strictly conforming to the HTTP semantics (especially un-
>    quoting of the string parameter values).  In this protocol, those
>    values are further categorized into the following value types: tokens
>    (bare-token and extensive-token), string, integer, hex-fixed-number,
>    and base64-fixed-number.
>
>    For clarity, implementations are RECOMMENDED to use the canonical
>    representations specified in the following subsections for sending
>    values.  Recipients SHOULD accept both quoted and unquoted
>    representations interchangeably as specified in HTTP.
>
> I think the last SHOULD must be a MUST, because clients that generate
> these values
> might be using libraries that automatically quote values. So this is
> really not
> under sender's control.
>
>
> 3.2.2.  Strings
>
>    All character strings MUST be encoded to octet strings using the
>    UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
>    [ISO.10646-1.1993].
>
> This is the same as Unicode 1.1. Unicode now released version 9.0! I
> suggest you use a Unicode reference.
>
> In 3.2.3:
>
> I think you are overusing SHOULDs instead of MUSTs in many
> places in the document (not just just in this section). For example:
>
>    When
>    these values are generated from any cryptographic values, they SHOULD
>    have their "natural length"; if these are generated from a hash
>    function, these lengths SHOULD correspond to the hash size;
>
> Why not a MUST here?
>
>    if these
>    are representing elements of a mathematical set (or group), its
>    lengths SHOULD be the shortest for representing all the elements in
>
> Again, why not a MUST? Having a unique encoding will improve
> interoperability.
>
>    the set.
>
>    The numbers represented as base64-fixed-number SHALL be generated as
>    follows: first, the number is converted to a big-endian radix-256
>    binary representation as an octet string.  The length of the
>    representation is determined in the same way as mentioned above.
>    Then, the string is encoded using the Base 64 encoding [RFC4648]
>
> I assume you meant Section 4 alphabet and not Section 5 alphabet from
> this
> RFC. Please add section reference to the above.
>
>    without any spaces and newlines.  Implementations decoding base64-
>    fixed-number SHOULD reject any input data with invalid characters,
>    excess/insufficient padding, or non-canonical pad bits (See Sections
>    3.1 to 3.5 of [RFC4648]).
>
> 7.1.  Applicability notes
>
>    When the client is a Web browser with any scripting capabilities, the
>
> Can you explain why scripting capabilities are important here?
>
>    underlying TLS channel used with HTTP/TLS MUST provide server
>    identity verification.  This means (1) anonymous Diffie-Hellman key
>    exchange cipher suites MUST NOT be used, and (2) verification of the
>    server certificate provided by the server MUST be performed.
>
> In Section 9:
>
>    In both cases, it is the sender's duty to correctly prepare the
>    character strings.  If any non-normalized character string is
>    received from the other peer of the communication, recipients MAY
>    either use it as a bare UTF-8 string without any preparation, perform
>    any appropriate preparations (which may cause authentication
>    failure), or reject any ill-prepared inputs from the sender and
>    respond as a communication error.
>
> I think you are giving too many choices which might cause
> interoperability issues.
> Even reducing the choices from 3 to 2 would help here.
>
> In Section 11:
>
>       *  Otherwise, send a 200-VFY-S response.  If the session was in
>          the "key exchanging" state, the session SHOULD be changed to an
>          "authenticated" state.  The maximum nc and nc flags of the
>          state SHOULD be updated appropriate.
>
> Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are
> possible reasons for a server implementation to violate these SHOULDs?
>
> In Section 15:
>
> It would be good to be able to bind extension data to shared secret
> constructed by
> both parties.
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>



-- 

Best regards,
Kathleen