Skip site navigation (1)Skip section navigation (2)
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>