Hi Eliot,
On 2018-11-27 23:04, Eliot Lear wrote:
>
>
>> 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,
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>. 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"
I'm aware of that list and catching up with is on my to-do list. However, my
immediate concern is specifically ANIMA business - an autonomic network
(the chartered scope for BRSKI). If the solution can be generalised, so
much the better.
>
> 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.
Indeed not. My suggestion creates no new protocol and doesn't change anything
for the registrar, proxy, and pledge. It recycles the registrar-MASA protocol
as the registrar-OASA protocol. And presumably it also recycles the
registrar-MASA
protocol as the OASA-MASA protocol, when the OASA needs to get a new nonceless
voucher for a newly purchased pledge. I think there's a very modest amount
of "new".
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
