Just submitted: https://datatracker.ietf.org/doc/draft-friel-brski-over-802dot11/
-----Original Message----- From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Owen Friel (ofriel) Sent: Tuesday 27 February 2018 11:06 To: Toerless Eckert <t...@cs.fau.de>; Michael Richardson <mcr+i...@sandelman.ca> Cc: Max Pritikin (pritikin) <priti...@cisco.com>; anima@ietf.org; Eliot Lear (elear) <el...@cisco.com> Subject: Re: [Anima] BRSKI over 802.11 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:t...@cs.fau.de] Sent: Friday 16 February 2018 18:01 To: Michael Richardson <mcr+i...@sandelman.ca> Cc: Owen Friel (ofriel) <ofr...@cisco.com>; Max Pritikin (pritikin) <priti...@cisco.com>; Eliot Lear (elear) <el...@cisco.com>; anima@ietf.org 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) <ofr...@cisco.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
