Re: [netconf] ietf crypto types

---- Original Message -----
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "tom petch" <ietfc@btconnect.com>; "Martin Bjorklund"
<mbj@tail-f.com>
Cc: <netconf@ietf.org>
Sent: Friday, May 03, 2019 12:00 PM
Subject: RE: [netconf] ietf crypto types - permanently hidden

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

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.

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
> > > netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>
>