Re: [netconf] ietf crypto types - permanently hidden

[tom petch <[e-mail]>]

----- Original Message -----
From: "Rob Wilton (rwilton)" <[e-mail]>
To: "tom petch" <[e-mail]>; "Martin Bjorklund"
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, May 03, 2019 2:46 PM

> > -----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? 😉

Rob

I am wanting an action, generate key pair, that I can invoke, as opposed
to e.g. install hidden key.

The scenario I describe is an operational one, the user has a
configured, working device but the network it is now going to be used on
requires that a certificate be generated, which, yes, comes under the
general heading of OAM but is to me a different kind of configuration
compared to the initial configuration or updates driven by other
changes.

And I did comment earlier that I find the references to hidden and to
generate hidden misleading.  What I see generated is always a key pair,
not one half of a key pair. I do find the terminology mutating in a way
that seems unclear to me, something I may comment on once the
functionality has been agreed.

Tom Petch
>
> 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
> > > > >
> > >
> > >
>
>