Subject: discussions with Wes and results..

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Oct 2004 09:20:38 +0200

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Oct 2004 08:48:38 -0400

Hi,

A few comments on your proposed changes, inline.

dbh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Eliot Lear
Sent: Monday, October 18, 2004 3:21 AM
To: Rob Enns; netconf
Subject: discussions with Wes and results..

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

      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.

Dbh> two points: 1) here yoy refer to the "native user interface" and
elsewhere you refer to the "craft interface". Are these the same? If
so, consistency would be good. I prefer natiuve user interface to
craft interface, because I don't know what craft is involved, and if
you have to be a craftsman to use it, it's probably not very
user-friendly. 2) How one coordinates NETCONF and the native user
interface is implementation-dependent.

--- 521,529 ----

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

+    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.

Dbh> I would eliminate the "it was viewed that" as being unnecessary.

+
+    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.

Dbh> I would eliminate "There are factors." as being unnecessary. 

Dbh> I'm not sure I know what point you are making in the second
factor. Are you saying that these other schemes don't support
user-specific authorization, or are you saying that other NM
interfaces may use these approaches and the NETCONF scheme may be
incompatible with them? If the latter, wouldn't it be good to suggest
using compatible schemes, and wouldn't that already be covered in the
first point? So I'm not sure just what the second point is. Maybe you
should simply make the point that an administrator should try to
deploy networking devices in which the multiple NM interfaces utilize
the same or compatible security mechanisms. (It would be nice, of
course, if the IETF made such a thing possible by defining standards
that utilized the same or compatible securtiy mechanisms).

+
+    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.

Dbh> ameliorated, huh? Does this have something to do with getting
lost at sea? Let me go get my dictionary ... ;-)

Dbh> I don't see how removing the offending user from the AAA server
does anything at all to ameliorate the situation. First, why is it
assumed that either NM interface utilizes a AAA server? Second, if a
AAA server is utilized, removing a user simply means the user's
authentication and authorization is no longer centrally managed, I
guess, and is likely to generate calls to the helpdesk when the user
is no longer allowed network access, or permitted to do other things
controlled using the AAA server. I don't see why that is an
improvement. If anything, I would think one could ameliorate the race
condition caused by inconsistent authorization by having both NM
interfaces use the same or compatible security schemes for their NM
interfaces, and utilizing a centralized AAA server to better
coordinate the authorizations. Therefore, I think you could ameliorate
the race condition by **adding** users to a AAA server. So this
paragraph needs some work.

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

!

--- 2785,2797 ----

!    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 [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Robert Moore <[email-masked]>
Date: Mon, 18 Oct 2004 09:16:36 -0400

Dave,

Admittedly, I've been following these discussions from a *great* distance. 
 But I read Eliot's second factor in a third way.  See <rem>/</rem> below.

Regards,
Bob

Bob Moore
Advanced Design and Technology
IBM Software Group System House
+1-919-254-4436
[email-masked]

> --- draft-ietf-netconf-prot-03e.txt     Thu Oct  7 18:01:27 2004
<rem>
I think the second factor is talking about something different from both 
of these: the idea that for a given user U and a given configuration 
object C, U will be authorized to performs different operations on C 
depending on which of the listed mechanisms was used.  At the very least,
that's a possible reading of "...authorized based on mechanisms...."
</rem>