Java Pre-auth for Windows 2003 mixed case revival
Seema.Malkani at Sun.COM
Mon Feb 14 16:34:20 EST 2005
Douglas E. Engert wrote:
>>which it fails, and since the pa-enc-timestamp is included,
>>windows should throw a KDC_ERR_PREAUTH_FAILED(24) as per rfc1510. But
>>the previous note is stating that we aren't handling the error 24. That
>>is where I tend to disagree, with the KDC_ERR_PREAUTH_FAILED there will
>>be no e-data provided as stated in rfc1510.
>OK, I will agree with that, some KDCs may send extra data with 24 but
We do handle the preauth correctly when PA-ENC-TIMESTAMP is included;
however currently we do not support the new preauthentication types as
defined in the Kerberos clarifications. Sun's implementation of Java
GSS/Kerberos currently always includes the PA-ENC-TIMESTAMP, and if the
KDC returns error code 24 KDC_ERR_PREAUTH_FAILED, we do not process the
padata if included with it.
I believe in MIT Kerberos implementation, the first AS-REQ does not
include preauth, KDC returns error 25 with the padata included in the
eData, and client then re-tries with the preauth using the new salt.
As per RFC1510bis, the padata is included only when KDC returns error
code 25 KDC_ERR_PREAUTH_REQUIRED. Hence Kerberos implementations are
expected to process the padata only when error 25 is returned by the
KDC. If the the pa-enc-timestamp is included, KDCs do not return with
error code 25. However, some KDCs include the padata (new salt in the
case of mixed case) even with the error code 24 KDC_ERR_PREAUTH_FAILED.
I agree, the solution here is not to include the pre-auth in the first
request. However, if the client knows what pre-authentication to use, it
may optimize the round-trip and include the pre-auth. However, if the
client includes the wrong pre-auth, how should the KDC/client handle is
Should the KDC return error 24 or 25 ? If KDC returns the error 24 with
padata, should implementations ignore it, or retry with the new salt ?
In the case of mixed-case, should the KDC return an error 24 or 25 with
the new salt ? Seems like we have two cases :-
1) PreAuth_Required, now retry (error code 25)
2) PreAuth_Failed, no retry, client should fail. (error code 24)
Should there is a new error code for PreAuth_Failed, retry again ? Or
irrespective of the error code, client should always process padata if
included and retry ?
Or let's say we have a scenario if preauth is not included in the first
request, KDC returns error 25 with the padata, and client re-tries with
the new salt; however, if the pre-authentication failed (due to various
reasons, such as further change to the mixed-case), should the KDC
return error 25 again with the new salt, or should KDC return error 24
with/without the padata ? Should the client process the padata and retry
again with the new salt ?
Maybe the next Kerberos clarifications should clarify this particular
More information about the Kerberos