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

Alexey Melnikov <alexey.melnikov@isode.com> Sat, 31 October 2009 19:10 UTC

Return-Path: <alexey.melnikov@isode.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 D304E3A6782; Sat, 31 Oct 2009 12:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level:
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 r0WxzL6Y0rN1; Sat, 31 Oct 2009 12:10:42 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A61C13A6768; Sat, 31 Oct 2009 12:10:41 -0700 (PDT)
Received: from [94.197.211.97] (94.197.211.97.threembb.co.uk [94.197.211.97]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <SuyLwABfG3M5@rufus.isode.com>; Sat, 31 Oct 2009 19:10:58 +0000
Message-ID: <4AEC8BA9.3040202@isode.com>
Date: Sat, 31 Oct 2009 19:10:33 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Lonvick <clonvick@cisco.com>
References: <Pine.GSO.4.63.0910131301090.17359@sjc-cde-007.cisco.com>
In-Reply-To: <Pine.GSO.4.63.0910131301090.17359@sjc-cde-007.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Sat, 31 Oct 2009 19:10:42 -0000

Chris Lonvick wrote:

> Hi,

Hi Chris,
Thank you for the review.

> 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've updated comments in the ABNF to clearly indicate where various 
productions are coming from.

> I think that mostly all you need to do there is to copy the ABNF from 
> RFC 3112 and insert your values.

I don't think copying all productions defined elsewhere into this 
document is a good idea.

> 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.)

Ok, I've added a clarifying comment.

> 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.

I thought all three sentences are related to each other.

> 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.

Ok, I will try to rework this.

> 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.

Right. I will let RFC Editor handle that. I would like to use symbolic 
references, but xml2rfc doesn't make it easier without cut and pasting 
reference descriptions.