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

["Randy Presuhn" <[e-mail]>]

Hi -

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

> From: "Magnus Nyström" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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