[Bug] javax.security.auth.kerberos.KeyTab returns unrequested keys

[Wei-Jun Wang]

Hi Michael,

I've filed https://bugs.openjdk.org/browse/JDK-8331975. I plan to introduce a system property to control the string comparison mode.

In my earlier reply I mentioned fixing keytab entry lookup no matter how the comparison is done. I did some evaluation and the code change will be quite big. The lookup of a long term service key is now divided in 2 steps: first find the keys for the service, and then pinpoint the key with the correct kvno and the etype. Unfortunately the name info is lost after the 1st step. In order to do a case-sensitive preferred 2nd step search, the name has to be retained. Also, if a vendor goes case-insensitive, in theory there is a probability that between the 2 entries in the keytab actually the one that has a different case is the right one! Who knows.

Therefore I decide not to implement this part and only rely on the system property. If a program wants to work with a case-sensitive KDC that really has service names only differ in case, please just turn this system property on.

Thanks,
Weijun

> On May 7, 2024, at 7:27 AM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> I'm thinking of the opposite. 
> 
>> On May 6, 2024, at 3:59 PM, Osipov, Michael (IN IT IN) <michael.osipov at innomotics.com> wrote:
>> 
>> On 2024-05-06 21:55, Wei-Jun Wang wrote:
>>> Hi Michael,
>>> Thanks for the report. It seems not conforming to the RFC strictly
>>> but I hesitate to make a change now.
>>> The getKeys() method uses the PrincipalName.match() method to
>>> compare principal names in case-insensitive style. The same method
>>> is also used to locate a ticket from a ccache file. This has been
>>> true from the beginning of JGSS before it became a part of Java SE
>>> 1.4. There must be a history on why it's coded this way, probably
>>> relate to what you said MS deviates from the rule.
>>> That said, I would look into the code to see if this might return
>>> the wrong key when decrypting the authenticator in a AP-REQ. If
>>> there is any bug there, I'll fix it. On the initiator side, I will
>>> also see if it can help locating the correct ticket.
>> 
>> Thanks, looking forward to. In theory, foo$ and FOO$ are two distinct
>> principals and ca be associated with different keys. In AD land not, but
>> in MIT Kerberos and Heimdal for sure.
>> If the behavior won't change I'd appreciate anything of either:
>> * Update of docs
>> * Maybe a sysprop to disable this behavior
>> * Still a JBS issue closed as wontfix for future reference
>> 
>> Michael
>