Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
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)" To: "Stephen Hanna" ; "Tom.Petch" ; ; ; 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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; sec...@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-l...@tools.ietf.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:sisyp...@dial.pipex.com] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; > > draft-ietf-netconf-partial-l...@tools.ietf.org > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > > > - Original Message - > > From: "Stephen Hanna" > > To: ; ; ; > > > > 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 edito
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman > said: AB> Oherwise the agent would deadlock. AB> discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. AB> It just resets the scratchpad database. AB> Why bother applying the ACLs before the edit operation AB> is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). AB> Requiring small embedded devices to serve as robust AB> database engines may be more expensive than AB> the rest of the code combined. We are coming from AB> an operational environment based on humans using the CLI, AB> which has no locking at all. The globally locked AB> candidate "edit, validate, and commit" model AB> is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using "vi" and hitting "save" without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I think "being fixed" is a great long term goal. But for right now, I'd suggest we simple say "this is version 1 at the moment and it is currently designed for use by single-operator systems". (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman > said: AB> discard-changes only works because authorization is ignored, AB> otherwise the agent would be deadlocked. Huh why would discard-changes be authorization ignorant??? That's just as unsafe (unless you're only discarding your own changes). AB> Only the global lock operation defined in RFC 4741 AB> can prevent this problem. The global lock has different issues. The problem isn't with the locking. Locking, and partial locking are good. It's with the global-level commit operation. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Wes Hardaker wrote: >> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman >> said: > > AB> Oherwise the agent would deadlock. > AB> discard-changes does not affect the running configuration. > > No, but it does affect the other users notion of changes. You should > never be allowed to discard changes that another user has made. > this assumes you have an access control model in mind. I do too -- they aren't the same. Without any standards for this, neither of us are wrong. > AB> It just resets the scratchpad database. > AB> Why bother applying the ACLs before the edit operation > AB> is attempted for real? > > user 1: add new important policy configuration > user 2: discard-changes > user 1: commit > > Granted, user 1 should be using locks of some kind. > what is the NETCONF 'add new' operation? step 1 is very unclear. > To undo changes it's rather important that someone with proper > authorization to the everything changed (IE, an admin) performs the > discard. > > Or are you suggesting that one shouldn't ever have access control > applied to the candidate store in the first place? (I hope not). > I apply it to the candidate and to running, except discard-changes, otherwise the agent would deadlock often and that would be counter-productive to network operations. When you start with an awful design premises like locking should be optional to use, then you might end up with messy code. Nothing new there. > AB> Requiring small embedded devices to serve as robust > AB> database engines may be more expensive than > AB> the rest of the code combined. We are coming from > AB> an operational environment based on humans using the CLI, > AB> which has no locking at all. The globally locked > AB> candidate "edit, validate, and commit" model > AB> is way better than anything we ever had in SNMP or CLI. > > If you look at history of operating just about anything, after it gets > to a point where multiple operators need to scale things up you'll find > that eventually stuff gets put into a multi-user revision database type > system. We are far beyond the point where operators are editing single > flat-files using "vi" and hitting "save" without any form of revision > control. After that point, then went to locking version control systems > (sccs? I'm forgetting the early version-control system names). Then > people realized that caused huge headaches because the global file > locking, although it prevented some types of problems, caused a bunch of > other problems. Eventually more modern version control systems were > developed that allowed people to simultaneously edit things and only > get bothered when conflicts happen. This was a huge win, ask anyone who > works with version control systems. > > But now, in this space, we're going back to the older methodologies of > editing a single file and hoping that two people don't conflict (with or > without a lock). > again -- when locking is optional to use, the database is never going to be very good. > > I've said this before, but I'll repeat it now: netconf, from a > protocol-operation point of view, is designed to work in a > single-operator type environment. The instant you add multiple-users > with or without different roles all these problems come up. This is > actually just fine, but it needs to either: > > 1) be fixed so that these problems go away. > 2) stop being advertised as a multi-operator type solution. > I disagree. The partial-lock feature is not needed in every environment. NETCONF supports the SQL-like model (write directly to the persistent datastore) and that is good enough. Why does the scratchpad model need to be per-session? That is nice-to-have, but not important. > I think "being fixed" is a great long term goal. But for right now, I'd > suggest we simple say "this is version 1 at the moment and it is > currently designed for use by single-operator systems". > > (And it doesn't prevent an external version-control system for being the > master and pushing the config down. It just doesn't work on the device > itself). Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Wes Hardaker wrote: >> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman >> said: > > AB> discard-changes only works because authorization is ignored, > AB> otherwise the agent would be deadlocked. > > Huh why would discard-changes be authorization ignorant??? That's > just as unsafe (unless you're only discarding your own changes). > Oherwise the agent would deadlock. discard-changes does not affect the running configuration. It just resets the scratchpad database. Why bother applying the ACLs before the edit operation is attempted for real? > AB> Only the global lock operation defined in RFC 4741 > AB> can prevent this problem. > > The global lock has different issues. > > The problem isn't with the locking. Locking, and partial locking are > good. It's with the global-level commit operation. Requiring small embedded devices to serve as robust database engines may be more expensive than the rest of the code combined. We are coming from an operational environment based on humans using the CLI, which has no locking at all. The globally locked candidate "edit, validate, and commit" model is way better than anything we ever had in SNMP or CLI. If concurrent edits instead of serialized edits are needed, then the :writable-running + :partial-lock capabilities support that. Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Stephen Hanna wrote: > 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. > The partial-lock operation does not work on the candidate database, yet the draft insists that this database is supported. It also says it works on the startup database, yet there is no way to edit this database, so why does it need to be partially locked? There is a global commit operation issued by a session. That session must be authorized to make all the changes to the running config that are contained in the candidate (all-or-nothing). The partial-lock design does not really have any affect on the candidate -- using it is just as ineffective as not using any locking at all. So it is subject to the 'candidate-deadlock' first described by Wes Hardaker: Let's say there is a simple config to edit: 3 fred Let's say user A is authorized to write /foo and user B is authorized to write /bar. 1) user A does partial-lock(target='candidate', data='/foo') 2) user B skips the lock and just edits the /bar leaf directly in the candidate database (even if user B took out a partial lock on /bar, the result would be the same) HALT: User A is not authorized to issue commit User B is not authorized to issue commit The database is wedged until somebody issues a discard-changes. discard-changes only works because authorization is ignored, otherwise the agent would be deadlocked. Only the global lock operation defined in RFC 4741 can prevent this problem. > Thanks, > > Steve Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-netconf-partial-lock-09.txt
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:berti...@bwijnen.net] > Sent: Thursday, August 13, 2009 7:35 AM > To: Stephen Hanna > Cc: Tom.Petch; sec...@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-l...@tools.ietf.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:sisyp...@dial.
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:sisyp...@dial.pipex.com] Sent: Thursday, August 13, 2009 4:00 AM To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; draft-ietf-netconf-partial-l...@tools.ietf.org Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt - Original Message - From: "Stephen Hanna" To: ; ; ; 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
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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; sec...@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-l...@tools.ietf.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:sisyp...@dial.pipex.com] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; > > draft-ietf-netconf-partial-l...@tools.ietf.org > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > > > - Original Message - > > From: "Stephen Hanna" > > To: ; ; ; > > > > 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 > > > a
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:sisyp...@dial.pipex.com] > Sent: Thursday, August 13, 2009 4:00 AM > To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-l...@tools.ietf.org > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > - Original Message - > From: "Stephen Hanna" > To: ; ; ; > > 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 Grou
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
- Original Message - From: "Stephen Hanna" To: ; ; ; 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.o
secdir review of draft-ietf-netconf-partial-lock-09.txt
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. 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
