next up previous
Next: Experiences in Designing Up: Secure Non-Local Access Previous: Secure IP tunnelling

Remote Login and Remote Execution

Permanent secure IP tunnels do not meet all of our needs, however. While travelling, users cannot always gain access to a trusted host, and those connections have a short duration. To support incoming access in these cases, we allow remote login channels providing the illusion of a terminal connection to a machine inside the firewall. Support for this service is straightforward: the packet filter allows access to a single bastion machine acting as a gatekeeper. After authenticating themselves to the bastion machine, users are given a proxy that permits a single telnet session to another machine inside the firewall. We do not want shells running on the bastion machine, because we believe that a machine upon which one can execute a shell is more easily compromised.

The need for remote login access is not unique to our firewall. Many mechanisms are in widespread use. We provide two remote login services: S/Key and Kerberos.

S/Key [16] generates a set of one-time passwords enabling the remote user to log onto a bastion from anywhere. The keys are provided by interacting with the S/Key server over a secure channel (local or Kerberos-encrypted telnet). Users must be careful to acquire enough keys before going off-site, because they have no safe way to acquire more keys using only S/key access through the firewall.

S/Key provides only limited functionality. It is intended for users who only have access to an off-the-shelf telnet client. Because the conversation is not likely to be encrypted, we do not consider it completely trustworthy. In particular, users of unencrypted S/Key must assume that their passwords are compromised when typed over an insecure network.

Encrypted Kerberos connections [23,19] are more secure and, therefore, can permit greater functionality. Kerberos is used to authenticate the remote user, and encryption is used to keep the connection secure. The Kerberos password is never typed over the network in the clear; so it is not compromised. Because the connection is encrypted, a Kerberized login may, for example, be used to acquire more S/Key passwords.

We provide a Kerberos remote login server on a bastion machine that only allows users to execute an rlogin command. No shells are permitted on this machine. Kerberos does not eliminate the need for S/Key: Kerberized telnet clients are not available for all of our portable platforms, and even when a Kerberized telnet client is available on a visited machine, we should be wary of trusting it with a secret key.



next up previous
Next: Experiences in Designing Up: Secure Non-Local Access Previous: Secure IP tunnelling



Sandeep Singhal
Thu Nov 30 01:58:58 PST 1995