ietf
[Top] [All Lists]

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

2009-08-17 07:41:40
Stephen

As Dan and Bert think and believe, I guess #1.

My experience with other technologies is that where enterprise systems
are involved, then authorisation is likely to be powerful and comprehensive (and
proprietary) but where network and operators are involved, then this is not so.

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <dromasca(_at_)avaya(_dot_)com>
To: "Stephen Hanna" <shanna(_at_)juniper(_dot_)net>; "Tom.Petch" 
<sisyphus(_at_)dial(_dot_)pipex(_dot_)com>;
<secdir(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>;
<draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org>
Sent: Thursday, August 13, 2009 1:10 PM
Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

Steve, I believe that the situation is #1 below.

Dan

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Stephen Hanna
Sent: Thursday, August 13, 2009 1:53 PM
To: Tom.Petch; secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org
Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

Tom,

Thanks for responding to my comments. Allow me to respond.

You wrote:
As a participant in netconf, I see authorization as one of those
topics which the Working Group sees as necessary but cannot
be tackled
just yet.  As RFC4741 says, "  This document does not specify an
authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and as yet, there is no data model; hence, no
authorization, not yet,
nor, IMHO, for some time to come.

This is just the sort of background information that a WG
participant would know but that a secdir reviewer would not.
Please allow me to ask a clarifying question. You say that
there is no authorization yet.
I think that could mean several things:

1) Existing NETCONF implementations implement authorization, ensuring
   that each user gets an appropriate and perhaps different level of
   access to the database. However, there are no standards for the
   manner in which authorization is performed or configured.

2) Existing NETCONF implementations require authentication
but generally
   just give complete read-write access to the database to
all authenticated
   users.

3) Existing NETCONF implementations do not require authentication.
   Anyone with network access has complete, unfettered access to
   the database and can modify it at will.

Could you tell me which of these meanings is most accurate?
Of course, it could be a mix of these but I'd like to get
your real-world assessment of the state of the NETCONF world.
If the answer is 3), we have a serious problem! If the answer
is 1) or 2), that's acceptable in my view.

Now on to the language in the draft. My comment was relating
to this quote from the Security Considerations:

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

I'm afraid that this statement is not justified if there is
no normative text requiring implementations to comply. I
suggest that normative text be added to at least require
authentication.
With such text, the statement above could be justified.
Requiring that levels of authorization be implemented is less
important in this application. And standardizing the manner
in which authorization is performed or configured (which I
think is your concern with respect to the lack of a data
model) is really not important at all unless NETCONF
customers or vendors decide that it is. Standardizing an
authorization policy format is a tremendously challenging
task for any protocol and often not necessary.

I hope that this helps you address my comments in a
reasonable and achievable manner. The intent of secdir
comments is not to impose unreasonable requirements. It is to
point out issues that might not be evident to someone who is
not a security expert.

Thanks,

Steve

-----Original Message-----
From: Tom.Petch [mailto:sisyphus(_at_)dial(_dot_)pipex(_dot_)com]
Sent: Thursday, August 13, 2009 4:00 AM
To: Stephen Hanna; secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

----- Original Message -----
From: "Stephen Hanna" <shanna(_at_)juniper(_dot_)net>
To: <iesg(_at_)ietf(_dot_)org>; <secdir(_at_)ietf(_dot_)org>; 
<ietf(_at_)ietf(_dot_)org>;
<draft-ietf-netconf-partial-lock(_at_)tools(_dot_)ietf(_dot_)org>
Sent: Monday, August 10, 2009 4:28 PM

I have reviewed this document as part of the security
directorate's
ongoing effort to review all IETF documents being
processed by the
IESG.  These comments were written primarily for the
benefit of the
security area directors.  Document editors and WG chairs
should treat
these comments just like any other last call comments.

This document defines optional partial-lock and partial-unlock
operations to be added to the NETCONF protocol. These
operations are
used to lock only part of a configuration datastore, allowing
multiple management sessions to modify the configuration
of a device
at a single time.

The Security Considerations section of the document
highlights the
risk that a malicious party might employ partial locks to impede
access to a device's configuration. Therefore, it states "Only an
authenticated and authorized user can request a partial lock."
Unfortunately, I cannot find any normative text (MUST)
that supports
this statement. The NETCONF spec (RFC 4741) says "NETCONF
connections must be authenticated" but this is not clearly
normative. Perhaps a NETCONF expert can point to some
normative text
requiring authentication and authorization for any party
requesting
a partial lock. If not, I suggest that such normative
text be added
to the partial-lock specification.

As a participant in netconf, I see authorization as one of those
topics which the Working Group sees as necessary but cannot
be tackled
just yet.  As RFC4741 says, "  This document does not specify an
authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and as yet, there is no data model; hence, no
authorization, not yet,
nor, IMHO, for some time to come.  In the light of this, I
am not sure
what adding a normative statement to this I-D would do; delay
publication sine die?

Tom Petch




Another security concern that I have related to the partial-lock
operation is that the configuration might become
inconsistent if one
manager changes one part of a datastore at the same time that
another manager changes another part. The resulting inconsistency
could have security implications. For example, an
organization might
have a rule that either the firewall or the intrusion detection
features must be enabled on a device. If one manager might lock
intrusion detection configuration, check that the firewall is
enabled, and then disable intrusion detection. Another
manager might
lock the firewall configuration, check that intrusion
detection
is enabled, and then disable the firewall. If those
operations were
interleaved, they could result in a violation of policy.
To address this concern, I suggest that the draft contain
a warning
that parallel operations are tricky and should be carefully
considered. Sometimes, it may be necessary to lock a
portion of the
datastore that will not be modified, just to ensure the datastore
remains consistent and compliant with policy.

Of course, a human administrator using a GUI could easily
run into
this same problem if the human does not have the ability
to control
configuration locks. The human might look at the firewall
configuration to make sure that it's enabled and then switch to
another section of the display to disable the intrusion detection
function. If the management console only locks the datastore to
execute the administrator's request to disable intrusion
detection,
overlapping operations from another administrator could
result in a
bad configuration.
This problem can arise even without the partial lock operation.
Probably the best that can be done here is to include language
warning of this sort of problem. Warning human
administrators that
someone else is also editing the device should help and
giving these
administrators the ability to easily communicate with
each other to
coordinate their work would also probably help.

Here are a few minor issues:

* At the end of section 2.1.1.2, the comma in the last
  sentence is superfluous.

* In section 2.1.1.3 in the sentence "Manager A terminates it's
  session", the apostrophe should be removed.

* In section 2.4.1, I think that the sentence that begins with
  "If someone later creates a new interface" would be clearer
  if the second comma was changed to "so".

* Later in section 2.4.1, the sentence that begins with
  "A NETCONF server MUST" should instead start with "A NETCONF
  server that supports partial locks MUST". I think that
  paragraph should end with "all of the overlapping locks are
  released" not "all of the locks are released".

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf