Hi Authors, Thank you for working on the document, and thanks to Toerless for shepherding the document. The document was fairly easy read, but could be improved.
Here is my review of the document. It is divided between COMMENTs and NITs. I expect some resolution of the COMMENTs, and it would be nice to see the NITs also addressed. ------------------------------------------------------------------------------- COMMENT ------------------------------------------------------------------------------- Overall: My overall comment on the document is related to two items. One is the use of Note(s) liberally in the document, and use of words like "could" and "can" throughout the document. On the use of Notes, I would strongly suggest that they should be formalized, i.e., the prefix "Note:" should be removed, or replaced with text such as "It should be noted ..." or something more formal. On the use of words such as "could", "can" etc., I would suggest that the authors review them and use BCP 14 suggested words such as SHOULD, MAY etc. "Abstract", paragraph 2 > This offers the following advantages. The origin of requests and > responses can be authenticated independently of message transfer. > This supports end-to-end authentication (proof of origin) also over > multiple hops, as well as asynchronous operation of certificate > enrollment. This in turn provides architectural flexibility where > and when to ultimately authenticate and authorize certification > requests while retaining full-strength integrity and authenticity of > certification requests. This paragraph should be moved to the Introduction (or at least removed from here) to keep the abstract truly an abstract. That section already details how BRSKI-AE is different from BRSKI, and covers the advantage of this approach. Section 1, paragraph 8 > Note: The BRSKI voucher exchange of the pledge with the registrar and > MASA uses authenticated self-contained objects, so the voucher > exchange already has these properties. To formalize the Note, could the sentence be changed to say "It is useful to note that the BRSKI voucher ...", or something like that? See note above. Section 1.1, paragraph 4 > - the registration Authority (RA) not being co-located with the > registrar while requiring end-to-end authentication of > requesters, which EST does not support over multiple hops Consider using assertive language vs passive language for most of these bullet items. For example, in this bullet item, based on my understanding, the reason that EST cannot be used is because it does not support multiple hops for end-to-end authentication. Therefore, anything that is more than one hop away cannot be authenticated. If that is the intent of this bullet item, can it reworded to say that? Section 1.1, paragraph 3 > - the RA or certification authority (CA) operator requiring > auditable proof of origin for Certificate Signing Requests > (CSRs), which is not possible with the transient source > authentication provided by TLS. Similarly, I read this as "TLS provides transient source authentication, while RA an CA operators require proof of origin for CSRs". Section 1.2, paragraph 8 > Bootstrapping can be handled in various ways, depending on the > application domains. The informative Appendix A provides > illustrative examples from various industrial control system > environments and operational setups. They motivate the support of > alternative enrollment protocols, based on the following examples of > operational environments: > > * rolling stock > > * building automation > > * electrical substation automation > > * electric vehicle charging infrastructures > > * infrastructure isolation policy > > * sites with insufficient level of operational security Consider moving this section to the Appendix where the examples are, or removing this entire section as it is describing an use case scenario, and does very little to help the specification itself. Section 3, paragraph 2 > At least the following properties are required for a certification > request: Consider removing the phrase, "At least". Section 3.1, paragraph 4 > Note: The integrity protection of CSRs includes the public key > because it is part of the data signed by the corresponding private > key. Yet this signature does not provide data origin authentication, > i.e., proof of identity of the requester because the key pair > involved is fresh. It is not clear what it means for "the key pair involved is fresh". Section 3.2, paragraph 5 > Yet this binding is only valid in the context of the TLS session > established with the registrar acting as the EST server and > typically also as an RA. So even such a cryptographic binding of > the authenticated pledge identity to the CSR is not visible nor > verifiable to authorization points outside the registrar, such as > a (second) RA in the backend. What the registrar must do is to > authenticate and pre-authorize the pledge and to indicate this to > the (second) RA by signing the forwarded certificate request with > its private key and a related certificate that has the id-kp-cmcRA > extended key usage attribute. Consider using MUST instead of lowercase must in this paragraph. Section 3.2, paragraph 8 > To sum up, EST does not meet the requirements for authenticated self- > contained objects, but SCEP, CMP, and CMC do. This document > primarily focuses on CMP as it has more industrial relevance than CMC > and SCEP has issues not detailed here. What does "industrial relevance" mean? Or did you mean to say "industry adotption"? Section 4.1, paragraph 1 > The key element of BRSKI-AE is that the authorization of a > certification request MUST be performed based on an authenticated > self-contained object. The certification request is bound in a self- > contained way to a proof of origin based on the IDevID credentials. > Consequently, the certification request may be transferred using any > mechanism or protocol. Authentication and authorization of the > certification request can be done by the domain registrar and/or by > backend domain components. As mentioned in Section 1.1, these > components may be offline or off-site. The registrar and other on- > site domain components may have no or only temporary (intermittent) > connectivity to them. Consider using BCP 14 terms like MAY in the above paragraph. Section 4.1, paragraph 8 > 2. Rather than having full RA functionality, the registrar MAY > act as a local registration authority (LRA) and delegate part > of its involvement in certificate enrollment to a backend RA, > called RA. In such scenarios the registrar optionally checks > certification requests it receives from pledges and forwards > them to the RA. The RA performs the remaining parts of the > enrollment request validation and authorization. Note that to > this end the RA may need information regarding the > authorization of pledges from the registrar or from other > sources. On the way back, the registrar forwards responses by > the PKI to the pledge on the same channel. Consider giving RA a different or more qualified name, otherwise it is not clear how is this RA different from a "normal" RA. How about Backend RA, or a Full RA or something similar? Section 4.1, paragraph 8 > Note: In order to support end-to-end authentication of the > pledge across the registrar to the RA, the certification > request structure signed by the pledge needs to be retained by > the registrar, and the registrar cannot use for its > communication with the PKI a enrollment protocol different to > the one used by the pledge. This note is confusing. It is not clear what it means for the certification request structure to be "retained by the registrar". By retained, do you mean it is stored locally, and a new request is initiated by the registrar. Also, the sentence "registrar cannot use its communication with the PKI an enrollment protocol" does not parse for me. Can it be reworded? Finally, as noted below, please be consistent in the use of "certificate request", "certification request", and "certs request". Section 4.1, paragraph 8 > 3. The use of a certificate enrollment protocol with > authenticated self-contained objects gives freedom how to > transfer enrollment messages between pledge and RA. > Regardless how this transfer is protected and how messages are > routed, also in case that the RA is not part of the registrar > it MUST be guaranteed, like in BRSKI, that the RA accepts > certification requests for LDevIDs only with the consent of > the registrar. See Section 7 for details how this can be > achieved. After the first sentence, I got lost in the "also", "like", and "only". Can the rest of paragraph be broken up into multiple statements? Section 4.2.4, paragraph 6 > Note: Connections between the registrar and the PKI components of the > operator (RA, CA, etc.) may be intermittent or off-line. Messages > should be sent as soon as sufficient transfer capacity is available. There are several uses of the word "could", "can" in the notes below. Consider using BCP 14 keywords. See note above. Section 4.2.4, paragraph 9 > Also certificate confirmation messages will usually be forwarded to > the backend PKI, but if the registrar knows that they are not needed > or wanted there it can acknowledge such messages directly. Is this paragraph part of the above Note? If so, consider combining them. Section 4.2.4, paragraph 14 > * Attribute Response (4): This MUST contain the attributes to be > included in the subsequent certification request. Shouldn't the response contain the attributes requested in (3)? If so, should it not be stated here? Also, it would be useful to describe what happens if no attributes are returned. Section 4.3, paragraph 3 > A pledge SHOULD use the endpoints defined for the enrollment > protocol(s) that it is capable of and is willing to use. It will > recognize whether its preferred protocol or the request that it tries > to perform is understood and supported by the domain registrar by > sending a request to its preferred enrollment endpoint according to > the above addressing scheme and evaluating the HTTP status code in > the response. If the pledge uses endpoints that are not > standardized, it risks that the registrar does not recognize and > accept them even if supporting the intended protocol and operation. The last sentence does not parse for me. Did you mean to say that the registrar does not recognize the request, but still goes ahead and accepts it, even if it does not support the intended protocol? This should be highlighted in the Security Considerations section also. Section 5.1, paragraph 2 > * CA Certs Request (1) and Response (2): > Requesting CA certificates over CMP is OPTIONAL. > If supported, it SHALL be implemented as specified in [RFC9483], > Section 4.3.1. Is it "CA Certs Request" or "CA Certificate Request"? Let us be consistent. Section 5.1, paragraph 2 > * Attribute Request (3) and Response (4): > Requesting certificate request attributes over CMP is OPTIONAL. > If supported, it SHALL be implemented as specified in [RFC9483], > Section 4.3.3. Is requesting attributes optional, or requesting them over CMP is OPTIONAL? The optionality was mentioned in Figure 2, but not in the abstract description of the flow. Section 5.1, paragraph 5 > Note: When the registrar forwards a certification request by the > pledge to a backend RA, the registrar is recommended to wrap the > original certification request in a nested message signed with its > own credentials as described in [RFC9483], Section 5.2.2.1. This > explicitly conveys the consent by the registrar to the RA while > retaining the certification request with its proof of origin > provided by the pledge signature. Let us be consistent in the use of "Certificate Request". I see "Certs Request", "Certification Request" etc. Section 5.1, paragraph 8 > * If delayed delivery of responses (for instance, to support > asynchronous enrollment) within CMP is needed, it SHALL be > performed as specified in Section 4.4 and Section 5.1.2 of > [RFC9483]. This bullet item does not parse for me. Section 5.1, paragraph 8 > Note: The way in which messages are exchanged between the registrar > and backend PKI components (i.e., RA or CA) is out of scope of this > document. Due to the general independence of CMP of message > transfer, it can be freely chosen according to the needs of the > application scenario (e.g., using HTTP), while security > considerations apply, see Section 7, and guidance can be found in > [RFC9483], Section 6. This paragraph also does not parse for me. Section 7, paragraph 9 > Note that CMP messages are not encrypted. This may give > eavesdroppers insight on which devices are bootstrapped into the > domain, and this in turn might also be used to selectively block the > enrollment of certain devices. To prevent this, the underlying > message transport channel can be encrypted, for instance by employing > TLS. On the link between the pledge and the registrar this is easily > achieved by reusing the existing TLS channel between them. As noted above, what happens if a device masquerades itself as a registrar? Is such a scenario possible? If so, it should be highlighted here. No reference entries found for these items, which were mentioned in the text: [LCMPP], [draft-ietf-anima-brski-async-enroll-03], [THISRFC], and [draft-ietf-anima-brski-async-enroll]. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Terms "him" and "his"; alternatives might be "they", "them", "their" ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Abstract", paragraph 6 - Source for this draft and an issue tracker can be found at - ^ + The source for this draft and an issue tracker can be found at + ^^^^^ Section 1, paragraph 1 - authenticated self-contained objects for device certificate + authenticated self-contained objects for the device certificate + ++++ Section 1, paragraph 5 - certificate, called LDevID certificate. On success it receives + certificate, called LDevID certificate. On success, it receives + + Section 1.1, paragraph 1 - BRSKI-AE is intended to be used situations like the following. + BRSKI-AE is intended to be used in situations like the following. + +++ Section 2, paragraph 4 - authenticated self-contained object: data structure that is + authenticated self-contained object: a data structure that is + + Section 2, paragraph 13 - needed if a backend RA is used, and in this case the LRA is co- + needed if a backend RA is used, and in this case, the LRA is co- + + Section 3, paragraph 5 - The rest of this section gives an non-exhaustive list of solution - - Section 3.1, paragraph 3 - signature is used generated over (part of) the structure with the - - + signature is used to generate over (part of) the structure with the + +++ Section 3.2, paragraph 4 - CSR was not designed to include a proof of origin, there is a - -- Section 3.2, paragraph 6 - This would allow for source authentication at message level, such + This would allow for source authentication at the message level, such + ++++ Section 4, paragraph 2 - The enhancements needed are kept to a minimum in order to ensure - --------- Section 4, paragraph 2 - reuse of already defined architecture elements and interactions. In + the reuse of already defined architecture elements and interactions. In + ++++ Section 4.1, paragraph 5 - as BRSKI, but with more flexible placement of the authentication and + as BRSKI, but with a more flexible placement of the authentication and + ++ Section 4.1, paragraph 7 - onboarding new devices and to facilitate the communication of - --- ^ + onboarding new devices and facilitating the communication of + ^^^ Section 4.1, paragraph 9 - called RA. In such scenarios the registrar optionally checks + called RA. In such scenarios, the registrar optionally checks + + Section 4.1, paragraph 9 - authorization of pledges from the registrar or from other - ----- Section 4.1, paragraph 10 - Note: In order to support end-to-end authentication of the - ^^^^^^^^^^ + Note: To support end-to-end authentication of the + ^ Section 4.1, paragraph 10 - the registrar, and the registrar cannot use for its - - ---- Section 4.1, paragraph 10 - communication with the PKI a enrollment protocol different to + communication with the PKI an enrollment protocol different to + + Section 4.1, paragraph 11 - Regardless how this transfer is protected and how messages are + Regardless of how this transfer is protected and how messages are + +++ Section 4.1, paragraph 11 - the registrar. See Section 7 for details how this can be + the registrar. See Section 7 for details on how this can be + +++ Section 4.1, paragraph 12 - Despite of the above generalizations to the enrollment phase, the - --- Section 4.1, paragraph 17 - may be located on-site or off-site in the target domain. - - Section 4.1, paragraph 19 - and authorized by the registrar and/or and an extra RA. - ---- Section 4.1, paragraph 26 - messages, the (D)TLS channel established between pledge and + messages, the (D)TLS channel established between the pledge and + ++++ Section 4.2.1, paragraph 1 - discovery of registrars with enhanced feature sets. A pledge cannot + the discovery of registrars with enhanced feature sets. A pledge cannot + ++++ Section 4.2.4, paragraph 2 - The certificate enrollment phase may involve transmission of several + The certificate enrollment phase may involve the transmission of several + ++++ Section 4.2.4, paragraph 8 - answer the request directly itself. In this case, it MUST - ------- Section 4.2.4, paragraph 8 - authenticating itself at TLS level for the voucher exchange. - Otherwise the registrar MUST forward the request to the RA and + authenticating itself at the TLS level for the voucher exchange. + ++++ + Otherwise, the registrar MUST forward the request to the RA and + + Section 4.2.4, paragraph 9 - Note: The decision whether to forward a request or to answer it + Note: The decision of whether to forward a request or to answer it + +++ Section 4.2.4, paragraph 10 - Note: There are several options how the registrar could be able to - directly answer requests for CA certificates or for certificate - ---- + Note: There are several options for how the registrar could be able to + ++++ Section 4.2.4, paragraph 10 - asking for the same data. The contents could also be explicit + asking for the same data. The contents could also be explicitly + ++ Section 4.2.4, paragraph 11 - rejected, for instance because is not properly authenticated or not + rejected, for instance, because it is not properly authenticated or not + + +++ Section 4.2.4, paragraph 11 - Also certificate confirmation messages will usually be forwarded to + Also, certificate confirmation messages will usually be forwarded to + + Section 4.2.4, paragraph 13 - cert (which is contained in the voucher and may be just the domain - - Section 4.2.4, paragraph 15 - additional attributes specific to the target domain into the - -- Section 4.2.4, paragraph 18 - contained object ensuring both proof of possession of the + contained object ensuring both the proof of possession of the + ++++ Section 4.2.5, paragraph 2 - step, but due to the generalization on the enrollment protocol - ^ - described in this document its regarded as a separate phase here. + step, but due to the generalization of the enrollment protocol + ^ + described in this document it is regarded as a separate phase here. + ++ Section 4.3, paragraph 1 - certification requests. As this is supported by various existing - ^^^^ + certification requests. This is supported by various existing + ^ Section 4.3, paragraph 3 - protocols such as CMC and SCEP, or for newly defined protocols are - ---- Section 4.3, paragraph 5 - supported at the registrar. - ^^ + supported by the registrar. + ^^ Section 4.3, paragraph 7 - The following list of endpoints provides an illustrative example for - -- + The following list of endpoints provides an illustrative example of + + Section 5.1, paragraph 5 - Alternatively, the registrar MAY modify the contents of requested + Alternatively, the registrar MAY modify the contents of the requested + ++++ Section 5.1, paragraph 12 - asynchronous enrollment) within CMP is needed, it SHALL be - ^^^^^^ + asynchronous enrollment) If CMP is needed, it SHALL be + ^^ Section 5.1, paragraph 13 - Note: The way in which messages are exchanged between the registrar - ^^^^ ----------- - and backend PKI components (i.e., RA or CA) is out of scope of this - ^^ + Note: How messages are exchanged between the registrar + ^^ + and backend PKI components (i.e., RA or CA) are out of scope of this + ^^^ Section 5.1, paragraph 14 - In this scenario, of course the EST-specific parts of + In this scenario, of course, the EST-specific parts of + + Section 6, paragraph 3 - LCMPP being necessary and sufficient. - -- ^^ + LCMPP is necessary and sufficient. + ^ Section 7, paragraph 1 - The security considerations laid out in BRSKI [RFC8995] apply for the - ^ - + The security considerations laid out in BRSKI [RFC8995] apply to the + ^ Section 7, paragraph 2 - cannot circumvent the registrar in the decision whether it is granted + cannot circumvent the registrar in the decision of whether it is granted + +++ Section 7, paragraph 9 - eavesdroppers insight on which devices are bootstrapped into the - - + eavesdroppers insight into which devices are bootstrapped into the + +++ Section 7, paragraph 9 - TLS. On the link between the pledge and the registrar this is easily + TLS. On the link between the pledge and the registrar, this is easily + + "Appendix A.", paragraph 1 - This informative annex provides some detail to the application - - + This informative annex provides some details about the application + + ++++ "A.1.", paragraph 1 - asynchronous enrollment will include generating certification + asynchronous enrollment will include generating a certification + ++ "A.1.", paragraph 2 - UNISIG has included a CMP profile for enrollment of TLS client and + UNISIG has included a CMP profile for the enrollment of TLS client and + ++++ "A.2.", paragraph 1 - controllers that are connected with each other in a local network but - -- ------- ------- "A.2.", paragraph 2 - network as preparation for the operational phase. In this case, - ^^ + network in preparation for the operational phase. In this case, + ^^ "A.3.", paragraph 1 - of several enrollment protocols in order to support the various - --------- "A.4.", paragraph 1 - mutual authentication is required. In both cases the charging point + mutual authentication is required. In both cases, the charging point + + "Appendix B.", paragraph 6 - one and thus is no more applicable here. - ^ - + one and thus is no longer applicable here. + ^ +++ "Abstract", paragraph 1 s/authenticated independently of/authenticated independent of/ Section 3.2, paragraph 8 > * CMC [RFC5272] also supports utilizing a shared secret (passphrase) > or an existing certificate to protect certification requests, > which can be either in CRMF or PKCS #10 structure. The proof of > identity can be provided as part of a FullCMCRequest, based on CMS > [RFC5652] and signed with an existing IDevID secret. Thus also > CMC does not rely on the security of the underlying message > transfer. s/Thus also CMC/Thus CMC/ Section 4, paragraph 1 > To enable using alternative certificate enrollment protocols > supporting end-to-end authentication, asynchronous enrollment, and > more general system architectures, BRSKI-AE provides some > generalizations on BRSKI [RFC8995]. This way, authenticated self- > contained objects such as those described in Section 3 above can be > used for certificate enrollment, and RA functionality can be > distributed freely in the target domain. s/functionality can be distributed/functionality can be deployed/ Section 4.1, paragraph 8 s/different to/different from/ Section 4.2.4, paragraph 1 > This replaces the EST integration for PKI bootstrapping described in > [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the > final phase, see below). s/This/This section/ s/Section 5.9.4/Section 5.9.4 of [RFC8995]/ Section 4.2.4, paragraph 13 s/certification request/Certificate Request/ Section 4.2.4, paragraph 17 > * PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST > be sent on reception of the Cert Confirm. s/Cert Confirm/Certificate Confirm/ Section 4.3, paragraph 1 > BRSKI-AE provides generalizations to the addressing scheme defined in > BRSKI [RFC8995], Section 5 to accommodate alternative enrollment > protocols that use authenticated self-contained objects for > certification requests. As this is supported by various existing > enrollment protocols, they can be employed without modifications to > existing RAs/CAs supporting the respective enrollment protocol (see > also Section 5). s/enrollment protocols, they/enrollment protocols. They/ Section 4.3, paragraph 1 > The addressing scheme in BRSKI for certification requests and the > related CA certificates and CSR attributes retrieval functions uses > the definition from EST [RFC7030], here on the example of simple > enrollment: "/.well-known/est/simpleenroll". This approach is > generalized to the following notation: "/.well-known/<enrollment- > protocol>/<request>" in which <enrollment-protocol> refers to a > certificate enrollment protocol. Note that enrollment is considered > here a message sequence that contains at least a certification > request and a certification response. The following conventions are > used to provide maximal compatibility with BRSKI: s/[RFC7030], here on/[RFC7030]. Here is/ Section 4.3, paragraph 1 > * <enrollment-protocol>: MUST reference the protocol being used. > Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as > in [RFC9483] and Section 5.1 below. Values for other existing > protocols such as CMC and SCEP, or for newly defined protocols are > outside the scope of this document. For use of the <enrollment- > protocol> and <request> URI components, they would need to be > specified in a suitable RFC and placed into the Well-Known URIs > registry, as for EST in [RFC7030]. s/as for/just as/ Section 5, paragraph 0 > 5. Instantiation to Existing Enrollment Protocols s/Instantiation to/Instantiation of/ Section 5.1, paragraph 0 > 5.1. BRSKI-CMP: Instantiation to CMP s/Instantiation to/Instantiation of/ Section 5.1, paragraph 8 > BRSKI-AE with CMP can also be combined with Constrained BRSKI > [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment > message transport as described by CoAP Transport for CMP [RFC9482]. > In this scenario, of course the EST-specific parts of > [I-D.ietf-anima-constrained-voucher] do not apply. Suggest to drop the phrase "of course". Document references draft-ietf-anima-constrained-voucher-23, but -24 is the latest available revision. Section 1.1, paragraph 2 > e reason that EST cannot be used is because it does not support multiple hop > ^^^^^^^^^^ The word "because" means "for the reason that" and thus introduces redundancy. Section 2, paragraph 21 > on of the certification request. Typically this is achieved by a signature u > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Typically". Section 3, paragraph 4 > ity protection and proof of possession- Typically a self-signature is used to > ^^^^^^^^^^^^^^^^^^^^^ This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Section 3.2, paragraph 6 > ned with an existing IDevID secret. Thus also CMC does not rely on the securi > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Section 7, paragraph 2 > e 4 of the BRSKI-AE draft 04 status update at IETF 116. [I-D.eckert-anima-brs > ^^^^^^ Possible agreement error. The noun "update" seems to be countable. Section 7, paragraph 7 > munications security - Part 9: Cyber security key management for power syste > ^^^^^^^^^^^^^^ The word "cybersecurity" is spelled as one. Section 7, paragraph 9 > American Reliability Council, "Cyber Security -Electronic Security Perimeter > ^^^^^^^^^^^^^^ The word "cybersecurity" is spelled as one. Section 9.2, paragraph 4 > bset-137 specifying the ETRAM/ETCS online key management for train control s > ^^^^^^ Do not mix variants of the same word ("online" and "on-line") within a single text. Mahesh Jethanandani [email protected]
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
