[secdir] Secdir review of draft-ietf-isms-radius-vacm-09

Magnus Nyström <magnusn@gmail.com> Tue, 17 August 2010 05:31 UTC

Return-Path: <magnusn@gmail.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 F1D293A6927; Mon, 16 Aug 2010 22:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 5XMh5Qt1TNq2; Mon, 16 Aug 2010 22:31:40 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 00E723A6924; Mon, 16 Aug 2010 22:31:30 -0700 (PDT)
Received: by gyg8 with SMTP id 8so2657136gyg.31 for <multiple recipients>; Mon, 16 Aug 2010 22:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=beK+8opxGl2BhamekfX3Oq9FFpNatS0ZVFdvoDRsfTA=; b=bWhGm0xauhAEyMwVyXisZzBYFLRH2acSZgn+iy0D+GpscXbeGdjw26SNAdN8yorKtY K0Y8nIGe2pd56mTOFy0lTgAwP7/Kp92f3UtR6RTtP8y1577tzMS2AisjscpnkJMD7Dbz 411ezXxTAPoDsKZG7Jz6uOVn+3I+8zvDTYcRU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wdCx8UF0jXJB0PcEnx3A5a5HrW9Pj4jPZLIKwMq7cc/nltUDRlZsaA1GyYA3Q8rKsW rhyjzEp3wgFhJUpBQ9ETJpTNtfZ10plGEE2SjlaClrMLY/eAYpEd0t+R8sm/shS5mlsJ FE9sehtQ385Sw/9wcC/DIHKXh0peQLsJ+tugE=
MIME-Version: 1.0
Received: by 10.231.191.16 with SMTP id dk16mr1095713ibb.161.1282023118736; Mon, 16 Aug 2010 22:31:58 -0700 (PDT)
Received: by 10.231.145.67 with HTTP; Mon, 16 Aug 2010 22:31:58 -0700 (PDT)
Date: Mon, 16 Aug 2010 22:31:58 -0700
Message-ID: <AANLkTikOLU6mAXVMY-kJAHO4_9qiY+UFQZTAw2UWLM1d@mail.gmail.com>
From: Magnus Nyström <magnusn@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-isms-radius-vacm@tools.ietf.org
Content-Type: multipart/alternative; boundary="0016367d6d4296118b048dfe44fd"
Subject: [secdir] Secdir review of draft-ietf-isms-radius-vacm-09
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, 17 Aug 2010 05:32:06 -0000

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.

This document defines "the use of information provided by [AAA] services ...
to dynamically update user-to-group mappings in [VACM]." - it does this by
adding a module to the MIB and defining elements of procedure for the new
object types in this MIB.

The document reads well and has a good security considerations section. I
only have a couple of comments on Section 7:

1. (Editorial:) Suggest letting the first paragraph form a new
sub-subsection 7.2.1: "Required Information". Easier to reference.
2. In the current subsection 7.2, please clarify if all items are required
for "further processing" or not. The current text just states that User-Name
and Management-Policy-ID are.
3. Current sub-subsection 7.2.1 seems to indicate that neither the User-Name
nor the Management-Policy-ID are required (says "or equivalent"). Please
clarify if this is inconsistent with the text in 7.2 or not (maybe I'm
missing something here).
4. In Section 7.2.3, how many groups can a user be a member of for a given
securityModel in this design? Only one?

-- Magnus