Re: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-19.txt
Hi all, This update closes 16 issues that can be found on the GitHub issue tracker, using this query : https://github.com/anima-wg/constrained-voucher/issues?q=is%3Aissue+is%3Aclosed+closed%3A2022-11-12..2022-12-31 Main change is the inclusion of new examples and new scripts/security-materials that were used to generate the examples. That should fix the issue found (#215) with the signatures in the examples. Best regards Esko -Original Message- From: Anima On Behalf Of internet-dra...@ietf.org Sent: Monday, January 2, 2023 15:54 To: i-d-annou...@ietf.org Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-19.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) Authors : Michael Richardson Peter van der Stok Panos Kampanakis Esko Dijk Filename: draft-ietf-anima-constrained-voucher-19.txt Pages : 94 Date: 2023-01-02 Abstract: This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. Constrained BRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. This document Updates RFC 8366 and RFC 8995. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-19.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-19 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] I-D Action: draft-ietf-anima-constrained-voucher-19.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) Authors : Michael Richardson Peter van der Stok Panos Kampanakis Esko Dijk Filename: draft-ietf-anima-constrained-voucher-19.txt Pages : 94 Date: 2023-01-02 Abstract: This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. Constrained BRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. This document Updates RFC 8366 and RFC 8995. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-19.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-constrained-voucher-19 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Iotdir early review of draft-ietf-anima-brski-prm-05
Hi Marco, Thank you for the early review, I made my comments to yours inline. > -Original Message- > From: Marco Tiloca via Datatracker > Sent: Donnerstag, 22. Dezember 2022 14:33 > To: iot-director...@ietf.org > Cc: anima@ietf.org; draft-ietf-anima-brski-prm@ietf.org > Subject: Iotdir early review of draft-ietf-anima-brski-prm-05 > > Reviewer: Marco Tiloca > Review result: Ready with Nits > > [Section 3.1] > > * "Once a pledge with such combined functionality has been bootstrapped, it > may act as client for enrollment or re-enrollment of further certificates > needed, e.g., using the enrollment protocol of choice." > >Considering the normative words used in the previous paragraph for a > pledge >with combined functionalities, I would have expected the use of "MAY" > here >about a pledge-initiated enrollment. Is the use of the non-normative "may" >intentional? Yes you are right. We should consequently to the preceding paragraph also use MAY here. Will adapt this. > [Section 3.2] > > * "The mechanism described in this document presume the availability of the > pledge to communicate with the registrar-agent." > >The last sentence in the paragraph says that "the registrar-agent is >similarly presumed to be unavailable for certain periods of time". >Consistently, the first sentence quoted above can already suggest that >point, instead of focusing on the pledge only. E.g., it can say: > >"The mechanism described in this document presumes the availability of > the >pledge and the registrar-agent to communicate with one another." Yes, taken. > [Section 4] > > * "A POI is also required for the certification request and therefore needs to > be additionally bound to the existing credential of the pledge (IDevID)." > >The subject of "needs" is the certification request, right? Yes, enhanced the sentence for clarity to: " A POI is also required for the certification request and therefore the certification request needs to be additionally bound to the existing credential of the pledge (IDevID)." > * "This binding supports the authorization decision for the certification > request may be provided directly with the certification request." > >I am not sure how to parse this sentence. It think you mean "... for the >certification request and may be provided ...". Correct? Yes, updated as suggested > > * "... based on COSE [RFC9052]" > >I think it is appropriate to cite also RFC 9053. Yes, certainly. Included in the text and as additional reference. > [Section 5.1] > > * "enhances existing with new supported media types, e.g., for JWS > voucher" > >What is existing and enhanced? Data exchanges and messages, or instead >endpoints again? Yes, it was intended to enhance the endpoints. Corrected accordingly to " enhances existing endpoints with new supported media types, e.g., for JWS voucher " > > [Section 5.1] > > * "The registrar-agent may provide additional data to the pledge in the > context of the voucher triggering request, to make itself visible to the > domain registrar." > >Could you elaborate on this, perhaps through an example? How does this > help >the registrar-agent to make itself visible to the domain registrar? Okay, after rereading the sentence, it may be misleading. The intention was to allow the registrar to realize with which registrar-agent the pledge was in contact. I will reformulate that sentence to make that clearer and also make the may normative. Updated bullet: " The registrar-agent MAY provide additional data to the pledge in the context of the voucher triggering request, that the pledge includes into the PVR. This allows the registrar to identify, with which registrar-agent the pledge was in contact." > >Isn't visibility a general issue between Registrar Agent and Domain >Registrar, for which the specific Pledge does not play a role? Yes, as stated above, the intention was to allow the registrar to know, with which registrar agent the pledge was in contact. > > * "The registrar-agent may be implemented as an integrated functionality of > a commissioning tool or be co-located with the registrar itself." > >This feels like something quite important to say already in Section 1 >"Introduction". Good point. I moved that sentence to the first bullet in the introduction. > > [Section 6.2] > > * "Registrar-agent: possesses ... In addition, it may possess the IDevID CA > certificate of the pledge vendor/manufacturer to verify the pledge certificate > in the received request messages." > >Consistently with what is said later on about the MASA, I think that the >sentence above should also better use the normative "MAY". Agreed, changed to "MAY" > > [Section 6.2.2] > > * "If the validation fails the registrar SHOULD respond with HTTP 404 Not > Found status code to the registrar-agent." > >Why 404? The registrar has been processing the
Re: [Anima] Secdir review of draft-ietf-anima-brski-prm-05
Hi Charlie, I'm resending the message as I realized it did not go to the ANIMA WG list. Thank you for the review of BRSKI-PRM. I addressed the points you identified. All of them were easy to address. By rereading the review comments, I thought about your statement "The protocol is more elaborate that I would have thought necessary, but I could find no problems with it.". Is there anything we could improve in the approach itself or the description, which caught your eye? We restructured the document a while ago to make it better readable and aligned it with experiences gained from the implementation. If there is anything we can improve in the specification, which you feel would help better understanding, please let us know. Also, if you think that optimizations in the protocol itself could be done to reduce complexity, would also be interesting. Based on the current state of the document (before WGLC), changes could still be done. Best regards Steffen > -Original Message- > From: Charlie Kaufman > Sent: Montag, 5. Dezember 2022 08:22 > To: sec...@ietf.org; i...@ietf.org; draft-ietf-anima-brski-prm@ietf.org > Subject: Secdir review of draft-ietf-anima-brski-prm-05 > > Reviewer: Charlie Kaufman > Review result: Has nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This Standards Track ID extends a family of protocols for limited function > devices to obtain certificates from their surrounding environment with the > assistance of an on-line manufacturer's authority that can authenticate > information as coming from their device. It extends the BRSKI (RFC8995) > protocol to deal with devices that prefer to accept incoming initialization > requests rather than initiating outbound requests. It does this be defining a > new > node called a "registrar-agent" that acts as a client to both the > to-be-registered > "pledge" and the domain registrar. > > The protocol is more elaborate that I would have thought necessary, but I > could > find no problems with it. > > Typos: > p1 "To establishment the" -> "To establish the" > p4 "In this scenarios it is" -> "In this scenario it is" > p5 "defined i this" -> "defined in this" > p8 "as describe in" -> "as described in" > p8 "it SHOULD initiate to that Registrar" --- initiate what? a request? a > connection? > p9 "This operational parameters" -> "These operational parameters" > p9 "presume the" -> "presumes the" > p11 "constraint environments" -> "constrained environments" > p12 "endpoints were the" -> "endpoints where the" > p12 "endpoints were additional" -> "endpoints where additional" > p45 "a manufactures pledge" -> "a manufacturer's pledge" > p64 "on misusage" -> "of misuse" > p64 "an registrar-agent" -> "a registrar-agent" > p64 "rouge" -> "rogue" > > > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
