On Thu, Aug 24, 2000 at 05:04:02PM -0700, Andrew Morgan wrote: > Nicolas Williams wrote: > > I imagine telnetd or ftpd going through this sequence: > > > > - accept connection, perform Kerberos or GSS-API (likely Kerberos) > > authentication > > Before we go there. Is there any reason why we couldn't pursue the idea > of implementing GSS's authentication in a PAM module? I've just had an > hour to catch up on the pam-list fraction of the kerberos thread, and I > didn't see anything that touched on this. Actually, I did broach the idea of integrating GSS-API into PAM to Sun. No answer so far :( I'm not sure it's worth doing that however. GSS-API is strictly about remote authentication, whereas PAM is also about authorization and session management and has room for lots of things. GSS-API does what it does rather well and probably doesn't need to be messed with. But the data involved is of use to PAM. The one advantage to integrating GSS-API with PAM would be that there would be no need to call pam_gss_authenticated() or anything like that: PAM would get at the data automagically as the GSS-API exchange completes. And it's not just principal names and QoPs we're talking about, since GSS-API has a provision for credentials forwarding (as in Kerberos TGT forwarding), PAM could get at any forwarded credentials first and do the right thing with them. Any such integration could simply be a thin layer atop GSS-API that communicates the relevant data to PAM. So pam_gss_authenticated() or something like that would still make sense as a building block. I'm not sure there's much room for a tighter integration of GSS-API and PAM, not because things won't jibe but because PAM has little or nothing to bring to GSS-API whereas GSS-API has something to bring to PAM (data). Hmmm, then again, one could have a GSS-API standard mechanism for doing PAM interactive and binary prompts remotely via GSS-API. Protocols that already handle interactive username/password prompting wouldn't need that, but new protocols certainly could be made simpler if they only have to deal with GSS-API, letting the underlying GSS-API plug-in mechanisms do the rest. Much to think about. Why can't I go to sleep? :( > If I read your proposal, it sort of looks like: > > - have something else manage authentication > - use PAM too. > > I'm personally more interested in extending PAM to be general enough to > deal with more interesting authentication schemes (as modules). I can certainly understand that. And I agree. > What stands in the way of doing that? Nothing. See above. Well..., for one, there's more than just GSS-API; some apps do straight Kerberos or straight NTLM without bothering with GSS-API, so we shouldn't limit ourselves to GSS-API. If you go back to my suggestion og pam_gss_authenticated(), it would only receive information, and if the app didn't use GSS-API it can still create GSS-API objects to represent what went on. GSS-API, BTW, for those of you who don't know, is just a standard for wrapping and unwrapping tokens exchanged during authentication in network protocols in a way that is independent of the authentication mechanism actually being used. The C API for GSS-API is rather simple and well thought out, IMNSHO (don't be scared by the fact that there's something like 69 functions), with a few minor shortcomings, primarily in that the underlying mechanisms need to be exposed to the app a bit more (e.g., there's no mechanism enumeration API). GSS-APIed apps simply go through a loop where they exchange tokens until the underlying mechanism informs GSS-API that authentication is complete; GSS-API then informs the apps and then they proceed with life as usual (well, GSS-API also provide functions for doing cryptographic integrity and/or encryption afterwards, if desired by the apps). > Cheers > > Andrew > Thanks, Nico --
