Re: preauth_always option?

[Ken Raeburn <raeburn@MIT.EDU>]

On May 29, 2008, at 17:44, Michael B Allen wrote:
>> I would think you'd want to bury this code in the library, and maybe
>> have a flag at the API layer enabling or disabling the use of the
>> cached data, but otherwise leave it for the internal implementation,
>> which has access to all that info.  Why do you think it should be  
>> at a
>> higher level?
>
> Because the library doesn't know how the application would like to  
> cache
> ETYPE_INFO data.
>
> Some applications might want to put it in a file (e.g. kinit). In my
> scenario simply saving the one ETYPE_INFO as a hint in a static  
> variable
> of the function calling krb5_get_init_creds_whatever would be  
> sufficient
> to eliminate 99% of the faulty AS-REQs.

Ah, I see.  I figured it would be the library, and thus independent of  
whatever application was doing the caching, and applicable even if you  
use a different application to get credentials the next time (e.g.,  
pam at login time, then kinit after expiration).  But I guess there  
are cases where you don't have, for example, a home directory  
available, and you may need to do something else...

The etype-info data cache will probably solve a lot of cases, but if  
you need to use preauth, you still wind up having to configure that,  
or incur the round-trip to have the KDC tell you.  Saving the preauth  
type too -- or maybe exporting a opaque "AS-REQ info cache" blob from  
the library, which might be extended later -- might be better.  Maybe  
the opaque blob only contains etype-info to start, but is set up to be  
extensible?

Ken