Java Pre-auth for Windows 2003 mixed case revival
Douglas E. Engert
deengert at anl.gov
Thu Feb 10 13:58:52 EST 2005
> I am working on figuring a solution to the Java conundrum that was
> stated in an earlier thread last month i.e.:
>>Sun's implementation of Java GSS/Kerberos currently supports
>>PA-ENC-TIMESTAMP as per RFC 1510. The new pre-authentication types
>>specified in the Kerberos clarifications provide additional
>>pre-authentication. Support for these new pre-authentication types
>>PA-ETYPE-INFO and PA-ETYPE-INFO2 will be available in future J2SE
> Yes it appears the PA-ENC-TIMESTAMP works, if it is encrypted using the
> correct key. But if the salt or what 1510 referees to as an
> 'alternate "mix-in" string' is wrong the KDC returns with a error 24,
> rather then a 25.
> RFC 1510 does refer to the pa-pw-salt as a returned PA-DATA. Java
> does not handle this in the 24 error. Although it is underspecified,
> one could argue the Java implementation is not 1510 compliant.
> Comments on the Kerberos mailing list from others indicate that the
> code is not handling pre-auth correctly.
>>However, if you specify the etype correctly, you should not get the
>>pre-authentication error. You can specify the default encryption
>>used by the Java client in the Kerberos configuration file.
> Its not an e-type problem, it is a wrong salt or failure of the client
> to use the salt returned by the KDC.
> You can easily test this with a network trace program, like Ethereal
> use the Java kinit against a Windows AD. Just change the case of one
> of the letters in the principal name, and you will get a KRB5_ERROR
> response with (24). If you look at the message you will see the salt
> returned twice, as a PA-ETYPE-INFO and PA-SALT-DATA. (Ethereal has some
> problems parsing these, but the salt is in the message.)
> I am responsible for the IBM Java Kerberos piece, and am trying to work
> out a solution.
> Here is the problem. Java kerberos always sends the pa-enc-timestamp,
> but since windows 2003 is using mixed case names, then the salt will be
The first problem is Java is sending the pa-enc-timestamp with the first
request. If it did not then you would get the (25) response. I think
that is the real solution.
The pseudo code on page 92 says:
pa_enc_timestamp not present) then
if(pa_enc_timestamp present) then
decrypt req.padata-value into decrypted_enc_timestamp
if (decrypt_error()) then
if(decrypted_enc_timestamp is not within allowable
skew) then error_out(KDC_ERR_PREAUTH_FAILED);
if(decrypted_enc_timestamp and usec is replay)
add decrypted_enc_timestamp and usec to replay cache;
If you did not send the pa_enc_type and it is needed you get a 25.
If you sent the pa_enc_timestamp, and it is wrong, then you get a 24.
3.1.3 says also says:
The authentication server looks up the client and server principals
named in the KRB_AS_REQ in its database, extracting their respective
keys. If required, the server pre-authenticates the request, and if
the pre-authentication check fails, an error message with the code
KDC_ERR_PREAUTH_FAILED is returned.
(BTW if the account was renamed, the principal name could change,
but not the salt, so it is not just mixed case problem.)
> 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
> What we need is a
> KDC_ERR_PREAUTH_REQUIRED(25) with the e-data in the KRB_ERROR. Am I
> right in assuming that?
If the first request sent in did NOT have the pa-enc-timestamp,
then that this is the response you would receive.
> If so since I already send the as-req
> automatically with the pa-enc-timestamp, if I get the
But the KDC is not keeping state. Since you sent in a req with pre-auth
it is assuming it had already sent you a 25 in the previous response
and that you did all the right things with extra data in the 25 error
response. So it sends a 24, in which case you can't do anything else.
> should I be required to read the e-data
> method-data as the new salt to encypt with?
In a 25 yes.
> The problem arises is that I have the pa-enc-timestamp in the
> as-req, and as per rfc1510, they should be sending a
> KDC_ERR_PREAUTH_FAILED error if present but failed, and not
> KDC_ERR_PREAUTH_REQUIRED. So how is it with the mixed case names can
> this be handled?
Don't send any pre-auth in the first request.
> Sorry to open this can of worms again. But I am trying to work a
> solution on the Java side of the arguement.
> Michael W. Chapel
> mchapel at us.ibm.com
> Java Kerberos/JGSS Development
> IBM/Tivoli Java Security
> Austin Texas
> Kerberos mailing list Kerberos at mit.edu
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the Kerberos