-----Original Message-----
From: Toerless Eckert <[email protected]>
Sent: Sunday 15 July 2018 08:19
To: Owen Friel (ofriel) <[email protected]>
Cc: Eliot Lear <[email protected]>; Michael Richardson <[email protected]>;
[email protected]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
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.
[ofriel] The point here isn't for the MASA can tell the owner that he owns the
devices, the purpose is for the owner to explicitly claim the devices on the
MASA to accomplish your option 1(b) for later in this thread (the thread is
very disjointed at this stage):
" b) Some form of sales integration on the MASA so that it would reject
non-owners. "
I think we are actually talking about exactly the same thing here, if that's
not clear in the draft text, we can certainly clarify.
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.
[ofriel] Sales integration with the MASA (where sales integration means that
the MASA explicitly has a map of devices to owners) is not required here at
all. One of the core features of MASA is that it audit logs all issued vouchers
and the vouched registrar identity. If a network operator knows the identity of
a device they own, but that device has not connected to their network, the
operator can query the MASA audit logs to see if that missing device has been
vouched for on a different network.
E.g. I own serial#abc123 signed by AcmeCA, I can see it powered up and
apparently live on the desk beside me, but my Registrar/AAA doesn't see it. My
Registrar /AAA could query MASA for logs pertaining to serial#abc123 and see
that a voucher was issued for that device against
registrar.the-company-on-the-floor-above-me.com. So this does not prevent my
device from connecting to the wrong network, but it does allow me to detect it
after the fact.
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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
