Jacob Bachmeyer <[email protected]> writes: > On 2/19/26 21:26, Russ Allbery wrote:
>> That's also possible for services that accept usernames and passwords >> and validate them with Kerberos (common for POP and IMAP servers), >> although of course best practices in those cases is to immediately >> discard the resulting ticket after authentication. > I would that think in such a scenario, the client should be presenting a > Kerberos service ticket to the POP/IMAP server. That requires Kerberos support in the client, which is notoriously not always available (mobile clients, for instance, often do not have Kerberos clients). It's been a problem in the mail world for a long time that we have a ton of better authentication protocols than PLAIN but a lot of mail clients still like using PLAIN, to such an extent that we have things like device-specific passwords to allow use of password authentication with less risk to the user's real credentials. > If PAM is creating the ticket cache when the session is opened, then PAM > should also be destroying the ticket cache when the session is closed. Yeah, definitely, it's a problem of not calling the right PAM functions to end the authentication (whether that involves a PAM session or not), which is a service bug, not a Kerberos bug. > Across the open Internet is one thing, but I would expect (perhaps > naively) that communications between web servers and the KDC would be on > a secure internal network. The problem isn't so much the open Internet as it is load balancers, Kubernetes, VMs on bridge networks, and all the other network complexities that might be sitting between the server's understanding of its IP and the KDC, which is often segregated into an entirely separate secure network from general Internet-facing services and thus on the other side of some variety of NAT or the like. At least back in the day, the general feeling in the community I was part of was that address-locked tickets were operationally fragile and the security benefit wasn't really worth it. It's possible that changed, or that analysis is wrong. > It stops the use of a stolen ticket in the report's scenario of a web > service leaking files from /tmp. :-) I'm not sure I would go to the effort of making address-locked tickets work just in case I configured a web server to serve /tmp for some reason, which comes back to your point about the merits of the original report (or lack thereof). > Aha! I did not know if the Kerberos cache stored tickets in separate > files or all together. > If they are all stored in one file, along with the session keys needed > to use them, then yes, distinctions between service tickets and TGTs are > useless: an attacker who steals a usable service ticket will also get a > usable TGT, outside of very specialized scenarios where the service > ticket endures after the TGT expires. I should add the substantial caveat that my experience is almost entirely with UNIX Kerberos. Windows uses its own way of managing ticket caches and it may well be mediated by some sort of process that, for instance, obtains service tickets and provides them without providing access to the TGT. I know nothing about how all that works except I know Microsoft did things to try to make it more secure. But the report seemed to be primarily about UNIX Kerberos, and in that context generally the TGT and the service tickets are all in the same place (whether that be a file or keyring). I don't know how KCM works. There's a daemon involved, so maybe it does something more sophisticated. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
