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

[Wei-Jun Wang]

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