Hi all First off, thanks much for all the comments and for your time.
Trying to answer comments and queries received till now in this email along with reference to the new revision posted here.. Thanks Srihari 1. Fixed the text in the new revision, regarding voucher handling by MASA. 2. "Unfortunately, the result of the year+ effort to provide a way to incrementally extend RFC8366 has failed due to limitations in YANG. Under the hood, it ought to be trivial to do in the JSON or CBOR. RFC8366bis simply revises the module as a whole, and your extension would have to go into 8366bis, if it made sense." >>>>SRI_1: If the consensus of the WG after the review of the new version deems it useful to add this text to RFC8366bis, we can surely do that...<<<< 3. " Indeed letting the owner independently set security policies for the owner's own domain sounds useful...If we let the domain owner's security policy settings piggy-back on the Voucher document, so that all security policies are distributed via one signed document, that may be nice and simple but it's less flexible that having policies that the domain owner can determine fully independent from the MASA." >>>>SRI_1: Yes. The intent of this proposal is to keep it nice and simple via voucher extensions, but there are also other reasons like licensing and security gates to be opened in the device. There are updates in the new version to explain this a bit more and also captured some aspects of what you mentioned. I have also added text in the acknowledgement section to the fact. In addition, if there is sufficient interest, please consider this as an enthusiastic invite to be co-authors of the future versions of the draft and help with the direction of the same as well.<<<< 4. " 32 is not enough bits. Using bits is probably a failure. Probably you need an IANA registry of posture definitions, and it probably needs to have an integer per item. There is probably need to have vendor extensions, probably by PEN." >>>>SRI_1: Yes. Increased it to 64-bit and made some changes to yang as well w.r.t typedef and grouping and also pointed out PEN/IANA aspects<<<< 5. " that's a entire API from Registrar to MASA which you have to design and document." >>>>SRI_1: Yes. We have not done that in this version. We can document this in the next version, as needed <<<< On 08/06/23, 2:36 PM, "Esko Dijk" <esko.d...@iotconsultancy.nl <mailto:esko.d...@iotconsultancy.nl>> wrote: > I think that there are better ways to do accomplish the configuration, such > as extending the BRSKI-EST link with new actions. Indeed letting the owner independently set security policies for the owner's own domain sounds useful. Such policies could be sent by the Registrar over the same TLS / DTLS connection that is created for the BRSKI-EST, or for the standalone EST, protocol. E.g. device gets a policy update every time it gets a renewed LDevID. The policy data can be a voucher-like document, or a JWT, or a CWT, signed by the Domain CA. To get the policy data, the BRSKI/EST client could request it using a RESTful request. This has the benefit that we can define it as a building block independent from EST itself, while the underlying security and effort and standards-text of setting up the TLS connection is shared with EST. I'm assuming the protection provided by the TLS connection is useful and wanted in this case. That said, security policies determined by the vendor (through MASA) could also be useful for some use cases. The vendor could enforce policies on the use of the Pledge for the particular target Domain/customer. E.g. enable some features, disable others. Currently that would be encoded in the Voucher in a vendor-specific way. Question is if there's a need to standardize this format? Or maybe have an informative document showing how to do it is sufficient. If we let the domain owner's security policy settings piggy-back on the Voucher document, so that all security policies are distributed via one signed document, that may be nice and simple but it's less flexible that having policies that the domain owner can determine fully independent from the MASA. Esko -----Original Message----- From: Anima <anima-boun...@ietf.org <mailto:anima-boun...@ietf.org>> On Behalf Of Michael Richardson Sent: Tuesday, May 30, 2023 18:47 To: Srihari Raghavan (srihari) <srih...@cisco.com <mailto:srih...@cisco.com>>; anima@ietf.org <mailto:anima@ietf.org>; jabir Mohammed (jamohamm) <jamoh...@cisco.com <mailto:jamoh...@cisco.com>>; Reda Haddad (rehaddad) <rehad...@cisco.com <mailto:rehad...@cisco.com>>; Sandesh Rao (sandeshr) <sande...@cisco.com <mailto:sande...@cisco.com>> Subject: Re: [Anima] FW: New Version Notification for draft-mohammed-anima-voucher-security-profile-00.txt Srihari Raghavan (srihari) <srih...@cisco.com <mailto:srih...@cisco.com>> wrote: > Agreed that MASA is the signing authority and the draft is meant to > convey that the owner can influence the choice by way of parameterized > inputs to the MASA APIs. So, owner can be presented with a 'security > profile selector' input via the MASA external APIs and when the owner > provides the PDC and the selector input values, MASA can then go ahead > and create the voucher with appropriate security profile settings > (after verification and validation) for the device. okay, that's a entire API from Registrar to MASA which you have to design and document. And you mention SZTP, and it doesn't have that link. I think that there are better ways to do accomplish the configuration, such as extending the BRSKI-EST link with new actions. -- Michael Richardson <mcr+i...@sandelman.ca <mailto:mcr+i...@sandelman.ca>>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
