Liubing (Leo) <> wrote:
    > A clarification question: it sounds like there are two approaches
    > proposed, not sure I understood it correctly:

(1) > Michael's proposal: there is a dedicated SSID, say "Anima", it is
    > enabled by default, and there is no security. And that SSID can only do
    > BRSKI, no other services permitted (just like the http portal
    > authentication).

(2) > After getting the certificate, then certificate-based
    > EAP could be run to do the 802.1x authentication; or maybe they just
    > negotiated a key for WPA2. In this case, the BRSKI just works as the
    > bootstrap of WiFi.

(3) > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just
    > treat BRSKI as an option encapsulated in EAP protocol, under the WiFi
    > access framework.

    > Michael and Eliot: did I get you correctly?

Yes, I think you described that exactly correctly.
I've put some numbers in to help split up the thoughts.

The decidcated SSID would be in IBSS mode, and it could use WPA2-Enterprise
with a known username/password (like we do for the IETF SSID), which would
get per-station keying material.    There is also "Wifi Direct", defined by
the Wi-fi Alliance, which also might make sense and might provide similar L2
keying.   There would be no DHCPv4 or DHCPv6 or RAs on the link, as it would
all just be LL.  The only traffic would be GRASP M_FLOODs (from the DULL).

There is a
(4) - bring up an ACP across this dedicated SSID.  This is not mutually
    exclusive with (2).

If one does (3), then I guessone can do (2) to get connectivity.
(3) still has to define some kind of SSID on which this new 1x method will be

It could be that we can do something with 802.11 beacons to indicate the
capability and not have to pick a particular SSID name on which to

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc
Description: PGP signature

Anima mailing list

Reply via email to