Subject: Re: discussions with Wes and results..

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Oct 2004 15:03:24 +0200

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

---

From: "Rob Enns" <[email-masked]>
Date: Mon, 18 Oct 2004 10:56:14 -0700

Thanks Eliot, I'll integrate the changes (and include further
revisions as necessary based on the followup discussion). 

Rob

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Monday, October 18, 2004 12:21 AM
> To: Rob Enns; netconf
> 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
> 
> 
> !    example, if the native user interface restricts users 
> from changing
> !    the network interface configuration, the user should not 
> be able to
> +    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 of individual users via the netconf agent 
> may or may
> +    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
> !    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.
> 
> 
>