Subject: RE: [Isms] Re: modularity

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Aug 2005 02:47:48 -0500 (GMT-05:00)

Hi -

> From: David B Harrington <[email-masked]>
> Sent: Aug 1, 2005 5:08 PM
> To: 'Randy Presuhn' <[email-masked]>, [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 07:50:47 -0400

> mechanism we might end up defining yet another access control 

This is exactly what I'm trying to avoid. There should be NO
dependencies between specific security model and sepecific AC models.
If you're designing an AC model to match each security model, you're
not building per the RFC3411 architecture.

> or not you think these dynamic mappings should be visible to 

And I am in agreement with the just-in-time dynamic mappings, as long
as there are no dependencies between specific models. If the mappings
you want to make visible are the raw RADIUS data, then you need to
develop a RADIUS-specific MIB module to show them and if that depends
on a RADIUS-specific security model, you've got dependencies. 

I suggested a generic user-to-group mapping MIB module, that is
dynamically-configured behind-the-scenes from RADIUS and/or TACACS
and/or .... and then an AC model can use the securityName ASI
parameter for lookup purposes. I think this is just what you're
arguing for, and I have no problem with this as long as we avoid any
dependencies between specific models.

So it would not be a requirement that all security models must support
triggers to cause the population of this MIB module, and it would not
be a requirement that all AC models utilize this MIB module. The
specific security model does not depend on a specific AC model to
provide access control, and a specific AC model does not depend on a
specific security model to trigger the population. I could live with
that.

> the SM to know when the triggered AAA exchanges have finished.

Why does the SM need to know this? 

> I think we're in agreement here.
Agreed

David Harrington
[email-masked]