Re: preauth_always option?

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On May 29, 2008, at 2:44 PM, Michael B Allen wrote:

> On Thu, 29 May 2008 15:04:47 -0400
> Ken Raeburn <raeburn@MIT.EDU> wrote:
>
>> On May 29, 2008, at 14:19, Michael B Allen wrote:
>>> It had occured to me that the "salt hint" should be dealt with
>>> outside the
>>> get_in_tkt loop. But it's not obvious to me as to how one can
>>> retrieve the
>>> ETYPE_INFO after a successful AS-REQ such that it can be cached in
>>> some
>>> way whether it by in a static variable or a file on the client. I
>>> suppose
>>> there could be a set of krb5_get_init_creds_opt_{get,set}_etype_info
>>> functions.
>>
>> 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.

Isn't that even more transient than the ccache with the tgt in it?   
It's single-application-instance, while the ccache is at least for the  
whole login session.

>
> Mike
>
> -- 
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/