Gen-ART LC Review of draft-ietf-nsis-nslp-auth-06
Ben Campbell <ben@nostrum.com> Tue, 31 August 2010 22:55 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ACD3A68D1; Tue, 31 Aug 2010 15:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.45
X-Spam-Level:
X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 6ThFclHI21My; Tue, 31 Aug 2010 15:55:14 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 18A993A694A; Tue, 31 Aug 2010 15:55:13 -0700 (PDT)
Received: from [10.0.1.13] (adsl-68-94-10-224.dsl.rcsntx.swbell.net [68.94.10.224]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o7VMtgMg093435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Aug 2010 17:55:43 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART LC Review of draft-ietf-nsis-nslp-auth-06
Date: Tue, 31 Aug 2010 17:55:37 -0500
Message-Id: <74BBA174-C2A2-49F4-89F6-873146DD6655@nostrum.com>
To: draft-ietf-nsis-nslp-auth.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 68.94.10.224 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Wed, 01 Sep 2010 09:24:40 -0700
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2010 22:55:15 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nsis-nslp-auth-06.txt Reviewer: Ben Campbell Review Date: 2010-08-31 IETF LC End Date: 2010-08-31 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as an experimental RFC. There are some minor issues that should be considered first, and a few editorial comments. -Major issues: None -Minor issues: -- section 3.2.7, 2nd paragraph: "The creator of this attribute lists every NSLP object..." Is there an order requirement? At least, the order in this list must match the order in the signature, right? -- section 4.1.1, 2nd paragraph: Is HMAC-MD5 still a reasonable choice for a single mandatory-to-implement algorithm these days? -- Section 6.4, 1st paragraph: This paragraph seems to conflate authentication with authorization. Integrity protection provides authentication, from which one can apply authorization policy. But it's not authorization policy in itself. -- Section 7, 3rd paragraph: This seems to conflict with 3.2.7 and 3.2.8, which only conditionally require AUTHENTICATION_DATA to be included. -Nits/editorial comments: -- section 2, paragraph 2, 2nd sentence: s/chose/choose -- section 2, 5th paragraph, 1st sentence: "...operation of the authorization is to add one authorization policy object" Does this mean "... operation of the authorization layer..."? -- section 4.2, 2nd paragraph: "The ticket can be presented to the NSLP node via Kerberos by sending a KRB_CRED message to the NSLP node..." Who presents it? "...must be known in advance..." Who must know it? -- section 4.3.1.1, 1st paragraph: "...X509_V3_CERT, AUTHENTICATION_DATA MUST be generated following these steps" Who must generate it? -- section 4.3.1.1, 2nd paragraph: "...verification MUST be done following these steps:" Who must do the verification? -- section 4.3.1.1, 7th paragraph: " ... the public key of the authorizing entity can be extracted from the certificate." I assume this step is not intended to be optional, but the language "can be" implies that it is. -- section 4.3.1.2, 1st paragraph: "...AUTHENTICATION_DATA MUST be generated following these steps:" Who must generate it? -- section 4.3.1.2, first bullet in list of steps: That's not really a step. --... Third bullet Who signs it? -- ... First paragraph after first bullet list: "verification MUST be done" Who must do the verification? -- section 4.4, 1st paragraph after bullet list: The Key-ID in the AUTHENTICATION_DATA allows to refer" "allows" is a transitive verb in this context. I suggest "... allows [some actor] to refer", or "...allows the reference..." -- section 6.2.3, general: It's not clear to me if you mean for QNE/PDP to refer to one or the other, or the combination of the QNE and PDP.
- Gen-ART LC Review of draft-ietf-nsis-nslp-auth-06 Ben Campbell
- Re: Gen-ART LC Review of draft-ietf-nsis-nslp-aut… Roland Bless
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-nsi… Russ Housley
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-nsi… Roland Bless
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-nsi… Lars Eggert
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-nsi… RJ Atkinson