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

Kathleen Moriarty <> Tue, 08 November 2016 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 546FD1295CB; Mon, 7 Nov 2016 17:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fwa6ox6lKYl1; Mon, 7 Nov 2016 17:44:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78CF11295BD; Mon, 7 Nov 2016 17:44:33 -0800 (PST)
Received: by with SMTP id b35so135378572uaa.3; Mon, 07 Nov 2016 17:44:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id t24mr6842297uaa.21.1478569472608; Mon, 07 Nov 2016 17:44:32 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 7 Nov 2016 17:44:32 -0800 (PST)
In-Reply-To: <>
References: <>
From: Kathleen Moriarty <>
Date: Mon, 07 Nov 2016 20:44:32 -0500
Message-ID: <>
To: Alexey Melnikov <>
Content-Type: multipart/alternative; boundary="f403045dd96030cec20540c0483a"
Archived-At: <>
Cc:, "" <>, The IESG <>,
Subject: Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2016 01:44:36 -0000


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,

On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <>

> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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


Best regards,