Re: [netconf] ietf crypto types - permanently hidden

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

Hi Tom, 

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: 03 May 2019 12:32
> To: Rob Wilton (rwilton) <[e-mail]>; Martin Bjorklund <mbj@tail-
> f.com>
> Cc: [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
<snipped>
> > > >
> > > > 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?
> 
> How else is the key pair going to come into existence?  The device is not
> shipped with one (although it is the sort of the thing that a Microsoft
> might organise if it becomes the norm).  A user (with suitable
> credentials) brings in his device, the organisation says 'generate key
> pair', and certificate, and the user is then good to go for however long
> they use the organisation's network, could be years; and yes, the public
> key, and certificate, must persist in the device across restarts but not,
> of course, if the hardware is replaced by fresh hardware - it is a device
> certificate, not a user certificate.

Sorry, I still don't get it, I'm missing something 😉

list crypto-keys {
  config true;
  key "name";
  leaf "name" { type string; }
  choice key-type {
     case explicit {
        leaf private-key { type binary; }
        leaf public-key { type binary; }
     }
     case auto-generated {
        leaf auto-generated { type boolean; default false; }
        leaf public-key { type binary; config false; }
     }
  }
}

If the client configures an entry in the list with explicit keys then that is what the server uses.

However, if the client configures an entry in the list with leaf "auto-generated" set that the device generates a public/private key pair and persists them internally.  The public-key is available via the config false leaf.  The private key is kept private.  No separate YANG action is required to instantiate the keys - it happens automatically due to the configuration.  What is the obvious step that I am missing as to why this doesn't work? 😉

Thanks,
Rob


> 
> Tom Petch
> 
> > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> >
> >