[244] in Zephyr Mailing List
Re: Interrealm support issues
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri Jan 3 15:51:10 1997
To: Derek Atkins <warlord@MIT.EDU>
Cc: Greg Hudson <ghudson@MIT.EDU>, Derrick J Brashear <shadow@DEMENTIA.ORG>,
zephyr@MIT.EDU
From: Marc Horowitz <marc@cygnus.com>
Date: 03 Jan 1997 15:40:13 -0500
In-Reply-To: Derek Atkins's message of 03 Jan 1997 10:44:22 -0500
First, I'd like to agree with Greg that massive changes to the
protocol are not good right now. My personal requirements are that I
be able to zephyr with people at athena and people at my office
without leeching off athena's zephyr servers (which some of us do, and
some of us don't, and so don't run zephyr). In trying to make this
happen, I have more control over my clients than then servers at many
sites.
Second, I'm going to establish some terminology. A zephyr realm is a
set of zephyr servers which share a database and an authentication
key. Interrealm zephyr is what Derrick implemented, where realms know
about each other, and pass messages between each other. New term:
multirealm zephyr is what I'm working on, where each client knows
about the realms it cares about, and zephyr servers are totally blind
to the existence of other realms.
Third, currently, zephyr realms do not have names. A zephyr recipient
is a fully qualified kerberos name, and nothing more, and this is the
way the implementation behaves (I'm ignoring the issues of
non-kerberized zephyr for now). If a non-canonical name is provided
("zwrite marc"), then the local kerberos realm is appended.
Derek Atkins <warlord@MIT.EDU> writes:
>> Greg Hudson <ghudson@MIT.EDU> writes:
>>
>> > Unless I'm confused, I think this is wrong. Both the sender and the
>> > recipient have Kerberos realms associated with them, which are
>> > independent of the server's Kerberos realm. If the above statement
>> > were true, marc@cygnus.com or shadow@andrew.cmu.edu would have
>> > difficulty receiving authentic zephyr notices.
>>
>> It depends on whether you are talking about the sending side or the
>> receiving side. From the *sending* side, the receipient principal
>> realm and the zephyr kerberos realm are assumed to be the same. With
>> an unhacked client, it automatically authenticates to the local realm
>> and sends the messages to the local realm. So, sending a message to
>> marc@cygnus.com from a standard Athena client would authenticate to
>> zephyr.zephyr@ATHENA.MIT.EDU and send it to the Athena z-servers.
As of 2.0.4 (and the revisions before it), the clients assume that the
kerberos realm in which the zephyr servers reside is the same as the
kerberos realm of the local host, not the kerberos realm of the
reipient, and authenticate to zephyr.zephyr@LOCALREALM.
This means that if I tried to use the athena zephyr servers from my
machine here at cygnus, I would lose, because my machine is in the
CYGNUS.COM kerberos realm, and trying to use zephyr.zephyr@CYGNUS.COM
to authenticate to arilinn.mit.edu fails miserably.
>> >From the receiving side, there really isn't any assumption at all.
>> The current (single realm) code assumes that it is only talking to one
>> server. I made a slight change which assumed that zephyr kerberos
>> realm == sender's principal realm. Marc fixed this to look at the
>> z-server IP address and do a krb_realmofhost() on that address to
>> attempt to find the z-server kerberos realm, which works more often.
This is basically correct. In particular, I made changes to have my
clients (in ZInitialize()) query the hostmanager to get the zephyr
server name. I call krb_realmofhost() on this name, and use that,
instead of the local realm, as the realm of the server. This is
analogous to what happens when I use telnet, rlogin, ftp, etc., and
seems to be clearly the right thing. As a side-effect, when I do
"zwrite warlord", the realm appended is ATHENA.MIT.EDU, not
CYGNUS.COM, which turns out to be convenient, as the bulf of users of
these kerberos servers have principals in the ATHENA.MIT.EDU kerberos
realm.
>> With the default clients, no interrealm messages can be authentic at
>> all. With my hacked zwrite, one can *send* an authentic inter-realm
>> message (which is received by all in the remote realm as authentic).
>> It assumes that the receipient principal realm (or *@realm) is the
>> zephyr realm, and assumes the zephyr realm == zephyr kerberos realm.
>>
>> Receiving messages from the remote realm is still unauthentic with the
>> standard zwgc. With *my* hacked zwgc, I could receive authentic
>> messages from remote realms only from people within that realm;
>> messages I sent to that realm came back to me unauthentic (well,
>> forged). Marc changed zwgc to use krb_realmofhost(); so long as that
>> is correct, it will DTRT and received messages will show up as
>> authentic.
I'm not sure what Derek means by "interrealm" here, but when I send
messages from my cygnus machine to the athena zephyr servers, these
messages appear authentic to the recipients. This is with standard
2.0.4 (or maybe even older than that) clients. When they "zwrite
marc@cygnus.com", with standard clients, I receive those messages, and
they are authentic.
The important thing to remember here is that with the multirealm
model, zephyr servers only know about one realm, and it is their own,
and they authenticate accordingly.
The changes I am working on are to have the zhm and clients understand
multiple independent zephyr realms. I chose to augment the protocol
between the client and the zhm to include a zephyr realm, which
introduces a requirement to be able to name zephyr realms. I do this
with a configuration file which maps a zephyr realm name into a list
of server names. The library uses krb_realmofhost() to determine the
kerberos realm to use to authenticate to the servers in the zephyr
realm. The client creates composes a message in protocol version
ZEPH0.3, which is sent to the zhm. This message includes all the
ZEPH0.2 fields, plus a destination zephyr realm. The zhm converts the
message to a plain ZEPH0.2 message, and delivers it to the correct
realm. When a message is received by a client, it looks at the IP
address the message came from, and uses this to derive the zephyr
realm, and from that, the kerberos realm to use to validate the
message.
This system does require changes to many clients, since with
independent realms, you need to be able to store and access location
and subscription information for each realm separately. The clients
as I'm implementing them do most of this work for you.
It is important to see that the older clients are simply a degenerate
case of the new clients, and simply function in a one-realm universe.
Users using the new code simply need to configure their client to talk
to any realm the user wishes to be able to converse with.
Marc
