-----Original Message-----
From: Toerless Eckert <[email protected]>
Sent: Sunday 15 July 2018 18:34
To: Eliot Lear <[email protected]>
Cc: Owen Friel (ofriel) <[email protected]>; Michael Richardson
<[email protected]>; [email protected]
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
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.
[ofriel] If the pledge is connecting to an 802.1x network behind an SSID, I
don't think there is any need at all to explicitly tell the pledge the SSID at
all. There could be multiple different SSIDs (in theory anyway) connecting to
the same 802.1x network, the key thing is that the voucher tells the pledge to
trust the EAP server that is it is establishing the TLS connection to. If the
EAP connection is trusted, then is doesn't really matter which AP or SSID the
pledge used to get there...
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.
[ofriel] I don't think we can rely on that.
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.
[ofriel] Agreed. Simple 802.11u/aq/etc. could reduce the number of SSID
candidates, but its still a round robin by the device if it fails to get a
voucher when it tried any given SSID candidate.
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.
[ofriel] If connecting to a cloud-registrar then that pretty much mandates
strong sales integration and ownership info on the MASA.
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.
[ofriel] There is an option 3, which is
https://tools.ietf.org/html/draft-friel-brski-over-802dot11-01#section-2.1.3.
DPP or any similar protocol where proof-of-ownership is required.
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
