[no subject]

[owner-netconf@ops.ietf.org]

earn=3Dham=20
=09version=3D3.1.6
Received: from [194.199.18.100] (helo=3Dmx-serv.inrialpes.fr)
=09by psg.com with esmtp (Exim 4.63 (FreeBSD))
=09(envelope-from <cridligv@loria.fr>)
=09id 1GftgI-000Ksf-Hy
=09for netconf@ops.ietf.org; Fri, 03 Nov 2006 07:41:39 +0000
Received: from smtps.inrialpes.fr (smtps.inrialpes.fr [194.199.18.58])
=09by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id kA37fSv0025378=
;
=09Fri, 3 Nov 2006 08:41:29 +0100 (MET)
Received: from [192.168.0.2] (4be54-1-89-80-248-137.dsl.club-internet.f=
r [89.80.248.137])
=09(authenticated bits=3D0)
=09by smtps.inrialpes.fr (8.13.7/8.13.4) with ESMTP id kA37fS6P007697
=09(version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 verify=
=3DNO);
=09Fri, 3 Nov 2006 08:41:29 +0100
Message-ID: <454AF2B4.3040509@loria.fr>
Date: Fri, 03 Nov 2006 08:41:40 +0100
From: Cridlig Vincent <cridligv@loria.fr>
User-Agent: Thunderbird 1.5.0.7 (X11/20061027)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>, netconf@ops.ietf.org
Subject: Re: Access control [was: action RPC I-D]
References: <C1555612.21B37%sberl@cisco.com>=09<45300CC0.60203@andybier=
man.com>=09<4533466E.9080103@ericsson.com> <20061016.125830.90119364.mb=
j@tail-f.com> <45338A0B.8020306@andybierman.com> <45421D60.2080909@eric=
sson.com> <454227B7.8060801@andybierman.com> <4549CF2E.6000308@ericsson=
.com> <454A0415.4010508@andybierman.com> <454A1D02.3080602@loria.fr> <4=
54A451E.6080609@andybierman.com>
In-Reply-To: <454A451E.6080609@andybierman.com>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2=
 (mx-serv.inrialpes.fr [194.199.18.100]); Fri, 03 Nov 2006 08:41:29 +01=
00 (MET)
X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmast=
er@inrialpes.fr for more information
X-mx-serv-inrialpes-fr-MailScanner: Found to be clean
X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel,
=09SpamAssassin (score=3D0, requis 5)
X-mx-serv-inrialpes-fr-MailScanner-From: cridligv@loria.fr
Sender: owner-netconf@ops.ietf.org
Precedence: bulk

Andy Bierman a =E9crit :
> Vincent Cridlig wrote:
>> Andy Bierman a =E9crit :
>>> Balazs Lengyel wrote:
>>>> Hello,
>>>> I feel that we should be careful not to make access control to=20
>>>> complicated. While technically it is possible to design a good,=20=

>>>> fine grained access control model, I fear the user (operator) will=
=20
>>>> have difficulties understanding it.
>>>>
>>>> I see that read/write (and possibly disturb traffic) are three eas=
y=20
>>>> to understand concepts that might be executed by different people=20=

>>>> in the network operator's organization. On the other hand I don't=20=

>>>> see who would be the operator who is allowed to modify a route(or =
a=20
>>>> customer), but not to create a new one.
>>>>
>>>> I agree that operationally separating delete, replace, etc. is a=20=

>>>> useful notion, but I don't see the need for the same with access=20=

>>>> control.
>>>>
>>>
>>> I suggest that people implement NETCONF, and also implement
>>> some kind of ACM, and prove to operators and the WG that the
>>> design and feature set is necessary and sufficient.
>>
>>
>> We have some kind of implemented ACM which assumes an XML data model=
=2E
>> I don't know if it is necessary and sufficient ! Here is a quick=20
>> overview:
>>
>
> Sounds very good to me.
> I bet it could be easily extended to configure the RPC method
> access control as a list of Xpath expressions.
>
> There seems to be WG consensus that actions should not
> be modeled as data, but rather as RPC methods.  Therefore,
> restricting access to certain RPC methods (<delete-config>,
> <reset-device>, etc.) is going to be important.
>
>> Each permission is expressed with two things:
>> - an XPath expression, saying which nodes are concerned,
>> - an attribute which can be "r", "w", or "rw".
>
> What happens if Xpath expressions overlap (i.e. 1 or more nodes
> are selected by more than 1 Xpath expression)=3F

It does not matter. The authorized nodes are seen as a set of nodes, so=
=20
order is not important. When I build the list of authorized nodes, I=20=

just check that the new node is not already there. If one selected node=
=20
is a descendant of another, the descendant is dropped since you have=20=

access to the whole subtree defined by the ancestor.
There is no conflict since only positive permissions are possible.

>   Do you just
> execute the list in order, like an ACL on a router=3F

For get-config, access control is a post-process. We apply the "r" XPat=
h=20
expressions to the XML configuration data reponse. Every node that is=20=

not a child or a parent of one of the selected nodes is discarded from=20=

the reply. This works exactly like the #xpath filter.
For edit-config, access control is done before the processing. "w" XPat=
h=20
expressions are applied on the config data request. If not all nodes ar=
e=20
selected after propagation to the children and parents, then access is=20=

denied.
For copy-config or delete-config, you need "w" access on the root of th=
e=20
XML configuration data.

>
> Sounds interesting.
> You should write a draft about it.

Well, I already started to write a draft a few time ago but it needs=20=

some more work. I will submit it by the end of next week.

Regards,
Vincent





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