Java Pre-auth for Windows 2003 AD renamed accounts

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Java Pre-auth for Windows 2003 AD renamed accounts

Douglas E. Engert
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
>
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

Seema Malkani
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

Booker C. Bense
-----BEGIN PGP SIGNED MESSAGE-----

In article <[hidden email]>,
Seema Malkani <[hidden email]> wrote:
>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.
>

_ I've downloaded test versions of jdk_1.6.0 and while they
contain the man page for kinit, they do not have the kinit
binary. Can this be fixed? I would very much like to test
this...

_ Booker C. Bense

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBQwt6MmTWTAjn5N/lAQGwFQP/cpgh1V/wOY5gIxYIRLFdCGvKE+idWr9K
9p1r43gBcDgc64U7/GBVj99fkjUnIxXmHcEwVea0NX9JwVS6OaOpkfvAvqp0mAnS
ppWQ73IldNjiADIf06pfK5F4CKGH149J9A8pmBez4ttchTjm6x7JkDFcrBfdfR9o
o6VQLUPMd4Q=
=iCsY
-----END PGP SIGNATURE-----
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

Markus Moeller
In reply to this post by Seema Malkani
Will Mustang finally include arcfour-hmac Kerberos ciphers to et more then
DES encryption when used with MS ?

Thanks
Markus


"Seema Malkani" <[hidden email]> wrote in message
news:[hidden email]...

> 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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

Seema Malkani
In reply to this post by Booker C. Bense
Sun's implementation of Java GSS/Kerberos includes Kerberos tools
(kinit, klist, ktab) for Windows.

Please download the latest build of Java SE 6 (Mustang).
http://download.java.net/jdk6/binaries/

Seema

Booker C. Bense wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>In article <[hidden email]>,
>Seema Malkani <[hidden email]> wrote:
>  
>
>>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.
>>
>>    
>>
>
>_ I've downloaded test versions of jdk_1.6.0 and while they
>contain the man page for kinit, they do not have the kinit
>binary. Can this be fixed? I would very much like to test
>this...
>
>_ Booker C. Bense
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQCVAwUBQwt6MmTWTAjn5N/lAQGwFQP/cpgh1V/wOY5gIxYIRLFdCGvKE+idWr9K
>9p1r43gBcDgc64U7/GBVj99fkjUnIxXmHcEwVea0NX9JwVS6OaOpkfvAvqp0mAnS
>ppWQ73IldNjiADIf06pfK5F4CKGH149J9A8pmBez4ttchTjm6x7JkDFcrBfdfR9o
>o6VQLUPMd4Q=
>=iCsY
>-----END PGP SIGNATURE-----
>________________________________________________
>Kerberos mailing list           [hidden email]
>https://mailman.mit.edu/mailman/listinfo/kerberos
>  
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

Douglas E. Engert
In reply to this post by Seema Malkani


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

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Java Pre-auth for Windows 2003 AD renamed accounts

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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos