Keytab-based initiator creds design

[Simo Sorce]

On Mon, 2012-06-04 at 09:30 -0400, Sam Hartman wrote:
> >>>>> "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.

I am ok with KRB5_KEYTAB_PRINCIPAL

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York