That's totally fine, thank you.
There is a typo in JDK-8331976: environemnt
On 2024-05-09 00:13, Wei-Jun Wang wrote:
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.w...@oracle.com> wrote:
I'm thinking of the opposite.
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
