On Sep 10, 2023, at 6:38 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > So, this replaces draft-richardson-emu-eap-onboarding-03 > which would use onboard...@eap.arpa. (Hmm. I keep thinking it was going to > be "nob...@eap.arpa")
This document defines the @eap.arpa and the associated registry. It doesn't define how entries in the registry are used. There's a trivial example, but it's not fleshed out. >> HTML: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-00.html > > You use por...@eap.arpa here. > > 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. 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. 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. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
