Java Pre-auth for Windows 2003 mixed case revival

[Douglas E. Engert]

To anseret your last question first, read:

  "Generalized Framework for Kerberos Pre-Authentication"
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-framework-02.txt

I think it clarifies all the questions you have. In section 2:

    "when a Kerberos client wishes to obtain a ticket using the
     authentication server, it sends an initial AS request.  If
     pre-authentication is being used, then the KDC will respond with a
     KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
     what pre-authentication to use, it MAY optimize a round-trip and send
     an initial request with padata included.  If the client includes the
     wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
     indication of what padata should have been included.  For
     interoperability reasons, clients that include optimistic
     pre-authentication MUST retry with no padata and examine the
     KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
     response to their initial optimistic request."

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. 

Thats OK, for now.

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

That is OK too.

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

Just as Sam's draft says.

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

But they are not required to return anything with 24.
> 
> 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.

See Sam's section 2. Start over with no pre-auth.

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

Since it is not required to return any pre-auth, Do wat Sam says
and start over with  no preauth.

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

mixed-case is a red hering. The client thinks it knows the salt but it does
not. There are other cases where this may also be true. So use the salt
returned by the KDC in the 25 message.

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

NO new error coe is needed.

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

OK, as stated in Sam's draft.

> however, if the pre-authentication failed (due to various
> reasons, such as further change to the mixed-case), 

The only way this would fail is that the user or admin is changing
the salt at the exact same time as the user is trying to get a ticket.
This is extreamly unlikly, and most likely it is because the user is
changing the password. Most likely it would fail because the user typed
in the wrong password.


> should the KDC
> return error 25 again with the new salt, 

No. a client that was not keeping state could get in a loop!

> or should KDC return error 24
> with/without the padata ? 

A KDC MAY return the data, so don't coult on it.

Should the client process the padata and retry
> again with the new salt ?


I would say keep it simple:
  Send request without pa-data,
  get 25 message, get pa-data types and salts
  send request with pa-data,
  if error 24 returned, fail.

> 
> Maybe the next Kerberos clarifications should clarify this particular
> scenario.
> 
> Seema
> 
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444