Skip to main content

Last Call Review of draft-ietf-netconf-sztp-csr-11
review-ietf-netconf-sztp-csr-11-secdir-lc-sheffer-2021-11-17-00

Request Review of draft-ietf-netconf-sztp-csr
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-11-23
Requested 2021-11-09
Authors Kent Watsen , Russ Housley , Sean Turner
I-D last updated 2021-11-17
Completed reviews Yangdoctors Last Call review of -02 by Joe Clarke (diff)
Genart Last Call review of -11 by Meral Shirazipour (diff)
Secdir Last Call review of -11 by Yaron Sheffer (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Secdir Telechat review of -12 by Yaron Sheffer (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Request Last Call review on draft-ietf-netconf-sztp-csr by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/I9GpSAAbZ5yDYp_NJuBbzAX-vj4
Reviewed revision 11 (document currently at 14)
Result Has issues
Completed 2021-11-17
review-ietf-netconf-sztp-csr-11-secdir-lc-sheffer-2021-11-17-00
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).