Gunter Van de Velde has entered the following ballot position for draft-ietf-anima-brski-ae-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # 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. " _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
