Subject: [Isms] Re: modularity

From: Randy Presuhn <[email-masked]>
Date: Mon, 1 Aug 2005 11:27:25 -0500 (GMT-05:00)

Hi -

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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 1 Aug 2005 19:30:57 +0200

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Aug 2005 18:08:06 -0400

Hi Randy,

Comments (as a contributor, not SNMPv3 co-chair) inline. 

> > By consensus of the SNMPv3 WG, the

Agreed that the dual nature of the documents makes it harder to see
the separation. The following text was included in the documents to be
100% clear that the document (or document section) is model-specific:

>From RFC3412 (SNMPv3-format message processing):
"7.  Elements of Procedure for v3MP

   This section describes the procedures followed by an SNMP engine
when
   generating and processing SNMP messages according to the SNMPv3
   Message Processing Model."

>From RFC3414 (USM):
"   This document describes the User-based Security Model (USM) for
   Simple Network Management Protocol (SNMP) version 3 for use in the
   SNMP architecture.  It defines the Elements of Procedure for
   providing SNMP message level security.  This document also includes
a
   Management Information Base (MIB) for remotely monitoring/managing
   the configuration parameters for this Security Model."

>From RFC3415:
"It is the purpose of this document to define a specific model of the
   Access Control Subsystem, designated the View-based Access Control
   Model."

I don't think there's much ambiguity in these statements.

> might be expiration dates on entries, etc.

I agree one could be designed for subsystem usage and it would likely
vary from VACM's, which was designed to meet model-specific
requirements not general-usage requirements.

> be, but the I think one could reasonably argue otherwise, as 

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.

If we do decide to revamp the subsystem or the architecture to address
what might now be considered oversights of the original
subsystems/architecture, then we should be aware of the implications
of the changes, and not overlook the original design decisions or
their motivation. I don't believe the changes being suggested were
oversights in the original design, but were deliberate choices to meet
modularity goals, and to meet WG consensus requirements such as "the
mandatory-to-implement models should have no dependencies on external
protocols" and "to not require a user/group mapping".

Let's not get hung up on the new requested features so much we forget
the original design decisions.

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

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. 

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.

> subsystem or the engine that is talking to the AAA server?)

I don't think splitting hairs between the subsystem and the engine is
helpful, and reminds me of the agent vs manager or "agent acting in a
manager role" distinctions of the past. Let's focus on architecturally
splitting the responsibility for different types of functionality, and
then remain consistent about the responsibilities.

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?

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

> those created / deleted via an ASI or netconf.

The underlying instrumentation can certainly be dynamically configured
by means other than SNMP, and then have the configuration reflected in
SNMP MIBs that can be used by the AC subsystem. As pointed out,
netconf and CLI are commonly used to configure SNMP MIB modules.

It certainly is common for SNMP events (incoming SETs or
NOTIFICATIONS) to cause events to happen in the underlying
instrumentation. 

I have concerns that the documentation not create dependencies between
specific subsystems or between specific models, in a manner that
contradicts the SNMPv3 WG consensus to require architectural
modularity. I view this as similar to ISMS not being allowed to
dictate to the EAP WG a new applicability statement, even though many
of the original SNMPv3 WG members are present here as well. If we're
going to change the architectural requirement for modularity, then we
should (gasp) re-open and update the architecture standard.

And let me be clear that I also have similar concerns about TMSM.

> mappings as needed is not as much of an abomination as one 

I don't consider it an abomination. I have concerns that if a
EUSM-style security model manipulates the entries in the
vacmSecurityToGroupTable, that would violate the Design Decision that
models should not reference the MIB modules of other models or other
subsystems, because it creates unwanted dependencies between models.

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 am not opposed to changing the architecture if necessary, or
extending the architecture with new ASI parameters or new caches, or
even making some aspects implementation-dependent, but I am opposed to
just ignoring the subsystem boundaries, which were defined by the
SNMPv3 WG to avoid ending up with a monolithic architecture that
suffered with hard-to-debug side-effects from every MIB object change
or semantic tweak.

David Harrington
[email-masked]