Hello Mohamed, Thank you for the review and the feedback. Regarding the nits you sent, we will address them in the next version of the document.
I put my comments inline Best regards Steffen > -----Original Message----- > From: Mohamed Boucadair via Datatracker <nore...@ietf.org> > Sent: Sunday, April 6, 2025 5:04 PM > Subject: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: (with > DISCUSS and COMMENT) > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > # DISCUSS > > # Unconditional MUST > > CURRENT: > The pledge MUST respond to all requests regardless of the > Host header field provided by the client (i.e., ignore it). > > I don't think that is safe. > > I'm afraid this needs some scoping; as there are other legitimate conditions > where the pledge doe snot have to reply. [stf] Based on the existing discussion on this, we opened an issue on github to align on the solution (https://github.com/anima-wg/anima-brski-prm/issues/136). The current proposal takes your suggestion into account: OLD The pledge MUST respond to all requests regardless of the Host header field provided by the client (i.e., ignore it). NEW In the absence of a security policy the pledge MUST respond to all requests regardless of the Host header field provided by the client (i.e., ignore it). A security policy may include a rate limiting for a requests to avoid susceptibility of the pledge to overload. Once aligned, we will include it in the draft > # Compliance with HTTP BCP (RFC9205) > > CURRENT: > If the pledge is unable to create the PVR, it SHOULD respond with an > HTTP error status code to the Registrar-Agent. The following client > error status codes SHOULD be used: > > The use of normative language is IMO not compliant with the guidance in > RFC9205, about error handling. [stf] I created a new issue for this: https://github.com/anima-wg/anima-brski-prm/issues/137 >From RFC 9205 I understood that we could use the HTTP status codes in this way >(https://datatracker.ietf.org/doc/html/rfc9205#section-4.6 ) What would you suggest here? > > There are several similar constructs in the document. > > # Cluster with 8366bis > > CURRENT: > > The JSON PVR Data MUST contain the following fields of the "ietf- > voucher-request" YANG module as defined in > [I-D.ietf-anima-rfc8366bis]; > > I think this spec should be clustered with 8366bis. There are several > structure > that used in this document and which depends on what is defined in 8366bis. > Changes to the bis will have implications on this one. > > With that in mind, I tend to suggest holding approval of this specification > till we finalize the bis spec. [stf] As indicated by Michael, we already have a cluster for RFC 8366bis and further drafts related to BRSKI variants to take care of mutual influences. I opened an issue (https://github.com/anima-wg/anima-brski-prm/issues/138) to discuss optimization in handling of the documents. > > # Requires TLS1.3 > > CURRENT: > As already stated in [RFC8995], the use of TLS 1.3 (or newer) is > encouraged. TLS 1.2 or newer is REQUIRED on the Registrar-Agent > side. TLS 1.3 (or newer) SHOULD be available on the registrar, but > TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the > MASA, but TLS 1.2 MAY be used. > > Please update to take into to reflect draft-ietf-uta-require-tls13. [stf] I saw that there was already discussion on this issue. I created a corresponding issue as https://github.com/anima-wg/anima-brski-prm/issues/139 We will discuss the use of TLS 1.2 and if there is a desire to also allow or existing pledges, that may have no option to only allow TLS 1.3, we would add a note as suggested and explain the necessity. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Consider having a reference figure early in the document with the various > entities. [stf] We currently have the architecture overview figure in section 5 discussing the solution architecture. To avoid repeating that figure, would it be fine to essentially reference the figure from the introduction to guide the reader to the overview? > # Be consistent through the document about how you expand as both forms are > used: Xccc Xccc Xcc (XXX) or XXX (Xccc Xccc Xcc). [stf] okay, we will double check the referencing. Changed according to proposals in the NITs. > # Entities are functional one: There might be multiple servers, RAs, pledges, > etc. Consider fixing this through the document. For example: > > OLD: > EST in turn > relies for the authentication and authorization of the certification > request on the credentials used by the underlying TLS between the EST > client and the EST server. > NEW: > EST in turn > relies for the authentication and authorization of the certification > request on the credentials used by the underlying TLS between the EST > client and an EST server. > > OLD: BRSKI addresses scenarios in which the pledge initiates the > NEW: BRSKI addresses scenarios in which a pledge initiates the > > OLD: > * introduces the Registrar-Agent as new component to facilitate the > communication between the pledge and the domain registrar. > > NEW: > * introduces the Registrar-Agent as new component to facilitate the > communication between the pledge and a domain registrar. > > OLD: is cryptographically bound to the end entity (EE) certificate. > NEW: is cryptographically bound to an end entity (EE) certificate. [stf] agree to all of the above. Will be changed accordingly. > Etc. [stf] we will look for further places to ensure openness to utilize multiple instances > # Consider providing an example of non-IP > > CURRENT: > * also enables the usage of alternative transports, both IP-based > and non-IP, [stf] we discussed connectivity via Bluetooth or NFC and can include it as example. Would lead to NEW * also enables the usage of alternative transports, both IP-based and non-IP (e.g., Bluetooth-based or NFC-based communication), > # Capability management: > > CURRENT > There may be pledges that can support both modes, initiator and > responder mode. In these cases, BRSKI-PRM can be combined with BRSKI > as defined in [RFC8995] or BRSKI-AE [I-D.ietf-anima-brski-ae] to > allow for more bootstrapping flexibility. > > Do we need to expose these capabilities to a management system? How this can > be managed/controlled? [stf] good point, we address this capability exchange options later on in the discovery section by referencing the ongoing work on BRSKI-Discovery, but keeping it at a minimum in BRSKI-PRM. The BRSKI-Discovery discusses solutions for all existing variants of BRSKI Proposal to add after the stated sentence NEW Providing information about capabilities of BRSKI components like the pledge or registrar is handled as part of the discovery. BRSKI-PRM relies only on a minimum necessary set of capabilities for the interaction and leaves the definition of more advanced mechanisms allowing to signal specific capabilities to [I-D.ietf-anima-brski-discovery]. > # Not a definition > > CURRENT: > CSR: Certificate Signing Request. > > This is not a definition. May be point to the RFC you cited in the doc. [stf] We do this in later sections of the document, but it is good to also include it here. OLD CSR: Certificate Signing Request. NEW CSR: Certificate Signing Request, as defined in [RFC2986]. > # Resource vs. Endpoint > > CURRENT: > endpoint: Term equivalent to resource in HTTP [RFC9110] and CoAP > [RFC7252]. Endpoints are accessible via Well-Known URIs > [RFC8615]. > > For the CoAP mention, this may be confusing as CoAP has also the concept of > "Endpoint", which is not identical to resource. [stf] Do you have a suggestion on how to address potential confusion here? We tried this already by providing references to both RFCs, but if there is a clearer way of describing it we could include it. > # Lack of reference > > CURRENT: > mTLS: mutual Transport Layer Security. > [stf] proposal to enhance the description to OLD mTLS: mutual Transport Layer Security. NEW mTLS: mutual Transport Layer Security, refers to mutual authenticated TLS as specified in [RFC 8446]. > # Unfortunate acronym > > PoP: Unfortunate as this one is widely used for Point of Presence. No need to > change anything, though. [stf] hm, that is unfortunate indeed, but proof-of-possession (PoP) is already used in other RFCs (RFC 7030, RFC 9483) and we aligned with that terminology. > # Consistency > > OLD: Registrar_Agent > NEW: Registrar-Agent [stf] good catch, most importantly, it needs to be correct in the terminology section. Changed as suggested. > # Mysterious > > CURRENT: Requirements Discussion and Mapping to Solution-Elements > > What does Solution-Elements mean? [stf] In the discussion we handled solution elements as "parts of the solution" like the introduction of the registrar-agent as new component or the reliance on self-contained objects, enhancements of assertion types in the voucher etc. If you have a proposal for a better name, we could change it. > # Thanks! > > CURRENT: > An abstract overview of the BRSKI-PRM protocol can be found on slide > 8 of [BRSKI-PRM-abstract]. > > That figure is helpful. I didn't checked though that all the steps are still > valid in the latest version of the spec. I trust you have done that check. [stf] yes, the steps are still fine. We did no include the details on the data objects but the exchanges are still valid. > # Outsource Key Infrastructure > > This is currently drawn within the customer domain. Can this be > outsourced/external to the customer domain? [stf] The intention was to show the supporting infrastructure on the customer side without including the operational model. So the PKI may be customer operated or provided to the customer as service. > # HTTP(S) > > CURRENT: the pledge and the Registrar-Agent is assumed to be HTTP(S) > > In which case the non-secure mode is allowed? [stf] The communication between the pledge and the registrar-agent is protected by relying on self-contained objects for the integrity protection. So it is not "non-secured". TLS is intended to provide confidentiality protection if needed. As the pledge in BRSKI-PRM would act as server, it needs a certificate (this is at least what we targeted for BRSKI-PRM) to authenticate accordingly. This comes with certain boundary conditions for the handling, which we put together in Annex B: https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.html#pledgehttps > # Group OPS considerations in one single section > > Consider moving the following to the OPS cons section: > > CURRENT: > The benefits of BRSKI-PRM can be achieved even without the > operational complexity of stand-alone Registrar-Agents by integrating > the necessary functionality of the Registrar-Agent as a module into > the domain registrar as shown in Figure 3 so that it can support the > BRSKI-PRM communications to the pledge. [stf] Good idea! Included the following in the Ops Con section: NEW As outlined in {{colo-regagt}} the functional support of BRSKI-PRM can also be achieved using a Registrar-Agent co-located with the Registrar instead of a stand-alone Registrar-Agent, which may reduce operational complexity. > > And > > CURRENT > Overall, this may have > operational implications when the registrar is part of a scalable > framework as described in Section 1.3.1 of > [I-D.richardson-anima-registrar-considerations]. [stf] The reference to [I-D.richardson-anima-registrar-considerations] is already contained in the Ops Con. So I would propose to move the sentence as suggested to the Ops Con section as following to keep the context: NEW Requirements to the utilized credentials authenticating and artifact signatures on the registrar as outlined in Section 6.3 may have operational implications when the registrar is part of a scalable framework as described in Section 1.3.1 of [I-D.richardson-anima-registrar-considerations]. > # Need concrete behavior > > CURRENT: Further, the Registrar-Agent SHOULD have synchronized time. > > Should we provide more concrete behavior here? [stf] We have certain considerations added for the pledge, that may have no synchronized time, but not for the registrar-agent. I created an issue (https://github.com/anima-wg/anima-brski-prm/issues/140) to discuss the further approach as there exist different options > # Non-discovery > > CURRENT: > 6.1.1. Discovery of the Registrar > > This is more about non-discovery :-) > > Consider changing to "Explicit Configuration of Registrars" [stf] Well, besides the configuration, there is also the reference to the standard discovery approach as already specified in RFC 8995 and the pointer to the BRSKI discovery draft for a more flexible discovery my feeling is it would be good to keep the naming. > # hostname and intermittent connectivity > > CURRENT: > While the Registrar-Agent requires the IP address of the domain > registrar to initiate a TLS session, a separate discovery of the > registrar is likely not needed and a configuration of the domain > registrar IP address or hostname is assumed. > > How to reconcile this with the intermittent connectivity condition mentioned > early in the document, including with a name resolution service which may not > be reachable? > > BTW, multiple IP addresses may be available. Consider updating to: > > NEW: > While the Registrar-Agent requires an IP address of the domain > registrar to initiate a TLS session, a separate discovery of the > registrar is likely not needed and a configuration of the domain > registrar IP address or hostname is assumed. [stf] I would be fine with the suggested text. > # Configurable knobs > > CURRENT: > In the absence of a more general discovery as defined in > [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use > > Do we need to have a control parameter here to instruct the behavior of the > RA? [stf] This is covered in the referenced draft. It allows to discover the functionality of the registrar with much more details about operational mode, encoding options, etc. Would you suggest to provide a sentence that the discovery may be a configuration item of the Registrar-Agent. I had assumed this is already implicitly given through the existing formulation, but explicit may be better. > The same applies for the following: > > CURRENT: > A nonceless voucher MAY be accepted as in [RFC8995] if allowed by the > pledge implementation of the manufacturer. [stf] As above, the suggestion is to include a sentence that the manufacturer may opt to have this as configuration item? > # Expired I-Ds > > CURRENT: e.g., as proposed in [I-D.richardson-emu-eap-onboarding]. > > I suggest to remove citations of expired individual I-Ds. [stf] Yes, we could remove it as it is just intended as example. Will double check with Michael if there will be an update of the draft > # "MUST ...unless" constructs should be "SHOULD ...unless" > > OLD: > To enable interaction as responder with the Registrar-Agent, pledges > in responder mode MUST act as servers and MUST provide the endpoints > defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI > path, except for the OPTIONAL endpoint "qps". The endpoints are > defined with short names to also accommodate for resource-constrained > devices. > > NEW: > To enable interaction as responder with a Registrar-Agent, pledges > in responder mode MUST act as servers and SHOULD provide the endpoints > defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI > path, except for the OPTIONAL endpoint "qps". The endpoints are > defined with short names to also accommodate for resource-constrained > devices. [stf] Hm, for compliance with BRSKI-PRM we require the support of the two stated endpoints in Table 1 to ensure they can be trigger. > (also s/the/a) [stf] done in the original text > # Redundant language (many occurrences in the text) > > OLD: Optionally, TLS MAY be used to provide transport security > NEW: TLS MAY be used to provide transport security [stf] Thank you, done as suggested for all occurrences. > # TTL > > CURRENT: > Note that the pledge provisionally accepts the registrar EE > certificate contained in the tPVR until it receives the voucher (see > Section 5.4). > > Shouldn't that be TTLed as well for better security control? [stf] Good point we need to discuss this to avoid a dead lock of the pledge. As the situation is different to the TLS connection in BRSKI we may add some further clarification. Created issue for discussion https://github.com/anima-wg/anima-brski-prm/issues/142 > # Inappropriate use of normative language > > CURRENT: > The following assumes that a Registrar-Agent MAY need to query the > overall status of a pledge. > > This is an assumption, s/MAY/may [stf] yes, true. Changed to lower case. > # Rate-limit log actions > > CURRENT: > The registrar SHOULD log certain events to provide an audit trail for > the onboarding of pledges into its domain. > > In order to protect the registrar from overload attacks, consider adding a > rate-limit guard for logging the same event. [stf] Added the following at the end of the section NEW In order to protect the registrar from overload attacks, a rate-limiting may be used by logging events from the same type just once. > # Missing IANA action > > CURRENT: IANA has registered the following service names > > Please ad an action for IANA to update that entry. Thanks. [stf] We've got the following information from IANA: "The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed." Are there additional actions necessary? > # You are allowed to not use the template! > > CURRENT: > The use of YANG to define data structures via the [RFC8971] > "structure" statement, is relatively new and distinct from the common > use of YANG to define an API accessed by network management protocols > such as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, > these guidelines do not follow the template described by Section 3.7 > of [RFC8407] (Security Considerations). > > You can delete this text. 8407bis have the required provisions for you :-) > > Documents that define exclusively modules following the extension in > [RFC8791] are not required to include the security template in > Section 3.7.1. Likewise, following the template is not required for > modules that define YANG extensions such as [RFC7952]. [stf] Updated the text as suggested > > Hope this helps. [stf] definitely, again thanks for the review. > Cheers, > Med > > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
