stel(1)

NAME
stel - Secure TELnet

SYNOPSIS
stel [ hostname ] [ options ] [ commands ]

DESCRIPTION
stel(1) is intented to be a simple and practical plug and play solution for logging into a remote system or executing commands on a remote system. stel offers a variety of features which range from mutual authentication to file transfer. The security of stel relies upon the underlying cryptographic desing, not trusting the net in any way. hostname is the name of the remote system. If no options are provided, stel defaults to triple DES encryption, 1024 bits Diffie Hellman modulus, no protection from active attacks, and the remote system user's shell as the command to be executed on the remote system. This should be reasonable for most systems, and it is believed to be a good compromise between speed, ease of use and security.

OPTIONS
stel recognizes the following options:

    -1  Use the single DES cipher. For the crypto impaired, single DES has a 64-bit block size for the plaintext and the ciphertext. It uses a key size of 56 bits. It is based on the design concept of combining substitutions and permutations, and it has 16 rounds. DES is probably the best studied encryption algorithm available today, in fact it was first released in 1976. Since then, there has been much speculation on the key length, on the number of interations, and the design of the S-boxes. Some people even feared that the NSA embedded a ``trap-door'' into the algorithm but, as far as it is publicly known, nobody has never proved or misproved anything. The only real practical problem DES is suffering from is key length. This is why triple DES remains the default encryption method.

    -4  Use the RC4 cipher. It is the (alleged) RC4 algorithm posted in the Usenet News in 1995 (RC4 was originally a trade secret algorithm of RSA Data Security and has not been published; however, this implementation is widely believed to be equivalent). RC4 is a stream, variable-key-size cipher, and it uses a key size of 128 bits in the present implementation. RC4 is a very new algorithm, and it is not nearly so well-studied as DES or IDEA. RC4 is the fastest algorithm currently supported by and it is intended to be used when speed is an issue and security is

    -a  Protect from active attacks. This is one of the most advanced features of When using this option, the data stream which is transmitted from client to server and vice versa is ``packetized'' and sanity checks are performed on each data packet. Sanity checks include CRC32 encrypted MACs, to foil garbage injection, and encrypted sequence numbers, to foil replay attacks. When using this option, file transfer facilities are available.

    -D  Enable debug mode. When this option is set, extensive debugging information are displayed. Most variables and keys are dumped, and they are effectively visibile on to the screen, so use this option with care. -D should only be used to achieve a better understanding about how stel really works. When this option is set, both encrypted and unencrypted data are dumped on to the screen, making it difficult to read what is being displayed on the screen.

    -e  Disable escape features. By default, stel provides escapes features by means of the default escape character ``^]''. When this option is set, escapes features are disabled. This option is intended if using stel in conjuction with modem file transfer programs (i.e., kermit), when a complete terminal transparency is required.

    -h  Display some help information.

    -i  Use the IDEA cipher. For the crypto impaired, IDEA has a 64-bit block size for the plaintext and the ciphertext. It uses a key size of 128 bits. It is based on the design concept of ``mixing operations from different algebraic groups''. It has been developed at ETH in Zurich by James L. Massey and Xuejia Lai, and published in 1990. It is estimated that the workload to exhaust all the possible 128-bit keys in the IDEA cipher would roughly equal the factoring workload to crack a 3100-bit RSA key, which is quite a bit bigger than the 1024-bit RSA key size that most people use for high security applications. IDEA is resistant to differential and related-key cryptanalysis, and it could be significantly more secure than DES. However, it is not nearly so well-studied as DES. This is why triple DES remains the default encryption method.

    -l username
        Set the user login name on the remote host to username The default name is the current account name of the user invoking

    -m  Set Diffie-Hellman key exchange algorithm's modulo to 512 bits. Diffie-Hellman is used by stel for sharing a secret between client and server. The DH algorithm gets its security from the difficulty of calculating discrete logarithms in a finite field, as compared with the ease of calculating exponentiation in the same field. 512 bits are considered the minimum size for achieving a minimum security level. stel uses, in fact, 1024 as default. The size of the modulus severely impacts the speed of the authentication process, so this option is merely suggested when sitting at or connecting to a very slow system.

    -M  Set Diffie-Hellman key exchange algorithm's modulo to 2048 bits. 2048 bits should be enough for the most security demanding contexts. When using this option on slow systems, stel timeouts before the authentication phase completes, so use -M when when sitting at and connecting to fast systems.

    -n  Do not use data encryption at all. This is intended to be a debugging only option; when this option is set stel loses most of its security strength. Do not use it for real connections.

    -p port
        Use a non standard port number. If -p is not used, stel attempts to contact a STEL server at the standard STEL port that is, 10005 or the one described by the stel service.

    -r  Enhance randomness. When this option is set, the user is asked to type in a reasonably long random string, which is passed, among with other internal random information, through a strong hash function (MD5), in order to distill randomness. By default, stel generates internal random information by means of system dependent information (such as processes, frequently changing file's time stamps, internal variables) and by means of the truerand package.

    -t  Do not allocate a pseudo terminal on the remote system. Normally stel allocates a pseudo terminal on the remote system, since standard shell sessions require it. This option can be handy when executing non-interactive commands on the remote system. When this option is set, it is not possible, for the STEL server, to turn off printing while passwords are being typed in. Use this option with care.

    -v  Be verbose. When this option is set, some debugging information, internal variables and encryption keys are displayed. Encryption session keys are effectively visibile on to the screen, so use this option with care.

USER AUTHENTICATION
Basically, stel supports three authentication methods: SecurID, s/key and Unix passwords. The three systems are checked in order. If the user is SecurID registered, by means of then SecurID authentication is required. Else, if the user is s/key registered, by means of /etc/skeykeys or remotely, by means of the skeyd s/key daemon and the /etc/skeydconf configuration file, then s/key authentication is required. Users can be forced not to use standard passwords, by means of the /etc/skey.access configuration file. Unix passwords are considered the last resort authentication method. However, being all data transmissions encrypted, even standard Unix password offer a reasonable level of security. Finally, all logging-in users are checked against which controls access from the network.

MUTUAL AUTHENTICATION
stel uses the Diffie-Hellman exponential based method to determine a common encryption key. This completely eliminates the need of keyservers to store and manage user keys and it greatly simplifies the overall system design. The Diffie-Hellman method does not require any a-priori shared secret between the parties. The algorithm is based on the difficulty of factoring in finite fields, and the protocol is very clever and very simple. However, it provides no authentication between the two parties. A malicious hacker using an active line tap could intercept and change all messages, impersonating the client to the server and the server to the client. The client and the server would not realize that; for example, all messages sent by the client to the server would be received by the hacker, decrypted by the hacker using the client's session key, encrypted again using the server's session key and sent to the server. This is what is commonly called Man In The Middle Attack. To defeat such an attack, a system based on the Interlock Protocol (an idea by Shamir and Rivest) is supported by If the user wishing to login on the remote system owns a file named .stelsecret in his/her remote home directory then the information contained in the file is exploited to perform mutual authentication between the parties. Similarly, system to system mutual authentication is provided by means of which applies to all users of the system. It is desiderable to keep the contents of .stelsecret and /etc/stelsecret files confidential, since mutual authentication depends on them. It is up to the user to protect his/her file while it is up to the adminitrator to protect eventually by making stel a SUID program and chown-ing /etc/stelsecret to the UID stel is SUID to. stel attempts, in fact, to act safely in case it has been made a SUID program. The syntax of ~/.stelsecret and /etc/stelsecret files is as follows:
    hostname1, hostname2, ... , hostN : secret-pass-phrase
secret-pass-phrase is a single string (no spaces) of arbitrary length. Mutual authentication relies upon this secret; maintenance of this secret, and distribution of its contents to remote sites for use when connecting there is left as an exercise for the reader. The suggested way for doing this is logging to the remote system's console and editing the file. hostname1 is a host name optionally expressed in dotted notation or by means of regular expressions. Supported regular expressions are ``*'', ``?'' and ``[]''. For example:
    sun-[ab].some.domain.org
matches sun-a.some.domain.org and system-b.some.domain.org , while
    *.some.domain.org
matches all systems in the *.some.domain.org domain . DOTS (``.'') are never matched by ``*'' or ``?'', so *.some.domain.org does not match this.one.domain.org or this.other.one.domain.org. A sample, one line, stelsecret file may look like this:
    work[123].domain.edu,10.20.30.4?,*.big.net:some-secret
When someone connects to a STEL server as username, the server checks /etc/stelsecret and username's secret files on the server system. If a match between the user's source address and any host address contained in the secret files occurs, the logging-in user is required to type in the corresponding secret. The typed-in secret is verified by means of a strengthened version of the Interlock Protocol which is supposed to foil the Man In The Middle Attack completely.

ENVIRONMENT
The following environment variables are inherited by the server:
The following environment variables are set by the server, upon the logging-in user being authenticated:
The user is also provided with a new environment variable, which is a one-way hashing of the actual session key. The environment variable is checked and it is used when generating s/key reponses by means of the MJR DES-padding method. Refer to for details.

ESCAPE FEATURES
The escape menu is enabled by hitting the escape character once the connection between client and server has been established. Escape features include experimental ftp-like file transfer commands ( ), a command, a command, and s/key response generation commands ( ). The command detects s/key prompts and automatically generates and sends s/key responses. A special s/key operation mode, MJR DES padding, is available. MJR DES padding mode is supposed to foil s/key dictionary attacks. Use of these commands should be straightforward.

SECURITY OF STEL
The security of stel depends on different factor. They are the strength of the encryption algorithms , the strength of the Diffie-Hellman key exchange method, the strength of the random number generator, the strength of the underlying protocol , the correctness of the implementation (that is, bugs! ) and, last but not least, the Human Factor(tm) , which is universally known to be one of the crucial factors for all security systems. The encryption algorithms used by stel are considered to be the state of the art algorithms available today. RC4 is not intented for real secure communications, since it is too new and untested, and rumors about alleged weak keys families are enough for most security demanding users to stay away from it. On the the other hand, RC4 is very fast, and it is handy when connecting to or sitting at a very slow computer, or for file transfers. IDEA is supposed to be very strong, and most cryptographers are today betting on it. But the algorithm is new, and there could be some devastating cryptanalytic news about IDEA tomorrow. Single DES is a well-known and well-built algorithm, and it is still secure, unless you need your secrets to be protected from the efforts of the major governments and organizations. The default encryption method, that is triple DES which three different pseudo-independent keys, is much stronger than single DES. The first and third key are really independent and unrelated keys, and the second key is generated using the IDEA cipher and the other two keys. Being considered the Meet In The Middle Attack , it is supposed that triple DES encryption is at least as secure as one might naively expect double DES encryption to be (112 bits effective key space). RC4, single DES, triple DES and IDEA are used in 8-bit 8-bit Cipher FeedBack mode, since data streams are typically to be processed in byte-sized chunks. The Diffie-Hellman method is so simple that everyone can trust it at first sight. Diffie-Hellman gets its security from the difficulty of calculating discrete logarithms in a finite field. The size of the field is reasonably large, with 1024 bits as the default size, and 512 bits or 2048 bits as alternative sizes. 512 bits are only intended to be used when sitting at or connecting to a very slow system. According to the publicly known best algorithms for finding discrete logs in GF(p), 1024 bits are secure enough for protecting information in the next few years. stel uses fixed fields, and this is a disadvantage, since the main amount of cryptoanalytic efforts needed to crack Diffie-Hellman has to be done only once per field. Also, it uses a fixed low exponent as generator, that is the number 3, and this has been found to be dangerous due the Hastead attack. To prevent the mentioned attack, stel uses random padding for initial data transmissions, so it should never happen to encrypt the same message under different keys (a condition for the Hastead attack to succeed). The most practical attack against Diffie-Hellman is, however, a Man In The Middle Attack. Being protocol publicly available and getting the active attacks techniques more and more advanced, it would no be hard, for a malicious hacker, to impersonate the logging-in user to the STEL server and vice versa, as described above. Mutual authentication foils impersonation, and it is highly suggested when high security is required. Random numbers are generated by ``distilling'' randomness from unpredictable, but low entropy, information. That is, MD5 is used to transform such information into pseudo random bit strings. Low entropy information is composed by system dependent information, by output and, eventually, by a random string the user is required to type in (by means of the -r option). Random numbers are crucial to the security of They are, in fact, used for randomizing data streams, for generating random Diffie-Hellman exchanges (and thus generating encryption session keys), for performing mutual authentication. protocol will be described in a forthcoming Internet Draft. Security bugs are an open question. stel is a new tool, and it has not been extensively tested yet. Bugs should be reported to or to To subscribe to the list, contact The Human Factor(tm) is often what weakens a security system most. The choice and management of the mutual authentication secrets are, for instance, some of the most critical aspects of The use of one-time password based authentication method is recomended, since shoulder surfing attacks, X server spoofing, and tampering with local applications are well known, elementary attacks. Still, it should be remembered that s/key is vulnerable to dictionary attacks, so it is advisable to choose strong s/key seeds or make use of the MJR DES-padding method. Care should be taken when entering sensitive data or passwords. Albeit the communication channel is always encrypted with it is not really safe to send passwords or other authenticating reusable information to the remote party. When generating s/key responses, it is recomended to use the built-in s/key response generator. When stel prompts the user with something like then all typed-in data are not trasmitted to the remote party, and it is thus safe to enter s/key passwords for generating s/key responses. Upon establishing a connection, a banner is displayed. All subsequent typed-in data are transmitted to the remote party, unless the local prompt is displayed. Please note the local prompt's PID: it should never change in a stel session. If it does, you are being spoofed.

DIAGNOSTIC
stel reports errors via syslog and, when applicable, via standard output.

AUTHOR
David Vincenzetti <vince@idea.sec.dsi.unimi.it>, Stefano Taino <taino@idea.sec.dsi.unimi.it> and Fabio Bolognesi <bolo@idea.sec.dsi.unimi.it>.

CREDITS
Thanks to all stel beta testers, for they excellent job in testing and providing fixes. Special thanks to: Wietse Venema, Marcus J. Ranum, The _H*bbit, Giordano Pezzoli, Paul Leyland, Tom Dunigan, Mark C. Henderson, Uri Blumenthal.

SEE ALSO
steld(1), skeyd(1), skey.access(5), skey.access, login.access, securid.conf, skeydconf MJR-SKEY-MODE