Alan DeKok <al...@deployingradius.com> wrote:
>> I think that this is a mistake to be so specific.
>> I don't think the supplicant should know/care, at this point, what kind
of
>> access it is going to get. I liked what we we had done with
eap-onboarding
>> where you get limited network, and then if DHCP says, via the DHCP option
>> (or the RA option) that there is a captive portal, then it should do
that.
>> Or, it could say do RFC8995 (BRSKI) via GRASP announcement.
>> Or...
> There have been long discussions about not tying EAP to DHCP. I forget
> which RFC it is, but there's an IAB architectural document which says
> this is a bad idea.
There is no connection here.
EAP(nobody) gets you a useable L2.
L2 makes DHCP possible. There is no link, and they are not tied.
> I think the supplicant should know what kind of access it's getting.
> This is also a signal to the RADIUS server as to what kind of
> authorization to send to the NAS / switch.
When you write this, what I am hearing: the end user has to know everything
about the network they are joining. And that's exactly what I think we are
trying to avoid.
> In contrast, if there's only one kind of on-boarding access,
> authorization has to be done through DHCP which has much more limited
> capabilities for that.
There are possibly many different ways depending upon where you open the lid
of your laptop, phone, chromebook, personal IoT device.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
