Java Pre-auth for Windows 2003 AD renamed accounts

[Markus Moeller]

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
>