[krbdev.mit.edu #8676] RFE: [realms] should support an "always_use_preauth" option

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[krbdev.mit.edu #8676] RFE: [realms] should support an "always_use_preauth" option

Jeffrey Arbuckle via RT
(Sorry for the long delay.  I somehow didn't see this in the krb5-
bugs moderation queue until today.)

What you are asking for is called "optimistic pre-authentication."  
The problem with doing it usefully for this scenario is that the
PREAUTH_REQUIRED error doesn't just convey a need to do preauth; it
also conveys:

1. The types of pre-authentication supported by the KDC.
2. The encryption type of at least one password-derived key that the
KDC can validate.
3. The salt to be used for the string-to-key operation.
4. (Rarely) any other string-to-key parameters which should affect
the password-derived key.

I think for user accounts in a Windows domain which don't use PKINIT
it might generally work to try with the first requested enctype
(assuming that would be aes256-sha1 and the server is reasonably
modern) and the default salt, and then retry if we get back an error
indicating the wrong key.  But it could easily make things worse if
any of the assumptions change.

The ideal implementation of optimistic encrypted timestamp would
cache the preauth type and etype-info parameters (items 2-4 above)
per client principal name, so that a retry is only needed if one of
those parameters changes.  We could perhaps keep such a cache in the
user home directory if configuration explicitly requests it (doing it
by default would create problems for NFS-mounted home directories and
has privacy implications), but it would add a non-trivial amount of
code complexity.

We haven't gotten many requests to implement optimistic preauth, so I
will leave this open as an enhancement request in case that changes.
krb5-bugs mailing list
[hidden email]