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

Andy Bierman <> Thu, 13 August 2009 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2886028C0F1 for <>; Thu, 13 Aug 2009 08:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uHPnu7+FfyrG for <>; Thu, 13 Aug 2009 08:28:17 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id C956628C0EF for <>; Thu, 13 Aug 2009 08:28:15 -0700 (PDT)
Received: (qmail 657 invoked from network); 13 Aug 2009 15:25:18 -0000
Received: from unknown (HELO ? (ietf@ with plain) by with SMTP; 13 Aug 2009 15:25:18 -0000
X-YMail-OSG: bWQ0oZ0VM1nNdLT2TL7AWbez_vUN_jnlY5eQhKGiBJPwGPs30AfvH1hFSGtK6a6R9ddF7a9SQwzZhcZIoVkhH2_73VkkqvZcJ8txWjLZXxBZWUPrPxbS5NKTMGue_4ukt8128xtVNfDB00sozxrzgg5l4p6CH7H7nMnauXWoal1tMfXNqQxk.hVwU5p8PdCWTFKQBJab.vpBTsb8sluji6n.kKJnaCpLBCbGU39Cqt16Cn.QmRukuKYh_F1EdcHHrDSlZtecUJsM4t0-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Thu, 13 Aug 2009 08:26:54 -0700
From: Andy Bierman <>
User-Agent: Thunderbird (X11/20090608)
MIME-Version: 1.0
To: Stephen Hanna <>
References: <> <016701ca1bf7$400ac480$0601a8c0@allison> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 13 Aug 2009 08:31:49 -0700
Cc: "" <>, "" <>, "Bert (IETF) Wijnen" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2009 15:28:17 -0000

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

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:


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)


  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