The Stanford Telnet/FTP Package

Stanford is starting to phase out insecure remote login software that sends passwords in the clear over the network. As a result of recent computer security incidents involving network eavesdropping attacks, and partly as a result of an effort by the Internet Engineering Task Force and working groups within the IETF to eliminate cleartext passwords in TCP/IP protocols, Stanford is encouraging users to use software that performs secure password authentication without sending unencrypted passwords over the network.

Currently, the Sweet Hall cluster, which uses Kerberos, can be accessed by the "MacLeland" and "PCLeland" software packages, which can be set up to encrypt login sessions. To log in securely to departmental servers and other systems around campus, Stanford is making the SRP Telnet and FTP package available to students, faculty, and staff. SRP is an authentication technology designed at the Stanford Computer Science Department which provides secure password-based authentication and session encryption without requiring either users or system administrators to become involved in key management or distribution. SRP provides everyone with transparent password security without the expensive overhead that has prevented the deployment of other security suites. Unlike other security packages currently available over the Internet, the SRP suite is designed as a definitive solution for password authentication, not a stopgap measure. Compared to standard /etc/shadow-style security, SRP is better in every way, with no security or deployment disadvantages whatsoever.


The SRP authentication package offers a number of benefits to both users and administrators interested in improved password security:

How it works

The details of how SRP itself works can be found at the SRP Website. You can find both an on-line description of the protocol, as well as a published technical white paper describing the authentication mechanism in detail.

The Stanford Telnet suite is implemented as an extension of the standard Telnet protocol, as described in RFC 854. [For more information on Internet RFCs, or Request for Comments, visit the IETF Website.] This means that the SRP-enabled telnet client and server executables are drop-in replacements for their unsecure counterparts.

Specifically, the SRP Telnet package is implemented as a Telnet authentication option under the framework described in RFC 1416. For those readers familiar with this mechanism, SRP has its own option number assigned to it by the IANA. This framework provides for the automatic negotiation of authentication mechanisms, including SRP, when a Telnet session is initiated. If both sides of the conversation discover that they support SRP, for example, then they will both attempt to authenticate the user using SRP. If either side does not support SRP, then authentication will fall back to either a weaker mechanism or, if that fails, standard cleartext authentication. Please see the Internet-Drafts for the SRP Authentication Protocol and the SRP Telnet Authentication Option for details.

Rather than requiring users to remember the names and command-line options of additional commands, like kinit -t or ssh, the SRP Telnet package allows users to stick with the familiar telnet hostname command, enter their password as usual, and get a secure session. The SRP Telnet is, as explained above, fully compatible with standard Telnet, so it can replace the existing system binaries.

A sample secure Telnet session might look like:

$ telnet
Connected to
Escape character is '^]'.
[ Trying SRP ... ]
*  Unauthorized access to this computer system is prohibited. *
*    Violators are subject to criminal and civil penalties.   *
[ Using 1024-bit modulus for 'tjw' ]
SRP Password:         (Password is typed locally)
[ SRP authentication successful ]
[ Output is now encrypted with type CAST128_CFB64 ]    (Encryption enabled)
[ Input is now decrypted with type CAST128_CFB64 ]
Sun Microsystems Inc.   SunOS 5.5.1     Generic May 1996


xenon$                (User now has a secure session)
Astute readers will note that the SRP package uses the 128-bit CAST encryption algorithm by default. CAST-128 is described in RFC 2144. The Stanford Telnet and FTP package also supports 56-bit DES and 40-bit (exportable) CAST. International distributions of the software may have limited support or even no support at all for encryption, depending on how the software was obtained. All versions of the SRP package, however, support strong authentication with SRP, since authentication by itself is not subject to US export regulations.

Earlier efforts

In the last several years, there have been a number of attempts at creating secure login packages. Here are some of the ones that we're aware of, along with a brief explanation of their relative merits.
SRA Telnet
Developed at Texas A&M University, this version of Telnet also used the Authentication option of RFC 1416. Although this allowed SRA Telnet to function as transparently as SRP Telnet, SRA Telnet had a number of security shortcomings.

The underlying security of SRA was based on an unauthenticated Diffie-Hellman key exchange with a fixed, short modulus (192 bits). This meant that authentication could be compromised either through a man-in-the-middle attack against Diffie-Hellman, or it could be broken by computing discrete logs against the 192-bit modulus, which would require at most a few hours of CPU time on a personal computer. It also did not encrypt the contents of the session itself, so it was still vulnerable to TCP session-hijacking attacks. SRA was intended to serve only as temporary solution to the rampant problem of password-sniffing at Texas A&M.

Of all the older packages presented here, SRA Telnet was the easiest to deploy, since it required no change in users' behavior and minimal system modification. Unfortunately, this transparency was accompanied by imperfect security, a necessary consequence of the underlying technology and one that is squarely addressed by SRP.

Developed at the University of Milan in Italy, Stel was designed as a completely new remote login protocol, claiming to offer secure authentication and session encryption. Like SRA Telnet, Stel was written to cope with the problem of password-sniffing over insecure networks.

Unfortunately, Stel still suffers from both security weaknesses and deployment limitations. As far as security is concerned, Stel uses nothing more than an unauthenticated Diffie-Hellman key exchange to set up a "secure" session. Although Stel allows a longer modulus than SRA, it is still fundamentally limited in strength by the underlying protocol. For example, it is still vulnerable to man-in-the-middle attacks. Stel tries to alleviate this problem with a predistributed secrets file, but this only changes the problem into a deployment issue.

As far as deployment is concerned, the Stel protocol is completely incompatible with standard Telnet, requiring users to memorize a new command and a new set of command line options. To protect against man-in-the-middle attacks, Stel employs the interlock protocol, which then requires users to have a secret file in their home directory that is shared between hosts beforehand. Of course, Stel doesn't offer any way for the user to distribute this file securely, since that would require a secure channel in the first place - a nice Catch-22. One can always fall back on floppy disks, but that seems like quite a bit of trouble for a little bit of security.

Stel by itself does not do authentication; instead it passes the buck and sends the password down the supposedly secure connection. When used with standard Unix authentication (probably the most common scenario), this is susceptible to server-side password capturing attacks, as described later. Indeed, the Stel Web page describes Stel as a "band-aid" solution, intended only for short-term security.

SSH is a utility that provides secure logins and remote command execution. Designed as a replacement for the rlogin/rsh commands, SSH uses the RSA cryptosystem along with host-based keys to implement secure connections.

SSH, while believed to be fairly secure, also suffers from a number of deployment problems that have limited its widespread use. The only real security problem with SSH is that it still sends passwords directly to the host over the secure connection. Since people have a tendency to share passwords between hosts, an attacker who has compromised one host can set up a Trojan horse server to capture incoming passwords and try those passwords on other hosts. Since the SRP protocol is zero-knowledge (see the technical paper for details), the SRP authentication suite is immune to this attack. The only way to get around this problem is to have SSH generate a password-protected RSA keypair. As usual, this security feature moves the problem into the deployment arena, because the user now has to push his public and/or private keys around manually from system to system.

Deployment-wise, SSH runs into a few more snags. Part of the SSH protocol involves the client receiving a copy of the host's public key. To reduce the threat of public-key-spoofing attacks, SSH requires that the client store a copy of each server's public key, usually in a user's home directory. While this may seem minor initially, keep in mind that these keys take up about 1K each and stay around effectively forever. If each user uses SSH to connect to a handful of hosts, it is not inconceivable that this may consume many megabytes of storage on a system. The problem gets worse in kiosk-style environments, since nearly all connections will be first-time connections, so the threat of key spoofing goes up along with key storage requirements.

Although SSH avoids US export restrictions by being developed outside the US, it uses RSA technology, which is patented within the US. A US company that wants to deploy an SSH-based product faces a two-pronged problem: Export restrictions prevent it from distributing the SSH-compliant code outside the US, and RSA would require a BSAFE license. In fairness, export regulations would hinder distribution of SRP with encryption enabled. However, SRP can perform secure authentication in the absence of encryption, while SSH depends on encryption to protect the cleartext passwords.

SPX, SSLtelnet, Kerberos
These products, while offering varying levels of security, all suffer from the problem of dependence on some kind of external certification or key-distribution infrastructure. This deployment issue alone makes these packages unacceptable in many situations and precludes their consideration as definitive replacements for general-purpose secure logins. They will not be considered further.

S/Key, OPIE, and other one-time password systems
In general, one-time-password (OTP) systems offer only one deployment advantage over alternatives: Client software does not need to be modified. However, this advantage is more than offset by a number of deployment and security disadvantages.

OTP systems do not enable any form of session encryption, so there is no confidentiality, which can be problematic if one wishes to read private e-mail or log in to another remote system within the first session. This also leaves the session vulnerable to TCP session hijacking. In addition, all current OTP systems are susceptible to brute-force guessing attacks against the initial, user-supplied password.

One of the big deployment difficulties is maintaining the big list of one-time passwords. Some systems require users to carry this list on paper, which is an obvious nuisance. Others employ a hand-held OTP "calculator" that generates the passwords on-the-fly, but carrying around this hardware is still inconvenient and adds a per-user cost to the system. The best solution is to have the password-calculator built-in to the remote login software, but now that destroys the only deployment advantage of OTP, which was the ability to function without modified client software.

Finally, the user needs to obtain another list of passwords when s/he runs out of OTPs. This problem is made worse by applications that perform automated authentication, which can exhaust even a long list of OTPs relatively quickly. These issues are enough to make OTP a non-starter in most remote access environments.

Deslogin is a remote login package that uses the DES encryption algorithm to perform password authentication and session encryption. As an alternative to cleartext password authentication, the deslogin protocol has two major shortcomings. The password file, unlike /etc/passwd or /etc/shadow, contains users' cleartext passwords, so it must be handled very carefully to avoid compromising the entire system. The protocol is also vulnerable to an eavesdropper dictionary attack. Since deslogin is not compatible with the standard Telnet protocol, users need to remember one command to access deslogin-protected systems and a different command for all other hosts.
Although all of the earlier attempts at creating a secure remote login suite were improvements over cleartext password authentication in at least one way, many of them introduced additional vulnerabilities (e.g. cleartext password storage), and all of them are either easily compromised, difficult to deploy, or both. The greatest difficulty is achieving complete transparency - allowing users to use the same software in the same way as they did before - while offering complete security against a variety of network attacks. While some of the offerings provided a way for users to obtain fairly bulletproof security, getting that level of security required users to engage in manual key- or bit-fiddling. Without technology like SRP, password-based solutions inevitably turn into a game of security-through-obscurity, which works in the short term but cannot withstand long-term scrutiny.

The Stanford suite, by contrast, offers users only one fundamental choice: Maximal password security with no key management. Users authenticate with their usual passwords and obtain security equivalent to that of using a full-blown secure public-key setup. There are no utilities or options for managing private keys, because they are not needed and would not add any additional security to the system. It is a system like this, which improves upon traditional authentication in every possible way, that has the potential to replace existing authentication mechanisms in their entirety, with virtually no user involvement or re-education.

Getting the software

The Stanford Telnet/FTP suite is available on a wide variety of platforms, with more to come. The following Unix plaforms are supported: A Windows 95/NT Telnet client is also available, along with an experimental Java implementation.

The distribution is available in two parts:

Exponential Password Suite (EPS)
The EPS is a suite of utilities that manage a password file in the format used by the SRP tools. Specifically, it generates password entries by hashing and salting the username and password and then performing a modular exponentiation in a predetermined prime field (for details, read the paper). The EPS utilities replace the passwd, login, and su commands with versions that consult and maintain the exponential-format password file. This password file is used by the server-side authentication daemons telnetd and ftpd.

The EPS utilities can be downloaded freely without export restrictions.

SRP Utilities
The SRP package consists of the Telnet and FTP clients and servers. While the clients may be used standalone as drop-in replacements for their insecure counterparts, the servers require that the EPS be installed in order to perform secure authentication.

Since the SRP utilities can be configured to enable session encryption, they fall under export control regulations of the US government. People within Stanford may download the US version of the SRP utilities with strong encryption. U.S./Canadian citizens outside Stanford should send a written request via e-mail, as explained on the download page.

People outside the U.S. may download an international version which performs authentication only.

Source code for the entire package is available directly to members of the Stanford community and by request to U.S. and Canadian citizens.