Twenty Year Anniversary


Posted Dec 21, 1999


tags | encryption
MD5 | ee8438e1a2541198d61e0a004e615b15


Change Mirror Download
<title>SRP: Telnet and FTP</title>
<body fgcolor="#000000" bgcolor="#FFFFFF">
<h1>The Stanford Telnet/FTP Package</h1>
Stanford is starting to phase out insecure remote login software that
sends passwords in the clear over the network.
As a result of recent
<a href="">computer security incidents</a>
involving network eavesdropping attacks, and partly as a result of an effort
by the <a href="">Internet Engineering Task Force</a>
and <a href="">working groups</a> 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 <b>SRP</b> Telnet and FTP package
available to students, faculty, and staff.
<a href="">SRP</a> is an authentication
technology designed at the
<a href="">Stanford Computer Science Department</a>
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
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 <code>/etc/shadow</code>-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:
<li>SRP defeats "password sniffing" attacks. An eavesdropper listening
in on a session with SRP authentication never sees the user's password
being sent over the network. This by itself addresses a significant
vulnerability in existing remote login software.
<li>Protection against simple password sniffing is not necessarily
enough. With utilities such as "crack", intruders can also perform
what is known as a "dictionary attack". Instead of sniffing the password
directly, such intruders can sniff an entire login session, and then run
that information through their "dictionary" of common passwords.
Even systems like Kerberos are known to be vulnerable to these attacks.
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.
<li>SRP is completely transparent to the end-user. There is no concept
of "keyrings", "certificates", or "tickets" to worry about.
<b>Your password is your key.</b>
SRP simply protects this key better than older, weaker mechanisms.
<li>SRP is also easy to implement from the administrator's point of
view. There is no concept of "key servers", "Verisign certificates",
or "authentication servers". The SRP password file sits alongside the
standard UNIX password file, and the software by default keeps the two
automatically in sync. Nothing else is needed to maintain the system.
<li>SRP exchanges an encryption key in the process of authenticating
a user. This means that the login session can be encrypted to protect
it from eavesdropping and malicious tampering. Users who read their
e-mail remotely will appreciate the confidentiality afforded by strong
128-bit encryption, which is in most cases turned on automatically as
the user logs in.
<h2>How it works</h2>
The details of how SRP itself works can be found at the
<a href="">SRP Website</a>.
You can find both an
<a href="">on-line description</a>
of the protocol, as well as a published
<a href="">technical white paper</a>
describing the authentication mechanism in detail.
The Stanford Telnet suite is implemented as an extension of the
standard Telnet protocol, as described in <a href="rfc854.txt">RFC 854</a>.
[For more information on Internet RFCs, or Request for Comments,
visit the <a href="">IETF</a> 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
<a href="rfc1416.txt">RFC 1416</a>.
For those readers familiar with this mechanism, SRP has its own
<a href="">option
number</a> assigned to it by the <a href="">IANA</a>.
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
Please see the Internet-Drafts for the <a href="">SRP Authentication Protocol</a> and
the <a href="">SRP Telnet Authentication Option</a> for details.
Rather than requiring users to remember the names and command-line
options of additional commands, like <code>kinit -t</code> or
<code>ssh</code>, the SRP Telnet package allows users to stick
with the familiar <code>telnet <i>hostname</i></code> 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: <i>(Password is typed locally)</i>
[ SRP authentication successful ]
[ Output is now encrypted with type CAST128_CFB64 ] <i>(Encryption enabled)</i>
[ Input is now decrypted with type CAST128_CFB64 ]
Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996
xenon$ <i>(User now has a secure session)</i>
Astute readers will note that the SRP package uses the 128-bit CAST
encryption algorithm by default.
CAST-128 is described in <a href="rfc2144.txt">RFC 2144</a>.
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
<h2>Earlier efforts</h2>
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.
<dt><a href="">SRA Telnet</a></dt>
<dd>Developed at <a href="">Texas A&M University</a>,
this version of Telnet also used the Authentication option of
<a href="rfc1416.txt">RFC 1416</a>.
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.
<dt><a href="">Stel</a></dt>
<dd>Developed at the <a href=""</a>University of Milan</a>
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"
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.
<dt><a href="">SSH</a></dt>
<dd>SSH is a utility that provides secure logins and remote command
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
<a href="">technical paper</a>
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
<dt><a href="">SPX</a>,
<a href="">SSLtelnet</a>,
<a href="">Kerberos</a>
<dd>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.
<dt><a href="">S/Key</a>,
<a href="">OPIE</a>,
and other one-time password systems
<dd>In general, one-time-password (OTP) systems offer only one deployment
advantage over alternatives: Client software does not need to be
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
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
<dt><a href="">deslogin</a></dt>
<dd>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 <code>/etc/passwd</code> or <code>/etc/shadow</code>,
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
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.
<h2>Getting the software</h2>
The Stanford Telnet/FTP suite is available on a wide variety of platforms,
with more to come.
The following Unix plaforms are supported:
<li>Solaris 2.x/SPARC
<li>Solaris 2.x/i386
<li>SunOS 4.x/SPARC
<li>SGI IRIX 5.2, 5.3, 6.x/MIPS
<li>DEC OSF/1 2.x, 3.x/Alpha
<li>DEC Ultrix 4.x
<li>HP-UX 9.x, 10.x
<li>Linux 1.x, 2.x/i386
A Windows 95/NT Telnet client is also available, along with
an experimental Java implementation.
The distribution is available in two parts:
<dt><a href="download.html#eps">Exponential Password Suite (EPS)</a></dt>
<dd>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
<a href="">paper</a>).
The EPS utilities replace the <code>passwd</code>, <code>login</code>,
and <code>su</code> commands with versions that consult and maintain
the exponential-format password file.
This password file is used by the server-side authentication daemons
<code>telnetd</code> and <code>ftpd</code>.
The EPS utilities can be <a href="download.html#eps">downloaded</a>
freely without export restrictions.
<dt><a href="download.html#srp">SRP Utilities</a></dt>
<dd>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
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 <a href="download.html#srp">download</a> 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 <a href="download.html">download page</a>.
People outside the U.S. may download an
international version which performs authentication only.
<a href="download.html#src">Source code</a> for the entire package is
available directly to members of the Stanford community and by request
to U.S. and Canadian citizens.
<a href="index.html">Back</a>


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

November 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    10 Files
  • 2
    Nov 2nd
    15 Files
  • 3
    Nov 3rd
    2 Files
  • 4
    Nov 4th
    2 Files
  • 5
    Nov 5th
    32 Files
  • 6
    Nov 6th
    27 Files
  • 7
    Nov 7th
    8 Files
  • 8
    Nov 8th
    9 Files
  • 9
    Nov 9th
    17 Files
  • 10
    Nov 10th
    2 Files
  • 11
    Nov 11th
    2 Files
  • 12
    Nov 12th
    33 Files
  • 13
    Nov 13th
    29 Files
  • 14
    Nov 14th
    23 Files
  • 15
    Nov 15th
    45 Files
  • 16
    Nov 16th
    11 Files
  • 17
    Nov 17th
    0 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2018 Packet Storm. All rights reserved.

Security Services
Hosting By