Hi Toerless,
On 15.07.18 09:19, Toerless Eckert wrote:
> 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
There is an ordering problem with 802.11 in particular. In order to get
the voucher one has to have network connectivity. In order to have
network connectivity, one needs to be authenticated (e.g., having
received the voucher). An EAP method seems like a good way to break
that logjam, especially in environments where EAP is already prevalent,
and TEAP has many of the characteristics that are already amenable to
BRSKI. As to SSID selection, the principle issue is some sort of proof
of ownership to the device. A blind acceptance solely by a MASA is what
causes our issue. If we can accept that problem statement, then we have
multiple paths we can take to avoid a deadlock.
There are a few constraints:
* In an environment with many SSIDs advertised, one doesn't want to
simply round robin, due to power consumption. Some sort of shortcut
is desirable.
* The discovery mechanism cannot be "chatty". This is what Stewart
Cheshire calls the "Stadium Problem". That is not to say that
devices must be entirely quiescent all the time.
Finding the right balance here is the trick.
Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
