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

Yaron Sheffer <yaronf.ietf@xxxxxxxxx> · Sat, 4 Dec 2021 13:58:10 +0200

I am good with the latest text. Thank you Kent and Russ!

                Yaron

From: Kent Watsen <kent+ietf@xxxxxxxxxx>
Date: Saturday, December 4, 2021 at 03:15
To: Yaron Sheffer <yaronf.ietf@xxxxxxxxx>
Cc: 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

Hi Yaron,

Please see below for some responses to your comments.

I did also just post -12 including these changes:
                https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.html

Here’s a direct link to the diffs (note: Opsdir and Gendir comments are also included):
                https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-12

Kent (and Russ and Sean)

On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <yaronf.ietf@xxxxxxxxx> wrote:

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.

Russ writes:

    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.

To which you replied:

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

As the originator of the OLD text, I have the following comments:

1) it is not uncommon to find new devices without an HSM or devices with an HSM that is only used as a source of entropy (not key protection).  So saying something to address these implementations seems prudent.

2) There’s no reason to call out CMP/CMS.  P10 also works, and note that the YANG in the draft is extensible to allow new formats to be introduced over time.

3) The protocol as a whole is intended to move a device from an “unmanaged” state to a “managed” state. That is, SZTP would no longer be in play, as the only management connections would be, e.g., NETCONF or RESTCONF.  Once in the device is in the managed state, “normal” ongoing management mechanisms are expected to be utilized.  We can hope that the mechanisms include periodically prompting the device to regen its key and a reissuance of an LDevID, but details are out of scope to this draft.
4) One case I’m aware of where a device runs the SZTP protocol throughout its lifecycle is when a device is deployed in a physically insecure location (think: a kiosk in an airport) whereby, to thwart inadvertent disclosure of networking settings from a slash-and-grab, the entirety of the device’s config is stored in memory (not on disk).  As such, every time power is lost, the device automatically reverts to its factory default state and, when power is restored, must run the SZTP protocol to join the network and be provisioned with configuration. The draft addresses this case with statement “It is RECOMMENDED that a new private key is generated for each CSR described in this document."

The net-net of all this is the following:

NEWEST:

   In cases where the SZTP-client does not possess an HSM, or is unable
   to use an HSM to protect the private key, it is RECOMMENDED to
   periodically reset the private key (and associated identity
   certificates) in order to minimize the lifetime of unprotected
   private keys.  For instance, an NMS controller/orchestrator
   application could periodically prompt the SZTP-client to generate a
   new private key and provide a certificate signing request (CSR) or,
   alternatively, push both the key and an identity certificate to the
   SZTP-client using, e.g., a PKCS #12 [RFC7292].  In another example,
   the SZTP-client could be configured to periodically reset the
   configuration to its factory default, thus causing removal of the
   private key and associated identity certificates and reexecution of
   the SZTP protocol.

Good?

[more below]

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.

One reason why the description statement in the "case p10-csr” node is so small is because that node (unlike "case cmc-csr" and "case cmp-csr”) uses the following typedef from the “crypto-types” draft (i.e. type ct:csr):

     typedef csr {
       type binary;
       description
         "A CertificationRequest structure, as specified in 
          RFC 2986, encoded using ASN.1 distinguished encoding
          rules (DER), as specified in ITU-T X.690.";
       reference
         "RFC 2986:
            PKCS #10: Certification Request Syntax Specification
            Version 1.7
          ITU-T X.690:
            Information technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER),
            Canonical Encoding Rules (CER) and Distinguished
            Encoding Rules (DER).";
     }

That is, the description for how the p10 is encoded on-the-wire is defined elsewhere, and not duplicated here.  To address your primary point, as well as the point just mentioned, how about this?

OLD:

         case p10-csr {
           leaf p10-csr {
             type ct:csr;
             description
               "A CertificationRequest structure, per RFC 2986.";
             reference
               "RFC 2986: PKCS #10: Certification
                          Request Syntax Specification";
           }
         }

NEW:
         case p10-csr {
           leaf p10-csr {
             type ct:csr;
             description
               "A CertificationRequest structure, per RFC 2986.
                Encoding details are defined in the 'ct:csr'
                typedef defined in RFC AAAA.

                A raw P10 does not support origin authentication in
                the CSR structure.  External origin authentication
                may be provided via the ZTP-client's authentication
                to the ZTP-server at the transport layer (e.g., TLS).";
             reference
               "RFC 2986: PKCS #10: Certification Request Syntax
                          Specification
                RFC AAAA: YANG Data Types and Groupings for
                          Cryptography";
           }
         }

Good?  

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

The final text reads:

   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
   [CVE-2008-0166], and some consequences of low-entropy random numbers
   are discussed in Mining Your Ps and Qs [MiningPsQs].  The generation
   of quality random numbers is difficult.  [ISO.20543-2019],
   [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and
   others offer valuable guidance in this area.

Good?

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

[the response for this “third point” is at the top of this email.]

Kent, on behalf of the authors

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