Date: Fri, 21 Apr 1995 10:21:38 -0400 (EDT) From: william pechter ILEX <pechter@stars.sed.monmouth.army.mil> To: jkh@freefall.cdrom.com Subject: Telnet Message-ID: <199504211421.HAA08118@freefall.cdrom.com> Resent-Message-ID: <22289.798502504@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
>From firewalls-owner@GreatCircle.COM Thu Apr 20 19:46:08 1995
>From: David Vincenzetti <vince@dsi.unimi.it>
>Subject: STEL: Secure TELnet -- Call for Beta Testers
To: firewalls@greatcircle.com
Date: Tue, 18 Apr 1995 16:34:39 +0200 (METDST)
X-Organization: Department of Computer Science, University of Milan, ITALY
X-Name: David Vincenzetti <vince@dsi.unimi.it>
X-Phone: +39 2 55006 391
X-Fax: +39 2 55006 394
X-Private: +39 2 7530600
X-Pgp-Key-Fingerprint: BC 78 16 B2 07 CC BF 26 8D B8 5D FA 1A A4 65 63
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 17837
Sender: firewalls-owner@GreatCircle.COM
Precedence: bulk
Jordan --
My wife forwarded this to me:
I know you were looking for an encrypting telnet.
Thanks again for all you're doing on FreeBSD. Even though my machine's
not among the stable it IS APPRECIATED.
Bill
*******************************************
STEL (SECURE TELNET): CALL FOR BETA TESTERS
*******************************************
1. WHY CALLING BETA TESTERS?
We, as CERT-IT, have developed STEL (Secure TELnet), a new
freeware tool which is intended as a secure telnet program.
We hope to present stel at the 5th USENIX Security Symposium
(Salt Lake City, Utah, June 5-7 1995).
Before releasing stel to the public we want to be sure that
it is reasonably correct and bug free. So, we are looking
for a limited number of beta testers.
2. MORE INFORMATION ABOUT STEL?
Stel is a small and compact tool able to provide encryption
and authentication using a variety of methods and algorithms.
More details are given below (please see ``INTRODUCTION'').
3. IS STEL AVAILABLE?
YES, it is available.
But is it still undocumented and unsupported, so it is now
available to beta testers ONLY.
4. WHERE HAS STEL BEEN PORTED TO?
Stel has already been ported to the following platforms:
HPUX 9.x
Sunos 4.1.3x
Solaris 2.4
Irix 4.0.x
Linux 1.5.x
We would be higly interested in seeing stel ported to other
platforms as well!
4. HOW TO BECOME A STEL BETA TESTER?
We are looking for a limited number of beta testers, whose
skills and experience should be as follows:
o good experience with Unix and TCP/IP
o some expertise in C/Unix programming (having developed
C/Unix network tools is considered as a BIG bonus).
o experience with system and network administration
o good experience with some of the most popular crypto
related protocols and tools such as S/Key, Crack,
Tripwire, SRA, PGP, PEM et cetera. Please let us know
if you have any experience with other similar tools.
o knowledge of the basic weaknesses / strenghts about
DES, IDEA, RSA, DH, EKE is considered as a bonus.
o experience with firewalls, IP packet filtering, strong
authentication tecniques, proxies and gateways is
considered as a bonus.
If you think that you have the required skills please send
email to:
stel-beta-test@dsi.unimi.it
Please be sure to send us a very brief resume (not more than
10 lines) about your skills and experiences. In particular,
we are interested in knowing about your PRACTICAL experiences
in security, networking, cryptography and incident handling.
Being a member of the FIRST (Forum of Incident Response Security
Teams) is considered as a bonus.
STEL: Secure TELnet
David Vincenzetti
Stefano Taino
Fabio Bolognesi
{vince | taino | bolo}@dsi.unimi.it
CERT-IT
Computer Emergency Response Team ITaliano
Department of Computer Science
University of Milan
ITALY
INTRODUCTION
Stel stands for Secure TELnet. We started developing Stel,
at the University of Milan, when we realized that eavesdropping
was a very serious problem and we did not like the freeware solutions
that were available at that time. It was about three years ago.
Still, as far as we know, there are no really satisfying packages
able to solve the line active and passing tapping problem, and to be
simple enough to use and to maintain by the average system administrator.
In fact, in our honest opinion, we believe that the actual security
packages available on the Internet suffer from at least one of the
following drawbacks:
- Not secure enough
- Too large and complicated to install
- Too complex to use and maintain
- Unable to scale well in a distributed environment
- Subject to severe export regulations, so not
suitable for users outside the United States
Stel is a simple package, and it is intended to act as a ``secure
surrogate replacement'' for telnetd, rlogind, rcmd or rshd.
[...]
Stel is able to provide secure communications between the client and
the server, and supports different authentications methods, in order
to be as simple, flexible and convenient as possibile.
Stel has several advantages in respect to other systems:
- It is very simple to install, use and maintain. There are
very few configuration files and two executables only
- All data transmissions, any kind, are sent encrypted
with a ``random'' session key
- There are three encryption algorithms available: DES,
Triple DES and IDEA
- The method uses the Diffie Hellman algorithm to exchange
session keys, and the DH modulus is reasonably sized
compared with other packages (see [4])
- Since the Diffie Hellman system is vulnerable to ``Man In
The Middle'' attacks, the protocol has been strenghtened
in order to make such an attack unfeasible (as described
in [1])
- The method is able to provide mutual authentication
- The method is reasonably fast (it adds about a couple
of seconds to a connection on a Sparcstation II class machine)
- Upon establishing a secure channel, a variety of authentication
methods are available: standard Unix passwords, S/Key and
SecurID. Even standard Unix passwords, being the communication
channel encrypted, provide a reasonable level of security in
respect to telnet and rlogin
- An optional skey daemon is included in the package. Skeyd
makes it possible to centralize skey passwords in order to
administer passwords in a single point
- It is possible to control logins by checking IP address,
authentication type, terminal name, user name,
as described in [2]
- Automatic killing of IP-OPTIONS is an option
- A built-in skey calculator is included in the escape (^]) menu.
As a feature, skey can make use of a keypad file to make
dictionary attacks unfeasible, an idea described in [3]
- The software is freeware, and sources are freely available
PRACTICAL EXAMPLES
Stel is client / server based. The client is named
``stel'', and it is intended to be directly run by users; the
server is named ``steld'' and can be run as a standalone
daemon by the superuser or be invoked by inetd.
The purpose of stel is to provide the user a remote terminal
session, very similar to a telnet or rlogin remote terminal
session. The difference is, of course, that all the traffic
between client and server is encrypted and that the resulting
authentication is much stronger in respect to telnet or rlogin.
In the following example the user connects with stel to
idea.sec.dsi.unimi.it as root. The authentication is performed
using SecurID smart card, being root a registered SecurID user on idea.
$ stel idea.sec.dsi.unimi.it -l root
Connected to idea.sec.dsi.unimi.it.
This session is using DES encryption for all data transmissions.
Escape character is '^]'.
SECURID authentication required
Enter PASSCODE for root:
Passcode accepted.
******************
Welcome to idea!
******************
idea# hostname
idea
idea# date
Fri Feb 10 17:33:27 MET 1995
idea# exit
Connection with idea.sec.dsi.unimi.it closed.
$
$
So, the user has stel-connected to idea.sec.dsi.unimi.it and he/she
has authenticated his/herself using SecurID. All data transmission
are DES (optionally 3DES or IDEA) encrypted with a session key that
is generated with the DH algorithm.
When the user is authenticated he/she is provided with a very
comprehensive set of environment variables that are inherited from the
client, and all the terminal settings are inherited from the client as
well. For instance, since the DISPLAY, LINES and COLUMNS environment
variables are inherited in the remote session, it is possible to
remotely execute commands like these:
$ stel bar xterm -fn 10x20 -bg black -fg white
$ stel foo -l root vi /etc/rc
$ stel somesite -l joe "ps aux > /tmp/xx; vi /tmp/xx"
In the following example the user ``verbosely'' connects to ghost as
vince and specifies /bin/csh as the command to be executed. The
authentication is performed using S/Key.
$
$ stel ghost -l vince -v /bin/csh
Connected to ghost on port 10004.
Diffie-Hellman modulo is 512 bits, secret exponent is 510 bits
Exchanging keys with DH scheme (can be a lengthy process)...
Shared encryption key: CAA90477A9CEA71D
This session is using DES encryption for all data transmissions.
Escape character is '^]'.
S/KEY authentication required
[s/key 93 cr520201]
Response: drub barb nod ret coco outs
SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:48:35 PDT 1993
1 @ghost ~ > hostname
ghost
2 @ghost ~ > exit
Connection with ghost closed.
$
$
$
In the last example, the user connects to idea again, and makes use of
some features in the escape menu. In particular, he/she takes advantage
of the built-int skey calculator to locally (and thus safely) generate
the required skey response.
$ stel idea
Connected to idea.
This session is using DES encryption for all data transmissions.
Escape character is '^]'.
S/KEY authentication required
[s/key 92 cr520201]
Response:
stel> ?
Commands may be abbreviated. Commands are:
close close current connection
skey generate skey response
status display operating parameters
escape set escape character
! shell escape
z suspend telnet
? print help information
stel> stat
Connected to idea.
Connection time: Fri Feb 10 19:07:42 1995
Elapsed time: 0 hours, 0 minutes, 47 seconds
User keystrokes: 1
Session output is 62 bytes
Escape character is '^]'
DES data encryption is on
stel> skey
Reminder - Do not use this while logged in via telnet or dial-in.
Enter seed: cr520201
enter sequence number: 92
enter secret password:
use mjr DES mode [n] ? y
CORD AD FLY FEAR NAY ARAB
stel>
CORD AD FLY FEAR NAY ARAB
******************
Welcome to idea!
******************
idea% date
Fri Feb 10 19:11:16 MET 1995
idea% hostname
idea
idea%
idea% exit
Connection with idea closed.
$
THE PROTOCOL
The protocol can be divided in different modules:
1. Key exchange
Stel uses the Diffie Hellman exponential based method to
determine a common DES (or 3DES, IDEA) key. This completely
eliminates the need of keyservers to store and manage user keys,
and it greatly simplifies the overall system design.
The principles of the method are shown in figure 1.
Initially, client and server, whom we call X and Y being
the system symmetric, share a large prime number, P, and
a generator, that is 3. Then both parties choose a secret value,
making the choice at random among the set of values in modulo
P arithmetic. The length of the modulo can be 512 or 1024
bits. Moduli whose length is 192 bits (see [4]), or, in general,
smaller than 512 bits, are not secure.
In the next stage, X and Y form the exponentials 3**x and
3**y respectively, and they exchange the exponentials.
A malicious hacker could intercept 3**x and 3**y by
reading the network but, due the difficulty of computing
logarithms in finite fields (see [1], [4]), he/she can not
calculate the x, y values.
In the final stage, X and Y compute a further exponential.
In the case of X the received value 3**y is raised to
the power x. In the case of Y, the received value 3**x
is raised to the power y. As a consequence, both partecipants
now share the same secret, thus a session key is generated
by digesting the shared value through MD5.
|-----------|-------------|---------------|--------------|
| | Known to X | Public | Known to Y |
| | | | |
|-----------|-------------|---------------|--------------|
| Initially | x | 3, P | y |
| | | | |
|-----------|-------------|---------------|--------------|
| Exchange | 3**x ------->------->------> 3**x |
| | | | |
| | 3**y <------<-------<------- 3**y |
| | | | |
| | | 3**x, 3**y | |
|-----------|-------------|---------------|--------------|
| Calculate | (3**y)**x | | (3**x)**y |
|-----------|-------------|---------------|--------------|
Figure 1.
2. Mutual authentication
The basic DH method is very clever, but it provides no
authentication between the two parties. A malicious hacker Z using
an active line tap could intercept and change all messages,
impersonating X to Y and Y to X. X and Y would not realize that;
for example, all messages sent by X to Y would be received by Z,
the Man In The Middle, decrypted by Z using X's session key,
encrypted again using Y's session key and sent to Y. X and Y
would share different session keys, yet not realizing
that because they have exchanged no information before
key exchange.
This is why we added a further step to the protocol in order to
make this attack ineffective.
If the user wishing to login on the remote system owns
a file named ``.stelsecret'' in his/her remote home directory
then the information K contained in the file is exploited to
perform mutual authentication between the parties. This is
an idea by Shamir and Rivest (see [1]).
X and Y construct authenticators AX and AY respectively.
Let AX be equal to E_K(X's session key) that is, X's session
key DES encrypted using K as encryption key.
Let AY be equal to E_K(E_K(Y's session key)), that is, Y's session
key encrypted twice using K as encryption key.
In case Z is actively tapping the communication line, the
sessions keys used by the parties are different. What is
more, Z does not know K. The goal of this authentication step
is, in fact, to verify that the sessions keys are the same at
both sides.
AX and AY are divided in two halves. Let AX be equal
to AX1 followed by AX2 and AY be equal to AY1 followed
by AY2.
The exchange is by alternating messages: X sends its
first half AX1, Y replies with AY1, then X sends AX2
and Y sends AY2. It is not possible for Z to translate
AX1, knowing only half of the cipher block, yet Y will
not reply until he/she receives something, so Z is forced
to concoct a value AX in order to receive AY.
Y's reply cannot be traslated by Z and passed on at the
correct time to X, since Z only receives one half of AY
at a time. After the exchange is complete X and Y
can decrypt the authenticators AY and AX respectively and
find out if they are really sharing the same session key.
If not, they are being impersonated by Z.
3. Encryption
All data transmitted from the client to the server
and vice versa is encrypted using the specified encryption
algorithm. The default algorithm is single DES, since it is
faster, but triple DES and IDEA are available as well.
DES is used in CBC mode when transmitting environment
variables or exchanging ``large numbers'' in the DH scheme.
CFB mode is used when making terminal I/O between client and
server. A ``random'' Initialization Variable is used, and the
source of randomness is, optionally, a garbage random string
which the user is required to type in.
4. Environment settings
A pseudo terminal is usually allocated by the server and
attached to the remote process; it is possible, however,
to specify that no pseudo terminal should be used in the
remote session, a la rshd.
Terminal settings are transmitted encrypted from the
client to the server, so it is not usually needed to
``stty'' parameters at all.
[...]
5. User authentication
It has been said already that there are three authentication
methods available. These methods can be listed according
to their security, in decreasing order:
1. SecurID
2. S/Key
3. Unix passwords
[...]
An optional skey daemon has been introduced, to administer
all skey passwords on a single host. We consider the
unability to centralize skey passwords as a major
need in the skey system. Skeyd severely simplifies skey
passwords management, since passwords are stored in a single
file and thus the passwords synchronization problem is
solved.
Data transmission between skey clients and the skey server
is DES-CBC encrypted. The encryption key is stored in
/etc/skeydconf, for all the clients and the server
(this is an approach common to other security systems,
i.e., Kerberos's kdb5_stash).
[...]
The three methods are checked in order. If the
user is SecurID registered, then SecurID authentication
is required. Else, if the user is S/Key registered he/she
is prompted with an S/Key challenge. If the user is not
S/Key registered, Unix passwords are used but, before that,
username is checked against a set of rules as defined in
/etc/skey.access. It is possible, in fact, to permit /
deny Unix passwords using a wide range of criteria, as
described in [2]. Finally, when the user is authenticated,
his/her username is checked against /etc/login.access to
control login using similar criteria.
Stel verbosely reports errors and login failures via syslog.
REFERENCES
[1] ``Security for Computer Networks'', D.W. Davies and L. Price
[2] The logdaemon package, by Wietse Venema <wietse@wzv.win.tue.nl>,
available as ftp://ftp.win.tue.nl/security/logdaemon-4.6.tar.gz
[3] A modification of the S/key client program by Marcus J. Ranum
<mjr@tis.com> to make dictionary attacks infeasible. Available
as ftp://ftp.tis.com/pub/firewalls/toolkit/patches/skey.tar.Z
[4] ``Computation of Discrete Logarithms in Prime Fields'',
Brian A. La Macchia and Adrew M. Odlyzko, available as
ftp://ftp.dsi.unimi.it/pub/security/crypt/docs/field.ps
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQBVAgUBL5PK1Sw4rhUX5imVAQEGIwIAwbd1FAJK5gYqpiqYKCrOGkzY2c5Ww2Ez
CTpyULHAzL3p6+/wCZlg6QyhVrrtauLA4wO7hCRF1b+WEWxdbRKrwQ==
=53th
-----END PGP SIGNATURE-----
Carolyn Pechter (908)530-7766 x415 cpechter@sesd.ilex.com
Ilex Systems, Inc (908) 532-1886/2130 pechterc@sun.sed.monmouth.army.mil
__________________________________________________________________________
identity crisis? what identity crisis?
I'm the "other" Carolyn, and the "other" Pechter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504211421.HAA08118>