RE: [Isms] Re: modularity

[Randy Presuhn <randy_presuhn at mindspring.com>]

Hi -

> From: David B Harrington <ietfdbh at comcast.net>
> Sent: Aug 1, 2005 5:08 PM
> To: 'Randy Presuhn' <randy_presuhn at mindspring.com>, isms at ietf.org
> Subject: RE: [Isms] Re: modularity
...
...
> > Agreed, and I think there is a legitimate question whether ephemeral
> > user/group mappings should be visible via SNMP at all.  I 
> > think they should
> > be, but the I think one could reasonably argue otherwise, as 
> > did the EUSM draft.
>
> And I think the best approach to this different sets of requirements
> is to define specific access control models that choose to expose the
> information or not. That would seem a better approach than trying to
> redesign the architecture or the subsystem to meet a new set of needs,
> when the architecture is already designed to accommodate multiple
> models to address different needs.

Though this sounds nice, I don't like where it leads: for each authentication
mechanism we might end up defining yet another access control mechanism,
which, if we stick with the MIB module structure you referred to a few messages ago,
would result in the need to distribute identical access control configurations to
multiple (for example) VACM-like MIBs that differ only in how their user/group
mapping gets populated.  That might be architecturally pure, but I think
it would be an operational problem.

> If we do decide to revamp the subsystem or the architecture to address
...

I don't think doing so would be terribly productive.

...
> > I think we're in agreement, though an implementation reality is that
> > events in the security subsystem might trigger the 
> > (not-necessarily-SNMP)
> > protocol exchanges that can eventually result in the arrival of 
> > user/group mapping updates.
>
> If any specific AC model **depends** on a specific Security model to
> provide that trigger, then there are dependencies between the models,
> and that is a bad thing. Likewise, if a specific security model
> **depends** on the AC model to apply the triggered authorizations,
> that creates a dependency.

Agree.  It should be able to work if the user/group mappings have been
configured through SNMP.  But from an operational perspective, we already
assume that user/group mappings will have been configured before a request
can be successfully processed.  The EUSM approach can be thought of as
just-in-time cache loading or just-in-time configuration, depending on whether
or not you think these dynamic mappings should be visible to management.

> But, if an AC model can take advantage of such behind-the-scenes
> configuration triggered by a security model that does this, but can
> also continue to function even if such a trigger is not provided by
> all security models, then one is not dependent on the other.  If the
> SM provides the information but the AC models in the system (e.g.
> VACM) are free to ignore such information, then we are not faced with
> inter-model dependencies. 

We are in agreement here.

> Of course, having optional features in SMs and ACMs increases the
> complexity of the designs, and having two subsystems responsible/not
> responsible for getting/triggering the appropriate configuration
> increases the ambiguity in the architecture/subsystem responsibility
> separation.

Yup, but it's really just defining procedures that spell out automatic delivery
of certain bits of information.  The existing SNMP specifications just allow an
incredibly large window for the delivery of these bits: any time before the
request that needs the user/group mapping.

...
> If the SM triggers an AAA-event, does it know about the re-routing to
> the AC subsystem? Does the AC system know who triggered and rerouted
> the information?

I think there is no need for SM (security model) to know that the AAA event will be routed to
the AC (access control) subsystem.  I think there is no need for the AC system to know what
caused the AAA information to arrive.  There is, unfortunately, a need for
the SM to know when the triggered AAA exchanges have finished.

> Are all SMs required to provide such functionality? Are all AC models
> required to utilize the mappings provided by the SMs? 

I think the answer to the first question is "no".  Only SMs that talk to AAA infrastructure
talk to AAA infrastructure.  :-)  I think the answer to the second question is that only AC
models that employ the bits of information that are also provided in the updates made
by AAA infrastucture could possibly
utilize the mappings.  So, for example, an access control model that did not have a group
concept would have no need to do anything with the AAA update, though it *might* use
the AAA update to ensure that the named user was recognized.

...
> VACM depends on a configured vacmSecurityToGroupTable to function
> properly. If EUSM-style authorization modifies the underlying
> instrumentation, which then is reflected in the
> vacmSecurityToGroupTable (just as if netconf or the CLI had been used
> to configure the underlying instrumentation which is reflected in
> vacmSecurityToGroupTable), then there is no **dependency** on a
> specific configuration approach, and if the EUSM-style configuration
> does not cause a Security model to manipualte
> vacmSecurityToGroupTable, then no dependency is created by the SM and
> ACM. 
...

I think we're in agreement here.

Randy

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms