Curious about final KRB5/GSSAPI patch inclusion.

[Nicolas Williams]

On Tue, May 21, 2002 at 03:39:28PM +0100, Simon Wilkinson wrote:
> 
> In particular, there are problems with user authorization (the kuserok()
> step), and with storing delegated credentials locally. Both of the two
> supported GSSAPI mechanisms (Kerberos and GSI) handle these differently,
> and Heimdal and MIT Kerberos even differ in their handling of credentials
> storage. Gack.
> 
> The Grid folk have an extensions draft that handles the credential storage
> issue, but doesn't address the authorization one (although Nico's
> extension of authorized_keys could do so). The extensions draft also still
> leaves somethings as "mechanism dependent"

As long as account authorization is done in a name-based way (as the
MIT and Heimdal krb5_kuserok() implementations do, or as I suspect
GSI does, and as the GSS RFCs say authorization should be done) then
implementing name-based authorization using exported GSS names will do.

And in the case of OpenSSH, because of the additional constraints that
one can place on account access using authorized_keys entry options,
I believe this approach to be superior.

As for credentials management, it may well be possible to remove much
mech-specific code from your patches by moving some tasks to PAM. This
means that a sort of protocol needs to be established by which
OpenSSH/GSS/PAM can interact such that: a) the end result is as today
with your code, b) OpenSSH requires no GSS mech-specific code and c) all
GSS mech-specific code is moved to PAM modules which would then be
expected to be distributed as part of the underlying GSS implementation.

What I envision is a PAM module interface where GSS path in OpenSSH
calls pam_setcred() on a PAM handle for a PAM service name indicating the
use of GSS; the module(s) in the stack would prompt OpenSSH for the GSS
context structure and OpenSSH would furnish a pointer to it in response
and it would be the module(s)' responsibility to perform mech-specific
credentials actions. The PAM service name might be "ssh-gss," say.

But such a protocol for app/gss/pam interaction might be easier to
specify and implement than the GGF proposal (well, at least that one is
specified :)

> I guess the upshot is that the OpenSSH GSSAPI code will still need some
> knowledge of the underlying mechanism for some time to come. However,
> it should be possible to make it work with an implementation supporting
> multiple mechanisms, providing that portions of the underlying API are
> exposed.

Hmmmm. See above. I'm not sure there's any incentive to try to get rid
of all mech-specific code though, not as long as the GSS implementors
aren't helping or as long as the necessary APIs (e.g., PAM) are less
than widely and well established or a pain to work with.


> Cheers,
> 
> Simon.


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.