Re: [Isms] Re: modularity

["Tom Petch" <nwnetworks at dial.pipex.com>]

I find myself thinking that user to VacmGroup mapping does not belong in either
SM or ACM and
that that is the crux of the problem.  Integration with existing security
structure means, for me, that the authoritative engine for this mapping is
elsewhere, in the organisation's security server, eg in RADIUS, so that placing
it in either SM or ACM is or will be a problem for SM or ACM or both.  Rather,
SNMP should only be caching this information for as little time as it needs it,
be that in 'manager', 'agent' or
whereever, a bit like the state references in the ASIs..

As I have commented before, SNMPv3 sets out to do everything for itself, to be
complete in itself, and that is no longer the market place we are in.

The actual access rules within VACM are a different matter, because they are so
SNMP specific so I do see them as properly part of an ACM MIB in the engine of
the Command Responder..

Tom Petch

----- Original Message -----
From: "Randy Presuhn" <randy_presuhn at mindspring.com>
To: <isms at ietf.org>
Sent: Monday, August 01, 2005 6:27 PM
Subject: [Isms] Re: modularity


> Hi -
>
> > From: David B Harrington <ietfdbh at comcast.net>
> > Sent: Aug 1, 2005 10:58 AM
> > To: 'Randy Presuhn' <randy_presuhn at mindspring.com>, isms at ietf.org
> > Subject: modularity
> ...
> > > (1) what does the architecture say about, for example, two
> > > different access control
> > > models making use of a commen table, if that table serves the
> > > needs of both models?
> >
> > "Elements of procedure plus the MIB objects which are needed for
> >          processing for a specific portion of an SNMP framework should
> >          be defined in the same document, and as much as possible,
> >         should not be referenced in other documents. "
> >
> > It was the consensus of the SNMPv3 WG that even models of the same
> > subsystem should not share MIB modules, unless the MIB model is
> > defined as a standard part of its containing subsystem (e.g.
> > SNMP-MPD-MIB) or a standard part of an overall architecture (e.g.
> > SNMP-FRAMEWORK-MIB). By consensus of the SNMPv3 WG, the
> > vacmSecurityToGroupTable is part of a specific model, and thus should
> > not be referenced by other models.
>
> That's not 100% clear.  I think one could reasonably argue that the user/group
> mapping concept belongs to the access control subsystem, and is not
necessarily
> limited to VACM.  The dual nature of the USM and VACM documents (they
> describe both the subsystem and a specific model) doesn't help here,
> but we didn't want the document explosion that would have resulted if we
> had separated everything.
>
> However, I also think it's fair to say that a properly general-purpose
user/group
> mapping designed for use by multiple access control models might look a little
> different from what we have today.  For example, the 1:N might be M:N, there
> might be expiration dates on entries, etc.
>
> > If they choose to use it, ISMS needs to decide whether an
> > xxxxSecurityToGroupTable should be part of a specific model proposal,
> > part of a subsystem, or part of an overall architecture.
>
> 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.
>
> > In my personal opinion, it will be relatively easy to define a table
> > that is part of an independent AC model; it be will harder to
> > officially modify the RFC3411 architecture to move responsibility for
> > user-to-group mappings into the security subsystem, and hardest to
>
> 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.
>
> > retrofit moving the responsibility from the AC subsystem to the
> > Security subsystem without officially modifying the architecture. Only
> > the first option appears to be within the ISM charter, but any
> > Transport-security approach will face the same problems.
>
> I think one could also think about it as events in the security subsystem
> triggering events that update access control:
>
> --(snmp)--> security--(aaa)-->server--(aaa)-->accessControl
> That is: security model decides to send something to AAA; the
> response is internally routed to accessControl (after all, is it the
> subsystem or the engine that is talking to the AAA server?)
>
>
> > > (2) how do ASIs handle information updates that don't
> > > correspond to an SNMP
> > > pdu, but rather contain information coming from a non-SNMP source?
> >
> > First let me respond to any assumption that ASIs are dependent on the
> > PDU:
> ...
> > So, RFC3411 doesn't state that the SNMP protocol must be used to do
> > the configuration.
> >
> > Does that answer your Not-entirely rhetorical question #2?
> ...
>
> We're largely in agreement, I think, but I'd like to emphasize the
> timing and sequencing (or lack of sequencing) rather than conceptual
> parameters and syntax.
>
> The invocation of the ASIs corresponds to a chain of events triggered
> by the receipt of a PDU or the decision by an application to request
> transmission of a particular PDU.  The ASIs don't address, for example,
> modification of configuration data through a CLI.  I think one could look
> at dynamic creation / deletion of user/group mappings via an AAA-like
> protocol as being no different, from the SNMP engine's perspective, from
> those created / deleted via an ASI or netconf.
>
> >From this perspective, I think an EUSM-like approach to obtaining the
user/group
> mappings as needed is not as much of an abomination as one might think.
>
> Randy
>
> _______________________________________________
> Isms mailing list
> Isms at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms


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