>> Also, I guess I find it personally frustating that a >> practice that has caused me a ton of pain over a few decades is justified >> by what I would charitably classify as "vague hand-waving". > >Me too. We've been recommending calling gss_accept_sec_context with >GSS_C_NO_CREDENTIAL for a long time, and almost no one does that. it's >very annoying.
It's comforting to know that at least I'm not the only old, grizzled Kerberos user that feels that way. >>But, fine, let's talk about a specific example. In the case of sudo, >> the local hostname is used to build a "host" principal and passed in as >> the server argument to krb5_verify_init_creds(). If you pass in NULL >> instead to the server argument, krb5_verify_init_creds() will try >> every "host" principal in the local keytab until one succeeds. > > >AFAIK, that's a relatively recent feature in the grand scheme of things. I am chuckling at the realization that "relatively recent" in Kerberos now means "within the last 12 years" (looks like that code went in to MIT Kerberos version 1.11). Now I feel even older. It seems like the sudo Kerberos code has been unchanged for even longer. But even then, the previous implementation of krb5_verify_init_creds() just did the same thing that sudo did, so the code in sudo was at best redundant even when it was written. >well, the keytab could contain a copy of a key that is known to other >services or to some user. even a principal intended to be used only as a >client could be an issue, if an attacker knows the key and can print valid >tickets. I mean, sure, that's possible ... but that could be true for the host key! I know that newer versions of MIT Kerberos have the configuration file entry "ignore_acceptor_hostname" (first appeared in 1.10) which does resolve these issues, so it's not as big of a deal as it once was. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
