RX Kerberos 5 security class requirements of Kerberos library

[Nicolas Williams]

On Tue, Jan 02, 2007 at 02:38:35PM -0500, Sam Hartman wrote:
> What's absolutely clear to me is that this is not an AFS issue.
> Either we want to have an API that is designed to get credentials for
> local maintinance or we do not.  That API should not be afs specific
> and if we have it, it needs to be something we're happy for other
> services to use.

I think you're proposing an API that allows one to use the Kerberos V AP
exchange as a pre-shared symmetric key authentication mechanism.

That's fine, of course, but I would advise users to be careful how they
use it.  Kerberos AP exchanges are supposed to authenticate a client
principal to a service principal (with a mutual auth option), but here
the PSK is associated with the service principal, so the possessors of
the shared key can impersonate any client principal -- therefore callers
of krb5_rd_req*()/gss_accept_sec_context() need to be aware of service/
acceptor principal names whose keys are shared so that they can limit,
if desired, the client principals that they allow PSK peers to assert.

Such a PSK mechanism could be seen as a portable alternative to
getpeerid()/getpeerucred() schemes for local authentication, but
generally I would prefer that the latter be used when available.

> The simplest approach is a gic_cred option that gives the keytab of
> the service.

Yes.

Nico
--