Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Toerless Eckert <[e-mail]>]

Owen,

I've associated draft-friel-brski-over-802dot11 to anima so folks
will see it in data tracker. Next time post new work for a particular
WG with draft-<group>-<friel>-<whatever>, that will make it happen
automatically.

2.1.1.1) There is no need to bother the MASA with sales
integration just so that the owner will know whether or not
it owns a particular device. Any protocol from the manufacturer/reseller
to the owner will suffice.

I recommend carrier pidgeons with USB sticks trained to insert them into
a USB slot releasing a food portion. Great protection against against
unrecognize NSA interception of the channel especially for vendors
products on the NSA shortlist ;-))

Kidding aside: A standard protocol for sales information disemination
would be great, and given how its for bootstrap automation it would
be fine for ANIMA. I would jus resist of mixing it with BRSKI/MASA
unless there is clear evidence of not keeping it modular. Especially
given how it cold come from the reseller, and nothe vendor.

2.1.1.2) This read a bit confused. I think it should mention
two methods: One is the aove mentioned to know what you own - independent
of MASA (yor last sentence in 2.1.1.2 confused this option with the
MASA). The other option is just to try the MASA in the absence
of better information. BUT: If you only try the MASA, you should
only do this automatically if you do know the MASA has sales
integation. Otherwise you better include a manual checkpoint before
enrollment.

2.1.2) This section is a bit unmotivated even though its part of the
best solution, but that solution requires more details than just WiFi.

Aka: You want to allow announcement (using any of the options
you specified) of open access SSID that allow to connect to cloud-registrars.
These do not even have to be free internet access. Ideally we would
think about an unencrypted channel to the cloud registrar that
relies only on authenticated but unencrypted messages. That way
the owner of the AP can veryify and constrict communications
to only cloud-registrar-enrollment so that this access is not
as a side-channel to gain full internet access. TLS 1.2 still allows
zero-encryption, that would be the easiest option. TLS 1.3 removed it *sigh*.

Note also that we have not defined cloud-registrar behavior. I
think Eliot wold jus like to add something like WiFi SSID to
vouchers, but i would rather like to see it as a separate
"next-step after enrolment" message

Cheers
    Toerless