Re: preauth_always option?

[Ken Raeburn <raeburn@MIT.EDU>]

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.  Then  
in many common cases (user has used the machine before, hasn't changed  
preauth scheme or password since the last time) you get the optimal  
behavior most of the time, and of course fall back to the current  
behavior with extra round trips (and extra errors in the KDC log, etc)  
in the worst case, and it doesn't require manual per-user/principal/ 
realm configuration.  Well, maybe you might want to configure realm- 
wide stuff, but even if you make everyone in your realm use the same  
preauth scheme, if the individual machines tend to be used by only one  
or two people for long stretches of time, the caching approach would  
get results nearly as good as configuring a realm-specific action,  
without requiring the configuration.

(BTW, the MIT code at least has the ability -- well, it doesn't  
compile right now but we'll probably fix it eventually :-) -- to keep  
track of failed "logins" and disable accounts after a certain number.   
Using timestamp preauth and guessing the wrong salt would be counted  
as a failed attempt, I think, so guessing seems like a bad idea for  
your SOP.  Maybe it would be better if we had a preauth datum that  
said, "this is what I'm assuming for the salt", and if it doesn't  
match, and if the KDC cares, return an error and ETYPE-INFO-2 but  
don't treat it as a failed login attempt....)

The cache wouldn't specifically be limited to one or two bits of  
information; other stuff, like user configuration options (default  
principal? ticket flags?) or KDC addresses, could be retained as  
well.  (So some of it may not strictly be just caching, but real long- 
term storage of user-provided options.)

We haven't really started to explore the idea; I just thought I'd  
throw it out there in case it helps....

Ken