Re: preauth_always option?

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

On May 29, 2008, at 11:19 AM, Michael B Allen wrote:

> On Thu, 29 May 2008 12:26:26 -0400
> Ken Raeburn <raeburn@MIT.EDU> wrote:
>
>> On May 29, 2008, at 10:03, Douglas E. Engert wrote:
>>> Michael B Allen wrote:
>>>> On Wed, 28 May 2008 18:55:26 -0700
>>>> Love Hörnquist Åstrand <lha@kth.se> wrote:
>>>>>> If not I'll make one and post it but I was hoping someone else
>>>>>> had  done
>>>>>> this already
>>>>> The problem with sending preauth data is that you get back an
>>>>> error if  you guess wrong salting.
>>>>>
>>>>> And its usually and error w/o the ETYPE_INFO(2) that hints want
>>>>> salt  to use.
>>>> I do not think that should be too much of a problem.
>>>
>>> Java-1.4 had this same problem with Windows AD as the KDC. The
>>> client assumed
>>> it knew the salt for a DES key, and sent the timestamp encrypted
>>> with the wron
>>> key which produced an failed error. But the client did not retry.
>>> Java-1.6 fixes the problem.
>>
>> I was talking with someone last night about some similar stuff for  
>> the
>> MIT implementation.  One idea we were kicking around was to cache  
>> per-
>> principal or per-user information on a client (with caveats about  
>> user
>> privacy issues) so that, for example, kinit (or login/pam) could  
>> first
>> try authenticating using the preauth scheme and enctype and salt (and
>> whatever else) that were used the last time for the same user.
>
> 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.
>
> Mike

Details aside, you need a place to put the cache.  This is a different  
set of cached info from anything that currently exists, so I forsee  
problems.  Good luck though.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu