Alan DeKok [mailto:al...@deployingradius.com] writes:
> Glen Zorn wrote: > > Hmm. Has another way been tried or is it the best way because it's > the > > easiest (or only) way we've tried? > > 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. No. Please don't confuse authentication with authorization. The parameters you mention above are policy-related, not related to authentication. > > 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. 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 not "authorization", > because > the user has not been authenticated. A server can tell me that I'm not authorized without knowing who I am? This is incredibly cool technology! Where can I get some of that? But seriously, the initial authorization checks made by a RADIUS server for example are based upon so-called "simple" authentication (as used daily by billions of humans). Although this consists of my telling you my name & you believing me (for the time being anyway), it is authentication all the same. > But that information is still > used > to make authentication decisions. No, they are authorization decisions. > > Enabling EAP to carry this information is well within the bounds of > the protocol. TLS-based EAP methods can carry information such as time > of life for a certificate, issuer, etc. I suppose so, but since all those things are typically in the cert, I don't know why. In any case, those things are directly related to authentication. > > 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
