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. 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. This is not "authorization", because the user has not been authenticated. But that information is still used to make authentication 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. 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. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
