Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)

["Randy Presuhn" <[e-mail]>]

Hi -
 
> From: "Martin Bjorklund" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Saturday, January 11, 2014 1:13 AM
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
...
> > 5) The security implications of not using the RFC3414 method for cloning and
> > key change are not discussed.
> 
> NETCONF generally over a secure and encrypted transport (this is
> pointed out in the Security Considerations section) hence the SNMP
> cloning mechanism is not needed.  I am not sure what kind of text you
> are looking for.
...

There's more to cloning than transport security.  The way keyChange works
requires the cloner to know the authKey/privKey of the clone-from user as
well as the secret key(s) to be used for the new user.

The Netconf client does not need to know a cloneFrom authKey/privKey to
create new users, nor does it need to reference an existing user to clone
from.  Both of these are paths permitting the potential creation of users with
combinations of protocols not represented in the usmUserTable, or to which
clone access would have been effectively blocked by an unpublished key change.
This could, for example, result in a situation where the SNMP security administrator
has blocked the ability for delegated administrators to create a noAuth/noPriv
user, but left them the ability to create auth/priv users; yet the Netconf interface
would restore that ability to those delegated administrators.

That's a fairly obvious security implication.  There are probably subtler ones, too.
I don't know whether you consider it a problem, but the properties *are*
different and should be systematically thought through and documented.

Randy