Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "David B Harrington" <dbharrington at comcast.net>
> To: <isms at ietf.org>
> Sent: Wednesday, June 10, 2009 2:53 AM
> Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
...
> Randy Presuhn described it best. The simplest way to approach this
> problem is to have the RADIUS authorization attributes simply there in
> the background. Screw the ASIs; we want to finish this within five
> years. A RADIUS-aware ACM can simply utilize the RADIUS attributes.
...

Lest I be credited with too much, let me re-cap the idea.  (I do not
claim to be the only person who's thought about it this way!)

(1) the RADIUS  authorization data includes the name of the
group of which this user is an authorized member.  (You can
call it a policy if you will, but to break out of chicken--egg
provisioning problems it must be possible to transform it into
a VACM group name without any prior configuration..)

(2) if one does not already exist, a corresponding entry is created
in the vacmSecurityToGroupTable.

(3) processing continues just like it would for any other transaction.

Details of step (2):
        vacmSecurityModel comes from the security model in use for this message
        vacmSecurityName obvious
        vacmGroupName comes from the RADIUS authorization data
        vacmSecurityToGroupStorageType volatile
        vacmSecurityToGroupStatus  active

If you really want to get fancy, you could AUGMENT  the vacmSecurityToGroupTable
with additional column(s) to make entries created in this manner behave like
elements in a age-out or LRU cache.

I *think* I went through this in more detail in the ancient "miasma" proposal
from the days when ISMS was just getting started.

The only "architectural" issue is that going through step (2) requires the
entity processing the request to be able to act like an SNMP CR application
operating on (rather than merely consulting) the VACM MIB (and possibly
an extension to that MIB).  This does *not* require defining any interfaces
that we don't already have.

Randy