MWChapel wrote:
Hello,
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
release.
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 Java 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
types
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 and 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 incorrect.
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:
if(client.pa_enc_timestamp_required and
pa_enc_timestamp not present) then
error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
endif if(pa_enc_timestamp present) then
decrypt req.padata-value into decrypted_enc_timestamp
using client.key;
using auth_hdr.authenticator.subkey;
if (decrypt_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
if(decrypted_enc_timestamp is not within allowable
skew) then error_out(KDC_ERR_PREAUTH_FAILED);
endif
if(decrypted_enc_timestamp and usec is replay)
error_out(KDC_ERR_PREAUTH_FAILED);
endif
add decrypted_enc_timestamp and usec to replay cache;
endif
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 not all.
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 KDC_ERR_PREAUTH_REQUIRED,
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.
Thanks.
Michael W. Chapel
[EMAIL PROTECTED]
Java Kerberos/JGSS Development
IBM/Tivoli Java Security Austin Texas
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
