access control issues

[Andy Bierman <ietf@andybierman.com>]

Hi,

I am somewhat concerned about the lack of specificity in the NETCONF
protocol document regarding proper access control techniques.

We can say when and where access control must be applied, without
specifying an access control model.  (IMO, without a model, we actually
are choosing the "everybody has access to everything" model, which
is known to be broken and obsolete.)

The document should say somewhere that access control (i.e., user's
ability to access specific portions of particular configurations in
particular ways) MUST be enforced, and error(s) returned (if needed),
instead of other protocol, rpc, or application errors, that would
otherwise be returned.

For example, a user shouldn't be able to issue a <validate> command on
the <candidate>, for config data for which that user has no access.

As for Wes' multi-mgr w/o locking scenario (mgr A allowed to access "foo",
mgr B allowed to access "bar"): IMO, together the shared <candidate> is 
wedged.
Neither A or B should be allowed to invoke ANY of NETCONF operations 
related
to <candidate> at this point -- not even <discard-changes> in the 
strictest sense.
(Locks are there for a reason -- use them or risk this outcome. ;-)

Andy




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