Hello Roman, Thank you for your comments. I put my comments inline, marked with [stf] We will address the points listed in the next version of the draft. We have intermediate versions already incorporating several comments received on https://github.com/anima-wg/anima-brski-prm (diff with version 18: https://author-tools.ietf.org/diff?doc_1=draft-ietf-anima-brski-prm&url_2=https://raw.githubusercontent.com/anima-wg/anima-brski-prm/refs/heads/main/draft-ietf-anima-brski-prm.txt)
Best regards Steffen > -----Original Message----- > From: Roman Danyliw via Datatracker <nore...@ietf.org> > Sent: Monday, April 14, 2025 11:59 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de; i...@kovatsch.net > Subject: Roman Danyliw's Discuss on draft-ietf-anima-brski-prm-18: (with > DISCUSS and COMMENT) > > Roman Danyliw 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/ > %2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C4583723db66 > 744933d3008dd7b9f900a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638802647448242206%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=cjnj2TcCo%2FpAySc7GyFqZjN2f1gJZYe9J%2Fw > yTOxXQK8%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://datatracker.i/ > etf.org%2Fdoc%2Fdraft-ietf-anima-brski- > prm%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C4583723db667449 > 33d3008dd7b9f900a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8802647448303370%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=z9SfJVUCjCxdUtBFZiDFTyRn7AeC%2BkWfnLGK4%2Fd > GbgA%3D&reserved=0 > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 6.1.2 > In the absence of a more general discovery as defined in > [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use > > The way this sentence is constructed makes [I-D.ietf-anima-brski-discovery] a > normative reference. Put more generally, it reads "If <A> then <B> MUST be > used". To know that <B> applies, one needs to fully understand <A>. I don't > think that is the intent. [stf] Thanks for spotting that. It was not intended. Actually the other way around. Proposal to reverse that to OLD In the absence of a more general discovery as defined in [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST use NEW For discovery the Registrar-Agent MUST use ... if it does not support a more general discovery as defined in [I-D.ietf-anima-brski-discovery]. > > ** Section 7.6.2.1 > * reason: contains a human-readable message; SHOULD NOT provide > information beneficial to an attacker > > Per the requirement in Section 4.2 of RFC2277 that the "Protocols that > transfer > text MUST provide for carrying information about the language of that text", > what is the recommended approach here? [stf] We used the same approach here as in RFC 8995 stating human readable message. Should we include a statement about appropriate language tagging like: NEW According to [RFC2277], human-readable information must contain information about the language of the text. Consequently, the utilized language is indicated at the beginning of the human readable information. > Same question for pvs-details in reason-context and pbs-details in > reason-context ( > > ** Section 7.6.2.1 > * reason: contains a human-readable message; SHOULD NOT provide > information beneficial to an attacker > > ... > * reason-context: contains a JSON object that provides additional > information specific to a failure; in contrast to Section 5.7 of > [RFC8995], MUST be provided; SHOULD NOT provide information > beneficial to an attacker > > When is it acceptable to provide information beneficial to the attacker? [stf] Well, likely never, but sometimes information on errors can be beneficial for an attacker to learn certain behavior and better target attacks. Would is be less irritating to delete that part resulting in the following: OLD reason-context: contains a JSON object that provides additional information specific to a failure; in contrast to Section 5.7 of [RFC8995], MUST be provided; SHOULD NOT provide information beneficial to an attacker NEW reason-context: contains a JSON object that provides additional information specific to a failure; in contrast to Section 5.7 of [RFC8995], MUST be provided > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Paul Kyzivat for the GENART review. > > ** Section 4. > > * The use of authenticated self-contained objects addresses both, > the TLS challenges and the technology stack challenge. > > What are "technology stack challenges"? [stf] We saw also challenges for instance when using BTLE or other near-field technologies or the communication between the registrar-agent and the pledge.The intension was to keep the security approach transport agnostic. > ** Section 6.1 > Alternatively, the registrar EE > certificate MAY be provided via configuration or a repository > > What is a "repository" and how is that difference than "configuration"? [stf] It is certainly sufficient to state configuration. What I had in mind are two ways of configuration one, were the device will be configured (some kind of push) and one were the device fetches the information from a database (some kind of pull). But this distinction is likely not necessary here proposal to change from OLD Alternatively, the registrar EE certificate MAY be provided via configuration or a repository NEW Alternatively, the registrar EE certificate MAY be provided via configuration > ** Section 6.1 > Further, the Registrar-Agent SHOULD have synchronized time. > > What is the impact of not having synchronized time? [stf] When the registrar-agent has no synchronized time it may not be able to validate the EE certificate of the registrar during the TLS handshake if the time drift is too big. As we recommend to utilize short-term certificates we may provide additional information. Proposal: NEW In case the registrar-agent does not have synchronized time, it may not be able to verify the registrar EE certificate during the TLS handshake. As the registrar-agent is recommended to utilize short-lived certificates in Section 12.3, a registrar-agent may use the valid from time of its short-lived certificate for time synchronization. > ** Section 6.1.2 > Note that this goes against the naming recommendation of [RFC6763]. > The _brski-pledge._tcp service, however, targets machine-to-machine > discovery. > > What in RFC6763 suggests a scope that would exclude "machine-to-machine > discovery" to provide justification for not following its recommendation? [stf] We interpreted section 7 RFC 6763 (https://www.rfc-editor.org/rfc/rfc6763#page-19) as application centric, but that may be misleading. The statement that the usage of the service name goes against the definition merely comes from the statement that "_tcp" is the second label. In the way the service name is constructed in BRSKI-PRM (<product-serial-number>._brski-pledge._tcp.local to discover a specific instance of the pledge, it becomes the third label. Would the following reformulation be better suited? OLD Note that this goes against the naming recommendation of [RFC6763]. The _brski-pledge._tcp service, however, targets machine-to-machine discovery. NEW Note that the service name definition is not fully inline with the naming recommendation of [RFC6763]. However, the definition allows to discover specific instances of a pledge. > ** Section 6.1.2 > For Ethernet, > it is provided by simply connecting the network cable. > > Isn't this an oversimplification? What if it there is local policy which > manages the behavior of the interface? What about provisioning that might > need > to occur on a switch? [stf] Understood. Pledges, not identifiable may be put into a quarantine VLAN until bootstrapped. We did not want to address network connectivity in the document and set it out of scope and merely provided some examples, but no specification. Proposal to enhance the statement from OLD For Ethernet, it is provided by simply connecting the network cable. NEW For Ethernet, network connectivity can be provided, e.g., via a switch to an operational network or to a specific VLAN for bootstrapping, depending on an operators security policy. > ** Section 6.1.2 > How to gain network > connectivity is out of scope of this document. > > If this is the case, why is there discussion of WiFi, Ethernet, references to > [I-D.richardson-emu-eap-onboarding], and 6LoWPAN. [stf] We intended them as illustrative examples to provide further pointers. If the text as such is irritating, should we provide a statement before that to underline that these points are examples and not intended as normative? > ** Section 6.3 > 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]. > > If these operational implications are important, why are they an informative > reference in an unadopted I-D? [stf] We are currently in the process to adopt the document in the ANIMA WG as WG items. Both documents provide operational considerations applicable for BRSKI and variants as BRSKI-PRM, BRSKI-AE, and cBRSKI. > ** Section 6.3.1 > This may be supported by a specific naming in the SAN (subject > alternative name) component of the Registrar-Agent EE certificate, > which allows the domain registrar to explicitly detect already in the > TLS session establishment that the connecting client is a Registrar- > Agent. > > What is the standardized approach for this naming scheme to enable > interoperability? Is this out of scope? [stf] There are no specific requirements to the SAN. The intention was to allow the registrar upon TLS connection establishment to detect a registrar-agent is connecting and not a pledge based on the provided used client certificate, which is useful for registrars supporting BRSKI and BRSKI-PRM (using a co-located registrar-agent). > ** Section 7.1.1.1.1 > The serial-number member SHALL contain the product-serial-number of > the pledge with which the Registrar-Agent assumes to communicate as > string. > > Is this the same serial number as emitted in in mDNS in Section 6.1.2? [stf] Yes, that was the intention. Should we provide a statement in section 6.1.2 that this is the serial number contained? > ** Section 7.1.1.1.2. are there any MTI "alg"s to support to ensure > interoperability? [stf] Good point! A proposal is to rely on RFC7518 and consequently include a statement that for algorithm support BRSKI-PRM relies on RFC 7518. NEW (for the sections related to JWS signature: Algorithms supported for JWS signatures MUST support ES256 as recommended in [RFC 7518] and MAY support further algorithms. > ** Section 7.3 > The registrar SHOULD verify the TLS client authentication of the > Registrar-Agent, in particular if the TLS session is used to obtain > the Registrar-Agent EE certificate (see Section 6.3). > > Why wouldn't the client authentication be verified? When is this acceptable > to > do? [stf] we also got the comment from Deb. The text ready odd and needs fixture. Since we already require mutual authentication between registrar--agent and registrar the complete abstract can be deleted. > ** Section 9 > Besides the above, also consider the existing documents on > operational modes for > * BRSKI registrars in > [I-D.richardson-anima-registrar-considerations] > > * BRSKI MASA in [I-D.richardson-anima-masa-considerations] > > What does it mean to "consider" these documents? Are they relevant > operational > considerations? [stf] Both documents provide insights into the operational handling of the registrar and the MASA and are intended as supporting documents or guidelines. Both documents are currently in the process of WG adoption. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
