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

[Yaron Sheffer <[e-mail]>]

Hi Kent,

 

Thank you for addressing my comments, I am happy with most of your responses but I do have a few remaining questions:

 

• The commit that removes the dependency on IDevID and LDevID does not fix the issue of non-orthogonality. There is very detailed description for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean “use PKCS#10 out of the box and it’ll just work”? Or does it mean “the usage of PKCS#10 for these certs is still TBD”?
• I suggest to add the following reference to the paragraph on quality randomness, as a strong proof that this is a real world concern:

 

Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21^st USENIX Security Symposium , August 2012, <https://factorable.net/" rel="nofollow">https://factorable.net/>.

 

• I understand that key generation is out of scope and maybe this needs to be a separate work item, but recommending periodic replacement of the certs without recommending a suitable mechanism leaves this solution with a big hole.
• It is really annoying that 21 years after PKCS #10, we still cannot provide a reference that would enable implementers to find out all available, non-deprecated AlgorithmIdentifier values. (And I realize there’s little you can do about it.)

 

Thanks,

                Yaron

 

 

From: Kent Watsen <[e-mail]>
Date: Monday, November 22, 2021 at 23:49
To: Yaron Sheffer <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11

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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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)