Douglas,
As per the Kerberos clarifications (draft-ietf-krb-wg-kerberos-clarifications-07.txt), if pre-authentication is required, but was not present in the AS-REQ, an error message with the code KDC_ERR_PREAUTH_REQUIRED is returned, and the e-data field of the KRB_ERROR message will contain the PA-DATA with the specified padata-type. If the pre-authentication check fails, an error message with the errorcode 24 "KDC_ERR_PREAUTH_FAILED" is returned. Hence PA-DATA seems to be included in the KRB_ERROR message when KDC returns errorcode 25. For error codes other than KDC_ERR_PREAUTH_REQUIRED the format and contents of the e-data field are implementation-defined.
As for the question on case-sensitivity, Kerberos principal names are case-sensitive. On MIT/Solaris/Linux KDCs one can create two separate account "alice" and "ALICE", but on Windows there can be only one account "alice". Windows KDC accounts are all lower-case, changing the logon name to upper-case is not allowed. When authenticating with a mix-in string "Alice", this does not exist in the Active Directory, and Windows KDC returns error 24 with the PA-DATA of type PA-ETYPE-INFO that includes the salt. However, when authenticating this mix-in string using MIT/Solaris/Linux KDCs, it fails with "Client not found in Kerberos database", since the Principal name did not match.
Looking briefly at MIT Kerberos implementation, the pa-data processing from the error message is done only when KDC returns error 25 KDC_ERR_PREAUTH_REQUIRED. When the first AS-REQ does not include preauth, KDC returns error 25 with the padata included in the eData, and client now re-tries with the preauth using the new salt. MIT team can provide more details.
As mentioned earlier, support for the new pre-authentication types will be available in future J2SE release. In order to interoperate with Windows KDC, you will need to use the correct case of Kerberos principal "alice", as specified in the AD settings.
The PA-PW-SALT preauth type was not completely specified in RFC 1510. The Kerberos clarifications also states that this pre-authentication type was not present in RFC 1510.
Seema
Douglas E. Engert wrote:
Seema Malkani wrote:
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.)
[libdefaults] default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1//
In addition, Windows allows to disable pre-authentication by selecting "do not require Kerberos pre-authentication" in the AD account settings.
Seema
Douglas E. Engert wrote:
Sam Hartman wrote:
All these issues have been discussed on the ietf-krb-wg list although never quite in the same place.
Java is wrong in how it handles preauth; the advice in my preauth draft would be a better approach.
I agree it is wrong. What I would like to see is the Java people admit this and fix it and work in the krb-wg too.
AD is stretching clarifications significantly in how it handles case of principal names. However it's much more usable than what other implementations do. There was a long and heated discussion between Martin Rex and people at Microsoft over this issue.
Some how I miss that point. Hopefully the explaination I put together will get the Java people to do something about the preauth.
--Sam
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
