Java Pre-auth for Windows 2003 AD renamed accounts

[Seema Malkani]

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