[6] in Kerberos
Re: Kerberos Support for Remote Serv
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:12:22 1987
From mtc@ATHENA.MIT.EDU Mon Jun 9 16:25:49 1986
To: saltzer
Cc: geer@athena.mit.edu, bcn@athena.mit.edu, spm@athena.mit.edu,
charlie@athena.mit.edu, noah@athena.mit.edu, jis@athena.mit.edu
Subject: re: Kerberos Support for Remote Services, Project Description (long)
Date: Mon, 09 Jun 86 16:24:04 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
Jerry,
Thanks for your comments and questions. Here are some answers:
> What is "vxlogin"?
As bcn stated, it is (at present) a utility which creates the tickets.
The user types his Kerberos name and password, and tickets are created
if they match. Eventually vxlogin is planned to be merged into login(?).
> The management of Kerberos service keys isn't clear here. Does every
> server that might allow Kerberos-mediated rlogin have a different
> key? Or is there a standard Kerberos-mediated rlogin key that every
> server must know? Assuming the former, just what does the
> prospective client ask for by way of a ticket? How does the proper
> UNIX user id get into the ticket? Do you assume that the Kerberos
> name of the user is identical to the UNIX user id to be used at the
> rlogin server?
I its the former: every server has a different key. Upon calling vxlogin,
the client gets ALL tickets s/he is entitled to. I do not need to assume
that the Kerberos name is the same as the Un*x id on server, because of
the following:
a. A kerberos name is placed in the ticket by vxlogin. This name may or
may not be the same as the client's local username; a translation is
performed by the server (via antoln) which takes the kerberos name
and translates it to the client's username. I understand that at
present they ARE in fact the same, but by using antoln to do the
"conversion", the code will continue to work if at some point in the
future they are different.
b. The remote username, specified by the client via a switch on the
rlogin command, is not involved with Kerberos. The login will be
attempted if Kerberos says that the request has been authenticated;
generally, changing one's username over an rlogin involves typing
a password anyway.
> 3. Are the same service keys used for rsh, rcp, and rlogin?
There are separate service keys for each type of service. rcp and rsh are
actually the same "service", in that the same server (rshd) is used to
service both clients; therefore, they both use the same service key.
rlogin is a different type of service and thus has a different service key.
You've probably noticed that the current scheme calls for the creation of
a large number of service keys: one for each type of service available on
each host. It is not clear to me that having separate keys for each service,
for the purpose of additional flexibility in controlling access, is worth
the cost of multiplying the number of keys that are required; this feature
appears to be a remnant of the days when Kerberos was also in the
authorization business.
> Where does the rlogin service store the private key it uses for
> deciphering Kerberos tickets?
In /etc/srvtab, under Un*x file protection (see bcn's note).
> This feature strikes me as being more of a bug. Have you established
> for certain that you can't just extend the present protocol in a way
> that produces a well-defined error response if you try to use the
> Kerberos extensions in talking to a server that doesn't know about
> Kerberos? I would expect that you could define a couple of new
> operation types within the protocol that request a Kerberos login and
> that supply the Kerberos ticket.
I generally refer to a "feature" as a known, unavoidable side effect.
Frequently a feature is undesirable, as is the case here. I could have
underscored this by labelling it a "misfeature". A "bug", by contrast,
is when a program fails to work as designed.
There are three cases worth considering here:
1. Both client and server speak Kerberos. If I could assume this to be
the case, it would be very easy to extend the protocol.
2. The server knows Kerberos, the client does not. My original version
assumed that this would be one of the cases. It distinguished between
a Kerberos-speaking client and one that did not by means of a special
cookie sent before the username in the protocol; receipt of this cookie
changed the server's expectation of what followed. Because of the
requirements of solving #3 below, I removed this ugly hackery.
3. The client knows kerberos, the server does not. The term "protocol"
glorifies the communication between the client and server: it is simply
a one-way message consisting of three or four NULL-terminated text strings
from the client to the server. It does NOT provide any well-defined error
indication. If rlogind does not like the information sent by the client,
it simply prompts the user for a "login: ". While I could look for
a string of characters like "login: ", I feel this is not well defined;
local versions of login may vary.
Steve had suggested the use of the new port. It has the advantage of
absolutely identifying servers which speak Kerberos (after it is made
"well-known" via registry). After thinking about it, I doubt a better
solution exists, but I'm listening.
mtc
