> 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 <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"

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.

Eliot

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to