Thank you Michael and Esko for the time and comments. An 01 revision is in the works, that has changes like 64 bits and some corrections based on your comments. Once uploaded, I will also add comments on the need for standardization as well as other aspects.
Thanks Srihari 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
