[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 <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.

Also see Sam's:


Which says:

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
    then retry.

> 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.

> Mike


  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444