Mohamed Boucadair has entered the following ballot position for draft-ietf-anima-brski-prm-18: Discuss
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-prm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Steffen, Thomas, Eliot, and Michael, Many thanks for editing such a well-written document. Enjoyed reading it, although some repetition here and there but that can be easily fixed. Special thanks for the well thought management/logging/operational considerations. Thanks to Ran Chen for the opsdir review. I have some few DISCUSS/COMMENT points. I will send you offline a set of minor/edits. # 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. # 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. 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. # 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Consider having a reference figure early in the document with the various entities. # Be consistent through the document about how you expand as both forms are used: Xccc Xccc Xcc (XXX) or XXX (Xccc Xccc Xcc). # 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. Etc. # Consider providing an example of non-IP CURRENT: * also enables the usage of alternative transports, both IP-based and non-IP, # 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? # Not a definition CURRENT: CSR: Certificate Signing Request. This is not a definition. May be point to the RFC you cited in the doc. # 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. # Lack of reference CURRENT: mTLS: mutual Transport Layer Security. # Unfortunate acronym PoP: Unfortunate as this one is widely used for Point of Presence. No need to change anything, though. # Consistency OLD: Registrar_Agent NEW: Registrar-Agent # Mysterious CURRENT: Requirements Discussion and Mapping to Solution-Elements What does Solution-Elements mean? # 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. # Outsource Key Infrastructure This is currently drawn within the customer domain. Can this be outsourced/external to the customer domain? # HTTP(S) CURRENT: the pledge and the Registrar-Agent is assumed to be HTTP(S) In which case the non-secure mode is allowed? # 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. 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]. # Need concrete behavior CURRENT: Further, the Registrar-Agent SHOULD have synchronized time. Should we provide more concrete behavior here? # Non-discovery CURRENT: 6.1.1. Discovery of the Registrar This is more about non-discovery :-) Consider changing to “Explicit Configuration of Registrars” # 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. # 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? 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. # 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. # “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. (also s/the/a) # 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 # 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? # 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 # 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. # Missing IANA action CURRENT: IANA has registered the following service names Please ad an action for IANA to update that entry. Thanks. # 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]. Hope this helps. Cheers, Med _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
