Subject: access control issues

From: Andy Bierman <[email-masked]>
Date: Thu, 19 May 2005 10:36:58 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 May 2005 13:16:56 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "netconf" <[email-masked]>
> Sent: Thursday, May 19, 2005 10:36 AM
> Subject: access control issues
...
> instead of other protocol, rpc, or application errors, that would
...

It sounds like this would be different from the SNMP approach, which
doesn't leak information about the existence of objects to which access
is denied when responding to a get/next/bulk request.  Are you proposing
that the error would identify the specific element(s) in the configuration to
which access was denied, or would it be more of a blanket response that
*something* *somewhere* in the request ran afoul of the rules?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 May 2005 14:06:16 -0700

>*something* *somewhere* in the request ran afoul of the rules?
the latter -- blanket response - a generic access-denied is fine.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 19 May 2005 15:51:02 -0700

>>>>> On Thu, 19 May 2005 10:36:58 -0700, Andy Bierman <[email-masked]> said:

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

You may wish to look at the examples in the slides for in the
proceedings that I bought up about this topic a while ago (San Diego).
There are multiple oddities in processing access control that I think
should be mentioned because they're not entirely obvious from reading
the document.  This was one such concern.  The response to my
presentation at the time was access control specifications were beyond
scope.  I'll certainly be happy if a discussion about access control
requirements is put into the current document (not to define access
control, but to define the requirements on future access control
imposed by the current architecture).

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 May 2005 15:05:46 +0200

Andy,

Please see inline.

> 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).

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

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 May 2005 08:12:42 -0700

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

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

Andy