Re: [netconf] ietf crypto types

Hi Tom,

Thanks for the insight.  Some comments inline ...

> -----Original Message-----
> From: tom petch <ietfc@btconnect.com>
> Sent: 03 May 2019 11:48
> To: Rob Wilton (rwilton) <rwilton@cisco.com>; Martin Bjorklund <mbj@tail-
> f.com>
> Cc: netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> ----- Original Message -----
> From: "Martin Bjorklund" <mbj@tail-f.com>
> Sent: Friday, May 03, 2019 7:47 AM
> 
> > "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> > > Hi Martin,
> > >
> > > > -----Original Message-----
> > > > From: netconf <netconf-bounces@ietf.org> On Behalf Of Martin
> Bjorklund
> > > > Sent: 01 May 2019 22:06
> > > > To: j.schoenwaelder@jacobs-university.de
> > > > Cc: netconf@ietf.org
> > > > Subject: Re: [netconf] ietf crypto types - permanently hidden
> > > >
> > > > Hi,
> > > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> wrote:
> > > > > On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund
> wrote:
> > > > > > Kent Watsen <kent+ietf@watsen.net> 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).
> >
> > 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).
> >
> > What did I miss; what makes this case special so that it can't be
> > handled like other config?
> 
> If I configure an interface, I am providing at least part of the
> information and anything that the device generates - interface name, MTU,
> privacy address - I can then see and may or may not be able to change.
> 
> When I generate a key pair, yes I want to see the public key but I have no
> interest in the private key.  I want the device, and it is the device not
> an individual user, to be able to do things with the private key, notably
> to generate a certificate for the device; I now see organisations where
> every device that is attached to the network must have its own certificate
> regardless of what the device is, who owns it, who is logged onto it etc.
> 
> So generate a key pair, keep the private private, use it for a certificate,
> but I will never change it, don't want to know it is, I just want it
> securely hidden - and it is unlikely that the notepad, smartPhone, laptop
> etc will have a TPM.
> 
> This is the policy of the most security-conscious organisation I know, the
> only one whose passwords would meet the criteria laid down in RFC, but it
> has only been around for a year or so so I expect others will follow suit.

This is all fine and sounds sensible to me.

The public key can be published in <operational>.

But why does there need to be a separate YANG action required to generate the public/private key pair on the device?

Why is the configuration intent of "I want you to use a securely allocated public/private key pair" (which could be in the configuration) not sufficient?

If the issue is that these keys need to persist over device restart, then I would think that the solution is for the device to securely persist these keys independently of the YANG configuration.

Thanks,
Rob

> 
> Tom Petch
> 
> > /martin
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >