Re: preauth_always option?

[Michael B Allen <miallen@ioplex.com>]

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

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