[Anima] Re: Gunter Van de Velde's No Objection on draft-ietf-anima-brski-ae-12: (with COMMENT)

["Gunter van de Velde (Nokia)" <[e-mail]>]

Thanks Steffen.

Be well,
G/

-----Original Message-----
From: Fries, Steffen <[e-mail]> 
Sent: Tuesday, September 3, 2024 7:05 PM
To: Gunter van de Velde (Nokia) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Gunter Van de Velde's No Objection on draft-ietf-anima-brski-ae-12: (with COMMENT)

[You don't often get email from [e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Gunter,

Thank you for your feedback. They certainly increase clarity of several statement in the draft.
We provided some specific reactions inline mainly to the major comment and to some of the minor comments. Most of the minor comments are straight forward and we will take the them into account to improve clarity and understanding in the next version of the document.

Best regards
Steffen.

> -----Original Message-----
> From: Gunter Van de Velde via Datatracker <[e-mail]>
> Sent: Friday, August 30, 2024 6:32 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Gunter Van de Velde's No Objection on 
> draft-ietf-anima-brski-ae-12: (with
> COMMENT)
>
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Ccbaac8746
> c09445dd47708dccc3a81dd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C6
> 38609798892322740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CvuDvH9jT%2B
> %2BXcduG48sDmD530DtmEokATFODLFn4kuc%3D&reserved=0
> %2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-
> positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C3751aac2dd
> be45f8167c08dcc8aca1c4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C638605891000583633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
> =f%2FDuCh4ZKKn6sjH3KeLeRqjUU7i%2BroDEP2zzamCTRJk%3D&reserved=0
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.i%2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Ccbaac874
> 6c09445dd47708dccc3a81dd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C
> 638609798892335324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dltr%2F%2BI
> 1xVNqYU%2Bma0gCP2MgxkdKiLNZCxYAMZdRkzs%3D&reserved=0
> etf.org%2Fdoc%2Fdraft-ietf-anima-brski-
> ae%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C3751aac2ddbe45f81
> 67c08dcc8aca1c4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6386
> 05891000595002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XrqJC
> 50D331eGQ%2FMrMOXgh3OJiKxRxaSvT7lB1okco4%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> 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. "
[stf] the proposal reads fine from my point of view. We may add a statement that the draft also defines one specific approach leveraging the introduced flexibility using CMP.

>
> 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?
[stf] Proposal text for clarification as replacement:
OLD
  This supports end-to-end authentication (proof of origin)

NEW
  This supports end-to-end authentication (i.e., end-to-end proof of origin)

>
> [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. "
[stf] Your proposal already includes a formulation addressing your major point above. We will take the whole paragraph into consideration when updating this part.

>
> 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. "
>
>