[526] in Kerberos
Re: Inter-Realm Access
daemon@TELECOM.MIT.EDU (sommerfeld@apollo.com)
Thu Nov 3 17:22:11 1988
From: sommerfeld@apollo.com
To: ota+@ANDREW.CMU.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ted Anderson's message of Thursday, November 3, 1988 3:29:28 pm (EST)
The interrealm mechanism works; however, it seems to require more
support from the application than many application writers seem to
want to provide.
The biggest problem on the client side is the question of "what realm
is this server or service in"?
Currently, this is handled by the use of what some call a heuristic,
but I call a kludge: the domain of the host (everything after the
first `.') is used as its realm, with the exception that (for historic
reasons; you really _don't_ want to know why) the domain MIT.EDU maps
to the realm ATHENA.MIT.EDU. This is under the control of a
configuration file on the client side, accessed through the use of a
library routine. I've been kicking around the idea of replacing the
configuration file with some sort of a "secured" nameservice. (It
should be obvious why the nameservice has to be secure).
The equivalent problem on the service end is "what do I do now that
this remote user claims to be in a completely different realm?". This
is just an authorization decision like any other.
In answer to your question about major interrealm kerberos users, I
believe the biggest (in terms of number of tickets requested) is
"discuss", a networked conferencing system. It doesn't have a concept
of a "unix user"; all its authorization decisions are made by looking
for the kerberos principal name of its caller on an access control
list.
The protocol for interrealm access is basically this: if I am user X
in realm A, and want to talk to service Y in realm B, I first need a
ticket granting ticket for realm A (a ticket for krbtgt.A@A), which I
presumably picked up at login time. I can then get a ticket for B's
ticket granting service, granted by A (a ticket for krbtgt.B@A), and I
can then present that to B's KDC to get a ticket for Y@B. However,
all these details are hidden under the covers.. all the applications
programmer has to do is come up with the realm of the server as a
parameter to krb_mk_req.
The application's service doesn't have to do anything "special" to get
it to work; the system managers of the two realms merely have to come
up with a shared secret.
One common error is forgetting to check the realm or instance of the
decoded authenticator, thus allowing user "joe@B" to have all the
access of "joe@A"; from the point of view of interface design, I think
that this error would have been harder to make had kerberos names been
a specific datatype, as opposed three strings travelling together...
- Bill
