[136] in Kerberos
Interrealm misfeatures and alternate
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:32:42 1987
From wesommer@ATHENA.MIT.EDU Mon Nov 3 03:46:33 1986
To: kerberos
Subject: Interrealm misfeatures and alternate an_to_ln
Date: Mon, 03 Nov 86 03:44:27 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I have just spent the last three hours examining some interrealm
misfeatures of Kerberos. Currently, Kerberos is quite inconvenient to
use in many protocols if both systems are not in the same realm.
One obstacle I ran across (but did not attempt to fix) is that ticket
files do not contain the realm of the principal they are for (it is
assumed that it is the same as the local realm of the machine). As a
result, when constructing an authenticator, mk_ap_req does a
get_credentials for the appropriate service; assuming that succeeds,
it proceeds to build the authenticator. When building the request ID
(including the user's identity encrypted in the session key), it uses
the name and instance retrieved from the ticket file, but always uses
the local realm, rather than the realm encoded in the ticket (which is
not stored in the clear in the ticket file). This makes "kinit -r"
(for an alternate realm) worthless unless you are empowered to do
surgery on /etc/krb.conf as well. (I am sure that others have noticed
this bug before).
The following syslog trace of a server which shall remain nameless
demonstrates the problem: [Oliver is in the ATHENA realm, and I have
"kinit"ed for the TELECOM realm]
Nov 3 02:15:58 paris xxx[15029]: connection accepted from OLIVER.SIPB.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: ticket->length: 56
Nov 3 02:15:59 paris xxx[15029]: Ticket Contents.
Nov 3 02:15:59 paris xxx[15029]: Aname: wesommer.TELECOM.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: Service: rcmd.paris
Nov 3 02:15:59 paris xxx[15029]: About to decrypt req_id
Nov 3 02:15:59 paris xxx[15029]: Done.
Nov 3 02:15:59 paris xxx[15029]: Pname: wesommer wesommer
Nov 3 02:15:59 paris xxx[15029]: Realm: TELECOM.MIT.EDU ATHENA.MIT.EDU
Nov 3 02:15:59 paris xxx[15029]: rd_ap_req(rcmd.paris) failed, code 36
"So close, and yet so far..."; the ticket is OK except for the bogus
realm (ATHENA.MIT.EDU) put in by the client code.
On a more optimistic note, I just implemented an "improved" an_to_ln()
routine (this is the routine which translates Kerberos names into
local names). In addition to translating {<name>, "", <local-realm>}
into the local name <name>, it also attempts to translate foreign
realms or non-null instances by looking them up in a DBM keyed
database (in /etc/aname.{dir,pag}).
To make this useable, I also wrote a simple user-interface program
(krb_alias) which allows one to examine and modify the database:
krb_alias with no arguments dumps the whole database; krb_alias with
one argument (a kerberos name of form <name>.<instance>@<realm>)
prints the local name or "unknown" if no local name can be found), and
krb_alias with two arguments (kerberos name and local name)
establishes a mapping, or deletes the mapping from the kerberos name
if the local name is "-delete". Naturally, /etc/aname.* is set up to
be mode 644, owner root, so krb_alias must be setuid root. I made a
few policy decisions:
- root can map any Kerberos name into any local name or delete any mapping
- <user> can map any Kerberos name of the form <user>.*@* into
<user>, or delete any mapping from <user>.*@*
I think that the second one could be relaxed a little bit, but I'm not
sure exactly how far (it's really a policy decision which I'm not
prepared to make at 3AM).
Sources for these modules may be found in
/@/paris/mit/w/e/wesommer/remote_krb/irlm/{lib,prog}; a binary for
krb_alias is installed in /krb on paris. Comments anyone?
- Bill
