I am giving a pretty lengthy presentation on Sun Kerberos next week and I want to make sure I have the correct understanding of how cross-realm authentication works.
Well, your understanding probably isn't as confused as some bits of your explanation:
Domain1: EXAMPLE.COM Domain2: EXAMPLE1.COM
1) The user [EMAIL PROTECTED] wants to telnet to host/[EMAIL PROTECTED] using cross-realm authentication.
The telnet is to a host named foo.example1.com, in Kerberos realm EXAMPLE1.COM (which is what one would expect from the names, but that isn't *always* the way it's set up). "host/[EMAIL PROTECTED]" is the name of the service principal used by the telnet server.
2) Both the KDC's host/[EMAIL PROTECTED] and host/[EMAIL PROTECTED] create krbtgt/[EMAIL PROTECTED] and vice-versa principals in a direct cross-real trust.
Again you're using "host/[EMAIL PROTECTED]", which is a Kerberos service principal name, when you probably should be saying something about the host named "foo" in realm "BAR". And in this case, I would describe it in terms of "the KDC for EXAMPLE.COM", not specific hosts, because there's no required correspondence, and while there can be multiple KDCs, the database is shared between them, so it's not *each* KDC doing the action.
And if we want to be really picky, it's an administrator who causes the database entries to be created, the KDCs don't do it spontaneously. :-)
"krbtgt/[EMAIL PROTECTED]" is created in both databases (that on the EXAMPLE KDC and that on the EXAMPLE1 KDC), and must have the same key in both. Likewise for krbtgt/[EMAIL PROTECTED] Currently -- at least in the MIT code, which Sun's Kerberos code is based on -- this has to be done in advance, with cooperation between the administrators of the two sites. There are some schemes in the works (if you care, check on the web far the "PKINIT" and "PKCROSS" proposals at the IETF) that could automate this in some cases, if both KDCs are tied in to some public key infrastructure.
3) The user [EMAIL PROTECTED] issues the following command:
bar.example.com$ telnet -a -f -x foo.example1.com
4) From here, host/bar.example.com contacts the KDC for EXAMPLE.COM looking for a cross-realm trust of host/foo.example1.com. Since there is a principal for host/kdc.example1.com, host/kdc.example.com issues a cross-realm service ticket for host/bar.example.com. The host/bar.example.com then contacts host/foo.example1.com with a service ticket presented from host/kdc.example.com and authenticates.
See above about the naming confusion for hosts and principals.
The telnet program run by the user on bar.example.com (no "host/bar.example.com" principal needs to exist anywhere, in this example) contacts the EXAMPLE.COM KDC, sending the user's ticket-granting ticket and requesting a ticket for the service krbtgt/[EMAIL PROTECTED] (not host/kdc.example1.com), which that KDC issues.
The program then contacts the KDC for EXAMPLE1.COM, sending that cross-realm ticket and asking for a ticket for host/[EMAIL PROTECTED], which that KDC issues.
Then the telnet program sends that ticket to the telnet server on foo.example1.com, to prove that the user in question really is [EMAIL PROTECTED] Whether or not [EMAIL PROTECTED] is allowed to automatically log in to any accounts on foo.example1.com without giving a password is another matter; that's usually governed by local policies, access control lists, etc.
The "host/*" service principals are a little odd; it might make things clearer if you change "telnet" (the program) and "host" (the service principal) to "ftp". In the FTP case, there is a special service principal name defined that is used for this service and this service alone. Other Kerberos-based services (at least, those not having to do with interactive logins and the like, like telnet, rlogin, rsh, and ssh) use per-protocol names as well, which allows an administrator to set up distinct protection domains for the different services. For example, an ftp server can run with one non-root uid and/or in a chroot environment, with access to the ftp/<hostname> service key but no others, so if the ftp service is compromised through some software bug, it can't be used to gain access to the service key for the IMAP server which runs similarly but separately protected.
This is where I am a little confused on how exactly the trust relationship plays out. To what degree do the two KDC's communicate this trust relationship in this specific scenario. What is the order of conversation? I am looking for some help with step 4 and if someone could set me straight.
I hope my description above makes the exchange a bit clearer.
Another way to think about it is: The ticket is essentially a message a KDC gives to the client to give to a server, which tells the server who the KDC thinks the client is. (With a bunch of encryption stuff happening to prevent forgery of the messages.) So, by way of the telnet (or ftp) client, the KDC for EXAMPLE.COM tells the KDC for EXAMPLE1.COM "this guy is [EMAIL PROTECTED]", so that second KDC produces another message telling the telnet server, "the KDC for EXAMPLE.COM says that this is [EMAIL PROTECTED]". The messages always go by way of the client program; the KDCs don't talk to each other or to the telnet service.
(By the way, this process can be repeated through KDCs for multiple realms, but don't think too much about that until you understand the two-realm case well.)
"Trust" is kind of a funny word, in this context. Sometimes "trust" is used to mean "we'll let this guy do stuff", but in this context, it merely means that a KDC from one realm will listen to a KDC from another realm when it issues tickets identifying someone as a user (or any principal, actually) in that other realm. The two KDCs have the cross-realm keys set up; all that means is that they can communicate what these claimed identities are in a secure fashion. It doesn't mean you're going to let the other realm's users log in to your machines, or anything else. That's an authorization decision that's separate from the authentication step performed by Kerberos. (Though the Kerberos protocol does have a way to carry some kind of authorization information -- again, don't think too hard about that until you've mastered the basics.) All that this "trust" allows you to do is prove your identity as a non-local principal to some remote service.
I hope this helps...
Ken
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
