Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman <[e-mail]>]

Stephen Hanna wrote:
> Thanks to Dan and Bert for answering my question.
> If most NETCONF implementations authenticate users
> and implement some form of authorization scheme,
> there should be no problem with including text
> in draft-ietf-netconf-partial-lock-09.txt that
> says "NETCONF servers that implement partial
> locks MUST ensure that only an authenticated
> and authorized user can request a partial lock."
> Even a server that implements authentication but
> does not implement fine-grained authorization
> would meet this requirement. It would just be
> saying that all authenticated users are fully
> authorized to perform any operation on the server.
> 
> Are there any concerns with this proposal?
> If so, please explain.
> 

The partial-lock operation does not work on the candidate
database, yet the draft insists that this database is supported.
It also says it works on the startup database, yet there
is no way to edit this database, so why does it need
to be partially locked?

There is a global commit operation issued by a session.
That session must be authorized to make all the changes
to the running config that are contained in the candidate
(all-or-nothing).

The partial-lock design does not really have any affect
on the candidate -- using it is just as ineffective as
not using any locking at all.  So it is subject to
the 'candidate-deadlock' first described by Wes Hardaker:

Let's say there is a simple config to edit:

  <config>
     <foo>3</foo>
     <bar>fred</bar>
  </config>

Let's say user A is authorized to write /foo and
user B is authorized to write /bar.

1) user A does partial-lock(target='candidate', data='/foo')
2) user B skips the lock and just edits the /bar leaf directly
   in the candidate database (even if user B took out a partial
   lock on /bar, the result would be the same)

HALT:

  User A is not authorized to issue commit
  User B is not authorized to issue commit
  The database is wedged until somebody issues a discard-changes.
  discard-changes only works because authorization is ignored,
  otherwise the agent would be deadlocked.

Only the global lock operation defined in RFC 4741
can prevent this problem.


> Thanks,
> 
> Steve

Andy