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

[Yaron Sheffer <yaronf.ietf@xxxxxxxxx>]

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 <housley@xxxxxxxxxxxx>
Date: Monday, November 29, 2021 at 18:38
To: Yaron Sheffer <yaronf.ietf@xxxxxxxxx>
Cc: last-call@xxxxxxxx <last-call@xxxxxxxx>, Kent Watsen <kent+ietf@xxxxxxxxxx>, draft-ietf-netconf-sztp-csr.all@xxxxxxxx <draft-ietf-netconf-sztp-csr.all@xxxxxxxx>, netconf@xxxxxxxx <netconf@xxxxxxxx>, IETF SecDir <secdir@xxxxxxxx>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11

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 <yaronf.ietf@xxxxxxxxx> wrote:

 

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

 

 

From: Russ Housley <housley@xxxxxxxxxxxx>
Date: Sunday, November 28, 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@xxxxxxxxx>
Cc: Kent Watsen <kent+ietf@xxxxxxxxxx>, IETF SecDir <secdir@xxxxxxxx>, draft-ietf-netconf-sztp-csr.all@xxxxxxxx <draft-ietf-netconf-sztp-csr.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, netconf@xxxxxxxx <netconf@xxxxxxxx>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11

Yaron:

 

 

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

 

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

 

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.

 

That is reasonable.  I will talk with my co-authors and see if we can come up with a brief summary.

 

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

 

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.

 

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

 

 

 

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

 

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.

 

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

 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call