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" <[EMAIL PROTECTED]> wrote in message >>>news:[EMAIL PROTECTED] >>> >>> >>> >>> >>> >>>>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 [email protected] >>>>https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>>> >>>> >>>> >>>> >>> >>>________________________________________________ >>>Kerberos mailing list [email protected] >>>https://mailman.mit.edu/mailman/listinfo/kerberos >>> >>> >>> >>> >>________________________________________________ >>Kerberos mailing list [email protected] >>https://mailman.mit.edu/mailman/listinfo/kerberos >> >> >> >> > > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
