Alan DeKok [mailto:al...@deployingradius.com] writes:
> Glen Zorn wrote: > > No. Please don't confuse authentication with authorization. The > parameters > > you mention above are policy-related, not related to authentication. > > You are making arbitrary distinctions between pieces of information. > Ones you like are deemed "authentication". Ones you don't like are > deemed "authorization". The distinctions may be arbitrary but I'm hardly inventing them; these are pretty standard. And for the record, I love both Authentication and Authorization equally; it does annoy me when people can't tell them apart, though ;-). > > > What authentication server is that? Not RADIUS: the semantics of the > > Access-Reject message don't distinguish between failed authentication > and > > failed authorization. > > This is the EMU WG, not RADIUS. Oh, yeah, thanks for reminding me. > EAP has an "EAP-Failure" code. It seems that here in EMU it is habitual to quote others extremely selectively. I guess I'll just have to get used to that; for the time being, though, here's a little context: <Alan DeKok> Authentication decisions have traditionally involved more than just username / password checking. Authentication decisions are also commonly based on "pre-authorization" data, such as: * time of day * location * physical * network * account balance * past behavior * machine used to authenticate And so on. An authentication server may use any of that information to return a "failed authentication" status to the client, even if the username / password is superficially correct. </Alan DeKok> So I guess that what you are saying is that _EAP_ servers (as opposed to AAA servers) typically use such data in making authentication decisions (not access-control decisions or authorization decisions). Is that correct? > > > A server can tell me that I'm not authorized without knowing who I > am? > > Yes. A policy could state that all logins between 5pm and 9am are to > be rejected. In that case, it can reject you without knowing (or > caring) who you are. This process can't be "authorization", because it > can happen *before* authentication. OK. So, if authentication is irrelevant to the enforcement of this policy, how is the policy relevant to EAP? > > >> If we restrict EAP to solely "authentication", then I would ask > what > >> that means. An authentication protocol that is incapable of > >> transporting the data required to make authentication decisions > would > >> be > >> perfectly secure: No one would ever be authenticated. > > > > I have no idea what you're talking about. > > Explain what criteria you use to distinguish between "authentication" > data and "authorization" data. Pretty obviously, authentication data is used for authentication & authorization data are used for authorization. Maybe I don't understand the question: are you looking for definitions of authentication and authorization? ? Give a name to the policies that get > processed *before* a user is authenticated. I don't know; what do you call it when you turn off the ringer on your phone (to use an example similar to the one you gave above)? The fact that you don't answer the phone has nothing to do with who's calling (authentication) nor whether you want to talk to them (authorization). > > Such policies exist, and are in wide use. The NEA use of EAP falls > within this use. Again, since authentication is irrelevant to the policies, how are the policies relevant to EAP (aside from the fact that it's just so darn convenient)? > > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
