Java Pre-auth for Windows 2003 AD renamed accounts
Seema Malkani
Seema.Malkani at Sun.COM
Tue Aug 30 19:38:51 EDT 2005
Support for RC4-HMAC Kerberos encryption type is available in Java SE
(Mustang), starting from b35 onwards. Support for the new
Pre-authentication types is available in Java SE 6 (Mustang) release,
starting from b49 onwards.
Please download the latest Mustang binary from:
http://download.java.net/jdk6/binaries/
We are looking into backporting, but currently don't have any backports
ready as yet.
Seema
Douglas E. Engert wrote:
>Seema Malkani wrote:
>
>
>
>>Sun's implementation of Java GSS/Kerberos supports DES, 3DES, RC4-HMAC
>>(ARCFOUR-HMAC), AES128, AES256 Kerberos encryption types.
>>
>>Support for RC4-HMAC Kerberos encryption type is available starting from
>>Java SE 6 (Mustang). We are also looking into backporting support for
>>RC4-HMAC to earlier releases of JDK.
>>
>>
>
>
>Good to here. What weekly snapshot has these? I can't seem to find any references
>to this on the "Summary of changes in Mustang" page.
>
>
>Will someone from Java be at the The IETF Kerberos Working Group interim meeting
>and interoperability event September 19-23? For details on meeting location, hotel
>and the interoperability event, please see the meeting website at
>http://grand.central.org/dl/ietf-krb-wg/200509/
>
>It would be nice to see this and pre-auth interoperate.
>
>Can you give any more information on the back porting of this and the pre-auth
>problem? We could use the pre-auth fix today.
>
>
>
>>Seema
>>
>>Markus Moeller wrote:
>>
>>
>>
>>
>>>Will Mustang finally include arcfour-hmac Kerberos ciphers to et more then
>>>DES encryption when used with MS ?
>>>
>>>Thanks
>>>Markus
>>>
>>>
>>>"Seema Malkani" <Seema.Malkani at Sun.COM> wrote in message
>>>news:43053BCC.3060206 at sun.com...
>>>
>>>
>>>
>>>
>>>
>>>>Sun's implementation of Java Kerberos has been updated to include support
>>>>for the new Pre-authentication types. This support is available starting
>>>>
>>>>
>>>>from Java SE 6.0 (Mustang Release). In addition, we are also looking into
>>>
>>>
>>>
>>>>backporting this support to earlier releases of JDK.
>>>>
>>>>Seema
>>>>
>>>>Douglas E. Engert wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>We have run into this same Java preauth problem from Febuary with
>>>>>Kerbeors preauth
>>>>>again, but this time it was because some acocunts where renamed. The
>>>>>problem
>>>>>is that the "salt" is uisng the old principal name and Java asumes it
>>>>>knows
>>>>>the salt, and does not know how to request the "salt" from the KDC.
>>>>>
>>>>>
>>>>>I see the ietf-krb-wg will be having a meeting and Microsoft will be
>>>>>hosting
>>>>>an interoperability event after the meeting. I would suggest that the
>>>>>Java SUN
>>>>>people participate, I would like to see this problem solved.
>>>>>
>>>>>
>>>>>Seema Malkani wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Douglas E. Engert wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>MWChapel wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>We do handle the preauth correctly when PA-ENC-TIMESTAMP is included;
>>>>>>however currently we do not support the new preauthentication types as
>>>>>>defined in the Kerberos clarifications. Sun's implementation of Java
>>>>>>GSS/Kerberos currently always includes the PA-ENC-TIMESTAMP, and if the
>>>>>>KDC returns error code 24 KDC_ERR_PREAUTH_FAILED, we do not process the
>>>>>>padata if included with it.
>>>>>>
>>>>>>I believe in MIT Kerberos implementation, the first AS-REQ does not
>>>>>>include preauth, KDC returns error 25 with the padata included in the
>>>>>>eData, and client then re-tries with the preauth using the new salt.
>>>>>>
>>>>>>As per RFC1510bis, the padata is included only when KDC returns error
>>>>>>code 25 KDC_ERR_PREAUTH_REQUIRED. Hence Kerberos implementations are
>>>>>>expected to process the padata only when error 25 is returned by the
>>>>>>KDC. If the the pa-enc-timestamp is included, KDCs do not return with
>>>>>>error code 25. However, some KDCs include the padata (new salt in the
>>>>>>case of mixed case) even with the error code 24 KDC_ERR_PREAUTH_FAILED.
>>>>>>
>>>>>>I agree, the solution here is not to include the pre-auth in the first
>>>>>>request. However, if the client knows what pre-authentication to use, it
>>>>>>may optimize the round-trip and include the pre-auth. However, if the
>>>>>>client includes the wrong pre-auth, how should the KDC/client handle is
>>>>>>not apparent.
>>>>>>
>>>>>>Should the KDC return error 24 or 25 ? If KDC returns the error 24 with
>>>>>>padata, should implementations ignore it, or retry with the new salt ?
>>>>>>In the case of mixed-case, should the KDC return an error 24 or 25 with
>>>>>>the new salt ? Seems like we have two cases :-
>>>>>>1) PreAuth_Required, now retry (error code 25)
>>>>>>2) PreAuth_Failed, no retry, client should fail. (error code 24)
>>>>>>Should there is a new error code for PreAuth_Failed, retry again ? Or
>>>>>>irrespective of the error code, client should always process padata if
>>>>>>included and retry ?
>>>>>>
>>>>>>Or let's say we have a scenario if preauth is not included in the first
>>>>>>request, KDC returns error 25 with the padata, and client re-tries with
>>>>>>the new salt; however, if the pre-authentication failed (due to various
>>>>>>reasons, such as further change to the mixed-case), should the KDC
>>>>>>return error 25 again with the new salt, or should KDC return error 24
>>>>>>with/without the padata ? Should the client process the padata and retry
>>>>>>again with the new salt ?
>>>>>>
>>>>>>Maybe the next Kerberos clarifications should clarify this particular
>>>>>>scenario.
>>>>>>
>>>>>>Seema
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>________________________________________________
>>>>Kerberos mailing list Kerberos at mit.edu
>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>________________________________________________
>>>Kerberos mailing list Kerberos at mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>>
>>>
>>________________________________________________
>>Kerberos mailing list Kerberos at mit.edu
>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>>
>>
>
>
>
More information about the Kerberos
mailing list