[netconf] AD review of draft-ietf-netconf-sztp-csr

["Rob Wilton (rwilton)" <[e-mail]>]

AD Review of draft-ietf-netconf-sztp-csr-03

Disclaimer, I am not a security expert and the security specific aspects
(e.g., the precise details of how the CSRs are encoded) is beyond my knowledge.
Hopefully this will be sufficiently checked by SEC DIR reviews and SEC AD,
whilst also acknowledging the expertise of the authors!

My main questions really relate to REST semantics.

1. It is always the case that the SZTP-client must do the handshake with
the server (i.e, populating the csr-support container, then getting a 400 error back,
before making the actual bootstrap request), or is it acceptable for the SZTP-client
to guess on acceptable parameters, and send a single request?  Obviously, this cannot
work in all cases, but I want to check whether it is allowed (or explicitly disallowed)
in any cases.


2. Section 2.2:
   Assuming the SZTP-server wishes to prompt the SZTP-client to provide
   a CSR, then it would respond with an HTTP 400 (Bad Request) error
   code:

I wonder whether returning a 400 "Bad Request" error is really the best return code, i.e., 
it wasn't clear to me whether this requesting the capabiltiies is really an error.
Did you consider potentially using other return codes?  Possibly:
  300 Multiple Choices,
  403 Fobidden,
  406 Not Acceptable


3. Does it make sense to recommend a default certificate-request-format that clients should
support, or does it make sense to not prioritize any particular certificate format, effectively
requiring that a generic server needs to support them all?


4. References.  RFC 3688 probably should be normative for the XML registry, noting that
RFC 6020 is normatively referenced.


Nits:

5. 
In the example data, would it helpful to add a sentence to explain
               "base64encodedvalue1=",
               "base64encodedvalue2=",
               "base64encodedvalue3="
			
Actually, given this convention is used in various places, there is a choice as to whether
to add a sentence to each example, or perhaps in the introduction.

			
6.
3.1.3.  Replay Attack Protection

   This RFC enables an SZTP-client to announce an ability to generate
   new key to use for its CSR.
   
"a new key"


7. In Security Considerations:
   Generating a new key each time enables the random bytes used to
   create the key to serve the dual-purpose of also acting like a
   "nonce" used in other mechanisms to detect replay attacks.
   
I wasn't clear to me what the two purposes are here.  One is acting like
a "nonce", but what is the other purpose?


8.
   In the case the SZTP-client must choose between the asymmetric key
   option versus a shared secret for origin authentication, it is
   RECOMMENDED that the SZTP-client choose using the asymmetric key
   option.
   
"In the case the" => "In the case that the ...

Terminology:
Should you add LDevID or IDevID

Potential spelling warnings:
descendent

Grammar Warnings (from tool):
Section: 2.3, draft text:
This module augments an RPC defined in [RFC8572], uses a data type defined in [I-D.ietf-netconf-crypto-types], has an normative references to [RFC2986] and [ITU.
Warning:  The plural noun "references" cannot be used with the article "an". Did you mean an normative reference or normative references?
Suggested change:  "an normative reference"

Section: 3.1.4, draft text:
Consistent with the recommendation presented in Section 9.6 of [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input parameter to an untrusted SZTP-server. 
Warning:  The modal verb 'SHOULD' requires the verb's base form.
Suggested change:  "pass"

Section: 3.1.5, draft text:
All of the certificate request formats defined in this document (e.g., CMC, CMP, etc.), not including a raw PKCS#10, support origin authentication.
Warning:  Consider using all the.
Suggested change:  "All the"

Section: 3.1.5, draft text:
Typically only one possible origin authentication mechanism can possibly be used but, in the case that the SZTP-client authenticates itself using both TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the SZTP-client may need to choose between the two options.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Typically,"

Thanks,
Rob