On Jun 27, 2008, at 11:51, Simo Sorce wrote: > Thanks, the explanation there makes a lot of sense, but reading > through > the lines it probably would not affect the original poster security, > because the "insecurity" of the TXT record is exploitable only in > case a > trusted realm is compromised (and the DNS spoofed at the same time).
The "trusted realm" idea gets tossed around a lot, without a lot of specifics. Sometimes what is meant is, "a client in realm A can prove its identity to a server in realm B", and with multi-hop cross-realm authentication and (someday, we hope) something like PKCROSS, that doesn't have to imply any relationship directly between the two. With PKCROSS, all that's needed is KDCs to have certificates issued by trusted CAs. Sometimes what is meant is, "I know the administrators of realm B (or run it myself), and I put complete trust in anything they tell me, even if they're telling me something about my own users or servers". Kerberos cross-realm authentication is about the former. That said, if you don't exchange cross-realm keys with any outside realms, and disable PKCROSS if/when it gets implemented, you could have an isolated set of realms collectively considered part of your trusted computing base. >>> How is local configuration data trustworthy given that to resolve >>> names >>> to IPs we still rely on DNS ? Or do you also rely on /etc/hosts >>> for most >>> of the data ? >> If the host name resolves to a different IP address, the >> authentication >> will fail. > > Uhmm perhaps we are thinking of two different things, once you control > DNS you control both direct and reverse address resolution. The RFC says a Kerberos implementation shouldn't rely on DNS for determining the service principal name. That MIT's implementation does is a bug. (A long-standing one, one with implications as far as choices of names stored in keytabs, and changing it will involve some transition issues, as well as needing better support for handling multiple names for a server.) The name you attempt to *authenticate* to SHOULD be the name provided by the user, possibly transformed in some secure ways (e.g., add the local domain name, but do not look it up in DNS without DNSSEC). Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
