Cross-Realm Authentication

[Ken Raeburn]

On Apr 22, 2005, at 00:20, Darren Hoch wrote:
> 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 darren at EXAMPLE.COM wants to telnet to 
> host/foo.example1.com at EXAMPLE1.COM 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/foo.example1.com at EXAMPLE1.COM" is the name of the service 
principal used by the telnet server.

> 2) Both the KDC's host/kdc.example.com at EXAMPLE.COM and 
> host/kdc.example1.com at EXAMPLE1.COM create 
> krbtgt/EXAMPLE.COM at EXAMPLE1.COM and vice-versa principals in a direct 
> cross-real trust.

Again you're using "host/foo at BAR", 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/EXAMPLE.COM at EXAMPLE1.COM" 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/EXAMPLE1.COM at EXAMPLE.COM.  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 darren at EXAMPLE.COM 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/EXAMPLE1.COM at EXAMPLE.COM (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/foo.example1.com at EXAMPLE1.COM, 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 
darren at EXAMPLE.COM.  Whether or not darren at EXAMPLE.COM 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 darren at EXAMPLE.COM", so that second KDC 
produces another message telling the telnet server, "the KDC for 
EXAMPLE.COM says that this is darren at EXAMPLE.COM".  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