Re: discussions with Wes and results..

[Eliot Lear <lear@cisco.com>]

Hi Dave,

Thanks for your comments.  Please see my response inline.

David B Harrington wrote:
> 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.

<1> You're right and it doesn't matter here.
<2> It doesn't matter here.

Why?  You looked at the wrong side of the diff ;-)  Please see changed 
text below:
> --- 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.

Fair enough.

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

Em.  This was *supposed* to be a count of factors.
> 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?

Egads.  Some wordsmithing seems necessary.  The point was that one 
should be able to authorize based on underlying transport.  For 
instance, one may trust netconf/BEEP over netconf/SSH (or visa versa)
--
>       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?

It shouldn't be.  My point is that use of a AAA server and the locking 
of that user's account can provide a limited form of protection against 
a guy who's doing a DOS attack (or for that matter a runaway script) by 
locking your config.

 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.

Remember, this is a mitigation against an attack.  Furthermore, as far 
as NETCONF is concerned, this is not something your local end user is 
going to run unless your local end user happesn to be a network 
administrator.

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

Let me agree with the last sentence since it seems we didn't state the 
problem clearly enough for you to discern what it was ;-).  But we still 
need words to this effect in order to cover our bases in security 
considerations.

Eliot

--
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/>