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
