Re: access control issues

[Andy Bierman <ietf@andybierman.com>]

Eliot Lear wrote:

> Andy,
>
> Please see inline.
>
> Andy Bierman wrote:
>
> > 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.)
>
>
> Yes, but nobody is saying that.  What we're saying is that we're not 
> standardizing the model.  Depending on who you are I might let you 
> change an interface or not.  I don't need to standardize a model to do 
> that (although it may help from a robustness perspective).

Of course every vendor can do some different proprietary access control 
scheme.
Or the IETF (or some other SDO) could develop a standard access control
scheme for NETCONF.   This is very coupled to the data modeling details,
so it's out of our scope. 

For the document, (IMO) we just need to specify that (for security 
purposes) access control
violations should cause application level errors to be suppressed in 
<rpc-error>
responses, which might otherwise reveal information about data models 
supported
or instantiated by the device.

It would also be nice to specify that portions of data models selected 
through filters
for <get> and <get-config>, which cannot be returned because of 
insufficient access,
are simply skipped in the retrieval process instead of causing an 
'access-denied' error.
The same is not true for <edit-config> of course.  

The <validate> command (as you mention below) is an interesting case.
Should the agent skip over no-access data or abort with an access-denied 
error?
IMO it should be an error, because if the <validate> works then a followup
<commit> should work, but it won't in this case. 

> > 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.
>
>
> Arguably a user shouldn't be able to <validate> a <candidate> that was 
> generated by a different user.

Well, technically, there should be an access-control model, and
user X should only see the portions for which user X has been
given read access. IMO, whether the data can be read should be based
on the data itself, not who wrote it.

The shared <candidate> has a lot of problems, including this one.

Note that the document (sec. 8.7) does not say that
<validate> is affected by locking at all.  We decided
that <get> and <get-config> are not affected by locking,
so by the same logic, neither is <validate>.

> Eliot

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