[39126] in Kerberos
Re: can realms get "aliased" when there is a one-way trust? or, what
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Aug 4 15:30:29 2022
Message-ID: <3c91f83c-c25a-156e-5c2a-ef6b66f3d9d4@mit.edu>
Date: Thu, 4 Aug 2022 15:27:10 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Jerry Shipman <jes59@cornell.edu>, kerberos@mit.edu
From: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <CAOVr6ae2H024BopGyZxktCWwvcx5Ltj05OkBciahEZUSjnMJ-Q@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 8/4/22 13:18, Jerry Shipman wrote:
> It seems that when a user tries to get a service ticket for the
> afs/mit.foo.cornell.edu@FOO.CORNELL.EDU (which doesn't exist), he will
> wind up with two tickets, one for
> afs/mit.foo.cornell.edu@FOO.CORNELL.EDU and one for
> afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU. But this is odd, because
> afs/mit.foo.cornell.edu@FOO.CORNELL.EDU doesn't exist.
Kerberos has the concept of "referrals" for TGS requests, which are
defined in RFC 6806. If the FOO.CORNELL.EDU KDC finds that
afs/mit.foo.cornell.edu doesn't exist in its database, but can determine
that it should be in MIT.FOO.CORNELL.EDU, then instead of issuing a
service ticket, it may issue a cross-realm TGT for MIT.FOO.CORNELL.EDU.
The client will then follow the referral to MIT.FOO.CORNELL.EDU and get
a afs/mit.foo.cornell.edu@MIT.FOO.CORNELL.EDU ticket.
How the result is cached depends on the client software. For MIT krb5,
prior to 1.18 the resulting ticket is cached under both the requested
name and the final ticket service name. In 1.18 and later the ticket is
only cached under the requested name, but klist shows the ticket service
name if it differs, like this:
08/04/22 14:52:52 08/05/22 14:50:28 a/x.d@KRBTEST1.COM
Ticket server: a/x.d@REFREALM
> But isn't that dangerous, because bar@MIT.FOO.CORNELL.EDU and
> bar@FOO.CORNELL.EDU are totally different entities! Why would it do
> that? Is there a way to turn that off?
The theory behind referrals is that service principal names are
generally unique across realms, because they incorporate FQDNs. So a
client looking for a ticket for afs/mit.foo.cornell.edu generally
doesn't need to know which realm takes responsibility for authenticating
that name; its KDC can make that decision.
Client names are of course much less likely to be unique across realms;
"fred" may refer to a completely different user in different realms even
if they have cross-realm relationships.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
