Skip Menu |
 

Download (untitled) / with headers
text/plain 10.5KiB
From basch@lehman.com Wed Dec 18 23:41:34 1996
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 XAA01308 for <bugs@RT-11.MIT.EDU>; Wed, 18 Dec 1996 23:41:25 -0500
Received: from lehman.Lehman.COM by MIT.EDU with SMTP
id AA24950; Wed, 18 Dec 96 23:41:14 EST
Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id XAA05481 for <krb5-bugs@mit.edu>; Wed, 18 Dec 1996 23:41:10 -0500
Received: from relay.messaging-svcs2.lehman.com(146.127.39.20) by lehman via smap (V1.3)
id tmp005479; Wed Dec 18 23:41:08 1996
Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6)
id AA17025; Wed, 18 Dec 96 23:41:07 EST
Received: from badger.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6)
id AA11039; Wed, 18 Dec 96 23:41:05 EST
Received: by badger.lehman.com (SMI-8.6/Lehman Bros. V1.5)
id XAA18369; Wed, 18 Dec 1996 23:41:04 -0500
Message-Id: <199612190441.XAA18369@badger.lehman.com>
Date: Wed, 18 Dec 1996 23:41:04 -0500
From: "Richard Basch" <basch@lehman.com>
To: krb5-bugs@MIT.EDU
Subject: krb524: requests with multi-home machines and null-address creds

Show quoted text
>Number: 305
>Category: krb5-kdc
>Synopsis: krb524: requests with multi-home machines and null-address creds
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: tlyu
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Dec 18 23:42:00 EST 1996
>Last-Modified: Fri Sep 28 21:35:54 EDT 2001
>Originator: Richard Basch
>Organization:
>Release:
>Environment:
>Description:
Problems:
1. On multi-home machines, the address used for the V4 credential
is the FIRST address in the V5 credential. With the old
V4 semantics, the address was always checked and computed
against the address used for the communications. Therefore,
the V5 address chosen should be the one which matches the request.
2. It is perfectly legitimate to have NO addresses encoded in a V5
credential, signifying that no address checking should be done.
If this is done, however, you CANNOT use krb524init. While
a V4 request needs to be deprecated into having a client
address encoded in it, this operation should not be denied
because of a NULL credential; instead the credential should
be constructed from the originating address of the request.
3. The starttime and lifetime calculation did not provide the maximum
possible duration. (This may or may not be partially included
in 1.0; I made these patches months ago, but the diffs included
below have been reconstructed against the 1.0 tree).

Enclosed are patches for krb524 that address the above problems.
--
Richard Basch
Sr. Developer/Analyst, DSO URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 38th Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049


--- 1.1 1996/12/13 18:23:41
+++ src/krb524/ChangeLog 1996/12/13 18:23:41
@@ -63,6 +63,25 @@

* configure.in: remove ref to ET_RULES

+Wed Aug 14 18:11:28 1996 Richard Basch <basch@lehman.com>
+
+
+ * krb524.h:
+ * krb524d.c (do_connection):
+ krb524_conv_tkt_skey now requires the client addr
+
+ * cnv_tkt_skey.c (krb524_convert_tkt_skey):
+ create the v4 ticket with now as the starttime
+ allow for null-addr creds - use the client addr
+
+ * conv_creds.c (krb524_convert_creds_plain):
+ Create the V4 ticket with now as the starttime and
+ the pro-rated lifetime (this will take the fullest
+ advantage of long-life V5 credentials).
+ Also, do not check the addresses in the v5 credential,
+ as they are checked by the server, and the appropriate
+ v4 ticket is created, even with a null-addr cred.
+
Mon May 6 12:09:44 1996 Richard Basch <basch@lehman.com>

* conv_creds.c: Fallback to slave kdc's wasn't working; it was not
--- 1.1 1996/10/15 21:32:56
+++ src/krb524/krb524.h 1996/10/19 17:15:31
@@ -32,7 +32,8 @@

int krb524_convert_tkt_skey
KRB5_PROTOTYPE((krb5_context context, krb5_ticket *v5tkt, KTEXT_ST *v4tkt,
- krb5_keyblock *v5_skey, krb5_keyblock *v4_skey));
+ krb5_keyblock *v5_skey, krb5_keyblock *v4_skey,
+ struct sockaddr *saddr));

/* conv_princ.c */

--- 1.1 1996/12/13 18:23:43
+++ src/krb524/krb524d.c 1996/12/13 18:23:43
@@ -292,7 +292,7 @@
printf("service key retrieved\n");

ret = krb524_convert_tkt_skey(context, v5tkt, &v4tkt, &v5_service_key,
- &v4_service_key);
+ &v4_service_key, &saddr);
if (ret)
goto error;

--- 1.1 1996/11/14 21:03:39
+++ src/krb524/k524init.c 1996/11/14 21:03:40
@@ -114,11 +114,17 @@
increds.server = server;
increds.times.endtime = 0;
increds.keyblock.enctype = ENCTYPE_DES_CBC_CRC;
+
+#if 0
+ if ((code = krb5_os_localaddr(context, &increds.addresses))) {
+ com_err("k524init", code, "getting local addresses");
+ exit(1);
+ }
+#endif
if ((code = krb5_get_credentials(context, 0, cc, &increds, &v5creds))) {
com_err("k524init", code, "getting V5 credentials");
exit(1);
}
-
if ((code = krb524_convert_creds_kdc(context, v5creds, &v4creds))) {
com_err("k524init", code, "converting to V4 credentials");
exit(1);
--- 1.1 1996/10/15 21:32:58
+++ src/krb524/conv_creds.c 1996/10/19 17:15:32
@@ -98,9 +98,12 @@
krb5_creds *v5creds;
CREDENTIALS *v4creds;
{
+#if 0
krb5_ui_4 addr;
+#endif
int ret;
krb5_timestamp lifetime;
+ krb5_timestamp starttime;

memset((char *) v4creds, 0, sizeof(CREDENTIALS));

@@ -124,12 +127,19 @@

/* V4 has no concept of authtime or renew_till, so ignore them */
/* V4 lifetime is 1 byte, in 5 minute increments */
+
+ if ((ret = krb5_timeofday(context, &starttime))) {
+ if (krb524_debug)
+ fprintf(stderr, "krb5_timeofday failed!\n");
+ return ret;
+ }
lifetime =
- ((v5creds->times.endtime - v5creds->times.starttime) / 300);
+ ((v5creds->times.endtime - starttime) / 300);
v4creds->lifetime =
((lifetime > 0xff) ? 0xff : lifetime);
- v4creds->issue_date = v5creds->times.starttime;
+ v4creds->issue_date = starttime;

+#if 0
/* XXX perhaps we should use the addr of the client host if */
/* v5creds contains more than one addr. Q: Does V4 support */
/* non-INET addresses? */
@@ -142,6 +152,7 @@
} else
memcpy((char *) &addr, v5creds->addresses[0]->contents,
sizeof(addr));
-
+#endif
+
return 0;
}
--- 1.1 1996/12/13 18:23:42
+++ src/krb524/cnv_tkt_skey.c 1996/12/13 18:47:33
@@ -56,17 +56,20 @@
* Convert a v5 ticket for server to a v4 ticket, using service key
* skey for both.
*/
-int krb524_convert_tkt_skey(context, v5tkt, v4tkt, v5_skey, v4_skey)
+int krb524_convert_tkt_skey(context, v5tkt, v4tkt, v5_skey, v4_skey, saddr)
krb5_context context;
krb5_ticket *v5tkt;
KTEXT_ST *v4tkt;
krb5_keyblock *v5_skey, *v4_skey;
+ struct sockaddr *saddr;
{
char pname[ANAME_SZ], pinst[INST_SZ], prealm[REALM_SZ];
char sname[ANAME_SZ], sinst[INST_SZ];
krb5_enc_tkt_part *v5etkt;
int ret, lifetime, deltatime;
krb5_timestamp server_time;
+ struct sockaddr_in *sinp = (struct sockaddr_in *)saddr;
+ krb5_address kaddr;

v5tkt->enc_part2 = NULL;
if ((ret = krb5_decrypt_tkt_part(context, v5_skey, v5tkt))) {
@@ -133,9 +136,19 @@
return KRB5KRB_AP_ERR_TKT_NYV;
}

- /* XXX perhaps we should use the addr of the client host if */
- /* v5creds contains more than one addr. Q: Does V4 support */
- /* non-INET addresses? */
+ kaddr.addrtype = ADDRTYPE_INET;
+ kaddr.length = sizeof(sinp->sin_addr);
+ kaddr.contents = (krb5_octet *)&sinp->sin_addr;
+
+ if (!krb5_address_search(context, &kaddr, v5etkt->caddrs)) {
+ if (krb524_debug)
+ fprintf(stderr, "Invalid v5creds address information.\n");
+ krb5_free_enc_tkt_part(context, v5etkt);
+ v5tkt->enc_part2 = NULL;
+ return KRB524_BADADDR;
+ }
+
+#if 0
if (!v5etkt->caddrs || !v5etkt->caddrs[0] ||
v5etkt->caddrs[0]->addrtype != ADDRTYPE_INET) {
if (krb524_debug)
@@ -144,6 +157,7 @@
v5tkt->enc_part2 = NULL;
return KRB524_BADADDR;
}
+#endif

if (krb524_debug)
printf("startime = %ld, authtime = %ld, lifetime = %ld\n",
@@ -157,7 +171,7 @@
pname,
pinst,
prealm,
- *((unsigned long *)v5etkt->caddrs[0]->contents),
+ *((unsigned long *)kaddr.contents),
(char *) v5etkt->session->contents,
lifetime,
/* issue_data */
Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, "Richard Basch" <basch@lehman.com>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/305: krb524: requests with multi-home machines and null-address creds
Date: Thu, 19 Dec 1996 00:06:39 -0500

For the record, the 1.0 release provides the maximum possible duration
for the V4 ticket lifetile. However, it didn't adjust the algorithm
used for calculating the lifetime in the V4 credential (i.e., the field
which is displayed to the user). So, for certain very long-lived
ticket, the klist display will be incorrect.

A similar bug (which is also present in your patch, Richard), is that
the algorithm in cnv_tkt_skey.c uses the CMU lifetime encoding hack,
whereas the code in conv_creds.c does not.

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: tlyu
Responsible-Changed-When: Sun Mar 16 02:02:14 1997
Responsible-Changed-Why:

Refiled


From: Tom Yu <tlyu@MIT.EDU>
To: basch@lehman.com
Cc: krb5-bugs@MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: krb5-kdc/305: krb524: requests with multi-home machines and null-address creds
Date: Sun, 16 Mar 1997 02:05:10 -0500

We should look into applying the patches that deal with multi-homed
machines and null-address creds as well, since I think there may be
another PR outstanding on that.

---Tom

Responsible-Changed-From-To: krb5-unassigned->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Wed Jun 17 16:38:28 1998
Responsible-Changed-Why:

Refiled

State-Changed-From-To: open-feedback
State-Changed-By: tlyu
State-Changed-When: Wed Jun 17 16:38:40 1998
State-Changed-Why:

Ok fixed the stuff regarding addresses, since it was causing coredumps
due to null dereference. Will look at the lifetime stuff later.

src/krb524/cnv_tkt_skey.c 1.15
src/krb524/conv_creds.c 1.19

State-Changed-From-To: feedback-closed
State-Changed-By: tlyu
State-Changed-When: Fri Sep 28 21:35:25 2001
State-Changed-Why:

stale and already fixed mostly; lifetime stuff will be dealt with for
1.3.x.

Show quoted text
>Unformatted: