Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Hi,

Juergen Schoenwaelder <[e-mail]> wrote:
> 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)

So, the current model supports 1 and 3 above.

Do we have to support 2?  (and what does "(protected) configuration"
mean?  is this different from "configuration"?)

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

AFAIK there is no standard model defined that actually do this.

The closest thing we have is the "type" of an interface:

           When an interface entry is created, a server MAY
           initialize the type leaf with a valid value, e.g., if it
           is possible to derive the type from the name of the
           interface.

If private keys are handled like this, then I can accept it.  But we
should NOT introduce special actions/rpcs that manipulate the
configuration.


/martin


> 
> /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).
> > 
> > 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/OtYAlqLmlErfCr3Z4mcXqRvez48 <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48>.
> > 
> > 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 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).
> > 
> > 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.
> > 
> > 
> > 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.
> > 
> > Thoughts?
> > 
> > Kent // contributor
> > 
> > 
> > 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>