Java Pre-auth for Windows 2003 mixed case revival

[Douglas E. Engert]

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
> mchapel at us.ibm.com
> Java Kerberos/JGSS Development
> IBM/Tivoli Java Security 
> Austin Texas
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444