Re: [netconf] ietf crypto types - permanently hidden

[Balázs Kovács <[e-mail]>]

Hi,

I agree with Juergen's view to add possibility of generating keys with an action that becomes (protected) configuration.

See more below.

/Balazs

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Friday, March 29, 2019 9:53 PM
> To: Kent Watsen <[e-mail]>
> Cc: Balázs Kovács <[e-mail]>; tom petch
> <[e-mail]>; [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> I agree, I think we need to distinguish
> 
> - upload of keys
> - generation of keys on the box that become (protected) configuration
> - generation of keys on the box that will to into hardware protected
>   storage (and never be accessible)
> 
> and the creation of a private key that becomes (protected) configuration is
> similar to the creation of a user account, where an unused uid is allocated
> that becomes configuration.
> 
> /js
> 
> On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote:
> > Hi Balazs,
> >
> > > In some implementations I can understand that backup/restore is via
> YANG interface, but backup/restore is possible by other methods too.  On
> the other hand, the private key material should be created and kept on the
> owner device according to best security practices and certification done by
> for example a certificate signing request.
> > >
> > > In that sense the generate-hidden-key action and the CSR creation action
> are solving the most common need for handling keys, and that is really
> regardless if the key is stored in a TPM, a file system, or centralized KMS.
> >
> > True.
> >
> > > I personally was fine with 'hidden' and I was also ok with the current
> actions, it was only the descriptions that seemed to be restrictive to TPM
> usage, thus I was asking some clarification. However, if 'hidden' is not true
> this way, then just call it 'generate-key'. Would that then create a binary
> string for the 'private-key' in operational too instead of 'permanently-hidden'
> thus you are referring to a 3rd option?
> >
> > As I understand it, your intention is to have users 1) use actions to generate
> private keys and CSRs and 2) that the private-key value is otherwise
> inaccessible to the users.   I don't believe you have a concern with the keys
> being "configuration" (since the nacm:default-deny-all makes the value
> inaccessible), and that the only bad part with the current model is that the
> user has to pass the private key value, which is bad because a) they are
> aware of the private key value and also it's possible that the private key value
> they generate is poor quality (e.g. having low entropy).

Yes. Correct. 

> >
> > This is effectively what was defined on page 22 in
> https://tools.ietf.org/html/draft-ietf-netconf-keystore-00
> <https://tools.ietf.org/html/draft-ietf-netconf-keystore-00> (we moved to
> the current strategy in the next version of that draft where (surprise!) the
> enum was called "INACCESSIBLE".   Some more history is here:
> https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez
> 48
> <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRve
> z48>.
> >
> > The main problem with this is actions don't typically create configuration,
> though we certainly could define this action as doing so (i.e., it locks
> <running> when called)...and we might even see ourselves doing this even
> for keys that are *interactively* generated by a cryptographic processor.  Of
> course, any keys generated by the vendor during manufacturing (i.e., the
> IDevID key) would still be operational state.
> >
> > In order to support systems that have crypto processors, since it may not
> be desirable to use the cryptographic processor for all keys, we need either a
> parameter or another action to direct the system to use the crypto processor
> to generate the key.
> >
> > Regarding what does "inaccessible" mean, the intention is that the value is
> not accessible for reasons beyond access control, with this driving use-case
> being a cryptographic processor.   Since the term (inaccessible) is being used
> in a YANG module, it stands to reason that it applies to all YANG-driven
> interfaces and that there is no statement regarding how it may or may not be
> "inaccessible" in other interfaces.  That said, the goal of YANG modules is to
> model reality, not just a view presented by YANG-driven interfaces, and I
> imagine great confusion ensuing if mismatches exist across interfaces.

I see, and agree. With the suggestion to make it mean "inaccessible via YANG interface" I think I rather meant all interface exposed to the same type of actor. For example if YANG interface is an external operator interface, then the key should of course be consistently inaccessible on all other type of external operator interface.

> >
> > I agree that the description statement for the "permanently-hidden"
> enumeration can be improved, how about this?
> >
> >     leaf private-key {
> >       nacm:default-deny-all;
> >       type union {
> >         type binary;
> >         type enumeration {
> >           enum permanently-hidden {
> >             description
> >               "The private key is inaccessible due to being
> >                protected by the system (e.g., a cryptographic
> >                hardware module).";
> >           }
> >         }
> >       }
> >       ...
> >     }
> >
> > Notes:
> >
> > 1) I removed the "It is not possible to configure a permanently hidden key,
> as a real private key value must be set." text because it was confusing and
> yet what's intended is self-evident (i.e., the leaf is a union of a value and an
> enum, only one can be passed).
> >

OK.

> > 2) I removed "Permanently hidden keys cannot be archived or backed up."
> text because it was a bit overreaching.  As mentioned, even TPM-protected
> keys can be backed-up/restored if shrouded and the restoration is to the
> same machine.  The more correct statement is "RMA workflows are limited",
> but it doesn't need to be said here.
> >
> >

OK.

> > If the goal is to open up these actions for general use, I think that we
> SHOULD update them to generate *configuration*.   Clearly the intent is that
> keys are configuration, use of the action should be seen as supporting a best
> practice, but otherwise shouldn't change the characteristic that interactively-
> generated keys are configuration.
> >

I'm fine with your proposal. I have no issues with actions generating configuration (but I never followed the discussions about actions and datastores) --that is relevant for backup--and we see the example of this keystore use case and also the user management use case Juergen brought up.

> > Thoughts?
> >
> > Kent // contributor
> >
> >
> >
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>