Ticket History #459: The KDC will return a cross-realm ticket when it shouldn't

From kenh@cmf.nrl.navy.mil Mon Aug 11 14:30:33 1997
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id OAA22294 for <bugs@RT-11.MIT.EDU>; Mon, 11 Aug 1997 14:30:28 -0400
Received: from [134.207.10.161] by MIT.EDU with SMTP
id AA19292; Mon, 11 Aug 97 14:30:26 EDT
Received: from elvis.cmf.nrl.navy.mil (kenh@elvis.cmf.nrl.navy.mil [134.207.10.38])
by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id OAA19841
for <krb5-bugs@mit.edu>; Mon, 11 Aug 1997 14:29:58 -0400 (EDT)
Received: (from kenh@localhost)
by elvis.cmf.nrl.navy.mil (8.8.5/8.8.5) id OAA22484;
Mon, 11 Aug 1997 14:30:22 -0400 (EDT)
Message-Id: <199708111830.OAA22484@elvis.cmf.nrl.navy.mil>
Date: Mon, 11 Aug 1997 14:30:22 -0400 (EDT)
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Subject: Using hierarchial cross-realm breaks getting service principals
X-Send-Pr-Version: 3.99

Navel Research Lab


System: SunOS elvis 4.1.4 4 sun4c
Architecture: sun4


If the KDC gets a TGS request for a principal that is unknown, it will
try to return the closest tgt available for that realm.

However, this is done for requests for tickets that are NOT tgt tickets.
Normally, this is never noticed. However, we just addded a cross-realm
ticket for the NRL.NAVY.MIL realm, and all of a sudden things started
failing with "KDC response was modified".

It turned out that on a few hosts, we hadn't placed host keys on yet (for
a variety of technical and/or political reasons). So when the clients
would try to get a ticket for "host/foo.cmf.nrl.navy.mil@CMF.NRL.NAVY.MIL"
they would instead get back a ticket for "krbtgt/NRL.NAVY.MIL@CMF.NRL.NAVY.MIL"
which would result in the above error.

I think this is wrong, and I think the KDC should only send back the "closest"
krbtgt ticket if the request is for a krbtgt ticket (but I believe this
behavior still breaks the 1.0pl1 client code, but that's a separate issue :-) )

Create a cross-realm entry for the realm above you, and try to get a ticket
for a non-existant principal in your realm.

Apply the following patch:

Index: kdc/do_tgs_req.c
===================================================================
diff -u -r1.1.1.1 do_tgs_req.c
--- do_tgs_req.c 1997/06/02 21:54:07 1.1.1.1
+++ do_tgs_req.c 1997/08/09 04:50:10
@@ -162,7 +162,7 @@
* might be a request for a TGT for some other realm; we
* should do our best to find such a TGS in this db
*/
- if (firstpass && krb5_princ_size(kdc_context, request->server) == 2) {
+ if (firstpass && krb5_is_tgs_principal(request->server) == TRUE) {
krb5_data *server_1 = krb5_princ_component(kdc_context, request->server, 1);
krb5_data *tgs_1 = krb5_princ_component(kdc_context, tgs_server, 1);


Responsible-Changed-From-To: krb5-unassigned->tytso
Responsible-Changed-By: tytso
Responsible-Changed-When: Thu Nov 13 20:43:22 1997

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Thu Nov 13 20:44:06 1997
State-Changed-Why: Checked into the source tree.