Subject: [Netconf] Netconf-partial-lock comment/discuss

From: Balazs Lengyel <[email-masked]>
Date: Mon, 19 Oct 2009 14:25:53 +0200

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: [email-masked]

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 19 Oct 2009 14:57:47 +0200

Adrian Farrel wrote:
> Good job. Very acceptable.
>
> Thanks,
> Adrian
>
>
Thanks Adrian

Bert Wijnen
document shepherd

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 19 Oct 2009 13:42:23 +0100

Thanks,
Adrian