[240] in Zephyr Mailing List
Re: Interrealm support issues
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jan 3 10:25:48 1997
To: Derek Atkins <warlord@MIT.EDU>
Cc: Derrick J Brashear <shadow@DEMENTIA.ORG>, zephyr@MIT.EDU
In-Reply-To: Your message of "Fri, 03 Jan 1997 09:31:06 EST."
<9701031431.AA03343@portnoy.MIT.EDU>
Date: Fri, 03 Jan 1997 10:22:07 EST
From: Greg Hudson <ghudson@MIT.EDU>
> Currently, zephyr assumes that these two "realms" (the recipient
> principal realm and the zephyr kerberos realm) are the same.
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.
> If we're going to change the protocol, we might as well fix all of
> the protocol problems, too.
Unfortunately, the more problems we decide to fix, the less likely the
protocol is to be upgraded. I do think all the problems which have
been mentioned so far (realm field, authentication instance, encoding)
are high priority, but we probably want to stop there. I also think
there will have to be some ordering requirement for the upgrade to
avoid making the library horribly complicated; probably the server
would have to be upgraded before the clients (since it's much easier
to verify that the server has been upgraded than that all of the
clients have). Even so, the server will still have to know how to put
together packets which a zeph0.2 client can understand, and that's a
lot of hackery to keep around. So I don't know how likely this is to
happen.
> If we are not going to change the protocol, then we must make the
> assumption that zephyr realm == zephyr kerberos realm == recipient
> principal realm.
Well, we can modify the protocol slightly without breaking backward
compatibility. For instance, we can encode the zephyr realm in the
recipient field (principle.instance@kerberosrealm/zephyrrealm) when
the zephyr realm is not the default (understanding that the zephyr
realm is *not* really part of the recipient, and this is just an
encoding hack). Then, a new client can talk to an old server as long
as it doesn't use a non-default realm (which is the best you can do
anyway), and an old client can talk to a new server.
It is certainly true that, without changing the protocol, you will
never be able to have two zephyr realms in the same kerberos realm
without compromising security (since clients will authenticate to
zephyr.zephyr@kerberosrealm when talking to either set of servers).
But you don't need to assume anything about the recipient principal
realm.
