[Netconf] Netconf-partial-lock comment/discuss

[Balazs Lengyel <balazs.lengyel at ericsson.com>]

Hello ,
In the tracker https://datatracker.ietf.org/idtracker/ballot/3035 about the 
draft-ietf-netconf-partial-lock-09 you have the comment:

I'm sure security has been extensively debated in the context of
RFC 4741 and I don't want to rehash any debates.

I wondered whether (2.4.1.1)...

   Negative Response:

   If a lock is already held by another session on any node within the
   subtrees to be locked, the <error-tag> element is 'lock-denied' and
   the <error-info> element includes the <session-id> of the lock owner.

...was potentially giving out more information than necesary/desirbale.
Probably you need to state that the filter (2.4.1.1)...

   If access control denies the partial lock, the <error-tag> is
   'access-denied'.

...and (3.)...

      Only an authenticated and authorized user can request a partial
      lock.

...SHOULD be evaluated first. Otherwise, an unauthrised user can easily
determine the identities of the authorised users. In 2.4.1.1 this will
need reordering of the text as well as the "SHOULD" statement.

-----
ANSWER: OK, updated, access control will be checked first, however anyway only the sessionId 
would be available not the user name, so the security risk is minimal. From the stored new -10 
version:

  "Access control SHOULD be checked before checking
   for conflicting locks to avoid giving out information about other
   sessions to an unauthorized client."
-----

It also seemed to me that (3.) ...

   A lock that is hung for some reason (e.g., a broken TCP connection
   that the server has not yet recognised) can be released using another
   NETCONF session by explicitly killing the session owning that lock
   using the <kill-session> operation.

...seemed quite an amusing attack. But I presume that the session
issuing the <kill-session> is suitably qualified.

-----
ANSWER: This is part of RFC4741. Nothing about <kill-session> is new in this draft. Yes 
authorization and authentication should prevent such an attack.
-----

===

2.4.2.  <partial-unlock>

   The operation unlocks the parts of the datastores that were
   previously locked using <partial-lock> during the same session.

This is not true in the case of overlapping partial locks as previously
described. Just need to tweak the text a little.

Comment [2009-08-13]:

----
ANSWER: OK, added:"In case of multiple potentially overlapping locks, only the lock identified
                      by the lock-id is removed."
-----



Please indicate if you can accept these answers!

regards Balazs


--
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel at ericsson.com