Two Telnet Scenarios


Scenario 1: Normal telnet

In a normal telnet session to an Athena dialup machine, the users's password is sent across the network in clear text, exposing it to eavesdropping. The dialup machine uses this password to obtain Kerberos tickets to authenticate to other servers, so that the user can use AFS, POP mail, Zephyr, etc.

This scenario will still be open to users of Athena dialup. As of 1994, We have no intention of taking it away or changing the default behavior of telnet. We may want to revisit this in a few years.


Scenario 2: Kerberos v4 authenticated telnet

(Encryption of the connection is optional.)

In a Kerberos4-authenticated telnet session, the client uses the password to obtain Kerberos tickets locally. These tickets are used to authenticate to the dialup server, which lets the user login. Unfortunately, there are no tickets on the dialup server to authenticate to AFS, so the user's home directory is inaccessible.

If we were using Kerberos v5, the user's tickets could be forwarded easily and safely to the dialup server. Unfortunately, we don't yet support v5. And even if we did, there is no Mac or DOS v5 client available yet.

With Kerberos v4, we can use rkinit to safely obtain remote tickets prior to login. If we have working rkinit clients on all platforms or rkinit is somehow bundled with the non-Unix telnet clients, then all that's left is a small :-) matter of education on how to use it.

Once Kerberized telnet has established an encrypted connection, the user's password may be sent safely from client to server, so that the dialup server can establish authentication. The issue we need to examine is how and when to do this. There are several post-login authentication options.

The DCNS Product Planning Team (PPT) has chosen the following strategy:

Please address comments to <athena-ws@mit.edu>.
$Date: 94/09/01 14:21:02 $
Bruce R. Lewis <brlewis@mit.edu>