Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11

[Kent Watsen <[e-mail]>]

Hi Yaron,

Thank you for your valuable comments.  My co-authors and I have the following
responses to your comments.



> On Nov 17, 2021, at 1:59 PM, Yaron Sheffer via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> This draft defines a mechanism for a device, when it first starts, to generate
> a CSR to get itself provisioned with one or more certificates it needs to
> identify itself during its normal operation.
> 
> * I was confused that the document starts out describing a generic cert request
> mechanism. Then deep into the YANG modules, it turns out that there is guidance
> (only?) for very specific types of certs, namely LDevID and IDevID. And the
> choice is non-orthogonal: it is unclear what is the guidance for other certs
> when using CMC and CMP, and conversely, whether these two certs can be
> generated with a PKCS#10 CSR.

We updated the YANG module to greatly remove references to IDevID/LDevID.

Specifically:
	1) s/IDevID/initial device identity certificate/g
	2) s/LDevID/local device identity certificate/g
	3) manually rewrap lines to col 69 as required
	4) removed the terminology-disclaimer block at top

The diff is here: https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d9874a85c604b <https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d9874a85c604b>

Good?


> * I suggest adding a Security Considerations section about the need for strong
> randomness, which is often unavailable to small embedded devices at the early
> stages of provisioning. I wish we were more successful with: 
> https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00

OLD:

    It is RECOMMENDED that a new private key is generated for each CSR
    described in this document.

NEW:

    It is RECOMMENDED that a new private key is generated for each CSR
    described in this document.

    This private key MUST be generated using a quality random source. The
    use of inadequate pseudo-random number generators (PRNGs) to
    generate private keys can result in little or no security.  An attacker may
    find it much easier to reproduce the PRNG environment that produced
    the private key, searching the resulting small set of possibilities, rather
    than brute force searching the whole private key space.  The generation
    of quality random numbers is difficult.  BCP 106 [RFC4086] offers
    important guidance in this area.

and we added an Informational reference to RFC 4086.

Good now?


> * Negotiation (?) of the CSR format and supported algorithms is unclear in Sec.
> 2.2: is it the client that provides the values it supports and the server picks
> one? Alternatively, is the list conveyed by the server in the error-info and so
> the client knows exactly what is supported? IOW, why include these values at
> all in error-info?

Section 2.1 states the sequence of exchanges, but we went ahead and added more context to the examples for additional clarity.  The diff is here: https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d427e843467d02 <https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d427e843467d02>

Better?


> * It is not clear from Sec. 2.2 how exactly the client is supposed to associate
> one of possibly multiple received certificates to the CSR it just sent out.
> Surely it is not expected to grep for the string "Newly-Generated"?

There doesn’t have to be any logic on the client to detect the signed certificate or, for that matter, to ensure that the server sent one at all.  The point  of the bootstrap process is to *configure* the SZTP-client, and the client's only post-update logic is to “run as configured”, whatever that might be.

That said, it wouldn’t be hard for a client to, e.g., search a “keystore" mechanism for a key having the key used in the CSR and then search certificates associated with that key for that cert having the matching attributes (e.g., the “Subject” attribute) as in the CSR.

Makes sense?   [No update to the draft was made to address this comment]


> * 2.3: the description of "error-info" still does not specify if the server
> should list all CSR format and algorithms it supports.


Section 2.1 indicates that the client’s message lists all of the key-algorithms and csr-formats it supports and the server’s message merely selects the specific algorithm/format it wishes the client use.   This comment is nearly identical to one of your earlier comments, for which we added more context around the examples.  Good enough?  


> * Is there really need to support 3 different CSR formats?

Yes and, FWIW, the PKI world has even more formats; we actually restricted them to just those that are most widely implemented.


> * Where does the client indicate which cert is wants to receive based on this
> CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in the CSR
> itself?

The CSR is always for an LDevID.  It can never be for an IDevID, which can (effectively) only be generated/installed by the vendor during the device’s manufacturing process. 

Makes sense?   [No update to the draft was made to address this comment]


> * Is RFC 2986 (published Nov. 2000) the best reference for an
> AlgorithmIdentifier? Is there no IANA registry we could reference instead?

There is not an IANA registry for AlgorithmIdentifiers.  RFC 2986 is the reference for the PKCS#10 CSR.

[No update to the draft was made to address this comment]



> * When talking about algorithm matching, I suggest changing "It is an error
> if..." into normative text, "The recipient MUST reject...".

OLD:

         It is an error if the 'AlgorithmIdentifier' field
         contained inside the 'SubjectPublicKeyInfo' field
         does not match the algorithm identified by the
         'selected-algorithm' node.";

NEW:

         If the 'AlgorithmIdentifier' field contained inside the
         certificate 'SubjectPublicKeyInfo' field does not match
         the algorithm identified by the 'selected-algorithm' node,
         then the client MUST reject the certificate and raise an
         error.";

Good?



> * "Details for how to generate a new private key and associate a new identity
> certificate are outside the scope of this document." - This is rather
> disappointing, since we just RECOMMENDED to regenerate certs periodically (and
> given that IOT devices often lack HSMs).

Understood, but key-generation is indeed outside the scope of this document.

[No update to the draft was made to address this comment]



Thanks again,
Kent (and Sean and Russ)