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 ; 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 Reply-To: mione@boeing.rutgers.edu To: krb5-bugs@MIT.EDU Subject: broken V4 compat w/multirealm KDC X-Send-Pr-Version: 3.99 >Number: 537 >Category: krb5-kdc >Synopsis: broken V4 compat w/multirealm KDC >Confidential: no >Severity: serious >Priority: medium >Responsible: tlyu >State: closed >Class: mistaken >Submitter-Id: unknown >Arrival-Date: Mon Jan 26 15:26:01 EST 1998 >Last-Modified: Fri Jan 22 00:53:28 EST 1999 >Originator: Tony Mione >Organization: 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 ***** >Release: 1.0pl4 >Environment: System: SunOS boeing.rutgers.edu 5.5.1 Generic_103640-05 sun4u sparc SUNW,Ultra-1 Architecture: sun4 >Description: 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. >How-To-Repeat: 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. >Fix: 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 + #include + + 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================================ >Audit-Trail: From: Tony Mione 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. >Category: krb5-kdc >Responsible: krb5-unassigned >Synopsis: Multi realm support does not work for V4 compatibility tickets >Arrival-Date: Mon Jan 26 15:26:01 EST 1998 -----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 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 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 To: tytso@MIT.EDU Cc: Tony Mione , 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: > Date: Thu, 17 Dec 1998 13:56:42 -0500 (EST) > From: Tony Mione > 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. 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. > 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, >... 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. >... > the realm B TGT.) Moreover, there's no way to actually do what you > want. Sigh. > 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. 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. > - Ted 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.... >Unformatted: