[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: preauth_always option?
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 <firstname.lastname@example.org> 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....