Just submitted: 

-----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:


-----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 
- 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. 


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


Anima mailing list

Anima mailing list

Reply via email to