RE: discussions with Wes and results..

[Robert Moore <remoore@us.ibm.com>]

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
remoore@us.ibm.com


owner-netconf@ops.ietf.org wrote on 10/18/2004 08:48:38
AM:

> Hi,
> 
> A few comments on your proposed changes, inline.
> 
> dbh
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
> 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
> 
> 
> *** 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.
> 
> 
> 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 ----
> 
>       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.
> 
> 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).
<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>
> 
> +
> +    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 ****
> 
>          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/>
> 
> 
> 
> --
> 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/>