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