ietf
[Top] [All Lists]

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

2009-08-13 09:22:01
Thanks to Dan and Bert for answering my question.
If most NETCONF implementations authenticate users
and implement some form of authorization scheme,
there should be no problem with including text
in draft-ietf-netconf-partial-lock-09.txt that
says "NETCONF servers that implement partial
locks MUST ensure that only an authenticated
and authorized user can request a partial lock."
Even a server that implements authentication but
does not implement fine-grained authorization
would meet this requirement. It would just be
saying that all authenticated users are fully
authorized to perform any operation on the server.

Are there any concerns with this proposal?
If so, please explain.

Thanks,

Steve

-----Original Message-----
From: Bert (IETF) Wijnen [mailto:bertietf(_at_)bwijnen(_dot_)net] 
Sent: Thursday, August 13, 2009 7:35 AM
To: Stephen Hanna
Cc: 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

Stephen,

I think it is your first bullet point. We have not standardize it yet.
And so it is implementation dependent as to what 
authorization is used.

Bert


Stephen Hanna wrote:
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
      
    
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


  

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