Minutes of the NETCONF WG session, 8 November 2010 ================================================== Many thanks to the minute takers Juergen Schoenwaelder, Lada Lhotka and Jabber scribe Wes Hardaker. The session started at 13:05, blue sheets were circulated. * Agenda Bashing - no change to the agenda * Abreviation of actors BW - Bert Wijnen ME - Mehmet Ersue AB - Andy Bierman JS - Juergen Schoenwaelder WH - Wes Hardaker Status of the drafts ==================== - Andy: I have a new version of -with-defaults Should I send it? Bert: Repository will open today, please send it. * NETCONF Access Control Model - Juergen: I am in favor of moving authorization out of the document, layering is desirable, it's better to stick with access control only. Bert: We can get it completed without finishing all the authentication details (local groups), I am in favor of finishing it asap. - Juergen: We can do better with group name provisioning than in SNMP. - Juergen: Radius has a separate issue - ssh authenticates before knowing the subsystem, so there is a chicken-and-egg problem with Radius. Andy: Confirms, in OpenSSH the auth process is indeed sequenced. BW asked who is in favour of keeping the document as is and who is in favour of move authentication details out of the access control document. He heard a hum in favour of moving authentication objects out of. - User to group mappings? It was discussed to keep the current user to group mapping. However, the document should consider dynamically provisioned user to group mappings in the elements of procedure. - Juergen: I think it doesn't belong here. Andy: It is a part of access control, once you are authenticated, what groups are you a member of? It is unclear yet whether or how to represent operational state representing user to group mappings. Juergen: Can you rephrase what we are talking about? Is the user-to-group a separate list? Andy: Yes. Groups only affect authorization. - What to do about copy-config side effects? If a user with partial access uses copy-config, the user gets the config she is allowed to read. If some root user does an with this config, all not included objects are discarded. - Bert: When somebody copies the config and doesn't get it all, then the server should tell the client. Andy: This is a case for RPC warning. Wes Hardaker: only makes sense as a root-only action. Andy agrees. Bert: Is that what we want to do? Should it be stated in copy-config description? Andy: It does say it's all or nothing. Martin Björklund (jabber) agrees with Wes. Andy: I'll write some text about it. After discussion, it was concluded that the basic approach in 4741bis and nacm is fine, perhaps documentation can still be improved. - Should we add an notification? - Wes: I personally don't care but some people want to know that. Dan: We have such notification in SNMP. Martin: It is not needed, we don't have it in SNMP, there is only one reporting auth. failures. There does not seem to be much interest. If anyone feels strongly about it, a concrete proposal should be brought to the mailing list. W3C XML access control ---------------- There are generic XML access control proposals, the WG might want to find out whether they are applicable and document (perhaps part of the document writeup) the conclusion. AB and JS made the point that a NETCONF database is not XML, NETCONF uses XML only as a serialization format. Bert: We should be at least be aware of this document to be able to answer questions. JS took an action item to post pointers to generic XML access control work to the WG mailing list. - Module identification (issue 1. in the ID) - Wes: Why are we creating exception? It's a user interface issue. Martin: In favor of module name, it has to be human readable, the NACM data is part of config, XML is not. JS suggests to make sure that the choice is consistent with /netconf-state/schemas/identifier. - Regular expressions (issue 3. in the ID) Nobody seems to ask for it. Andy: I am against regular expressions. - XPATH expressions (issue 4. in the ID) Martin: I am against XPath, AC is supposed to be simple. Nobody seems to ask for it. Tail-f does not support full XPATH. - access-denied (issue 5. in the ID) Already discussed. - path expressions (issue 6. in the ID) Need to check what YANG says about instance identifier and path expressions. - external access control (issue 7. in the ID) Not being done now since we do not plan to report operational state. - nacm:secure and nacm:very-secure (issue 8. in the ID) This is designed to simplify operational access control deployments. Wes: Is it so that even if the global config says everything is accessible, this tag makes certain data hidden? Andy: Yes. Wes: Does it apply to root? Andy: No. Wes: Who is the root? Andy: This is implicit. Wes: I am also worried about complexity. Andy: This is basically a formalized information that normally resides in a description. JS mentions that there will likely be many discussions what must be tagged as nacm:secure and nacm:very-secure across working groups. WH asks whether WGs not be better adviced to produce default ACM configs that achieve the same thing? This would perhaps be more flexible. We should try to get early security advice on this. Wes: What's the goal here? Operational environments have very different viewpoints on what should be secure. - Wes: This information should be specified in a way that stands out, not just as some attributes hidden in the structure. - Bert: This is a topic with a number of aspects to consider. - Martin: This is just a *default* security, sites can change it. - default access level (issue 9. in the ID) Wes: Generally you can do whatever you want. * NETCONF System Notifications Andy reviews the latest changes. JS likes to suggest some renaming to avoid system as a term, the notifications are netconf server specific and we should make this clear by some document renaming. - Martin: Is this system notifications over netconf or netconf server notifications? Andy: netconf server notifications. - Somebody from audience: Does the authentication-failed notification belong here? Andy: No, we don't have it here but I don't have a problem adding it. JS mentions that there is in principle a distinction between user authentication and session authorization. RADIUS likes to deal with this in a single operation, however SSH makes it hard to know whether a NETCONF session is being requested when user authentication is taking place. If we define an "authentication" failure notification, we probably need to be clear whether that really means "authentication failure" or both authentication and session authorization failure". Andy: The only important question we have is "Is the user allowed to use the NETCONF session?", why are you dividing it into two? Wes: RADIUS only knows yes and no. Proposals for fixing the EoM issue (Lada Lhotka) Lada presents the slides discussing the framing solution space for the unfortunate EOM marker problem. - Andy: I support the 0x04 marker the most since it does not require much code changes. - Wes: The EoM escaping method (#1) doesn't work, the sequence "]]>]]>]]>" won't be properly escaped. He should post a counter example. Why do you not simply look for the closing XML tag? This requires to parse the whole document. - Andy: What was the resolution about closing the session? My software just closes the session. Juergen: Why don't you tell the client what's happened? Bert: I believe the conclusion was to send an error message and not to close the session. Paul(?) does not recall what we do if we loose synchronization? Someone says that being cut&paste friendly is important. * Open Mike - Closing Sessions AB says that he simply closes the session if the document does not parse. He does not send an error. AB says that right now the WG concensus seems to be to send an error and to leave it implementation specific whether the session is closed.