Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 
> > What I object to is a third use case, where the action would modify
> > the config with the generated keys.
> 
> What is your proposal for how to address the best practice and, in some cases, 
> government requirement, that a private key never exists outside of a device 
> (controlled backups aside)?

Use the current "generate-hidden-key".  Note that the proposed 3rd
alternative does not address this requirement, since the private key will be
part of the normal config, and thus can be read by anyone (with the right
access).

> From https://revocent.com/best-practices-for-securing-private-keys: <https://revocent.com/best-practices-for-securing-private-keys:>
> 
>     "It’s crucial that the generation of the key be done on the same
>      system and the same local filesystem as the storage location.
>      Generating the key on a server and then transferring the key
>      back to the local system and storing it just adds multiple
>      points of vulnerability.  Why would you want to increase the
>      chance of your private key being compromised?"
> 
> 
> Additionally, SC-12(3) of NIST 800-53 says:   (note: the word
> "produce" is key here) 
> 
>     "Produce, control, and distribute asymmetric cryptographic keys
>      using [Selection: NSA-approved key management technology and
>      processes; approved DoD PKI Class 3 certificates; prepositioned
>      keying material; approved DoD PKI Class 3 or Class 4
>      certificates and hardware security tokens that protect the
>      user’s private key; certificates issued in accordance with
>      organization-defined requirements]."
> 
> 
> Many networking devices include an SSL-protected web-interface.
> 
>     1) Typically the interface is initially secured via a
>          self-signed certificate, which causes the browser to
>          display a nagging message when connecting, thus prompting
>          remediation.
> 
>     2) Almost all products include an ability to upload the 2-tuple
>          of a private key and a signed certificate.  This resolves
>          the self-sign cert issue, but the best practice and
>          government compliance concerns are not addressed.
> 
>     3) The better products have an ability to:
>           a) let the device generate the private key
>           b) let the device generate a certificate signing request
>              using its private key
>           c) upload to the device a certificate generated by an
>              external CA signing the CSR.   
>           [FWIW, Juniper's SRX device introduced this ability in 2011.]
> 
> The current model supports (2), as well as (3b) and (3c), we're just
> missing (3a),
> which is what the original `generate-asymmetric-key` action was for.

There must be some misunderstanding.  IMO, the current
"generate-hidden-key" clearly supports 3a.  The device generates the
key when this action is invoked.

> FWIW, from a product perspective, supporting (3a) is more important
> then supporting `generate-hidden-key` or `install-hidden-key` (so
> long as manufacturer-generated hidden keys are still supported,
> e.g., for IDevID certificates).  While client-generated
> permanently-hidden keys is goodness, it's not widely implemented.



/martin