Re: [netconf] ietf crypto types - permanently hidden

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: 03 May 2019 07:48
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> "Rob Wilton (rwilton)" <[e-mail]> wrote:
> > Hi Martin,
> >
> > > -----Original Message-----
> > > From: netconf <[e-mail]> On Behalf Of Martin
> > > Bjorklund
> > > Sent: 01 May 2019 22:06
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [netconf] ietf crypto types - permanently hidden
> > >
> > > Hi,
> > >
> > > Juergen Schoenwaelder <[e-mail]> wrote:
> > > > On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote:
> > > > > Kent Watsen <[e-mail]> wrote:
> > > > > >
> > > > > > Correct, as I didn’t think there was consensus yet.  Perhaps
> > > > > > there is rough-consensus, and it may be that the only way to
> > > > > > gauge that is to try and see how much push back there is.
> > > > > >
> > > > > > Okay, so how about this, based on this thread, there appears
> > > > > > to be support to add a flag to control if a key should be
> > > > > > “permanently hidden” or not, in which case configuration is created.
> > > > >
> > > > > I (still) object to this.  Actions shouldn't create config.  We
> > > > > already have generic protcol operations to do this.  We go from
> > > > > a document-oriented configuration model towards a
> > > > > command-oriented model.  Not good.  In RESTCONF, the generic
> > > > > methods support things like ETags, which I suspect you don't want to
> replicate in this
> > > > > action?   Will the action support all error-options of edit-config,
> > > > > like rollback-on-error?
> > > > >
> > > >
> > > > Martin,
> > > >
> > > > do you have any proposal how to support the requirement to
> > > > generate a key on the device that is workable with a
> > > > document-oriented configuration model? Do you propose that the
> > > > action/rpc returns the public key information as result data that
> > > > then needs to be written back to the server and somehow matched to
> > > > the key that is cached on the device? Perhaps you have other ideas I can't
> think of?
> > > >
> > > > I think I would be happy to not have this special hack but then we
> > > > need a workable alternative. Key generation on devices is
> > > > something that is being used - and may be even more used in the
> > > > future the more we get special hardware support for storing keys.
> > >
> > > So the current draft supports two use cases:
> > >
> > >   1.  The client configures the private and public keys explicitly
> > >       (simple case).  Both keys are availible in the config and
> > >       operaional state.
> > >
> > >   2.  The client asks the device to generate a "hidden" key which may
> > >       be a key in special TPM hardware.
> > >
> > > For 2, the client configures the name of the key (in <running>).
> > > Then the client invokes the action (in <operational>).  The device
> > > generates a new key pair (perhaps in tpm-hw).  In <operational>, the
> > > public key is now visible and the private key has the special enum
> > > "permanently-hidden".
> >
> > Why is a separate action required to create the keys?
> >
> > Why is the configuration to generate a hidden key not sufficient for
> > the device to automatically allocate a key in the TPM module?
> 
> This is a very good question.  Why don't we have actions for "create-interface',
> "create-user" or "create-acl"?  In all these cases we have config that a device
> internally parses and translates to some internal procedure (perhaps ifconfig,
> adduser, iptables etc).

For me, the ideal goal is that the configuration is intent based.  I.e. rather than telling the device what sequence of steps it should perform, it is telling the device what state the device should be trying to get into.

So for an interface, the intent of the interface configuration is "I want interface XXX to exist on the device, be enabled, have this IPv4 address configured on it".  As a client, I don't care what internal steps the device needs to take to reach this state, if it gets to this desired state.  Similarly, if something transiently goes wrong on the device, then it should always try to recover towards the desired state expressed in the intended configuration.

I think that users is a slightly orthogonal issue.  I think that the external primary manageability key for users should be unique usernames.  Certainly, whenever I log into any machine it is my username that I use to identify myself.  When I look folks up in the directory I do it via their name, not their userid.  In some cases, it might be desirable to use the same userid across multiple machines.  This can be achieved by having extra optional configuration to express this.  Otherwise, I think that userids should primarily be treated as internal user identifiers that need to persisted along with any files associated with the user.

> 
> In a way, this case is different b/c the client needs control of
> *when* the key is generated.  We cannot copy & paste some config to another
> device and expect it to work exactly the same.  OTOH that probably is true for
> other things as well; if a user has been created in the config there might be files
> owned by that user stored in the home directory.
> 
> Also, we might need the option to re-generate the key (even though the current
> version doesn't support this).  But *this* could be done w/ an action (if we need
> to support it).

Exactly.  Using an action to regenerate an internally managed key is fine.  This is equivalent to an action to reboot a linecard or clear some statistics.  This hasn't changed the intent of what the desired state the system should be in.

The alternative to the action would be to remove the config, wait until the device has confirmed that the key is removed (in operational), and then configure it again.


> 
> What did I miss; what makes this case special so that it can't be handled like
> other config?

For me, I think that the special cases are:
 (i) The ability to force a key to be recreated (i.e. the action described above)
 (ii) The ability to program a client defined key pair in a private way that is not visible in the configuration.  Have we considered a solution that puts these into the configuration but has them encrypted with a device specific public/private key pair.

Thanks,
Rob


> 
> 
> /martin