Subject: RE: [Isms] Re: securityName/groupName

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 23 Aug 2005 23:02:29 +0200

Inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Kaushik Narayan
> Sent: Tuesday, August 23, 2005 22:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] Re: securityName/groupName
> 
> 
> Hi David,
> 
> I think updating the vacmSecurityToGroupTable behind the scenes
> would not be a good idea since this would actually become part of the
> configuration of the SNMP engine. The groupName would be passed
> down from the RADIUS server for every session so I would consider
> part of the session state and not really long term configuration.
> 
> I think it would be preferable that would an additional parameter to
> the ASI.
> 

It has been a long time that I worked on the SNMPv3 Architecture document
i.e. RFC3411. But I do recall that we tried to make the ASIs such that
we would not have to change them for new access or scurity models.
Now we may have failed in doing so, but if my recollection is correct,
then I would hesitate to change any ASI unless we absolutely have to.

Dave Harrington wrote in an earlier message:

   4) let's add a parameter to the SNMPv3 ASIs for an accessFilterList,
   which in a standardized format contains a human-readable list of
   policy filters to be applied for that
   securityname/securityModel/securityLevel.

   This approach appends a new parameter, accessFilterList, to the ASIs,
   to be used with securityModel, securityName, and securityLevel for
   access control.

   Does this sound reasonable?

Could you pls list for me the ASI (or ASIs) that you think should be
modified. That way I can better think about what you are sugegsting

Bert
> regards,
>    kaushik!

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 23 Aug 2005 20:20:24 -0400

Hi Bert,

<toc>
	<ASI philosophy/>
	<ASI changes/>
</toc>

<ASI philosophy>
> then I would hesitate to change any ASI unless we absolutely have
to.

Our intention was to define the expected dataflows to support the
separation between the subsystems/models such that we would not have
to change them for new access or security models (or message models or
applications or transports ...). It is important to not modify the
ASIs in model-specific ways to accommodate specific new models.
However, I believe it was considered likely that, as we gained
experience, we might need to define additional dataflows between
subsystems, **for use by any/all models within the subsystems, and in
a way that created no dependencies between specific models within
different subsystems**. 

We felt that separating authentication and access control (which
included a user-to-group mapping) was adequate and appropriate. The
ASIs were built accordingly.

But, it appears there are three parts to the puzzle: authentication,
authorization (the user-to-group mapping), and access control (the
group-to-policies mapping). AAA binds the authentication and
authorization pieces together (e.g. RADIUS returns the authorizations
as a list of attributes in the Access-Accept message returned during
the authentication phase), so effectively this forces us to move the
user-to-group mapping functionality into the security subsystem. To
add user-to-group mapping into the architecture as a function of the
security subsystem instead of being a function of the access control
subsystem will require changing the expected dataflows (ASIs).

(or we need to accept the alternative approach that works like "the
authentication triggers the sending of authorization stuff that
magically appears inside the vacmSecurityToGroupTable", and "the close
of a session magically causes stuff to disappear from the
vacmSecurityToGroupTable." Ugh!)

Note that VACM has chosen group as the thing to map to access control,
and limits membership to one and only one group per user - "The
combination of a securityModel and a securityName maps to at most one
group." Other ACM models may use things other than group membership,
or support multiple groups/domains/etc per user, so I have proposed a
filterlist to name the (potentially multiple) things that would map to
access control policies.
</ASI philosophy>
<ASI changes>
Changing the ASIs:

It appears to me any ASI that passes securityName from the security
subsystem forward toward the access control subsystem would need to
include the filterlist (grouplist). It would presumably not be
necessary to modify any ASI that is outgoing. Here are the ones I
think would be affected:

processIncomingMsg() - the MP subsystem passes an incoming message to
the security subsystem, identifying the securityModel and
securityLevel; the security subsystem includes the filterlist it
received from AAA in its OUT parameters, with securityName. 

prepareDataElements() - the MP subsystem passes the filterlist to the
dispatcher.

processPdu() - the dispatcher passes the list to the applications
subsystem

isAccessAllowed() - the application passes the list to the access
control model

--
I think these ASIs would be unaffected:
sendPdu()
returnResponsePdu()
processResponsePdu()
prepareOutgoingMessage()
prepareResponseMessage()
generateRequestMsg()
<ASI changes/>

David Harrington
[email-masked]

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Tuesday, August 23, 2005 5:02 PM
> To: Kaushik Narayan; [email-masked]
> Cc: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Aug 2005 10:23:22 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, August 23, 2005 5:20 PM
...
> vacmSecurityToGroupTable." Ugh!)
...

I don't see what is so magical or so "ugh" about this alternative,
particularly if the table is augmented to indicate how an entry came
to be, so that, for example, the close of a session with a (redundant)
mapping didn't cause a non-volatile entry to be deleted.

Of course, I'm being consciously narrow-minded about finishing the
isms work, and am not particularly interested in enabling more.

> filterlist to name the (potentially multiple) things that would map to
...

I think we're one the verge of some serious over-engineering here.
How serious are we about defining other access control models,
and how much energy as part of the isms effort should go into
supporting them?  The architectural effort makes sense to me only
if we're actually planning to build something on that architecture.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Aug 2005 21:05:55 +0200

> if we're actually planning to build something on that architecture.

Since we talk about multiple ACMs: I never really understood how this
would work. How does a command responder choose the correct ACM to
apply if you have more than one?

My understanding is that each ACM would provide the isAccessAllowed
ASI - it remains unclear to me how the decision would be taken which
of these isAccessAllowed ASIs to call...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 15:25:32 -0400

The ASIs certainly are not perfect, and we knew that at the time we
published them.

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, August 24, 2005 3:06 PM
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: [Isms] Re: securityName/groupName
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Aug 2005 21:55:47 +0200

> The ASIs certainly are not perfect, and we knew that at the time we

Are you saying you also do not really know how multiple access control
models would work?

In my view, there is not a bug in the isAccessAllowed ASI or other
ASIs. What is simply missing is the mechanism to choose which ACM to
apply, or more concrete which data is used to select the ACM to
apply. RFC 3413 section 3.2 item (5) simply says that isAccessAllowed
is called and there are no provisions to determine the particular ACM
to choose. The same applies to RFC 3413 section 3.3 items (2) and (3).

If we conclude that multiple ACMs do not really work given RFC 3411
and friends, then we should be pragmatic and (a) drop all proposals
which would basically rely on a new ACM and (b) reduce the impact of
arguments which assume more ACMs will be defined in the future as this
is not as easy as the introduction of new security models (even though
this also turns out not to be all that easy ;-).

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 16:24:22 -0400

Hi,

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> 

The consensus of the SNMPv3 WG was to allow multiple ACM models.
Otherwise we wouldn't have bothered describing VACM as being one model
within the Access Control subsystem. Any solution that makes VACM the
only access control model violates the consensus of the SNMPv3 WG. But
that's history.

It could have been argued "How serious are we about defining other
security models?", not very long ago. USM meets all the requirements
we had defined as being requirements, but integration with other
security infrastructures was NOT one of the requirements. In fact, it
was a requirement that we have no dependencies on other security
infrastructure but now we've learned the operator community doesn't
like the USM approach.

Have you surveyed the equipment vendors? How many actually support
VACM in their products as a way to control access to the functionality
of the device? Have you surveyed the operators? How many actually use
VACM as a way to control access to the functionality of the devices in
their networks? 

My experience says VACM is not widely deployed. I think once we solve
the USM problem, oerators might start to use VACM, but I suspect we'll
learn the operator community doesn't like the VACM approach because it
doesn't leverage their existing access control infrastructure
(presumably neither the one applied to the CLI or to web-based
management).

Let's look at the future. One issue I have had with the IETF network
management community is a failure to consider the integration of its
various solutions.

We've had talks about "wouldn't it be nice if the various approaches
used a common database, etc." but most of that falls by the wayside.
Honestly, it hasn't been important that SNMP and NETCONF and CLI and
web-based managament share their databases, just as it has not been
important that SNMP local users and SSH local users be the same.

But now security has become one of the most important things in
networking, and network management is at the top of the scale for
vulnerability impact. Network managemnent must be secure, and security
requires balance. 

Network management protocols are simply interfaces to the underlying
instrumentation, whether you are using CLI, SNMP, NETCONF, or
web-based interfaces, or other approaches. They all access the same
instrumentation, and that instrumentation needs to be secured. [and
with legislation like Sarbanes-Oxley, you can believe that
corporatioons are getting very serious about making sure their
security doesn't have gaping holes.]

If I have a house with three doors, and I put ten deadbolts on one
door, five on the second door, and none on the third door, my house is
only as secure as the weakest door.

ISMS is addressing the need to balance security across NM interfaces
by adopting an SSH solution that is also commonly used by CLI, and by
NETCONF. It has similar security characteristics to the TLS used for
HTTPS. The ISMS SSH solution will presumably integrate with SSH
encryption and integrity checking and existing local "users" and
existing RADIUS "users". So message security and user authentication
are being balanced across multiple NM interfaces by our efforts here.

When we move to discussing access control, we need to consider how to
leverage existing access control mechanisms for other network
management systems, to ensure balanced security at the data level. No
other IETF NM protocol uses OIDs to organize its data. NETCONF might
adopt a hierarchical XML schema, which could then use a VACM-like
view-based approach to access control. [If SNMP adopts an XML
encoding, we might share such a schema and the resulting access
control.]  Web-based management typically works with documents; maybe
the W3C will develop an access control mechanism that is hierarchical
in nature, and a view-based access control mechanism could be applied
to web-based management. To my knowledge, most CLIs do not use a
hierarchical organization of attributes, but rather use a functional
approach to access control.

I think it highly likely the industry will need to develop a common NM
access control approach in order to provide balanced data security
across NM interfaces. I think SNMP may well need to define a new or
supplementary access control mechanisms to leverage existing and
future access control infrastructures.

The modular SNMPv3 architecture was defined so SNMP could evolve as
industry requirements changed. I think it would be a mistake to think
that VACM is the only access control model we will ever need in SNMP
(unless of course you want to work on the assumption that SNMP is
nearing death anyway, and then I question why we should bother doing
any of this work.)

David Harrington
[email-masked]