On 2018-11-28 00:49, Fries, Steffen wrote: > Hi Eliot ... >>> OK, thanks. I'm interested in another scenario too: one where the operator >>> will not accept using a connection to the open Internet and therefore will >>> not accept any real-time access to any MASA. As I've said for several >>> years, this is a highly likely scenario in some types of network which >>> insist on air-gap security or for some other reason do not trust a MASA >>> (see Randy Bush's comments a few weeks ago, e.g. >>> https://mailarchive.ietf.org/arch/msg/anima/rK_rlT3JH0AFGlS47XSRqQB2DJI ). >>> >>> For such networks the only solution I can see is that all MASAs are >>> replaced by a single OASA (Operator Authorized Signing Authority) that is >>> configured and controlled by the operator. It handles the Registrar-MASA >>> protocol and returns vouchers exactly like a MASA, except that it >>> emphatically isn't on the global Internet. The OASA would procure a >>> long-life voucher (normally from the relevant MASA, via a nonceless >>> registrar voucher-request) when a device is purchased and added to >>> inventory, and then deliver that voucher or a short-term voucher when a >>> registrar needs it. Instead of using the MASA URL for each manufacturer, >>> registrar-to-OASA connections all use a locally defined URL for the OASA. >>> Otherwise the protocol is standard BRSKI. >>> >>> Any thoughts? >> >> Yes, several. >> >> First, there is now a mailing list that is related to this, >> [email protected]<mailto:[email protected]>. This is a >> follow-up to the side meeting that took place at the IETF where we are at >> least documenting existing mechanisms and requirements. There is a GitHub >> repo https://github.com/iot-onboarding that people can commit into. We >> haven’t yet started the requirements aspect, except in as much as we are >> asking “How"
> [stf] Thank you for pointing that out. I already subscribed to the list. I > completely agree, discussing the requirements is crucial. That was the reason > I asked for the support of asynchronous handling. Again, in the ANIMA context, the air-gap scenario has been discussed since a very early stage. >> >> Second, I agree that there is a desire to handle the case where onboarding >> doesn’t go all the way out the door to the vendor. I think that is one use >> case, and a separate use case is where onboarding does. To me this boils >> down to a combination of Join Registrar functionality and a means to >> communicate proof of possession / proof of ownership to the device through >> that registrar. Let’s not create new entities if we can at all avoid doing >> so. > [stf] Agreed. Although I’m not sure if store and forward could be solely a > functionality of the domain registrar and not necessarily a new component. > Getting back to my original question, do you see the asynchronous handling of > pledge enrolment as part of the current charter of the working group? If yes, > would you rather expect to see EST enhanced to handle asynchronous support or > would it be better to allow for alternative enrolment protocol support on the > domain registrar featuring the handling of self-contained objects? As the > domain registrar is likely to be not a constraint device as a pledge, this > choice could technically be provided, while the pledge has the freedom to > choose, which enrolment to use. I don't see any reason why the pledge-proxy-registrar chain would change in any way. It's only obtaining the voucher that needs to be asynchronous, to avoid the need for real-time communication with the MASA. And I'm not a WG chair, but I see nothing in the ANIMA charter that would make this out of scope. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
