[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Access Control (was charter discussion)
hi
While we cannot solve the entire space of access control across all
perceivable protocols, if we are clever we might just not make the
problem worse.
We started to look at this in Netmod, but did not get too far. I am
quite glad to see it treated as a separate topic. People may wish to
take a look at section 2.3 of that specification
(http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-03.txt
).
What I think is the most promising is the first of the four classes of
access control discussed. This is based on a resource category. This
category would be solution (netconf, snmp, syslog, cli, etc) agnostic.
If we support this sort of coarse grain access control, perhaps not
exclusively, then this provides a hook for an achievable method of
defining cross-solution access control. We would not necessarily need to
define the 'miracle', but we would be enabling it.
Sharon
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
Sent: Monday, July 11, 2005 10:11 AM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: netconf@ops.ietf.org
Subject: Re: Proposed Update to Netconf Charter
On Mon, Jul 11, 2005 at 09:26:46AM -0400, Sharon Chisholm wrote:
> hi
>
> More or less. That and we should ensure that everything plays nice
> with a common security infrastructure, rather than each other
>
> ___________
> SNMP -------- / \
> / \
> CLI -------/ \
> | Miracle \
> Netconf -------\ |
> | /
> Syslog -------- \ \
> --------------
>
> As appose to
>
> SNMP <--miracle --> Netconf
> CLI <--miracle --> Netconf
> Syslog <--miracle --> Netconf
> SNMP <--miracle--> CLI
> SNMP <--miracle--> Syslog
> CLI <--miracle--> Syslog
We have VACM for SNMP and eventually we might have NACM for NETCONF.
There is no agreed access control mechanism for CLIs and syslog and I
think it is therefore out of scope to worry about this in the NETCONF
WG. I also believe that VACM is rather SNMP specific since it relies on
OID naming which luckily does not exist in NETCONF. So these two do not
align well and even if you were to try, you would have to solve the SNMP
naming to NETCONF naming coexistance/mapping problem as part of the
solution. So I still believe NETCONF needs a good enough ACM for
NETCONF, no more no less. This WG can't solve all the access control
problems out there.
Perhaps the only common denominator is the set of protocol specific
operations an authenticated identity is allowed to perform if you
consider integration. Everything above that which needs to be specific
to the data model and representation will be rather difficult (and
perhaps not even needed for a non-trivial class of operational
environments).
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen,
Germany
--
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/>