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

From: Magnus Nyström <[email-masked]>
Date: Mon, 16 Aug 2010 22:31:58 -0700

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

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 17 Aug 2010 07:53:22 -0400

Magnus Nyström writes...

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

Use of the term "or equivalent" is intended to cover the use of other AAA
protocols besides RADIUS.  For use with RADIUS, the User-Name and
Management-Policy-Id are required to use mechanism described in this
document.  For some other, hypothetical, AAA service the equivalent
attributes may have other names.  This is just a bit of editorial
future-proofing.  The other IETF standard AAA protocol, Diameter, inherits
the RADIUS attribute space, so these attributes are also available via
Diamter.

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

RFC 5607 allows zero or one instance of the Management-Policy-Id to occur in
any RADIUS Access-Accept message, so for RADIUS usage it would be only one.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 17 Aug 2010 12:43:46 -0700

Hi -

> From: "Dave Nelson" <[email-masked]>
> To: "'Magnus Nyström'" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Tuesday, August 17, 2010 4:53 AM
> Subject: RE: Secdir review of draft-ietf-isms-radius-vacm-09
>

> Magnus Nyström writes...
...
> any RADIUS Access-Accept message, so for RADIUS usage it would be only one.

Likewise, the design of VACM (RFC 3415) maps a (securityModel, securityName)
tuple to a single group.  If multiple (different) pairings were received from RADIUS,
(or from the security administrator) only the most recent would be in effect.  I think
this makes both operational and security sense.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 17 Aug 2010 14:03:41 -0700

Hi -

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

> From: "Magnus Nyström" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, August 16, 2010 10:31 PM
> Subject: Secdir review of draft-ietf-isms-radius-vacm-09
>

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

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

> clarify if this is inconsistent with the text in 7.2 or not (maybe I'm

Given Dave Nelson's explanation, do you still think a change is needed here?

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

Randy