An early draft of this is now available at: https://github.com/anima-wg/brski-over-802dot11/blob/master/brski-over-802dot11.md
-----Original Message----- From: Toerless Eckert [mailto:[email protected]] Sent: Friday 16 February 2018 18:01 To: Michael Richardson <[email protected]> Cc: Owen Friel (ofriel) <[email protected]>; Max Pritikin (pritikin) <[email protected]>; Eliot Lear (elear) <[email protected]>; [email protected] Subject: Re: [Anima] BRSKI over 802.11 I am not even sure we would need to come up with just one permitted option. The two directions i see now from Owens input: a) "enterprise" Model. Relying on AAA server to be able to authenticate Pledges based on e.g.: EAP-TLS with IDevID as auth. No additional SSID needed. Should try to also announce 802.11u GAS, but need to figure out if/how this would work in the face of multiple SSIDs supported (aka: multi-domain). b) SSID approach - can work without any change to 802.11 infra, just put BRSKI proxy on the BRSKI VLAN. - Work without AAA, e.g.: PSK (home AP). - multi-domain, no 802.11u support needed (unclear how ubiquitous that is). Single domain mode where AP has only one domain offering BRSKI, BRSKI SSID is just called BRSKI%%, no beacon sent (called "hidden" in most UIs). Connects only to BRSKI Proxy, carries only BRKSI traffic therefore. Multiple <ssid>'s on an AP, each one wanting to offer BRSKI, second and further SSID have to be renamed to BRSKI%<ssid>. But actual SSID for BRSKI for those <ssid>'s is BRSKI%<ssid>. No crypto, just connected to BRSKI Proxy. Cheers Toerless On Fri, Feb 16, 2018 at 11:43:04AM -0500, Michael Richardson wrote: > > Owen Friel (ofriel) <[email protected]> wrote: > > [ofriel] I think a more comprehensive analysis of the various SSID > > discover options (DPP, hardcoded SSID, NAI Realm,..) and how each fits > > into the two post-SSID discovery options of (i) a new EAP-BRSKI > > vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly with > > 2x 80.1x exchanges) is needed before any consensus on the contents of > > an ID is necessary. Unless you are suggesting than an initial ID merely > > outlines the multiple options but makes no final recommendation > > yet. Happy to get started on that... > > Yes... the point of the ID would be to layout the options.... > > The options-not-selected would go into an appendix of a final document > to explain paths not taken. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
