Ticket History #537: broken V4 compat w/multirealm KDC

From mione@boeing.rutgers.edu Mon Jan 26 15:25:15 1998
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA26347 for <bugs@RT-11.MIT.EDU>; Mon, 26 Jan 1998 15:25:14 -0500
Received: from boeing.rutgers.edu by MIT.EDU with SMTP
id AA00815; Mon, 26 Jan 98 15:25:19 EST
Received: (from mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) id PAA02703; Mon, 26 Jan 1998 15:25:05 -0500 (EST)
Message-Id: <199801262025.PAA02703@boeing.rutgers.edu>
Date: Mon, 26 Jan 1998 15:25:05 -0500 (EST)
From: Tony Mione <mione@boeing.rutgers.edu>
Reply-To: mione@boeing.rutgers.edu
To: krb5-bugs@MIT.EDU
Subject: broken V4 compat w/multirealm KDC
X-Send-Pr-Version: 3.99

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report ***** Important: John 17:3 *****

System: SunOS boeing.rutgers.edu 5.5.1 Generic_103640-05 sun4u sparc SUNW,Ultra-1
Architecture: sun4

When using a kdc for more than one realm, the kdc searches the
wrong database for principals in a V4 request. It searches the
database from the realm referenced in the previous V5 request.

Build kerberos with V4 compatibility support
(KRB5_KRB4_COMPAT). Set up 2 realms and create a couple principals in each
realm (do not create the same principal(s) for each realm). Now request a
V5 ticket with kinit. Then request a V4 ticket using a test client that
only requests V4 tickets (calls krb_get_in_tkt(), not
krb5_get_in_tkt_with_password(), etc).
If the same principal exists in both realms (but the passwords are
different), you should recieve a BAD_INTEGRITY return. If the same principal is
not in both realms, you should get KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN.

Patch dispatch.c to set up the realm context variable
(kdc_active_realm) before calling process_v4(). In kerberos_v4.c, do not
check local_realm in process_v4. Always reset it from
master_princ->realm.data.

=================================CUT HERE================================
*** dispatch.c 1997/12/27 01:39:37 1.1
--- dispatch.c 1997/12/27 01:48:05
***************
*** 29,34 ****
--- 29,42 ----
#include "extern.h"
#include "adm_proto.h"

+ /* Need these for realm setup later /ANM */
+ #ifdef KRB5_KRB4_COMPAT
+ #include <kerberosIV/krb.h>
+ #include <kerberosIV/prot.h>
+
+ extern kdc_realm_t *find_realm_data( char *, krb5_ui_4 );
+ #endif
+
krb5_error_code
dispatch(pkt, from, portnum, response)
krb5_data *pkt;
***************
*** 65,72 ****
}
}
#ifdef KRB5_KRB4_COMPAT
! else if (pkt->data[0] == 4) /* old version */
! retval = process_v4(pkt, from, portnum, response);
#endif
else
retval = KRB5KRB_AP_ERR_MSG_TYPE;
--- 73,102 ----
}
}
#ifdef KRB5_KRB4_COMPAT
! else if (pkt->data[0] == 4) { /* old version */
! char realm_name[1024];
! kdc_realm_t *newrealm;
! KTEXT_ST v4_pkt;
! KTEXT_ST *v4p_pkt;
!
! /*
! * Build a v4 style packet. Grab the realm name.
! * Then use find_realm_data to get the correct realm information
! * structure. Finally, that is the value to which we should set
! * kdc_active_realm. This will allow process_v4 to find the
! * correct realm info.
! */
! v4_pkt.length = pkt->length;
! memcpy( v4_pkt.dat, pkt->data, pkt->length);
! v4p_pkt = &v4_pkt;
! strcpy ( realm_name, (char *) pkt_a_realm ( v4p_pkt ) );
! newrealm = find_realm_data (realm_name, (krb5_ui_4) strlen ( realm_name ) );
! if ( newrealm ) {
! kdc_active_realm = newrealm;
! }
!
! retval = process_v4(pkt, from, portnum, response);
! }
#endif
else
retval = KRB5KRB_AP_ERR_MSG_TYPE;
***************
*** 76,78 ****
--- 106,109 ----

return retval;
}
+
=================================CUT HERE================================
*** kerberos_v4.c 1997/12/27 01:33:41 1.1
--- kerberos_v4.c 1997/12/27 01:36:00
***************
*** 171,184 ****
--- 171,193 ----
if ((retval = krb5_timeofday(kdc_context, (krb5_timestamp *) &kerb_time.tv_sec)))
return(retval);

+ /*
+ * Do this (set local_realm) each time (not just the first time)
+ * so we have the correct realm info with which to process
+ * the request. /ANM 26-Dec-1997
+ */
+ #if 0
if (!*local_realm) { /* local-realm name already set up */
/* XXX assumes realm is null-terminated! */
+ #endif
lrealm = master_princ->realm.data;
if (strlen(lrealm) < sizeof(local_realm))
strcpy(local_realm, lrealm);
else
retval = KRB5_CONFIG_NOTENUFSPACE;
+ #if 0
}
+ #endif
/* convert client_fulladdr to client_sockaddr:
*/
client_sockaddr.sin_family = AF_INET;
=================================CUT HERE================================


From: Tony Mione <mione@boeing.rutgers.edu>
To: krb5-bugs@MIT.EDU
Cc: kerberos-admin@ns2.Rutgers.EDU
Subject: Re: krb5-kdc/537: Multi realm support does not work for V4 compatibility tickets (fwd)
Date: Wed, 18 Feb 1998 14:06:49 -0500 (EST)

-----BEGIN PGP SIGNED MESSAGE-----


Hi. Do you think the below problem will be assigned soon. As yet, I
have not had any response at all on it. Tnx.


Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report ***** Important: John 17:3 *****

- ---------- Forwarded message ----------
Date: Mon, 26 Jan 1998 15:26:02 -0500
From: krb5-bugs@mit.edu
To: mione@boeing.rutgers.edu
Subject: Re: krb5-kdc/537: Multi realm support does not work for V4 compatibility tickets

Thank you very much for your problem report.
It has the internal identification `krb5-kdc/537'.
The individual assigned to look at your
report is: krb5-unassigned.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNOsxR/MKRuSgNA5pAQGaOgL+NCJLcJ7CaD4uc2591EFMUkdyGfUuzgFa
KCdTSFSBZyF5857rPQUscUTaW3jU3hJ9pkAcjAV1NR6KbtAweupXvZVSt/sCyxh8
YL1ipz/8Q0DMPqOHv23R0LsarR9sTWhF
=VHSs
-----END PGP SIGNATURE-----

Responsible-Changed-From-To: krb5-unassigned->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Fri Mar 27 19:44:56 1998
Responsible-Changed-Why:

Refiled.


From: Tom Yu <tlyu@MIT.EDU>
To: mione@boeing.rutgers.edu
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/537: broken V4 compat w/multirealm KDC
Date: Fri, 27 Mar 1998 19:47:48 -0500

Sorry for not getting back to you sooner. Multi-realm support in a
single KDC is not something that we treat as a terribly high
priority. I will try to evaluate your patch, though.

---Tom

From: tytso@MIT.EDU
To: mione@boeing.rutgers.edu
Cc: mione@boeing.rutgers.edu, krb5-bugs@MIT.EDU
Subject: krb5-kdc/537: Multi realm support does not work for V4 compatibility tickets
Date: Wed, 23 Dec 1998 09:31:53 -0500

Date: Thu, 17 Dec 1998 13:56:42 -0500 (EST)
From: Tony Mione <mione@boeing.rutgers.edu>

I talked to you at IETF about a bug report I submitted earlier in
the year concerning Multirealm KDC support for V4 tickets. The realm does
not get set correctly for V4 tickets when servicing multiple realms from a
single kdc image.

I took a closer look at your bug report, and your proposed patch isn't
correct, since the code which pulls apart the V4 ticket request looking
for the realm assumes that the request is an initial ticket (i.e., AS)
request, and doesn't work if the request is a TGS request; TGS requests
have an entirely different format.

So I looked at the format for a TGS request, and the problem is that the
V4 TGS request format doesn't have enough information to support a V4
Multirealm setup. Specifically, the realm of the application service
isn't specified in the V4 TGS request. Thus, it isn't possible to
support multiple realms using Kerberos V4, due to the inherent
limitations of its protocol.

As near as I can tell from looking at your patch, it will pull out the
realm from initial ticket requests, and use that to set the current
active realm. However, for TGS requests, the parsing routine will fail
(I'm surprised it doesn't core dump the server on occasion, since format
is really different, but apparently you're getting lucky), and whatever
garbage gets pulled out as the realm and passed to find_realm_data()
returns NULL, so the local realm doesn't get set. Hence, the realm
information used to interpret TGS requests --- in particular, the realm
desired for the application server --- is dependent on the realm in the
last AS request.

Did you actually test the patch which you submitted? From my analysis,
it couldn't possibly work correctly, unless by pure luck (i.e., you got
tickets for realm A, used those tickets, then got tickets for realm B,
used those tickets, and never tried to use the realm A TGT after getting
the realm B TGT.) Moreover, there's no way to actually do what you
want.

Why is it really important for you to support both V4 realms on the same
KDC? Machines are really cheap, after all --- just get an i386 box and
throw Linux on it. As a matter of fact, at this point I regret putting
the multi-realm support in the KDC at all. It adds a lot of complexity,
for relatively little gain.

- Ted

From: Tony Mione <mione@boeing.rutgers.edu>
To: tytso@MIT.EDU
Cc: Tony Mione <mione@boeing.rutgers.edu>, krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/537: Multi realm support does not work for V4
compatibility tickets
Date: Wed, 23 Dec 1998 13:09:59 -0500 (EST)

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 23 Dec 1998 tytso@mit.edu wrote:




Hmmm. Ok. This has been running fine for nearly a year but I know why. The
way we use Kerberos on the Macs and PCs is simply for login/password
check. No service tickets are ever requested so TGS requests are never
made. We only use V4 on the Macintoshes where the support group is running
a product called AuthMan. We have been trying to 'encourage' them to switch
to a V5 based product but there were supposed problems integrating other
products with Rutgers specific management software (Don't get me
started...:0)

I will likely keep the code running here until we can migrate the Macs away
from V4 tickets. Thank you for looking at the patch, though.




Yes, however, since we never use it for TGS's it isn't luck...it just works
for AS requests. I really hadn't looked carefully enough at the TGS
structure to realize this. If we were using TGSs it probably would have
failed quickly.


Sigh.


It is important since we are running about 7 realms (2 are large with
4000-40000 principals, the others are smaller with several hundred
principals each). Running 7 machines (even PCs) would be a management
nightmare to coordinate on the several hundred machines using kerberos
services (i.e. krb5.conf pointing at a different machine for each realm.)
Somewhat less cumbersome would be running 7 kdcs on the same machine but
then you have to hold 7 different ports. We decided to run it this way
mostly out of convenience and ease of management. For the most part,
everything works quite well. Note that we DO need to run 7 kadmind's (with
7 ports) since that does not handle multiple realms from one server.

Thanks again for the thorough review and report. Hope to see you in
Minneapolis.


Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B 0B918A4E22BAFA9F ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNoEx8fMKRuSgNA5pAQE/IgMArFukxu+mrQQImFkaF5xlAA+i8qstC4be
gJwx9GMy2bfFXx7yHAoQMebkN/o3Wab8/fqfXOY2Nd0x6KnK6ftdY6R33VzAdbix
rZecuJQ007V9eZS362TTxljZnKKYy38x
=so5C
-----END PGP SIGNATURE-----

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Fri Jan 22 00:52:14 1999
State-Changed-Why: Patch incorrect; not much we can do....