Re: [netconf] ietf crypto types - permanently hidden

[tom petch <[e-mail]>]

----- Original Message -----
From: "Martin Bjorklund" <[e-mail]>
Sent: Friday, May 03, 2019 7:47 AM

> "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).
>
> 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.

Tom Petch

> /martin
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>