[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: preauth_always option?
Michael B Allen wrote:
> On Wed, 28 May 2008 18:55:26 -0700
> Love Hörnquist Åstrand <email@example.com> wrote:
>>> If not I'll make one and post it but I was hoping someone else had
>>> 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.
Also see Sam's:
3. Model for Pre-Authentication
When a Kerberos client wishes to obtain a ticket using the
authentication server, it sends an initial Authentication Service
(AS) request. If pre-authentication is required but not being used,
then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
Alternatively, if the client knows what pre-authentication to use, it
MAY optimize away a round-trip and send an initial request with
padata included in the initial request. If the client includes the
padata computed using the wrong pre-authentication mechanism or
incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
indication of what padata should have been included. In that case,
the client MUST retry with no padata and examine the error data of
the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre-
authentication information in the accompanying error data of
KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
> If krb5_get_init_creds_opt_set_preauth_list() is not used (or the
> corresponding krb5.conf option is not set), then there is no change in
> behavior. So any patch would only improve the intelligence of the AS-REQ
> wrt to PA.
> If krb5_get_init_creds_opt_set_preauth_list() is used, and the error you
> describe occurs, then we can set ptypes to NULL and simply start over. In
> this worst case scenario we end up trying 3 times instead of 2.
> Also, a static "salt hint" could be used to reduce the error rate of
> multiple AS-REQs from the same process.
> Altogether I think it could be quite smart.
The Java developers also though they could be smart, and save a round trip,
but it introduced a bug that took years to get fixed. I would suggest keeping
it simple. With your worse case, it might turnout that the worst case
is the normal case, and even more round trips, and additional error messages
in the logs, then just doing the straight forward first request.
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439