[http-auth] AD review of draft-ietf-httpauth-scram-auth-11

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 27 November 2015 23:56 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEB71A895D for <http-auth@ietfa.amsl.com>; Fri, 27 Nov 2015 15:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 pdgeuCfFpp-z for <http-auth@ietfa.amsl.com>; Fri, 27 Nov 2015 15:56:00 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 48ABA1A8718 for <http-auth@ietf.org>; Fri, 27 Nov 2015 15:56:00 -0800 (PST)
Received: by wmuu63 with SMTP id u63so70210251wmu.0 for <http-auth@ietf.org>; Fri, 27 Nov 2015 15:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qg6NDfKD/LAvkN4CXKTKHXeuMCdQ/TNh6TWsXAYPptg=; b=CPVWYhitxfyx/BrZswhX8oJMS8KomU3jrrxKAyS/XZsKR6c+PPbC+uu5qIvJf4A39T YHCnEInVp6dLbrdOonnnZUzJzmjB8NEUsiYqN4SX29pNmgXkoEWb025tFYteKGfN9Y1N FFsoNyZfeoQ695b27XIWaRjTqtdhDdM+sjCCPidWYNdHXtHG7hvrQj33UsKLCL6zAPTy KsV1pRhGkfuS3b81xFjqFuDrNET8U3PDXt1w2WrXW8HRBbj5yu/k8QFmwVP4kLJE/api TSeJPYE2q2m+8U6xVhDWltobiEFh5C0/ghw3UafJqtPqH1nkhQ+SyGcxd+wg4aV2WWq9 Gpcg==
MIME-Version: 1.0
X-Received: by 10.28.224.7 with SMTP id x7mr13000891wmg.17.1448668558827; Fri, 27 Nov 2015 15:55:58 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Fri, 27 Nov 2015 15:55:58 -0800 (PST)
Date: Fri, 27 Nov 2015 18:55:58 -0500
Message-ID: <CAHbuEH5LqnaYLUvu5qutjN4TbzjGKkmg65B9VCnN0mjDKt=F-Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: "http-auth@ietf.org" <http-auth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/INWi1VOs8WPX8icJIF_bwuOsZHM>
Subject: [http-auth] AD review of draft-ietf-httpauth-scram-auth-11
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 27 Nov 2015 23:56:02 -0000

Hi Alexey,

Thank you for your work on this draft!

Question/Request:

I'd lie to see more text in the security considerations section on
SHA-1, limiting it's use and warning against it unless necessary.  The
Section 5, note on why SCRAM-SHA-1 is registered is helpful, but I
don't think it's enough.  It looks like this comment (recommendation
to not support SHA-1) came up in WGLC as well.  Additional text in the
security considerations on why it should not be used and that it is
here only in support of a couple of specific use cases will help.  I'm
sure this will come up again in IETF last call unless addressed.

Nits:
Abstract:
Up to you, but removing the word secure might be good since the only
thing secure about it is the session encryption protecting the
authentication:

Change from:

   The secure authentication mechanism most widely deployed and used by
   Internet application protocols is the transmission of clear-text
   passwords over a channel protected by Transport Layer Security (TLS).

To:

   The authentication mechanism most widely deployed and used by
   Internet application protocols is the transmission of clear-text
   passwords over a channel protected by Transport Layer Security (TLS).

In the abstract, digest method has it's issues too that are well
documented in the RFC published by this WG.  I'll let that go though.

2. In a few places, a sentence ends, but there is a space before the
ending period.  I'm sure the RFC editor would catch this, but it would
be better to resolve before it gets that far.  Her is an example from
section 5:

   *  a header consisting of a flag indicating whether channel
         binding is supported-but-not-used, not supported, or used .

3. Security Considerations

The first sentence should be a bit more explicit on what "security
layer" is being referred to, although the example helps.  How about a
change from:
  "If the authentication exchange is performed without a strong security
   layer (such as TLS with data confidentiality),"
To: "If the authentication exchange is performed without strong
session encryption (such as TLS with data confidentiality), "

4. Security Considerations:
It's safe to remove the last instance of the word "negotiation" in the
following sentence:
  "SCRAM does not negotiate a hash function to use. Hash function
   negotiation is left to the HTTP authentication mechanism negotiation."



Thanks!

-- 

Best regards,
Kathleen