Alan DeKok [mailto://al...@deployingradius.com] writes:
> Alper Yegin wrote: > > I’m not against this. But let’s face it, this is venturing into > dealing > > with authorization parameters with EAP (EAP layer? EAP method layer? > > Etc.) I’m not against that either. In fact, I know there are a lot of > > people who’d be happy to see that happen. > > Prior to authentication, EAP is the only communications protocol > between a supplicant and *anywhere* on the network. It is therefore > natural to overload it as a general purpose transport protocol. To transport what, exactly? > > > So, my question is, is this what we are doing: Enabling EAP to > exchange > > authorization parameters among the EAP peer – authenticator – > > authentication server? If not, I hope someone can explain how this is > > different than what it takes to solve channel binding problem. > > I believe that is what is happening: authorization parameters are > being exchanged in EAP. This should be made clearer in the documents. Above you said "Prior to authentication, EAP is the only communications protocol between a supplicant and *anywhere* on the network" by way of rationalizing the use of EAP "as a general purpose transport protocol". I could have sworn that authorization _follows_ and is parameterized by authentication. So, please tell me again why EAP should be (further) bastardized for this purpose. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
