On Friday, December 01, 2006 05:41:57 PM -0600 Nicolas Williams <Nicolas.Williams at Sun.COM> wrote:
> On Fri, Dec 01, 2006 at 05:52:53PM -0500, James Carlson wrote: >> The only >> difference is that instead of wiring the EAP client implementation >> directly to some UI with hard-coded function calls, we're >> intermediating the conversation through a local channel -- PAM -- that >> knows all about text-based UIs. It's really the same thing as >> intended. > > I see. I like this rationale. I don't think I do. If you're a NAS accepting a password from a user for authentication, why bother with EAP? Just speak the AAA protocol and be done with it. If you're a non-NAS accepting a password from a user for authentication, then you are not authenticating network access, and so are outside the scope of EAP's applicability. If it's appropriate to use AAA at all, then again, you should just do so. If you're an EAP client accepting a password from a user so you can authenticate to some NAS, then PAM is not the framework for you. PAM is not about text-based UI's; it's about connecting applications to authentication and authorization mechanisms. To use PAM in this way, you'd have to write a PAM application whose sole purpose was to invoke your EAP PAM module and provide a conversation function for it. The application wouldn't actually be getting anything out of PAM; being just a UI, it has no need for the authentication and authorization services which it is PAM's purpose to provide. -- Jeff
