Re: Proposed Update to Netconf Charter

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "David B Harrington" <dbharrington@comcast.net>
> Cc: "'Andy Bierman'" <ietf@andybierman.com>; "'Sharon Chisholm'" <schishol@nortel.com>; <netconf@ops.ietf.org>
> Sent: Tuesday, July 05, 2005 1:53 PM
> Subject: RE: Proposed Update to Netconf Charter
>
> HI,
>
> Two specific items...
> 1) I don't see the need for contexts in NETCONF data modeling,
>    since contexts are simply "a mechanism to add extra
>    indexing when the MIB designer failed to predict the future
>    evolution of technology" (or bandaid for poor MIB design).
>    With XML, I don't really believe this limitation is
>    present, and, thus, a "context" will not be needed.

However, netconf adds the notion of configuration datastores.
If there is ever any reason to treat different configuration datastores
differently, they'll need to be accounted for in the access control
model.  To me they resemble the SNMPv2p temporal domains,
which were part of what eventually morphed into contexts.

> 2) SNMP VACM access control is based on
>     1) the identication of the management information
>         (the variable name)
>     2) the operation type (read/write/notify)
>     3) the security model
>     4) the security level
>     5) the context
>     6) the group
>    It doesn't depend on the value of object instance. This
>    has resulted in MIB design patterns where objects are
>    made (unnaturally) into index object(s). The usual
>    case is where the security name (or group name)
>    is made into an index. Many other systems, especially
>    data base systems have access control based on
>    data values.

All the cases I have seen of using indexing information in conjunction
with VACM have been driven by the need to conveniently represent
ownership, rather than any requirement for the access control policy
to be sensitive to either the value of the object being set or the
value being proposed.

>    In the work that I have done explaining VACM, the
>    concept that what security level is used can affect
>    what can be accessed is always a very big surprise.

I believe this is more a comment on the level of awareness of
what goes into forming a security policy, than it is on VACM.
If access control policies for netconf cannot distinguish whether,
for example, the communication channel is encrypted or not,
then there's a serious defect.

>    So far, there is a single security model. If several
>    were present, then the number of entries in the VACM
>    table could increase by a factor of the number.

Only the vacmSecurityToGroupTable and vacmAccessTable
would be affected, though I think twisting VACM into securing
netconf data would be, well, twisted.  :-)

>    In general, the SNMP acess model is unlike anything
>    that most users are use to.

Agreed.

>   Thus, they can not
>    understand it, and its richness is typically never
>    used. It is also typically not used because the
>    objects used by management apps are not typically
>    characterized. Thus, most systems that I've seen
>    provide no restriction to management platforms, and
>    any restriction is done by a management platform
>    as to which management applications any specific
>    user can run.

I don't think these conclusions flow solely from the fact
that VACM is "different".  I think *any* non-trivial access
control model will be at risk of these same problems.

>    Thus, I would characterize VACM as completely missing
>    the target. It is too complex for typical usage,
>    and not rich enough for realworld usage.

I don't think anyone has suggested using VACM for netconf.
The heart of DavidH's question is how would access control
for netconf need to be different from VACM.

For example, if there is a need to control access to different portions
of the configuration based on a notion of ownership, then if one used
something like xpath to represent that aspect of the policy, one might
end up putting "owner strings" in, and end up with something uncomfortably
(from your perspective) similar to VACM's way of coping with the ownership
concept.

All this leads to the fundamental question of how much expressive power
netconf access control policies will need.

Randy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>