RE: discussions with Wes and results..

["Rob Enns" <rpe@juniper.net>]

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

Rob

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Monday, October 18, 2004 12: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.
> 
> 
> 
> --- 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/>