JAVASEC - Using Java client with Windows 2003 AD withmixedcase PrincipalNames

[Douglas E. Engert]

Seema Malkani wrote:

> Douglas,
> 
> As per the Kerberos clarifications 
> (draft-ietf-krb-wg-kerberos-clarifications-07.txt), if 
> pre-authentication is required, but was not present in the AS-REQ, an 
> error message with the code KDC_ERR_PREAUTH_REQUIRED is returned, and 
> the e-data field of the KRB_ERROR message will contain the PA-DATA with 
> the specified padata-type.

Yes, and the Java assumes PRE-AUTH using PA-ENC-TIMESTAMP is required,
and thus the above does not apply as the Java always sends a PRE-AUTH
with the AS-REQ.

> If the pre-authentication check fails, an 
> error message with the errorcode 24 "KDC_ERR_PREAUTH_FAILED" is 
> returned.

Yes and this is what Java sees as the first reply, since thw wrong
salt was used with the PA-ENC-TIMESTSAMP, the KDC assumes it must be
the worng password was used with the correct salt.

> Hence PA-DATA seems to be included in the KRB_ERROR message 
> when KDC returns errorcode 25. For error codes other than 
> KDC_ERR_PREAUTH_REQUIRED the format and contents of the e-data field are 
> implementation-defined.

But this reply is never sent to Java as the Java code never sends an
AS-REQ without PRE-AUTH.

> 
> As for the question on case-sensitivity, Kerberos principal names are 
> case-sensitive. On MIT/Solaris/Linux KDCs one can create two separate 
> account "alice" and "ALICE", but on Windows there can be only one 
> account "alice". Windows KDC accounts are all lower-case, changing the 
> logon name to upper-case is not allowed. When authenticating with a 
> mix-in string "Alice", this does not exist in the Active Directory, and 
> Windows KDC returns error 24 with the PA-DATA of type PA-ETYPE-INFO that 
> includes the salt. However, when authenticating this mix-in string using 
> MIT/Solaris/Linux KDCs, it fails with "Client not found in Kerberos 
> database", since the Principal name did not match.

Correct. Windows has loosely interpreted 1510 to allow case insensitivity.
I don't agree but that was what they did.

The other situation which is similar, is renaming a principal, but keeping
the same key. Since the protocol allows for the KDC to tell the client
the salt, then rename without changing the key is implied.

This requires the old salt to be used by the client, which requires
the client to process the PA-ETYPE-INFO to know the correct salt.
(Which is what we are going to do with these mixed case users, in
effect rename them to lower case. And since the Java code can not
handle this, tell them to change their password.)

Windows can rename. The MIT kadmin does not have a rename, but can
keep a separate salt in the database. I am not sure what other KDCs
can do. The issue at had has to do with using the correct salt for
the key.

> 
> Looking briefly at MIT Kerberos implementation, the pa-data processing 
> from the error message is done only when KDC returns error 25 
> KDC_ERR_PREAUTH_REQUIRED. When the first AS-REQ does not include 
> preauth, KDC returns error 25 with the padata included in the eData, and 
> client now re-tries with the preauth using the new salt. MIT team can 
> provide more details.
> 

Yes I have talked to them, and have network traces that conferm this.
They always sent the first AS_REQ without any PA-DATA.  See: Sam's
"Pre-Auth Framwork" draft:

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-framework-02.txt

    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.

The Java client is doing: "MAY optimize a round-trip" but it fails
to "MUST retry with no padata and examine..."

> As mentioned earlier, support for the new pre-authentication types will 
> be available in future J2SE release.

I would hope this would be in the *NEAR* future and you treat this problem
as a bug. I claim it is a bug because other vendors do not have this problem,
only Java.

> In order to interoperate with 
> Windows KDC, you will need to use the correct case of Kerberos principal 
> "alice", as specified in the AD settings.
>

Actually this should be of no concern to the Java code if it handles the
salt correctly. As far as it knows the user alice could have a salt with Alice.

> The PA-PW-SALT preauth type was not completely specified in RFC 1510. 
> The Kerberos clarifications also states that this pre-authentication 
> type was not present in RFC 1510.

I know this is one reason clarifications is called "Clarifications".
As the original WG chair of the IETF krb-wg, what was called "Kerberos
Revisions" by the CAT WG was split into "Clarifications" and Extensions".
"Clarifications covering all those features being in common use by vendors
and problems with 1510.

Sun has taken a very active roll in the WG since it founding, but
I don't recall ever seeing a posting from the Java side of the house.
Please correct me if I am wrong. (I see you are on the mailing list.)
I would hope The Java developers would take a more active roll, especially
with "Extensions" in regard to internationalization of the principal
name where all these problems of salt and comparing of names will be
brought up again.

> 
> Seema
> 
> Douglas E. Engert wrote:
> 
>>
>>
>> Seema Malkani wrote:
>>
>>> Sun's implementation of Java GSS/Kerberos currently supports 
>>> PA-ENC-TIMESTAMP as per RFC 1510. The new pre-authentication types 
>>> specified in the Kerberos clarifications provide additional 
>>> pre-authentication. Support for these new pre-authentication types 
>>> PA-ETYPE-INFO and PA-ETYPE-INFO2 will be available in future J2SE 
>>> release.
>>
>>
>>
>> Yes it appears the PA-ENC-TIMESTAMP works, if it is encrypted using the
>> correct key. But if the salt or what 1510 referees to as an
>> 'alternate "mix-in" string' is wrong the KDC returns with a error 24,
>> rather then a 25.
>>
>> RFC 1510 does refer to the pa-pw-salt as a returned PA-DATA. Java
>> does not handle this in the 24 error. Although it is underspecified,
>> one could argue the Java implementation is not 1510 compliant.
>>
>> Comments on the Kerberos mailing list from others indicate that the Java
>> code is not handling pre-auth correctly.
>>
>>>
>>> However, if you specify the etype correctly, you should not get the 
>>> pre-authentication error. You can specify the default encryption 
>>> types used by the Java client in the Kerberos configuration file.
>>>
>>
>> Its not an e-type problem, it is a wrong salt or failure of the client
>> to use the salt returned by the KDC.
>>
>> You can easily test this with a network trace program, like Ethereal and
>> use the Java kinit against a Windows AD. Just change the case of one
>> of the letters in the principal name, and you will get a KRB5_ERROR
>> response with (24). If you look at the message you will see the salt
>> returned twice, as a PA-ETYPE-INFO and PA-SALT-DATA. (Ethereal has some
>> problems parsing these, but the salt is in the message.)
>>
>>> [libdefaults]
>>> default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
>>> default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
>>> permitted_enctypes   = des-cbc-md5 des-cbc-crc des3-cbc-sha1//
>>>
>>> In addition, Windows allows to disable pre-authentication by 
>>> selecting "do not require Kerberos pre-authentication" in the AD 
>>> account settings.
>>>
>>> Seema
>>>
>>> Douglas E. Engert wrote:
>>>
>>>>
>>>>
>>>> Sam Hartman wrote:
>>>>
>>>>> All these issues have been discussed on the ietf-krb-wg list although
>>>>> never quite in the same place.
>>>>>
>>>>> Java is wrong in how it handles preauth; the advice in my preauth
>>>>> draft would be a better approach.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I agree it is wrong. What I would like to see is the Java people
>>>> admit this and fix it and work in the krb-wg too.
>>>>
>>>>>
>>>>> AD is stretching clarifications significantly in how it handles case
>>>>> of principal names.  However it's much more usable than what other
>>>>> implementations do.  There was a long and heated discussion between
>>>>> Martin Rex and people at Microsoft over this issue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Some how I miss that point. Hopefully the explaination I put together
>>>> will get the Java people to do something about the preauth.
>>>>
>>>>
>>>>>
>>>>> --Sam
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

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