[secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03

Chris Lonvick <clonvick@cisco.com> Tue, 13 October 2009 21:57 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1310A3A6971; Tue, 13 Oct 2009 14:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKXJt-k-lpu1; Tue, 13 Oct 2009 14:57:19 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 00BE73A6808; Tue, 13 Oct 2009 14:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=2749; q=dns/txt; s=sjiport06001; t=1255471041; x=1256680641; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Chris=20Lonvick=20<clonvick@cisco.com>|Subject: =20SECDIR=20review=20of=20draft-melnikov-sasl-scram-ldap- 03|Date:=20Tue,=2013=20Oct=202009=2014:57:20=20-0700=20(P DT)|Message-ID:=20<Pine.GSO.4.63.0910131301090.17359@sjc- cde-007.cisco.com>|To:=20alexey.melnikov@isode.com,=20pas i.eronen@nokia.com,=20iesg@ietf.org,=0D=0A=20=20=20=20=20 =20=20=20secdir@ietf.org|cc:=20Tom=20Yu=20<tlyu@mit.edu>, =20Kurt=20Zeilenga=20<kurt.zeilenga@isode.com> |MIME-Version:=201.0; bh=T9zu4JukYnmxB5J95YzTegnV3JzcJHFdxJeCcxYOlEE=; b=qCdLkWa0oh97KLB3ZCe3ydPawPrkxLfr8nLarmEP4Z3lc8pXG2QkG4yd 7nU3unUdqIuLHAmJoZLPqLjtUN/L5Fmbeyf3NNMYEBpiN5vhzoKBGwwg7 SrYA3xoEUGEBd7s/YJ0xZIUA+TgnOkzbYbEUhPJIlNyYXq8YwwR2JskwR Q=;
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvQEAIuU1EqrR7Hu/2dsb2JhbACPcgGxQpgshC0EgVs
X-IronPort-AV: E=Sophos;i="4.44,553,1249257600"; d="scan'208";a="408583010"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 21:57:21 +0000
Received: from sjc-cde-007.cisco.com (sjc-cde-007.cisco.com [171.69.23.150]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9DLvKKm005955; Tue, 13 Oct 2009 21:57:20 GMT
Date: Tue, 13 Oct 2009 14:57:20 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: alexey.melnikov@isode.com, pasi.eronen@nokia.com, iesg@ietf.org, secdir@ietf.org
Message-ID: <Pine.GSO.4.63.0910131301090.17359@sjc-cde-007.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2009 21:57:20 -0000

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Althought this isn't a WG document, it does state that discussion may take 
place on the sasl WG list, so I'm cc'ing the Chairs of that WG.

Overall, the concept is pretty straightforward and the description is 
succinct.  However, I do have some items that I would like to see 
addressed before I would recommend that this become an RFC.

Your ABNF is not complete.  You are using values taken from the complete 
ABNF in RFC 3112 so your ABNF is not going to properly parse.  I think 
that mostly all you need to do there is to copy the ABNF from RFC 3112 and 
insert your values.  You'll also need to define iter-count in the document 
somewhere.  (draft-ietf-sasl-scram-07 doesn't reference "iter-count"; only 
iteration count.)  Perhaps:
CURRENT:
       The "authInfo" part of the authPassword attribute is the iteration
       count, followed by ":" and base-64 [BASE64] encoded salt.
SUGGESTED:
       The "authInfo" part of the authPassword attribute is the iteration
       count [SCRAM] (identified here as the iter-count), followed by ":"
       and base-64 [BASE64] encoded salt [SCRAM].

An example is needed and I see that you have an anchor for that.  Please 
complete that.

Your Security Considerations section needs some work.  Each sentence you 
have there is actually a separate paragraph.  Rather than reworking that, 
I'd suggest that you start the section by stating that this specification 
utilizes the framework of RFC 4422 and the security concerns expressed 
there apply.  If needed, you could call out individual concerns from that 
Section 6.  Then you could call out any specific concerns that apply 
specifically to this document.

Just as a nit, you're mixing reference types.  RFC 3112 is referenced as 
[AUTHTYPE] whereas RFC 2119 is referenced as [RFC2119].  These should be 
consistent.

I'd also recommend that you revise the abstract a bit for clarity.
CURRENT:
    This memo describes how authPassword LDAP attribute can be used for
    storing secrets used by Salted Challenge Response (SCRAM) Simple
    Authentication and Security Layer (SASL) Mechanism.
SUGGESTED:
    This memo describes how the LDAP attribute of authPassword can be used
    for storing secrets used by the Salted Challenge Response (SCRAM)
    mechanism in the Simple Authentication and Security Layer (SASL)
    framework.

Best regards,
Chris