Hello Mike, Michael, Thank you for the clarification. My comments are inline. I will update the draft accordingly.
I will put an updated version on the ANIMA git. The changes are visible via the diff: 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 I will wait with a new submission if further comments need to be addressed. Best regards Steffen From: Mike Bishop <mbis...@evequefou.be> Sent: Wednesday, April 16, 2025 9:22 PM To: Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com>; The IESG <i...@ietf.org>; m...@sandelman.ca Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de Subject: Re: Mike Bishop's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS and COMMENT) Thanks, Steffen and Michael - If the discussion is happening, I'm happy with the outcome that decides on. I acknowledge the deployment considerations that could make mandating TLS 1.3 on existing components impractical, and the existing recommendation is good. I think 401 is the wrong status code to use for the failed signature; while it does bear a strong parallel to failed authentication, the expected authentication isn't going to be provided via the required WWW-Authenticate header, so it's probably best to go with something else. A better parallel might be a server that expects a client certificate on the TLS connection and the client declined or provided an unexpected certificate. That generally results in a 403. Michael's PR addresses this. [stf] Good point. I did not thought on the implication to the use authentication method. I accepted the PR as suggested. Proposed comment resolutions look fine; two pieces of feedback: * In 6.3.1, perhaps "The registrar MAY be configured to only accept certain Registrar-Agents, which authenticate using the Registrar-Agent EE certificate."? [stf] yep, that works too. I took your proposal. * In 7.7(.2), why not match the language from the end of 7.2? That allows implementation-defined payload on error responses and could be paralleled here. [stf] yes, that would provide more options regarding the error handling. So I will go forward and incorporate your suggestion. The logging hints in Section 8 apply generally, so may not need specific mentioning in 7.7.2 However, those are at your discretion. ________________________________ From: Fries, Steffen <steffen.fr...@siemens.com<mailto:steffen.fr...@siemens.com>> Sent: Wednesday, April 16, 2025 12:30 PM To: Mike Bishop <mbis...@evequefou.be<mailto:mbis...@evequefou.be>>; The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-anima-brski-...@ietf.org<mailto:draft-ietf-anima-brski-...@ietf.org> <draft-ietf-anima-brski-...@ietf.org<mailto:draft-ietf-anima-brski-...@ietf.org>>; anima-cha...@ietf.org<mailto:anima-cha...@ietf.org> <anima-cha...@ietf.org<mailto:anima-cha...@ietf.org>>; anima@ietf.org<mailto:anima@ietf.org> <anima@ietf.org<mailto:anima@ietf.org>>; i...@kovatsch.net<mailto:i...@kovatsch.net> <i...@kovatsch.net<mailto:i...@kovatsch.net>>; t...@cs.fau.de<mailto:t...@cs.fau.de> <t...@cs.fau.de<mailto:t...@cs.fau.de>> Subject: RE: Mike Bishop's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS and COMMENT) Hello Mike, Thank you for the feedback and the comments. I provided my comments inline, marked with [stf]. We will address the points listed in the next version of the draft, which I will upload later today to have the most recent version available for the telechat. Intermediate versions incorporating the resolutions for the comments received are available on https://github.com/anima-wg/anima-brski-prm If you have further input based on my comments below, I would integrate them in a further version. Best regards Steffen > -----Original Message----- > From: Mike Bishop via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> > Sent: Tuesday, April 15, 2025 6:42 PM > To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc: > draft-ietf-anima-brski-...@ietf.org<mailto:draft-ietf-anima-brski-...@ietf.org>; > anima-cha...@ietf.org<mailto:anima-cha...@ietf.org>; > anima@ietf.org<mailto:anima@ietf.org>; > i...@kovatsch.net<mailto:i...@kovatsch.net>; > t...@cs.fau.de<mailto:t...@cs.fau.de>; > i...@kovatsch.net<mailto:i...@kovatsch.net> > Subject: Mike Bishop's Discuss on draft-ietf-anima-brski-prm-18: (with DISCUSS > and COMMENT) > > Mike Bishop 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%7C5651163f1de > 4498c519408dd7c3c65da%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638803321045087452%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=aUGLC3WYG%2FQFxHiM6T%2BIO37Z9sAD006r > ePYZPl0l8c8%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%7C5651163f1de4498c > 519408dd7c3c65da%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638 > 803321045120000%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=8MJSiv8xVnKqaYuLZtq8gp%2FIkMaCjDorw2h5ZHEDx > %2Bc%3D&reserved=0 > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for a clear and well-structured document. Two points that I hope are > easily addressed, and then I'll update my ballot to No Objection: > > RFC 8995 predates draft-ietf-uta-require-tls13, obviously, since the latter is > also with the IESG now. This document only restates 8995's TLS requirements on > the registrar and the MASA, so those don't have to change here. However, in > Section 7.3, should the REQUIRED/SHOULD alignment of TLS versions be > swapped at > least for the Registrar-Agent to match the new guidance? For new protocols, > TLS > 1.3 ought to be the requirement; TLS 1.2 is permitted. (Non-blocking: Consider > whether to make corresponding requirements on the registrar and MASA when > BRSKI-PRM is being used. However, without updating 8995, this would > effectively > make both versions mandatory for servers supporting both BRSKI and BRSKI- > PRM.) [stf] Discussion to that already started on UTA and ANIMA WG list regarding the way forward. Main motivation in BRSKI-PRM as extension to BRSKI, is to keep backward compatibility and provide the same requirements as the RFC 8995 and also the availability of TLS 1.3 in existing frameworks. But I agree, for the registrar-agent, as new component, we can mandate TLS 1.3 support, but likely also require to mandatorily support TLS 1.2 to be backward compatible with registrars supporting BRSKI and BRSKI-PRM. I would propose to wait for the outcome of the telechat to address the TLS version point in general. > Can you give me a quick overview of the thinking between when you use the HTTP > status codes 401 vs. 403? This document seems to use both 401 and 403 for > various forms of failed authentication. In general, 401 means "I don't know > who > you are" and 403 means "I know who you are, and you don't get to do that." I > don't see any language around the WWW-Authenticate response field RFC 9110 > requires in a 401 response, for example. There may be BRSKI legacy here as > well, but I'd like to understand a little better first. Given that you're > passing around self-authenticating objects, there are multiple levels of > authentication going on here that make it tricky. [stf] we have different occasions for using 401. They all relate to the signature verification of a JWS object using a specific EE certificate (registrar or registrar-agent) on the relying party side (pledge or registrar). If the signature verification fails, it could be interpreted as "I don't know who you are". 403 was intended to cover failure situation independent from the actual signature of the self-contained object but related to it like problems with the certificate chain validation or wrong/missing parameters. Do you have a proposal for adding text for clarification? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please see > https://datatracker.i/ > etf.org%2Fdoc%2Fstatement-iesg-handling-ballot-positions- > 20220121%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C5651163f1de > 4498c519408dd7c3c65da%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638803321045141876%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=CvMqwLeONGxTfoxCo%2Be33RkWz8EeQ2oioJ > %2BTJsCBjMc%3D&reserved=0 > for more details on handling ballot positions. These comments are offered > purely to improve the document, and their incorporation is at the discretion > of > the authors and the responsible AD. > > ===================== > > In 5.1, can the contents of the slide be extracted and placed as a figure in > the document, or is there a reason we need to deep-link into an old > presentation? [stf] actually figure 1, 2, and 3 contain the information, together with the message flow in figure 4. We got the feedback that the figure from the presentation was an easy to grasp overview, so we decided to keep that link to help understanding the approach. We did not include the figure directly as it would somehow replicate the existing ones in the draft > Section 7.3 appears in neither of the tables in 6.2/6.3; upon further reading, > I see that's because the endpoint is already defined in RFC8995. However, as > the behavior is modified in this document I suggest noting the existence of > behavior changes in 6.3, even if it's not a new endpoint. It helps make > Section > 6 a more complete roadmap of the forthcoming section. [stf] okay, understood. As Table 1 and Table 2 describe the additional endpoints I would propose to add a sentence to section 6.3, to also relate to the usage of the existing (RFC8995-defined) endpoint to provide the PVR to the registrar. Proposal to add below Table 2: NEW For the supply of the PVR to the registrar, the pledge uses the endpoint "requestvoucher", defined in [RFC8995] as described in Section 7.3. > > The third paragraph of 6.3.1 seems unclear. Perhaps reword this? [stf] yes, after rereading it reads a bit complicated. Proposal: OLD The registrar MAY be restricted by configuration, if it accepts every Registrar-Agent, which can authenticate with a domain issued certificate or only explicitly authorized ones. NEW The registrar MAY be restricted by configuration, to only accept dedicated Registrar-Agents, based on the presented Registrar-Agent EE certificate. > Check your usage of the terms "HTTP(S)", "HTTPS", and "HTTP-over-TLS". I > assume > that the first two are intended to differentiate when TLS is optional and when > it's required, but the latter two seem duplicative of each other. [stf] yes, I replaced the one occurrence of HTTPS with HTTP-over-TLS to have it aligned. > Some of the 2119 language in 7.x is unneeded; a few examples: > - "MUST begin" could simply be "begins". The Agent is acting in its own time > when it wants to begin the process. - "SHALL trigger" could simply be > "triggers", and so on. - "MASA ... MUST support the same formats" is simply a > statement of a correct deployment, not a protocol conformance issue. If the > MASA doesn't support the format, the agent will get the 415 status code > described below. [stf] Understood, reviewed section 7 to remove certain normative statements which seem unnecessary > The requirements on the formats of the messages are appropriate 2119 targets, > however, as is the Pledge's response when a trigger message is received. > > Given the multiple ways that processing caCerts could fail, it might be worth > permitting some optional error detail in 7.7.2 for the Registrar-Agent to log > and/or debug. [stf] Added information regarding the logging at the end of section 7.7.2: NEW As the caCerts artifact processing on the pledge may result in errors signaled via HTTP status codes, the Registrar-Agent should log these for evaluation as outlined in Section 8. > Appendix A.2 defines the culinary term "parboiled" and references its use in > RFC 8995. It appears that while 8995 uses it in the filename of one example, > it > does not use the term to define any portion of the protocol, nor does this > document. If its use is widespread among implementers and it is > useful/necessary to know, elevate it to a Section 2 definition and use it as > appropriate throughout the document. Otherwise, it seems like the term could > be > dropped entirely without loss of clarity. [stf] yes, true, removed that part. > Nits: > > - Section 4 has several extraneous commas. > - Expand "incl." in 5.1 [stf] expanded, also the second occurrence in section 7.8.2.1 > - Consider expanding/defining CMS on first use or in Terminology, including a > reference directly to RFC 5652 [stf] added to terminology >- Section 7.6, inconsistent capitalization of > R/registrar and "to optimize [this process]"? - [stf] thanks. Good fining. Addressed both. Section 7.7, extra comma after > "only be done" [stf] deleted >- Section 11 has bullet points that render as in-line asterisks [stf] yes, corrected, a NL was missing > >
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
