Hi Balazs,
Looks great! I have cleared.
Thnaks,
Tim
On 10/19/09 8:45 AM, "Balazs Lengyel" <balazs.lengyel at ericsson.com> wrote:
Hello Tim,
In the tracker https://datatracker.ietf.org/idtracker/ballot/3035
about the
draft-ietf-netconf-partial-lock-09 you have the comment:
Discuss [2009-08-13]:
[revised discuss: I now agree that 4741 is not updated by this spec.]
The following two issues (initially raised in Steve Hanna's late
secdir review
posted Monday
August 11, see the email for the gory details) are also blocking:
(1) The document assumes an access control mechanism is in place,
but does not
actually
impose this as a requirement. I would like to see this language
strengthened, since I do
not see reasonable deployment scenarios that leverage
partial locking and do not require
access control. That is, if partial lock is
supported an appropriate access control mechanism
MUST also be in place.
----
ANSWER: Updated text in 2.4.1 to indicate authentication is
MANDATORY and access control (if
implemented) must be also passed. Access control is not
standardized for NETCONF so we cant
make it mandatory, however it is strongly recommended (In the
security section). If access
control is implemented by the Netconf server, partial-lock must be
subject to it. Today
practically all implementations implement access control even if
in a proprietary way, so the
situation is quite good. Updated security section to indicate
this. Excerpts from the already
stored -10 draft:
2.4.1
" A partial lock operation MUST fail if:
o The requesting user is not successfully authenticated.
o The NETCONF server implements access control, and the
locking user
does not have sufficient access rights. The exact handling of
access rights is outside the scope of this document, but it is
assumed that there is an access control system that MAY deny or
allow the partial lock operation.
"
3. Security Considerations
" The same considerations are relevant as for the base NETCONF
Protocol
[NETCONF]. <partial-lock> and <partial-unlock> RPCs MUST only be
allowed for an authenticated user. <partial-lock> and <partial-
unlock> RPCs SHOULD only be allowed for an authorized user.
However
as NETCONF access control is not standardized and not a mandatory
part of a NETCONF implementation, it is strongly recommended, but
OPTIONAL (although nearly all implementations include some kind of
access control).
A lock (either a partial lock or a global lock) might prevent
other
users from configuring the system. The following mechanisms
are in
place to prevent the misuse of this possibility:
A user, that is not successfully authenticated, MUST NOT be
granted a partial lock.
Only an authorized user SHOULD be able to request a partial
lock.
...
"
----
Discuss:
(2) The complexities of specifying the scope for related
operations should be
highlighted,
along with the consequences of incorrect scoping.
(Steve's review
includes a specific example of the results when the scope is
specified without
considering related operations.)
I would also recommend adding a pointer in the security
considerations to
section 2.1.1.3, where
the dangers of multiple managers in a semi-coordinated
mode are detailed. The results are
sufficiently bad to merit a reminder in the
----
ANSWER: The complexities of specifying the scope and some related
issues are pointed out in 2.4.1
"
o If part of the running datastore is locked, this has no
effect on
any unlocked parts of the datastore. If this is a problem
(e.g.,
changes depend on data values or nodes outside the
protected part
of the datastore), these nodes SHOULD be included in the
protected
area of the lock.
o Configuration data can be edited both inside and outside the
protected area of a lock. It is the responsibility of the
NETCONF
client application to lock all relevant parts of the datastore
that are crucial for a specific management action.
"
Due to other comments the possibility of locking the candidate
database have been removed and
with that the whole use case (and the chapter 2.1.1.3).
----
Comment [2009-08-13]:
Steve's review included a number of editorial comments the authors
may wish to
consider.
----
ANSWER: Comments accepted, document updated. See the already
stored -10 draft for details.
----
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
