On Mon, Aug 28, 2000 at 06:58:15PM +0200, Ingo Luetkebohle wrote:
> On Mon, Aug 28, 2000 at 11:14:50AM -0400, Nicolas Williams wrote:
> > For now, I would be happy if we can come to an agreement on the
> > feasibility and utility of using PAM binary prompts to move GSS-API
> > handling from the PAM app to a PAM module as discussed so far.
> > We'll probably need to poke some more holes in this proposal. Ingo, for
> > example, noticed the problem that the PAM app has to be able to get at
> > the GSS context after pam_authenticate() returns (easy to solve).
>
> Taking these two paragraphs together with your original post, you want:
> 1) use GSSAPI information in the PAM authorization stage
> 2) use GSSAPI calls for later cryptographic processing in the
> application
(2) was never part of the proposal. Once the app authenticates the
client it can fetch the gss context from PAM and use GSS-API for
integrity/privacy wrapping.
> So the goal is obviously not to remove the necessity of GSSAPI
> altogether.
Of course.
GSS-API abstracts the token exchange in authentication protocols by
wrapping the tokens. The PAM+binary prompts system abstracts the
authentication APIs.
Adapting an app to use GSS-API generally requires protocol and code
changes.
Adapting an app to use PAM+binary prompts requires server-side code
changes only.
> It would seem to me that the far easier approach would be to cut PAM
> into pieces, one for the authentication, one for authorization and one
> for accounting. That should make it possible easily to use PAM's
> authorization steps together with GSSAPI authentication -- just
> populate the PAM information struct from GSSAPI (through the
> gss_inquire_cred and gss_inquire_context calls) and then call
> pam_acct_mgmt, for example. I'm not sure, yet, but this might even be
> doable without any modification to PAM at all. All that needs to be
> written is a transfer-function.
>
> Thats incidently what I aimed at with my earlier mention of the
> conceptual seperation between these stages: If, like PAM does, you
> lump it all together you'll always run into the kind of integration
> problems like the one we spent quite some mals about. If, instead, you
> have it in pieces, you can easily integrate it by sticking parts
> together.
Originally I suggested adding a pam_gss_authenticated() API. Then Andrew
asked if I could go further. I looked into the binary prompts, thought
about it and fell in love with it.
We can certainly start with pam_gss_authenticated() though. Pam_gss'
pam_sm_authenticate() method could go something like this:
{
if (pam_gss_authenticated_p())
return PAM_SUCCESS;
if (prompt_for_are_we_doing_GSS_auth() != PAM_SUCCESS)
return PAM_IGNORE;
while(gss loop not complete)
{
/* GSS-API token exchange loop */
}
if (gss auth succeeded)
{
pam_gss_authenticated(h, gss params);
return PAM_SUCCESS;
}
return PAM_FAIL;
}
So pam_gss_authenticated() would be a useful thing to have lying
around.
Now, how to implement the pam_gss_authenticated() and
pam_gss_authenticated_p() utility functions? One way might be to use
pam_set_data() and pam_get_data(), both of which would have to be
exported to the app.
Ooops. Problem. The semantics of the pam data cleanup function will have
to be changed slightly so that when pam data is replaced the cleanup
function won't be called right away; the cleanup functions should only
be called when pam_end() is called. Why? See: app gets pam data, module
replaces pam data, libpam calls cleanup function of old data, the
cleanup function cleans up, now the app is left holding stale data
(pointers) -- oops.
Small problem though.
Another possibility would be to add an API/SPI for the app to be able to
query/tell PAM [modules] about things. After all, one can get answers
to questions, using pam_get_data(), but only if they've been answered
already. This could wait a bit. Though I have dreams of replacing
getpwnam()/getspnam() et. al. with an attribute/value-oriented API in
PAM and such an API would be similar to this one.
> --
> Ingo Luetkebohle / 21st Century Digital Boy
>
Nico
--
