discussions with Wes and results..

[Eliot Lear <lear@cisco.com>]

Rob,

Attached are some diffs of the changes that I'd like to see in the draft 
to address Wes' security concerns and one other omission.

Thanks,

Eliot


*** draft-ietf-netconf-prot-03.txt      Thu Oct  7 17:07:33 2004
--- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
***************
*** 521,530 ****

     The authentication process should result in an entity whose
     permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.  For
!    example, if the native user interface restricts users from changing
!    the network interface configuration, the user should not be able to
!    change this configuration data using NETCONF.



--- 521,529 ----

     The authentication process should result in an entity whose
     permissions and capabilities are known to the device.  These
!    permissions must be enforced during the NETCONF session.
!
!



***************
*** 2634,2639 ****
--- 2633,2657 ----

  8. Security Considerations

+    This standard does not specify an authorization scheme, as it was
+    viewed that such a scheme should be tied to a meta-data model or a
+    data model.  Implementators SHOULD also provide a well thought out
+    authorization scheme with NETCONF.
+
+    Authorization of individual users via the netconf agent may or may
+    not map 1:1 to other interfaces.  There are factors.  First, the
+    data models may be incompatable.  Second, it may be desirable to
+    authorize based on mechanisms such as netconf, telnet, ssh, etc.
+
+    In addition, operations on configurations may have unintended
+    consequences if those operations are also not guarded by the global
+    lock on the files or objects being operated upon.  For instance, a
+    partially complete access list could be committed from a candidate
+    configuration unbnownest to the owner of the lock of the candidate
+    configuration, leading to either an insecure or inaccessible device
+    if the lock on the candidate configuration does not also apply to
+    the <copy-config> operation when applied to it.
+
     Configuration information is by its very nature sensitive.  Its
     transmission in the clear and without integrity checking leaves
     devices open to classic so-called "person in the middle" attacks.
***************
*** 2679,2687 ****
     kill another netconf session programmatically from within netconf if
     one knows the session identifier of the offending session.  The other
     possible way to break a lock is to provide an function within the
!    craft interface.
!
!

  Enns, Editor           Expires December 18, 2004               [Page 48]
  ^L
--- 2697,2706 ----
     kill another netconf session programmatically from within netconf if
     one knows the session identifier of the offending session.  The other
     possible way to break a lock is to provide an function within the
!    craft interface.  These two mechanisms suffer from a race condition
!    that may be ameliorated by removing the offending user from an AAA
!    server.  However, such a solution is not useful in all deployment
!    scenarios, such as those where SSH public/private key pairs are used.

  Enns, Editor           Expires December 18, 2004               [Page 48]
  ^L
***************
*** 2766,2772 ****

        Margaret Wasserman, ThingMagic

!



--- 2785,2797 ----

        Margaret Wasserman, ThingMagic

!    The authors would like to awknowledge the members of the NETCONF
!    working group.  In particular, we would like to thank Wes Hardaker
!    for his persistance and patience in assisting us with security
!    considerations.  We would also like to thank Randy Presuhn, Sharon
!    Chisolm, Juergen Schoenwalder, Glenn Waters, David Perkins, Weijing
!    Chen, Simon Leinen, Keith Allen and Dave Harrington for all of
!    their valuable advice.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>