Doh!
Andrew,
I just started reading your draft to see how binary prompts might work.
I now think that PAM binary prompts could certainly be used to handle
GSS-API and anything else such as raw Kerberos, SRP and so on.
Here's what I'm thinking now:
- ftpd accepts a connection, calls pam_start(), registers its binary
prompt handler
- ftpd sets any relevant PAM items that it can
- ftpd calls pam_authenticate()
- pam_gss would probably be first in the auth stack and would issue
a binary prompt asking ftpd to negotiate for GSS-API
- if ftpd cannot use GSS-API then pam_gss returns PAM_IGNORE or
failure, as per its configuration
- if ftpd does negotiate GSS-API authentication, then pam_gss
continues binary prompting for GSS tokens until authentication
completes successfully or otherwise
- if authentication succeeds then pam_gss sets any PAM items,
pam_data, PAM env vars it can that is relevant and returns
PAM_SUCCESS, including possibly setting PAM_USER based on mapping
the client principal name to a local username or perhaps setting a
username mapping using pam_set_mapped_username()
- ftpd would call pam_acct_mgmt(), where pam_gss would have a chance to
authorize the session based on minimum QoP requirements and such
things
- ftpd goes on and eventually calls pam_setcred() to establish
credentials, at which point pam_gss will initialize any credentials
caches (pam_gss might cooperate with pam_krb5 for this, when the GSS
mechanism used is Kerberos V)
- etc...
The ftp client wouldn't have to know anything about PAM either as all it
would see is a standard FTP exchange, including GSS-API token exchanges.
Replace ftpd with telnetd, httpd, whatever and the same process should
still work. Replace pam_gss with pam_krb5 (for services that use raw
Kerberos instead of GSS-API).
Bingo. If my reasoning holds up then this approach should be much
simpler than adding new APIs as I was suggesting before.
Notice that GSS-API binary prompts don't seems to fit any of the
currently allocated binary prompt control characters. This is an area
that might need work to make this approach possible.
Nico
On Fri, Aug 25, 2000 at 02:35:00AM -0400, Nicolas Williams wrote:
> 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
> --
>
> .
--
