Re: preauth_always option?

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

On Thu, 29 May 2008 09:03:46 -0500
"Douglas E. Engert" <deengert@anl.gov> 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.
> 
> 
> Also see Sam's:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-framework-07.txt
> 
> 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.

Precisely. Thanks for the reference.

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

We all know too well that Java's Kerberos support was a comedy of errors
from the start. With your help I'm sure I can do a better job. 

If not, Love will not apply the patch.

Thanks,
Mike

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