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

"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 17 August 2010 21:03 UTC

Return-Path: <randy_presuhn@mindspring.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 2CE933A6A3F; Tue, 17 Aug 2010 14:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.966
X-Spam-Level:
X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 BAaSTTLOHl8S; Tue, 17 Aug 2010 14:03:06 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2C8773A6A2E; Tue, 17 Aug 2010 14:03:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bLfHqafPdK8TAigm2PahAM2NP+vXapH4123kaWV2hYoyt+yhiYy5q7199LBQwyRr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.41.48.100] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1OlTJt-00047S-4Q; Tue, 17 Aug 2010 17:03:41 -0400
Message-ID: <00d501cb3e4f$ad1ba640$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: Magnus Nyström <magnusn@gmail.com>, secdir@ietf.org, iesg@ietf.org, draft-ietf-isms-radius-vacm@tools.ietf.org
References: <AANLkTikOLU6mAXVMY-kJAHO4_9qiY+UFQZTAw2UWLM1d@mail.gmail.com>
Date: Tue, 17 Aug 2010 14:03:41 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fec4a90bd2698274c7c120a740f9361f35350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.41.48.100
Subject: Re: [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 21:03:07 -0000

Hi -

Thanks for the detailed comments.  Responses in-line below.

> From: "Magnus Nyström" <magnusn@gmail.com>
> To: <secdir@ietf.org>; <iesg@ietf.org>; <draft-ietf-isms-radius-vacm@tools.ietf.org>
> Sent: Monday, August 16, 2010 10:31 PM
> Subject: Secdir review of draft-ietf-isms-radius-vacm-09
>
> 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.

Ok.  I just hope we don't get an objection to using the 2119 keyword :-).

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

Ok.  I'll add "All four of these pieces of information are REQUIRED."
The issue we're trying to address in that last sentence are that one
of those (externally provided parameters) might be present but invalid.

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

Given Dave Nelson's explanation, do you still think a change is needed 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?

Would it help to add this sentence at the end of 7.2.3?
      The structure of the vacmSecurityToGroupTable makes it
      impossible for a vacmSecurityModel, vacmSecurityName tuple to
      map to more than one group.

> -- Magnus
>

Randy