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.
SRP takes password security a step further by resisting such dictionary attacks. The algorithm is structured in such a way that an attacker would have to perform an impossibly large computation before he could even begin such an attack. SRP even protects passwords against what is known as an "active" attack, so even attackers with the ability to interfere with network operations cannot break SRP. Thus, even users with easily-guessed passwords are protected from attack over the network.
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 xenon.stanford.edu Trying 171.64.64.24... Connected to xenon.stanford.edu. 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.
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.
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, 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.
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.
/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.
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.
The distribution is available in two parts:
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.
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.