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. 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
