Java Pre-auth for Windows 2003 mixed case revival

[MWChapel]

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. 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. 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 so since I already send the as-req
automatically with the pa-enc-timestamp, if I get the
KDC_ERR_PREAUTH_REQUIRED, should I be required to read the e-data
method-data as the new salt to encypt with?

   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?

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