Stephen Hanna [mailto:sha...@juniper.net] writes:
> Network Endpoint Assessment (NEA) messages can be considered > authorization data. They can, in the broadest sense of authorization as policy enforcement. It has almost nothing to do with actual security, but that's OK, I guess. > Certainly, they're not authentication. Certainly not. > They convey information about endpoint posture (like whether > anti-virus software is installed and enabled). Yet they are > carried in EAP messages every day, generally in tunnel methods. So is the argument "Juniper (& presumably Cisco) have already bastardized EAP, so we must rubberstamp it"? > > I don't think there's anything wrong with this practice. > In fact, it's the best way to ensure that a NEA assessment > is performed before network access is granted. Hmm. Has another way been tried or is it the best way because it's the easiest (or only) way we've tried? > > I wouldn't say that EAP is becoming a "general purpose" > transport protocol. EAP has many limitations that make > it a poor choice for most situations that need a > transport protocol. However, for some purposes it > is a good match. NEA is one of those purposes. Except for that whole pesky name & purpose thing -- you know, Extensible _Authentication_ Protocol. > > Thanks, > > Steve > > > -----Original Message----- > > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > > Behalf Of Alan DeKok > > Sent: Tuesday, August 11, 2009 2:36 PM > > To: Glen Zorn > > Cc: emu@ietf.org > > Subject: Re: [Emu] EAP and authorization > > > > 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. > > > > > > To transport what, exactly? > > > > The data discussed in the tunnel requirements draft, Section 3.6. > > Among others. > > > > >> 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. 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. > > > > 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
