Keytab-based initiator creds design

[Sam Hartman]

>>>>> "Simo" == Simo Sorce <simo at redhat.com> writes:

    Simo> On Sat, 2012-06-02 at 12:50 -0400, Greg Hudson wrote:
    >> On 06/02/2012 10:05 AM, Sam Hartman wrote:
    >> > I think you want to be careful about making it too easy for this code to
    >> > trigger automatically.

    Simo> I'd like to know what this means ?
    Simo> Do you have code lying around that tries arbitrarily a
    Simo> gss_init_sec_context on the off chance it works and then falls back to
    Simo> something else ?
    Simo> Although I believe this may exist I do not believe this to be common,
    Simo> besides you need access to a keytab to boot.

It's quite common.
ssh and many SASL libraries do exactly this.
ldap as well.

Unfortunately, one of the common cases where you have a keytab is root.
That's a case where you're quite sensitive to which authentication gets
used and what external service dependencies are involved.

I'd like to explore the role of k5identity in making this work
better. Are there things we can do now or with reasonable extensions to
k5identity to improve the probability that we'll know what principal we
want when contacting a service?

I do not support a KRB5_PRINCIPAL variable, because it seems to interact
very badly with kswitch and multi-principal ccaches. I think it would
create a real mess on Windows and on any platform where we have CCAPI in
the future.

KRB5_KEYTAB_PRINCIPAL doesn't seem to have these drawbacks.