Ballot for draft-ietf-anima-brski-prm
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Thank you for preparing this document, and the updaye in rev-19, I have remaining questions where I'd appreciate more clarity in the text: 1. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY" rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC 9325, which asserts that TLS 1.3 is in widespread use. (see related DISCUSS from Mike Bishop). 2. I could not understand the protocol action of the “MUST” requirement below (i.e. what does “available” mean for a RFC2119 requirement?: “if the certificate chain is not included in the x5c Header Parameter, it MUST be available at the domain registrar for verification” Please consider changing this text, for instance text like the following could be helpful: “if the certificate chain is not available at the domain registrar for verification, ... MUST ... be done“.
1. There appears to be some slight format problem with the bullets I saw listed in my rendering:
“such as: * Avoid
logging personally identifiable information unless unavoidable. *
Anonymize or pseudonymize data where possible.” (resolved).
2. I did not understand the list of three security considerations at the start of section 12. At least, it would be very helpful to explain these in sufficient detail to understand each, and also helpful to understand the implications for users of each. Some words to clarify would be very helpful.
3. Please could you add text to explain “no transport layer security between Registrar-Agent and pledge..” e.g., please explain: Is this something that users ought to add to a design? how? why? is it a desirable property? Why? ... or is this intended to be explained more in the next subsections? ... Especially since 7.1 speaks of optional use of TLS.
4. Please update the text to clarify what is intended by: “Pledges MAY support both initiator and responder mode.” ... (resolved - made "may").
5. Please consider updating the text:
“503 Service Unavailable: if a simple retry of the Registrar-Agent
request might lead to a successful response; this error response
SHOULD include the Retry-After response header field with an
appropriate value”
- Why is this not a MUST, if there is a reason, please explain the alternative to the SHOULD and when this is a suitable response.
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.) 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.
Please see https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ 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? 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. The third paragraph of 6.3.1 seems unclear. Perhaps reword this? 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. 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. 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. 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. Nits: - Section 4 has several extraneous commas. - Expand "incl." in 5.1 - Consider expanding/defining CMS on first use or in Terminology, including a reference directly to RFC 5652 - Section 7.6, inconsistent capitalization of R/registrar and "to optimize [this process]"? - Section 7.7, extra comma after "only be done" - Section 11 has bullet points that render as in-line asterisks
Section 7.3, para 2: Pick one: either 'mutual authentication' or 'client authentication'. If you pick 'mutual authentication', then in sentence 2, it could be 'mTLS uses....' [one should do a global search, there are a bunch of 'client authentication' instances throughout the draft] Section 7.3, para 3: Is this suggesting that the registrar only needs to verify the Registrar-Agent's connection if it doesn't already have the Registrar-Agent's EE certificate? seems odd....and possibly insecure. Section 12.1: Is there a resource exhaustion DOS attack on the Pledge? Section 6.1 and 12.3: Doesn't frequent rekey of the Registrar-Agent lead to synchronization issues with the Registrar? How is this mitigated?
# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-prm-18 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt # for your convenience, please find some non-blocking COMMENTS # My review is rather generic and high level, it is not my area of expertise. If my comments refer to items obvious when familiar with the technology, then feel free to ignore. # comments # ======== 14 Abstract GV> Would this abstract be a viable alternative? " This document defines the BRSKI-PRM (Pledge in Responder Mode) variant of the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. BRSKI-PRM supports the secure enrollment of devices, referred to as pledges, into a domain where direct communication with the registrar is not possible. Instead, the pledges interact with a proxy entity that relays authenticated and authorized enrollment requests to the registrar. This approach accommodates deployment scenarios where network constraints, operational considerations, or topological factors prevent direct pledge-to-registrar communication. The protocol extensions defined in this document maintain the security and trust properties of BRSKI while enabling broader applicability in constrained or segmented environments. " 183 Security information about the customer domain, specifically the 184 customer domain certificate, are exchanged and authenticated 185 utilizing signed data objects, the voucher artifacts as defined in 186 [RFC8995]. GV> original text reads odd. Revised textblob: " Security information pertaining to the customer domain, specifically, the customer domain certificate, is exchanged and authenticated through the use of signed data objects, namely the voucher artifacts, as defined in [RFC8995]. " 3789 10.2. Service Name and Transport Protocol Port Number Registry 3790 3791 IANA has registered the following service names: 3792 3793 *Service Name:* brski-pledge 3794 *Transport Protocol(s):* tcp 3795 *Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org) 3796 *Contact:* IETF Chair chair@ietf.org (mailto:chair@ietf.org) 3797 *Description:* The Bootstrapping Remote Secure Key Infrastructure 3798 Pledge 3799 *Reference:* [THISRFC] GV> Does this need to be the iesg and the chair to be as assignee and contact? At first glance this looks unusual. This seems to have happened in v18 of the draft. Gunter Van de Velde RTG Area Director
Hi Steffen, Thomas, Eliot, and Michael, Thank you for the productive discussion and for addressing almost all my points raised in [1]. The companion discussion [2] triggered by [1] is also instructive. (1) As indicated in the thread, I trust Mahesh will do the right thing with the following (used-to-be DISCUSS point): # 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 structures that used in this document and which depend on what is defined in 8366bis. Changes to the bis will have implications on this one. (2) Here are some few comments found when checking 18/19 diff: * nit OLD: building automation use case mentioned in (Section 3.1.1) NEW: building automation use case mentioned in Section 3.1.1 * Smells like a normative reference. Please change as follows: OLD: if it does not support a more general discovery as defined in [I-D.ietf-anima-brski-discovery] NEW: if it does not support a more general discovery such as defined in [I-D.ietf-anima-brski-discovery] * nit OLD: limiting for a requests to avoid susceptibility of the pledge NEW: limiting for requests to avoid susceptibility of the pledge * nit (many occurrences) OLD: Algorithms supported for JWS signatures MUST support NEW: Algorithms used for JWS signatures MUST support * Extra references, really? CURRENT: 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]. 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] I-D.richardson-anima-registrar-considerations cited in "Besides the above," was cited in the sentence right above ;-) Please update. * Commentary not intended initially to make it into the text: CURRENT: Documents that define exclusively modules following the extension in [RFC8971] 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]. I provided this text to motivate what you can safely remove the old paragraph. But, if you want to include it, then some tweaking is needed (Section 3.7.1 ref is broken in the context of this draft + we don't use 7952 here), I suggest: NEW: Documents that define exclusively modules following the extension in [RFC8971] are not required to include the YANG security template per the guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis]. Many thanks again for editing such a well-written document. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/anima/qHRppN_6T3KBdsjOksxu8bw4byI/ [2] https://mailarchive.ietf.org/arch/msg/anima/8HLrJ_PLjIbf11gZjMTuXkC2Z9g/
# Orie Steele, ART AD, comments for draft-ietf-anima-brski-prm-18 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### RFC 3339 or RFC 9557? ``` 1500 The created-on member SHALL contain the current date and time at tPVR 1501 creation as standard date/time string as defined in Section 5.6 of 1502 [RFC3339]. ``` See https://datatracker.ietf.org/doc/html/rfc9557#inconsistent ### Attacker controlled time? ``` 1580 * created-on: SHALL contain the current date and time at PVR 1581 creation as standard date/time string as defined in Section 5.6 of 1582 [RFC3339]; if the pledge does not have synchronized time, it SHALL 1583 use the created-on value from the JSON Agent-Signed Data received 1584 with the tPVR artifact and SHOULD advance that value based on its 1585 local clock to reflect the PVR creation time ``` Is there any risk of this section interacting with the provisional status? See https://datatracker.ietf.org/doc/html/rfc8995#section-5.1-6 ### nonce ``` 1587 * nonce: SHALL contain a cryptographically strong pseudo-random 1588 number ``` Do you mean a single number? or do you mean a sequence of byte of some length derived from some PRNG? Consider language like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-17#section-9.3 ### "created-on" vs "iat" ``` 1826 { 1827 "alg": "ES256", 1828 "x5c": [ 1829 "base64encodedvalue==", 1830 "base64encodedvalue==" 1831 ], 1832 "crit": ["created-on"], 1833 "created-on": "2022-09-13T00:00:02.000Z" 1834 } ``` Per https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 it is possible to replicate claims in headers. I wonder why the existing `iat` claim is not sufficient for this use case, aside from being an integer. It also seems like an integer based creation time would be easier and safer to use. ### application/pkcs7-mime ``` 2407 A successful interaction with the Key Infrastructure will result in a 2408 pledge EE certificate signed by the domain owner (e.g., LDevID 2409 certificate). The registrar MUST reply to the Registrar-Agent with 2410 the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the 2411 body of an HTTP 200 OK response. In the response header, the 2412 Content-Type field MUST be set to application/pkcs7-mime. ``` https://datatracker.ietf.org/doc/html/rfc2311#section-3.2 I don't think you want the optional "smime-type" parameter, but you might want to comment on envelopedData vs signedData here. ### application/voucher-jws+json vs application/jose+json ``` 2662 defined in Section 7.3.6. In the request header, the Content-Type 2663 field MUST be set to application/voucher-jws+json as defined in 2664 [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to 2665 application/jose+json. ``` I found myself wondering which objects use `application/voucher-jws+json` and which use `application/jose+json`. A simple table might help explain this once upfront. Are there cases where `application/jose+json` is used for encryption? ### reason-context ``` 2771 * reason-context: contains a JSON object that provides additional 2772 information specific to a failure; in contrast to Section 5.7 of 2773 [RFC8995], MUST be provided; SHOULD NOT provide information 2774 beneficial to an attacker ``` Consider giving this more structure, like: https://datatracker.ietf.org/doc/html/rfc7807#section-3 Also, seems potentially conflicting definitions exist: ``` 3474 "reason-context": { * $$arbitrary-map } ``` Yet there are map keys defined with very specific semantics, consider gathering them in a table. ## Nits ### Consider clarifying not base64url-encoded ``` 2567 format. For JSON syntax, the octet-based certificates MUST be 2568 base64-encoded. It SHALL contain one or more domain CA (root or 2569 issuing) certificates. ``` Since this is a common point of confusion, and you are using base64url nearby. You might highlight this once for both `x5c` and `x5bag`. ### Registrar Endpoints ``` 1071 +================+=========================+========================+ 1072 | Endpoint | Operation | Exchange and Artifacts | 1073 +================+=========================+========================+ 1074 | requestenroll | Supply PER | Section 7.4 | 1075 | | to Registrar | | 1076 +----------------+-------------------------+------------------------+ 1077 | wrappedcacerts | Obtain CA | Section 7.5 | 1078 | | Certificates | | 1079 +----------------+-------------------------+------------------------+ 1081 Table 2: Additional Well-Known Endpoints on a BRSKI-PRM Registrar ``` Some `-` / `_` could improve readability of these... later in the document I see `voucher_status` and `enrollstatus`...
(updated ballot for -20)
Thank you to Paul Kyzivat for the GENART review.
Thank you for addressing my DISCUSS feedback.
(Comments on -18)
** Section 4.
* The use of authenticated self-contained objects addresses both,
the TLS challenges and the technology stack challenge.
What are “technology stack challenges”?
** 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”?
** Section 6.1
Further, the Registrar-Agent SHOULD have synchronized time.
What is the impact of not having synchronized time?
** 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?
** 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?
** 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.
** 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?
** 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?
** 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?
** Section 7.1.1.1.2. are there any MTI “alg”s to support to ensure interoperability?
** 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?
** 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?
Version -20 addresses all my comments, hence my new No Objection ballot. # Below is for easy archiving (feel free to ignore) Thank you for the work put into this document (even using nice SVG graphics!), I am afraid that my review was rather superficial (lack of time due to last week AI pref interim), but I trust the responsible AD. It is also interesting to see how the scope has increased in the 10 years of ANIMA (while staying in the charter) from always-on big routers network to IoT. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Matthias Kovatsch for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to David Lawrence, the DNS directorate reviewer, please consider this dns-dir review: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/reviewrequest/21545/ (thanks Steffen for your reply) I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (archived) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 6.1.2 It appears that there is no restriction on 'product-serial-number' in this section and for mDNS a label has a strict syntax, i.e., if the serial number is always composed of only digits or A-2 or '-', then all is good, but if there is a dot, then all is bad or if the serial number if longer than 255 characters... Can this syntax check be added ? `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.` the readers and implementers will appreciate some explanations for the deviation and how to minimize the impact. ## COMMENTS (archived) ### Section 4 Please expand `BTLE` (usually written BLE I think). And section 7 uses a different acronym in `Bluetooth Low Energy (BLE), or Near Field Communication (NFC)` `over other technologies like BTLE or NFC, which may not support TLS protected communication` but the 6LO WG has defined IP over these media, i.e., COAP could be used. Suggest adding text why 6LO WG technologies cannot be used. `The use of authenticated self-contained objects addresses both, the TLS challenges` for sure mTLS offers authentication, but it also offers confidentiality and that is not the case for `authenticated self-contained objects`. Or did I miss something obvious ? ### Section 5 About the title s/5. Solution Architecture/5. Architecture/ ### Section 5.1 I was about to DISCUSS this point as I find *very unusual* to refer to another PDF document rather than having a SVG/ASCII ART diagram in the I-D... `An abstract overview of the BRSKI-PRM protocol can be found on slide 8 of [BRSKI-PRM-abstract].` In which figure ? `Note that the Join Proxy is not shown in the figure` ? I guess it is about figure 1, but let's be precise. Figure 1, what does `drop ship` means on this figure ? ### Section 6.1.2 I noted that authors of the related draft-ietf-anima-brski-discovery also tried to interact with the DNSSD WG, see https://mailarchive.ietf.org/arch/msg/dnssd/rWqgj_c_ZRT6CTGi7gby1r5FdLQ/ which is good of course. Thanks. ### Section 10.2 While I noted that the datatrack IANA note says OK, please add the exact URI for the IANA registry as I was unable to find it in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-pledge if this was the intended registry then s/IANA has registered the following service name*s*/IANA is requested to register the following service name/ ## NITS (non-blocking / cosmetic) ### Section 7.2.2.2 (and other places) You may want to use 2025 rather than 2022 ;-)