Eliot: I think you're trying this type of bootstrap:
https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma#/media/File:Muenchhausen_Herrfurth_7_500x789.jpg The way to IMHO unconfuse this is to separate out the discussion about how to get the voucher, and if at all, how to signal the right SSID to a pledge. 1. A pledge can either try to find his owners AP/SSID and hope that if it gets connected to another AP/owner in before, then it will get rejected. That rejection could logically be done in two ways: a) cooperatively by those other owners knowing what they own and rejecting anything else. Knowing what they own could have a standards protocol but IMHO it should be different from MASA because it could come from a reseller, not the manufacturer (because the MASA has no sales integration). b) Some form of sales integration on the MASA so that it would reject non-owners. We did not talk about those schemes so far in ANIMA, IMHO the most simple sales integration is if there is a protocol by which a reseller could indicate to the MASA who owns a particular pledge. This transaction would then happen from the vendor as soon as it sold the pledge (and knows its serial number). The customer would need to provide once its trust anchors to the reseller, so they could be passed to the manufacturer by the reseller whenever this customer buys new pledges. The reseller could also guarantee any form of anonymity required, aka: manufacturer would not know who owns the trust anchors (paranoid customers may need to generate a bunch of trust anchors so they can not be identified by correlation over the set of pledges with the same trust anchor). Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once can just limit search to those SSIDs that do support BRSKI and those who don't by coming up with appropriate network announcements, but those will not be able to help identifying the right owner. 2. Open but potentially constrained WiFi access allowing to access a cloud-registrar. Constrained in so far that the AP operator only support passing through BRSKI but not anything else (to avoid providing a free internet service). In this option, a case can be made to provide SSID information to the pledge during the voucher stage or after the enrolment stage. The argument for providing it during the voucher stage is that the pledge could earlier break the connection and take the third-party AP and manufacturer cloud registrar out of the picture. The main question is whether we should try to get the SSID passed to the pledge in an encrypted fashion so that the manufacturer MASA can not decrypt it. Of course, if you trust the manufacturers pledge, you kinda trust the manufacturer, but if i was running a MASA in a company of a country with perpass agencies, then i would like to define security procedures that would do its best to ensure that customers privacy is maximized. Cheers Toerless On Sun, Jul 15, 2018 at 09:38:47AM +0200, Eliot Lear wrote: > 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 > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
