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

From: Yaron Sheffer via Datatracker <[email-masked]>
Date: Wed, 17 Nov 2021 10:59:59 -0800

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.

* 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

* 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?

* 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"?

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

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

* 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?

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

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

* "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).

---

From: Kent Watsen <[email-masked]>
Date: Mon, 22 Nov 2021 21:49:40 +0000

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 <[email-masked]> wrote:
> 
> Reviewer: Yaron Sheffer

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?

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

> the client knows exactly what is supported? IOW, why include these values at

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?

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

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

> CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in the CSR

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]

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

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

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 25 Nov 2021 16:02:32 +0200

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 21st USENIX Security Symposium , August 2012, <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 <[email-masked]>
Date: Monday, November 22, 2021 at 23:49
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11

Hi Yaron,

Reviewer: Yaron Sheffer

Specifically:

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

Good?

OLD:

NEW:

Good now?

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

Better?

OLD:

NEW:

Good?

Thanks again,

Kent (and Sean and Russ)

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Nov 2021 10:53:03 -0500

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

PKCS#10 is pretty simple.  Are you aware of anything more that ought to be said?

> 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 21st USENIX Security Symposium , August 2012, <https://factorable.net/ <https://factorable.net/>>.

In another thread, something like this was suggested for another document:

   Implementations must randomly generate nonces and private keys.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 […]. The generation
   of quality random numbers is difficult. ISO/IEC 20543:2019 […],
   NIST SP 800-90A Rev.1 […], BSI AIS 31 V2.0 […], BCP 106 [RFC4086], and
   others offers valuable guidance in this area.

If this approach works for you, we'll dig up the appropriate references.

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

I do not agree.  It does offer the protocol for obtaining replacement certificates for devices that are able to generating a fresh public/private key pair.  Getting more detailed would be algorithm specific, which is not appropriate in this document.

> 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 r…

So, we will leave this part alone.

Russ

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Nov 2021 11:29:19 +0200

Hi Russ,

Please see my answers in-line.

Thanks,

Yaron

From: Russ Housley <[email-masked]>
Date: Friday, November 26, 2021 at 17:53
To: Yaron Sheffer <[email-masked]>
Cc: Kent Watsen <[email-masked]>, IETF SecDir <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11

Yaron:

·         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 think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin authentication methods are available when using PKCS #10 directly without wrapping it further.

·

·         I suggest to add the following reference to the paragraph on quality randomness, as a strong proof that this is a real world concern:

Yes, but the Heninger et al. reference is a better fit than the Debian CVE because (1) it discusses network devices rather than servers and (2) it shows how even less broken RNGs can be exploited by a network attacker that only sees the public keys.

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

Not really, because the “protocol” described here is: Client sends a CSR, Server responds with a complete client configuration blob. This obviously doesn’t work for an already deployed client.

·

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

Agreed. Sigh.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Nov 2021 13:09:59 -0500

> I think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin authentication methods are available when using PKCS #10 directly without wrapping i…

That is reasonable.  I will talk with my co-authors and see if we can come up with a brief summary.
 
> Yes, but the Heninger et al. reference is a better fit than the Debian CVE because (1) it discusses network devices rather than servers and (2) it shows how even less broken RNGs can be exploited b…

I just read the Abstract of the paper, and I see your point about the attacker only observing the public keys.  How about:

   Implementations must randomly generate nonces and private keys.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As an example of
   predictable random numbers see CVE-2008-0166 […], and some consequences
   of low-entropy random numbers are discussed in Mining Your Ps and Qs [...].
   The generation of quality random numbers is difficult. ISO/IEC 20543:2019 […],
   NIST SP 800-90A Rev.1 […], BSI AIS 31 V2.0 […], BCP 106 [RFC4086], and
   others offers valuable guidance in this area.

> Not really, because the “protocol” described here is: Client sends a CSR, Server responds with a complete client configuration blob. This obviously doesn’t work for an already deployed client.

I am really confused.  The document  is an addition to the Secure Zero Touch Provisioning (SZTP).  As such, it is technique to securely provision a networking device when it is booting in a factory-default state.  That should happen at the initial deployment or after the device is reset to the factory configuration.  This is not the protocol for use with an already deployed client.

Russ

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Nov 2021 22:22:54 +0200

Hi Russ,

Thank you for the quick response.

We are in agreement re: PKCS #10 and randomness.

In the third point below (certificate rotation), I understand why the editors see it as out of scope. But we are still leaving implementers with no guidance, and we’ve all seen enough real world cases where this leads to people ignoring the vague “regenerate the private key”. Let me try to offer an alternative.

Old:

In cases where the SZTP-client does not possess an HSM, or otherwise is unable to use an HSM for the private key, it is RECOMMENDED to regenerate the private key (and associated identity certificates) periodically. Details for how to generate a new private key and associate a new identity certificate are outside the scope of this document.

New:

In cases where the SZTP-client does not possess an HSM, or otherwise is unable to use an HSM for the private key, it is RECOMMENDED to regenerate the private key (and associated identity certificates) periodically. If CMP or CMC was used for initial certificate provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for periodic certificate registration. Similarly, implementations SHOULD also reuse the initial origin authentication method.

Thanks,

Yaron

Date: Sunday, November 28, 2021 at 20:10

Yaron:

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Nov 2021 11:38:31 -0500

Yaron:

Perhaps the word "regenerate" is the thing that is causing confusion.

Suggestion:

In cases where the SZTP-client does not possess an HSM, or otherwise is unable to use an HSM for the private key, it is RECOMMENDED that the device periodically reset the configuration to the factory default and repeat the SZTP protocol.  Repeating the SZTP protocol may cause the device to generate a fresh private key (and associated identity certificates). Details for how to generate a new private key and associate a new identity certificate are outside the scope of this document.

Russ

> On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Russ,
>  
> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> Cc: Kent Watsen <[email-masked] <mailto:[email-masked]>>, IETF SecDir <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 29 Nov 2021 19:55:08 +0200

Hi Russ,

I’m really surprised that a factory reset is the right thing to do in this use case. But you are the expert.

The new text works for me.

Thanks,

Yaron

From: Russ Housley <[email-masked]>
Date: Monday, November 29, 2021 at 18:38
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked] <[email-masked]>, Kent Watsen <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, IETF SecDir <[email-masked]>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11

Yaron:

Suggestion:

Russ

Hi Russ,

Old:

New:

Thanks,

Yaron

Yaron:

Russ

--
last-call mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/last-call