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

[Osipov, Michael (IN IT IN)]

That be fine. New Java version restores RFC behavior and property can 
bring back old case-insensitive behavior.

Michael

On 2024-05-06 22:03, Wei-Jun Wang wrote:
> I'll probably pick #2 if you also like it.
> 
>> 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
>