RE: [Isms] Re: modularity

["David B Harrington" <ietfdbh at comcast.net>]

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

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.

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

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.


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

Why does the SM need to know this? 

> ...
> 
> I think we're in agreement here.
> 
Agreed

David Harrington
dbharrington at comcast.net




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