BRSKI-AE: Alternative Enrollment Protocols in BRSKI
draft-ietf-anima-brski-ae-13

I'm leaving my old discuss text below, just because I can.  

The authors pointed me to RFC8995 section 5.6 and 11.4, which nicely explains how the chain between pledge, MASA, and registrar works to ensure that the registrar is the legit registrar.  In the process, one of the authors suggested that the voucher process could be added to figure 2, which I'd be happy to see, if and only if it doesn't make the figure unweildy.  

Thanks to the authors for the quick response and for politely pointing me to the referenced RFCs.

----------------------------------------------------------------------
old DISCUSS:
----------------------------------------------------------------------

While this draft clearly outlines the requirements for proof of possession and
integrity/authentication of the pledge, I did not see any discussion on
integrity/authentication of the RA/CA.  How can the pledge determine if it is
requesting certificates (either its own or CA) from the proper RA/CA?  One of
the advantages of EST is that the pledge can verify the EST server certificate,
and an on-path attack is harder when there is an adequate TLS session.  Is that
the case with CMP (or SCEP)?  If so, either point me to where that is
documented or add a couple of sentences on how that is done.  If not, please
add a section to the Security Considerations.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-ae-12

#GENERIC COMMENTS
#================
## The text contains many acronyms making it not easy to digest when not familiar with ANIMA technology. (i am not that familiar with ANIMA)

## I provided a few rewrites of text to help the structure and simplify reading the content, while keeping the original message, and hope it helps improve document quality

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

11	Abstract
12
13	   This document defines an enhancement of Bootstrapping Remote Secure
14	   Key Infrastructure (BRSKI, RFC 8995).  It supports alternative
15	   certificate enrollment protocols, such as CMP, that use authenticated
16	   self-contained signed objects for certification messages.

[minor]
Possibly we could make the abstract slightly higher level to describe the content of the draft. What about the following proposed alternative abstract:

"
This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative Enrollment). BRSKI-AE extends BRSKI to support alternative enrollment mechanisms beyond those originally specified, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing BRSKI mechanisms may not be feasible or optimal, providing a framework for integrating other automated bootstrapping and enrollment techniques. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.
"

106	   This approach provides the following advantages.  The origin of
107	   requests and responses can be authenticated independent of message
108	   transfer.  This supports end-to-end authentication (proof of origin)
109	   also over multiple hops, as well as asynchronous operation of
110	   certificate enrollment.  This in turn provides architectural
111	   flexibility where and when to ultimately authenticate and authorize
112	   certification requests while retaining full-strength integrity and
113	   authenticity of certification requests.

[major]
I am not sure what is the correlation between (proof of origin) and "end-to-end authentication". Why is the prrof of origin between brakets?

[minor]
I found this paragraph unfortunatly strucured. What about following proposal:

"
This approach offers several distinct advantages. It allows for the authentication of the origin of requests and responses independently of the message transfer mechanism. This capability facilitates end-to-end authentication (proof of origin) across multiple hops and supports the asynchronous operation of certificate enrollment. Consequently, this provides architectural flexibility in determining the location and timing for the ultimate authentication and authorization of certification requests, while ensuring the integrity and authenticity of those requests is maintained with full cryptographic strength.
"

137	   The goals of BRSKI-AE are to provide an enhancement of BRSKI for
138	   LDevID certificate enrollment using, alternatively to EST, a protocol
139	   that
140
141	   *  supports end-to-end authentication over multiple hops
142
143	   *  enables secure message exchange over any kind of transfer,
144	      including asynchronous delivery.
145
146	   Note that the BRSKI voucher exchange of the pledge with the registrar
147	   and MASA uses authenticated self-contained objects, so the voucher
148	   exchange already has these properties.
149
150	   The well-known URI approach of BRSKI and EST messages is extended
151	   with an additional path element indicating the enrollment protocol
152	   being used.
153
154	   Based on the definition of the overall approach and specific
155	   endpoints, this specification enables the registrar to offer multiple
156	   enrollment protocols, from which pledges and their developers can
157	   then pick the most suitable one.
158
159	   It may be noted that BRSKI (RFC 8995) specifies how to use HTTP over
160	   TLS, but further variants are known, such as Constrained BRSKI
161	   [I-D.ietf-anima-constrained-voucher] using CoAP over DTLS.  In the
162	   sequel, 'HTTP' and 'TLS' are just references to the most common case,
163	   where variants such as using CoAP and/or DTLS are meant to be
164	   subsumed - the differences are not relevant here.
165
166	   This specification is sufficient together with its references to
167	   support BRSKI with the Certificate Management Protocol (CMP,
168	   [RFC9480]) profiled in the Lightweight CMP Profile (LCMPP,
169	   [RFC9483]).  Combining BRSKI with a protocol or profile other than
170	   LCMPP will require additional IANA registrations based on the rules
171	   specified in this document.  It may also require additional
172	   specifications for details of the protocol or profile (similar to
173	   [RFC9483]), which are outside the scope of this document.

[minor]
A possible alternate rewrite to make the text easier to read:

"
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID certificate enrollment through the use of an alternative protocol to EST, which:

* Supports end-to-end authentication across multiple hops.
* Facilitates secure message exchange over any type of transfer mechanism, including asynchronous delivery.

It should be noted that the BRSKI voucher exchange between the pledge, registrar, and MASA involves the use of authenticated self-contained objects, which inherently possess these properties.

The existing well-known URI structure used for BRSKI and EST messages is extended by introducing an additional path element that specifies the enrollment protocol being employed.

This specification allows the registrar to offer multiple enrollment protocols, enabling pledges and their developers to select the most appropriate one based on the defined overall approach and specific endpoints.

It is important to recognize that BRSKI (RFC 8995) specifies the use of HTTP over TLS, but variations such as Constrained BRSKI [I-D.ietf-anima-constrained-voucher], which uses CoAP over DTLS, are also recognized. In this context, 'HTTP' and 'TLS' are used as references to the most common implementation, though variants using CoAP and/or DTLS are implied where applicable, as the distinctions are not pertinent here.

This specification, together with its referenced documents, is sufficient to support BRSKI with the Certificate Management Protocol (CMP, [RFC9480]) as profiled in the Lightweight CMP Profile (LCMPP, [RFC9483]). Integrating BRSKI with a protocol or profile other than LCMPP will necessitate additional IANA registrations, as detailed in this document. Furthermore, additional specifications may be required for the details of the protocol or profile, which fall outside the scope of this document.
"

175	1.1.  Supported Scenarios
176
177	   BRSKI-AE is intended to be used in situations like the following.
178
179	   *  Pledges and/or the target domain reuse an already established
180	      certificate enrollment protocol different from EST, such as CMP.
181
182	   *  The application scenario indirectly excludes the use of EST for
183	      certificate enrollment, for reasons like these:
184
185	      -  The Registration Authority (RA) is not co-located with the
186	         registrar while it requires end-to-end authentication of
187	         requesters.  Yet EST does not support end-to-end authentication
188	         over multiple hops.
189
190	      -  The RA or certification authority (CA) operator requires
191	         auditable proof of origin for Certificate Signing Requests
192	         (CSRs).  This is not possible with TLS because it provides only
193	         transient source authentication.
184
195	      -  Certificates are requested for types of keys, such as Key
196	         Encapsulation Mechanism (KEM) keys, that do not support signing
197	         (nor alternative forms of single-shot proof of possession like
198	         those described in [RFC6955]).  This is not supported by EST
199	         because it uses CSRs in PKCS #10 [RFC2986] format, which can
200	         only use proof-of-possession methods that need just a single
201	         message, while proof of possession for KEM keys, for instance,
202	         requires receiving a fresh challenge value beforehand.
203
204	      -  The pledge implementation uses security libraries not providing
205	         EST support or uses a TLS library that does not support
206	         providing the so-called tls-unique value [RFC5929], which is
207	         needed by EST for strong binding of the source authentication.
208
209	   *  No full RA functionality is available on-site in the target
210	      domain, while connectivity to an off-site RA may be intermittent
211	      or entirely offline.
212
213	   *  Authoritative actions of a local RA at the registrar is not
214	      sufficient for fully and reliably authorizing pledge certification
215	      requests.  This may be due to missing data access or due to an
216	      insufficient level of security, for instance regarding the local
217	      storage of private keys.
217
219	   Bootstrapping can be handled in various ways, depending on the
220	   application domains.  The informative Appendix A provides
221	   illustrative examples from various industrial control system
222	   environments and operational setups motivating the support of
223	   alternative enrollment protocols.

[minor]
possible rewrite for readability

"
BRSKI-AE is designed for use in scenarios such as the following:

* Pledges and/or the target domain leverage an existing certificate enrollment protocol other than EST, such as CMP.

* The application context precludes the use of EST for certificate enrollment due to factors such as:

    - The Registration Authority (RA) is not co-located with the registrar and requires end-to-end authentication of requesters, which EST does not support over multiple hops.

    - The RA or Certification Authority (CA) operator mandates auditable proof of origin for Certificate Signing Requests (CSRs), which cannot be provided by TLS as it only offers transient source authentication.

    - Certificates are required for key types, such as Key Encapsulation Mechanism (KEM) keys, that do not support signing or other single-shot proof of possession methods, as described in [RFC6955]. EST, which relies on CSRs in PKCS #10 [RFC2986] format, does not accommodate these key types because it necessitates proof-of-possession methods that operate within a single message, whereas proof of possession for KEM keys requires prior receipt of a fresh challenge value.

    - The pledge implementation employs security libraries that do not support EST or uses a TLS library lacking support for the "tls-unique" value [RFC5929], which EST requires for the strong binding of source authentication.

* Full RA functionality is not available on-site within the target domain, and connectivity to an off-site RA may be intermittent or entirely offline.

* Authoritative actions by a local RA at the registrar are insufficient for fully and reliably authorizing pledge certification requests, potentially due to a lack of access to necessary data or inadequate security measures, such as the local storage of private keys.

Bootstrapping may be managed in various ways depending on the application domain. Appendix A provides illustrative examples from different industrial control system environments and operational contexts that justify the support of alternative enrollment protocols.
"

258	   CSR:  Certificate Signing Request

[minor]
other entries have a RFC associated as reference, but this one has not? Is that intentional?

847	   BRSKI-AE provides generalizations to the addressing scheme defined in
848	   BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
849	   protocols that use authenticated self-contained objects for
850	   certification requests.  In existing RAs/CAs supporting such an
851	   enrollment protocol (see also Section 5), these generalizations can
852	   be employed without modifications.

[minor]
This seems to read odd. What about the following alternative:

"
BRSKI-AE extends the addressing scheme outlined in [RFC8995], Section 5, to support alternative enrollment protocols that utilize authenticated, self-contained objects for certification requests. These extensions are designed to be compatible with existing Registration Authorities (RAs) and Certification Authorities (CAs) that already support such enrollment protocols, enabling their use without requiring any modifications.
"

921	5.1.  BRSKI-CMP: BRSKI-AE instantiated with CMP
922
923	   Instead of referring to CMP as specified in [RFC4210] and [RFC9480],
924	   this document refers to the Lightweight CMP Profile (LCMPP) [RFC9483]
925	   because the subset of CMP defined there is sufficient for the
926	   functionality needed here.
927
928	   When using CMP, adherence to the LCMPP [RFC9483] is REQUIRED.  In
929	   particular, the following specific requirements apply (cf.
930	   Figure 2).
931
932	   *  CA Certs Request (1) and Response (2):
933	      Requesting CA certificates is OPTIONAL.
934	      If supported, it SHALL be implemented as specified in [RFC9483],
935	      Section 4.3.1.
936
937	   *  Attribute Request (3) and Response (4):
938	      Requesting certification request attributes is OPTIONAL.
939	      If supported, it SHALL be implemented as specified in [RFC9483],
940	      Section 4.3.3.
941
942	      Alternatively, the registrar MAY modify the contents of the
943	      requested certificate contents as specified in [RFC9483],
944	      Section 5.2.3.2.
945
946	   *  Certification Request (5) and Response (6):
947	      Certificates SHALL be requested and provided as specified in the
948	      LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483],
949	      Section 4.1.4 (based on PKCS #10).
950
951	      Proof of possession SHALL be provided in a way suitable for the
952	      key type.  Proof of identity SHALL be provided by signature-based
953	      protection of the certification request message as outlined in
954	      [RFC9483], Section 3.2 using the IDevID secret.
955
956	      When the registrar forwards a certification request by the pledge
957	      to a backend RA/CA, the registrar is RECOMMENDED to wrap the
958	      original certification request in a nested message signed with its
959	      own credentials as described in [RFC9483], Section 5.2.2.1.  This
960	      explicitly conveys the consent by the registrar to the RA while
961	      retaining the original certification request message with its
962	      proof of origin provided by the pledge signature.
963
964	      In case additional trust anchors (besides the pinned-domain-cert)
965	      need to be conveyed to the pledge, this SHOULD be done in the
966	      caPubs field of the certification response rather than in a CA
967	      Certs Response.
968
969	   *  Certificate Confirm (7) and PKI/Registrar Confirm (8):
970	      Explicit confirmation of new certificates to the RA/CA MAY be used
971	      as specified in [RFC9483], Section 4.1.1.
972
973	      Note that independently of the certificate confirmation within
974	      CMP, enrollment status telemetry with the registrar at BRSKI level
975	      will be performed as described in [RFC8995], Section 5.9.4.
976
977	   *  If delayed delivery of CMP messages is needed (for instance, to
978	      support enrollment over an asynchronous channel), it SHALL be
979	      performed as specified in Section 4.4 and Section 5.1.2 of
980	      [RFC9483].
981
982	   How messages are exchanged between the registrar and backend PKI
983	   components (i.e., RA and/or CA) is out of scope of this document.
984	   Since CMP is independent of message transfer, the mechanism for this
985	   exchange can be freely chosen according to the needs of the
986	   application scenario.  For the applicable security considerations,
987	   see Section 7.  Further guidance can be found in [RFC9483],
988	   Section 6.
989
990	   BRSKI-AE with CMP can also be combined with Constrained BRSKI
991	   [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
992	   message transport as described by CoAP Transport for CMP [RFC9482].
993	   In this scenario, the EST-specific parts of
994	   [I-D.ietf-anima-constrained-voucher] do not apply.
995
996	   For BRSKI-AE scenarios where a general solution (cf.  Section 4.2.1)
997	   for discovering registrars with CMP support is not available, the
998	   following minimalist approach MAY be used.  Perform discovery as
999	   defined in BRSKI [RFC8995], Appendix B but using the service name
1000	   "brski-registrar-cmp" (defined in Section 6) instead of "brski-
1001	   registrar" (defined in [RFC8995], Section 8.6).  Note that this
1002	   approach does not support join proxies.

[minor]
proposed readability rewrite:

"
In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in LCMPP sufficiently meets the required functionality.

Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The following specific requirements apply (refer to Figure 2):

  * CA Certificates Request (1) and Response (2): Requesting CA certificates is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.1.

  * Attribute Request (3) and Response (4): Requesting certification request attributes is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.3.

  Alternatively, the registrar MAY modify the requested certificate contents as specified in [RFC9483], Section 5.2.3.2.

  * Certification Request (5) and Response (6): Certificates SHALL be requested and provided as specified in LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or Section 4.1.4 (based on PKCS #10).

  Proof of possession SHALL be provided in a manner suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message as outlined in [RFC9483], Section 3.2, using the IDevID secret.

  When the registrar forwards a certification request from the pledge to a backend RA/CA, it is RECOMMENDED that the registrar wraps the original certification request in a nested message signed with its own credentials, as described in [RFC9483], Section 5.2.2.1. This approach explicitly conveys the registrar's consent to the RA while retaining the original certification request with the proof of origin provided by the pledge's signature.

  If additional trust anchors, beyond the pinned-domain-cert, need to be conveyed to the pledge, this SHOULD be done in the caPubs field of the certification response rather than through a CA Certificates Response.

  * Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit confirmation of new certificates to the RA/CA MAY be used as specified in [RFC9483], Section 4.1.1.

  Note that independent of certificate confirmation within CMP, enrollment status telemetry with the registrar at the BRSKI level will be performed as described in [RFC8995], Section 5.9.4.

  * If delayed delivery of CMP messages is required (e.g., to support enrollment over an asynchronous channel), it SHALL be performed as specified in Section 4.4 and Section 5.1.2 of [RFC9483].

The mechanisms for exchanging messages between the registrar and backend PKI components (i.e., RA and/or CA) are outside the scope of this document. CMP's independence from the message transfer mechanism allows for flexibility in choosing the appropriate exchange method based on the application scenario. For applicable security considerations, refer to Section 7. Further guidance can be found in [RFC9483], Section 6.

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 such scenarios, the EST-specific parts of [I-D.ietf-anima-constrained-voucher] do not apply.

For BRSKI-AE scenarios where a general solution for discovering registrars with CMP support is not available (cf. Section 4.2.1), the following minimalist approach MAY be used: perform discovery as defined in BRSKI [RFC8995], Appendix B, but use the service name "brski-registrar-cmp" (as defined in Section 6) instead of "brski-registrar" (as defined in [RFC8995], Section 8.6). Note that this approach does not support join proxies.
"

Thanks for this document. I have two minor comments/nits:

- please alphabetize your terminology section.

- in, “The following terms are described partly in addition.”

I don’t know what you mean by “partly“. Would the sentence be correct if you deleted that word?

Section 2 defines the following terms that don't appear elsewhere in the document: asynchronous communication, synchronous communication.

Thank you to Meral Shirazipour for the GENART review.

** Section 4.2.1
   As a more general solution, the BRSKI discovery mechanism can be
   extended to provide up-front information on the capabilities of
   registrars.  Future work such as [I-D.eckert-anima-brski-discovery]
   may provide this.
Does it make sense to reference and promise work on an individual, expired I-D?

** Section 7 notes that the Security Considerations of RFC8995 apply.  What of the privacy consideration of RFC8895 (Section 10)? Do they apply or need any refinement (e.g., Section 10.2)?

Thanks for working on this specification. No comments/issues raised druing my review from transport portocol point of view.

# Éric Vyncke, INT AD, comments for draft-ietf-anima-brski-ae-12

Thank you for the work put into this document (and the SVG figures). It is sometimes hard to read with very long sentences.

Please find below just one non-blocking NIT points.

Special thanks to Toerless Eckert for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# NITS (non-blocking / cosmetic)

## Section 1

As English is not my primary language, I find weird the use of "production" rather than "manufacturing" in `during its production`.