This discussion started with the statement that channel bindings are a form of authorization data. Our charter requires us to support carrying channel bindings in the tunnel method. Password change is another form of non-authentication data that we need to support. Clearly there are several kinds of non-authentication data that we must support carrying in EAP. They are in our charter. I see no harm in also supporting carrying NEA assessments in the tunnel method.
The only bizarre engineering here is Glen's suggestion that because the A in EAP stands for Authentication, it should not be allowed to carry anything other than authentication protocols. By that logic, RADIUS should be prohibited from carrying VLAN assignments and anything other than authentication information. After all, the A in RADIUS also stands for authentication. And RADIUS should be restricted to Dial In access since that's what the D and I stand for! Glen, if you don't have any substantive arguments to make, don't try to impress us with bluster. Thanks, Steve > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Glen Zorn > Sent: Tuesday, August 11, 2009 4:22 PM > To: 'Alan DeKok' > Cc: emu@ietf.org > Subject: Re: [Emu] EAP and authorization > > Alan DeKok [mailto:al...@deployingradius.com] writes: > > > Glen Zorn wrote: > > > Alan DeKok [mailto://al...@deployingradius.com] writes: > > ... > > >> 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. > > > > > > > > >> 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 ... by way of rationalizing > > > > "explaining" > > > > The two are very different. > > > > > the use of EAP "as a general purpose transport protocol". I could > > have > > > sworn that authorization _follows_ and is parameterized by > > authentication. > > > > I agree. I haven't seen any proposal that contradicts this. > > > > > So, please tell me again why EAP should be (further) > bastardized for > > this purpose. > > > > People are proposing it because they find it useful. > This isn't mean > > it's a good idea, just that it's one that has real-world uses. > > > > My message about this topic was intended to foster discussion. > > Success! > > > If > > there is strong objection to the idea, we can refuse to "bastardize" > > EAP. If there is strong consensus that this is necessary, > it's best to > > make it explicit in the documents. > > More likely the creation of a new protocol, unless > "convenience" (a word that is used often in the draft as > (often the only) justification for bizarre additions to EAP) > has taken precedence over engineering in this WG. > > > > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
