head	1.10;
access;
symbols;
locks
	vince:1.10; strict;
comment	@# @;


1.10
date	95.05.01.18.28.42;	author vince;	state Exp;
branches;
next	1.9;

1.9
date	95.05.01.10.47.31;	author vince;	state Exp;
branches;
next	1.8;

1.8
date	95.05.01.10.42.14;	author vince;	state Exp;
branches;
next	1.7;

1.7
date	95.05.01.10.31.49;	author vince;	state Exp;
branches;
next	1.6;

1.6
date	95.05.01.10.19.30;	author vince;	state Exp;
branches;
next	1.5;

1.5
date	95.05.01.10.01.39;	author vince;	state Exp;
branches;
next	1.4;

1.4
date	95.04.29.15.54.20;	author vince;	state Exp;
branches;
next	1.3;

1.3
date	95.04.29.14.59.07;	author vince;	state Exp;
branches;
next	1.2;

1.2
date	95.04.28.17.16.40;	author vince;	state Exp;
branches;
next	1.1;

1.1
date	95.04.28.17.08.20;	author vince;	state Exp;
branches;
next	;


desc
@@


1.10
log
@safety
@
text
@
**********************************
 1. WHAT IS THIS README FILE FOR?
**********************************

This is a quick and dirty guide to compiling, configuring,
installing and using STEL. This guide is intended to be used
by STEL beta testers only. We apologize for the poor quality of
this guide, but we have very little time lately and we hope to
provide better documentation in the official release.

Anyway, before starting to install stel please read the extended
abstract carefully. This will help you understand how stel
works and you will save time and energies in your beta testers
efforts!



****************************************************
 2. WHAT DO STEL's AUTHORS EXPECT FROM BETATESTERS?
****************************************************

What we would like the beta testers (that is, YOU) to do is:

	o	DO NOT distribute this version of stel! Please
		don't. Distributing a beta version of stel will
		increase confusion and make our goal to provide
		the Internet with a good tool harder.

	o	test stel extensively, trying all stel's options,
		all encryption modes, all configuration settings.
		send comments, flames, remarks, and bug reports
		(not necessarily in this order!) to the following
		address:

			stel-authors@@idea.sec.dsi.unimi.it
		
		Also, a mailing list has been set. All beta testers
		have been subscribed automatically to the list.  It is
		possibile to reach all the beta testers by using the
		following address:

			stel-list@@idea.sec.dsi.unimi.it
		
		Please use the latter address with care, since more
		than 90 people are subscribed to the list.  Write to
		stel-list only if you feel that something should really
		be known by all the testers.

	o	if you are a system administrator, install stel in
		your system(s) and let your users play with it. Collect
		their comments and bug reports, and send them to the
		above addresses (again, please use stel-list with care).

	o	please try to follow your personal goal about where to
		port stel to and what kind of test to perform. Please
		keep in mind that you are a selected set of skilled and
		experienced users. Most of you have higly specialized
		skills: it is important that you do not duplicate your
		efforts and take advantage of your most particular skills
		(i.e., a crypto guy should not cope too much with
		interface details or with porting details).
	
	o	please try hard to solve a problem yourself before
		writing to stel-authors or to stel-list.  If you have
		a problem please read the extended abstract.  If you
		still have a problem, please read the sources. After
		then, feel free to send email to stel-authors. We hope
		to keep all of you up to date about all the bug fixes
		and the patches.  In other words, we will mail to
		stel-list as soon as we receive a new patch from the
		betatesters or we build a patch ourself.
	
	o	last, but not least, please be propositive! We would
		like to hear your ideas, and we would be happy to
		follow your positive suggestions! I.e., if you feel
		that the crypto algorithms should be improved / extended,
		please let us know; if you feel that some more
		authentication techniques should be supported by stel,
		and you have experience with such techniques please
		send us your code and we will be glad to add that to
		stel. You have been selected according to your skills
		and experience; your are surely in the position to suggest
		us how stel should be improved and what to do to make it
		more secure, user friendly, et cetera.




*********************************
 3. WHAT DO THE AUTHORS WILL DO?
*********************************

Stel is a freeware tool, intended to be released in the public domain.
We would like to provide the Internet community a tool as secure,
tested and reliable as possibile. We believe that the quality of
software greatly depends on its testing degree. We will do our best to
improve stel and to fix all the bugs and weaknesses that will be
spotted by beta testing. 

Stel is to appear at the 5th USENIX Security Symposium (June 5-7, 1995).
It will be released by that date if it is ready, that is, it is
reasonably functional and bug free.

All the betatesters names will be included in the ``acknowlegments''
in the final release of stel, and special thanks will be given to
those who have effectively contributed with useful advise, C code and
constructive criticism.



***********************
 4. HOW TO BUILD STEL?
***********************

Stel is composed by different parts:


			stel-dist/
			   |
			   |
	-------------------------------------------------
	|		|		|		|
	|		|		|		|
      libdes/      gmp-1.3.2/         skey/            stel/

All the parts should be compiled in order. Compile libdes first,
then gmp-1.3.2, then skey and finally compile stel.

We used gcc, and GNU make. Using gcc is higly reccomended.
So, if you do not have gcc installed in your system please
take your time, get gcc sources at your nearest GNU mirror site
(eventually, ftp.dsi.unimi.it:/pub/gnu) and install gcc.

LIBDES is Eric Young's DES library, version 3.00 93/10/07.
It is used for DES and 3DES encryption.
This is the first part you have to compile. The Makefile is
original from Eric's distribution. It attempts to create
some executables, and it may fail on some systems in doing so.
If it fails compiling, let us say, des(1), do not worry about that:
you just need the DES library, that is, libdes.a.
We changed one single file: des.h. We just commented out crypt(3)'s
proto definition since it was conflicting with standard protos on
some systems.

GMP-1.3.2 is GNU's Multiprecision Library, version 1.3.2.
We did not touch anything, so just type make and, voila,
you should get libgmp.a. It is a math library needed to do all
the Diffie Hellman calculations.

SKEY is a modified version of the skey package. There are
many differencies betweeen Bellcore's skey package and this one.
This one has many enhancements: it runs well on (all?) little
endian systems, supports ``MJR mode'' to defeat guessing attacks,
supports an skey daemon (skeyd) intended for centralized keys
management in a distributed enviroment. Mode details about
MJR mode are given in skey/README.MJR; more details about
skeyd and skeyd's protocol are given in the extended abstract and
below.
Some files come from Hobbit's skey distribution, MDx files come
from RSA Data Security, Inc.
To compile skey, first go to the Makefile. You may have to slightly
change the Makefile to compile skey on some systems. Please search
``CUSTOMIZE THIS'' marks and edit accordingly.

STEL is where the ``real sources'' live. Some files come from the
logdaemon package by Wietzse Venema, some from The Regents of the
University of California, some from RSA and some from the developers
of the IDEA cipher. In the final release of stel we will give
precise credit to all of the above.
To compile stel, type make; then select your system and type
make <system>. If you port stel to a new system please make sure
to change the makefile accordingly. If you wish to use SecurID
cards for authentication please set $(SDIDIR), $(SDILIB) and define
-DSECURID in the Makefile: changes should be obvious.



***********************************
 5. INSTALLATION AND CONFIGURATION
***********************************

There is no automatic installation.

To install stel, just copy it to your favourite binary directory:

	# cp stel /usr/local/bin/stel
	# chmod 711 !$

eventually, if you want to take advantage of the /etc/stelsecret
experimental feature (see below), you may SUID stel to root
in order to make /etc/stelsecret readable to users:

	# chmod u+s !$

to install steld, just copy it to the daemon directory:

	# cp steld /usr/local/etc/steld

If you want to use steld as a standalone daemon you just need to run it:

	# /usr/local/etc/steld

Otherwise, edit the services and inetd.conf files:

/etc/services:
stel		10005/tcp	# 10005 is the default port number

/etc/inetd.conf:
stel    stream  tcp     nowait  root /usr/local/etc/steld in.steld  -i

Install basic skey tools:

	# cp key keysu skey.init /usr/local/bin
	# chmod 711 /usr/local/bin/key
	# chmod 4711 /usr/local/bin/skey.init

If you plan to use skeyd to centralize keys in a distributed environment,
please install it in the daemon directory:

	# cp skeyd /usr/local/etc/skeyd

then edit the services and inetd.conf files:

/etc/services:
skey		768/tcp	   	# you can use any port number

/etc/inetd.conf:
skey    stream  tcp     nowait  root /usr/local/etc/skeyd in.skeyd

then edit skey'd configuration file, that is, /etc/skeydconf;
skey/skeydconf is a configuration example.

Basically, you have done it.

There are some more configuration files, used for controlling
accesses and authentication methods. Some of the checks come
from Venema's logdaemon package. Please check stel/skey.access.5,
stel/login.access, stel/skey.access and stel/securid.conf.



************
 6. TESTING
************

If using skeyd please test it by means of the skey/try program:

alice% ./try $LOGNAME
[s/key 94 id49821]
Response: SUCH HAAS HYDE BALI RYE FILE
SUCCEEDED
alice%

skey/try tests the networking features of the skey system.
It reads the /etc/skeydconf configuration file and then
attempts to connect to the skey server. Details about skeyd's
protocol are given below.

Now, let us look at stel's options:

alice% stel
STEL: Secure TELnet, BETA -- bugs to stel-authors@@idea.sec.dsi.unimi.it
@@(#) $Id: stel.c,v 1.59 1995/04/22 11:13:50 vince Exp vince $
Usage: stel <hostname> [-l logname] [-p portnum] [-r3imentvD] [commands...]
        hostname:       the system you want to connect to
        -l logname:     the username on the remote system
        -p portnumber:  set port number (default port is 10005)
        -r:             enter a random string to enhance randomness
        -3:             use triple DES encryption (default is single DES)
        -i:             use IDEA encryption (default is DES)
        -m:             use 1024 bits modulus (default is 512 bits)
        -e:             disable escape features (^] is enabled by default)
        -n:             do not use data encryption at all
        -t:             do not use pseudo terminals
        -v:             be verbose
        -D:             be extra verbose
alice%

Let's connect to bob from alice, and use the built in skey calculator
to generate the proper skey response (we assume that steld is
running on bob):

alice% stel bob -v
Connected to bob on port 10005.
Using 512 bits modulus, 511 bits secret key
exchanging keys with DH scheme (can be a lengthy process)...
shared encryption key: 2A55767CFDC92CDE
This session is using single DES encryption for all data transmissions.
Escape character is '^]'.

S/KEY authentication required
s/key 9925 someseed38374472
Response:
stel> skey
Reminder -- Do not use this while logged in via telnet or dial-in
sequence number, seed: 9925 someseed38374472
secret password:
MJR DES padding mode ? y
SIGH OVA PAN BAWL AURA BOND
stel>
SIGH OVA PAN BAWL AURA BOND
You have new mail.
bob% hostname
bob
bob% exit
Connection with bob closed.
alice%

We have used MJR mode for skey password generation. The user is
prompted about MJR mode if the SKEYPADFILE environment variable is set.

Now we connect from alice to bob using IDEA encryption, using 1024
bits DH key exchange, disabling escapes (in case we want to use stel
with kermit, for istance), directly providing a source of randomness.

alice% stel bob -i -m -e -r
Enter a random string: *************************************
Connected to bob.
This session is using IDEA encryption for all data transmissions.
Escape features disabled.

S/KEY authentication required
s/key 9924 someseed38374472
Response: WAIL ALGA HEED BEAT DRUM JESS
bob% hostname
bob
bob% exit
Connection with idea closed.
alice%

Finally, we connect to bob again, taking advantage of the ~/.stelsecret
feature (see the extended abstract and below for more details).
Also, we specify the -D option, to debug what it is going on:

alice% stel bob  -D
Connected to bob on port 10005.
Sending firstack 0x30 to server (unencrypted)
random string: "unames = (HP-UX alice A.09.05 9000/735 A);
time = 799162872; ctime = Sat Apr 29 15:41:12 1995
 pid = 20145; getpgrp = 20145; getppid = 8209;
/etc/passwd dates = (799162872 799083395 799083395);
/dev/tty dates = (799162858 799158792 799158792);
/dev/console dates = (799150136 799154490 799154490);
/tmp dates = (799162853 799162813 799162813);
/usr/tmp dates = (799117321 799160513 799160513);
cwd: /res/usr/vince/src/stel"
digest of random string: DA492CF6302D64B81B78958233488975
first 20 random bytes: 0C9B91807EAEF52979B39B8664D3903776107347
next 20 random bytes : 3FB2094127FE3BB4C8C2C26D3474CF5CB6563E88
next 20 random bytes : 6F30A06D4B876CD81ECE45B43338478E060C6B38
skipped all remaining random bytes (512 bytes in all)
Using 512 bits modulus, 511 bits secret key
exchanging keys with DH scheme (can be a lengthy process)...
x (client secret key):
62591178037534581267639896442963588542975587201177832271012117761246563832602729
96492524929572216995380472588578968634724530002479067844728723308597176026
3**x (client public key):
21110084311183208208483471050298986494568610650248995824022255724055412983920207
60165943004798405010487835695405967344113021999472171220657481018438193109
3**y (server public key):
82280597125440065660190642554857440023966453072210051732485759739151700954362024
4122700041264271770346424368354199809059641097002673984812957178748818524
(3**y)**x (shared secret):
10527739414831776921126893924243669261866155166896582903078389812418376330703003
013196283523964611506220139857641047596570342767636094823589062331562180777
shared encryption key: A848058B03478921
Sending envinfo to server (encrypted)
Read reply from server 0x05 (unencrypted)
.stelsecret mutual authentication required
Enter stelsecret: **************
AX authenticator is equal to E_K(sessionkeyhash), where:
K is a stelsecret derived DES key, equal to: 82C6E480EED05C9E
sessionkeyhash is equal to: 316871A7941325EA
AX authenticator: 4C79C4AF5D3A1543
AX and AY are divided in two halves; AX = AX1|AX2, AY = AY1|AY2
sending AX1: 4C79C4AF
received AY1: EEEB4D3F
sending AX2: 5D3A1543
received AY2: 7DD1F562
AY: EEEB4D3F7DD1F562
AY is double encrypted. We decrypt it before comparing AX with AY
AY (decrypted): 4C79C4AF5D3A1543
AX: 4C79C4AF5D3A1543
AX = AY, authentication succeeded
This session is using single DES encryption for all data transmissions.
Escape character is '^]'.

S/KEY authentication required
s/key 9923 someseed38374472
Response:
stel> skey
Reminder -- Do not use this while logged in via telnet or dial-in
sequence number, seed: 9923 someseed38374472
secret password:
MJR DES padding mode ? y
LACE HUG BET LOB I YOU
stel>
LACE HUG BET LOB I YOU
bob%
bob% date
Sat Apr 29 15:41:37 METDST 1995
bob% hostname
bob
bob% exit
Connection with bob closed.
alice%

Enough!



*********************
 7. STEL's PROTOCOLS
*********************

Stel is not compatible with the standard telnet system; in fact,
it uses its own protocol. The protocol is composed by a number
of steps; they are briefly and higly informally described as follows:

		CLIENT				SERVER

1. alice% stel bob

2. build ``firstack''

3. connect to server			accept connection from client

4. send firstack			receive firstack

first ack is an integer used to transmit the following flags:

	FLG_NO_ENCRYPTION	do no use any encryption
	FLG_USE_IDEA		use IDEA encryption
	FLG_USE_TRIPLE		triple DES
	FLG_LARGE_MODULUS	1024 bits mod
	FLG_BE_VERBOSE		be verbose
	FLG_DEBUG		be very verbose
	FLG_NO_ESCAPE		disable escapes

5. start DH key exchange	start DH key exchange

the basic steps of the DH key exchange are:

	- generate a random buffer based on system dependent randomness
	  and, eventually, user provided randomness
	- use 3DES and MD5 to distill randomness from the random buffer;
	  extract a large random number < modulo
        - calculate 3**random (that is, 3**X)
	- receive 3**random (that is, 3**Y)
	- calculate shared secret (3**XY)
	- MD5 digest the shared secret to extract the session key

6. build ``user packet''

7. encrypt user packet (with session key, of course)

8. send user packet			receive user packet

user packet is a struct; it contains some information about
the user and the upcoming session:

	username
	session modes (only FLG_DONTUSE_PTY is actually supported)
	environment variables (TERM, LINES, COLUMNS, DISPLAY, WINDOWID)
	command to be executed (default is user's shell)
	MD5 checksum
	padding (used for DES CBC)

9.					decrypt user packet

10. receive secondack			send secondack

second ack is an integer; it is used to trasmit the following flags:

	MSG_OKAY_DATA		all right, let us continue
	MSG_CORRUPTED_DATA	communication path is garbled
	MSG_LOGIN_AUTH_REQUIRED	remote user, by means of the username
				field in the user packet, has a
				.stelsecret file in his/her home
				directory. so, mutual authentication is
				required.
	MSG_SYSTEM_AUTH_REQUIRED /etc/stelsecret exists on the system
				where the server is running on. so, mutual
				authentication between system is required.
	MSG_MUST_AUTH		mutual authentication is required by server,
				by means of ~/.stelsecret or /etc/stelsecret,
				but the client has requested to use no
				encryption (FLG_NO_ENCRYPTION is set). so,
				the connection is dropped by the server.


11. if login auth required, do it	if login auth required, do it

12. if system auth required, do it	if system auth required, do it

the basic steps of login mutual authentication (that is, based upon
~/.stelsecret) and system mutual authentication (that is, based upon
/etc/stelsecret) are:

	- read /etc/stelsecret or get ~/.stelsecret from user
	- MD5 digest the secret
	- create authenticator (see extended abstract for details)
	- split authenticator into halves
	- exchange them, one at a time (note: a given plaintext attack
	  is feasible in the current implementation of the protocol.
	  we do not consider that as a serious weakness; however,this
	  step will be slightly changed in the final release of stel)
	- compare authenticators; if different, a man in the middle
	  exists or client's secret does not match server's secret

13. set terminal, start IO		set terminal, start IO

14.					authenticate user

the basic steps of the authentication phase are:

	- if user is defined in /etc/securid.conf then try to
	  authenticate user with SecurID cards
	- else, if user is skey registered, use skey
	- else, if skey.access allows that, use unix passwords
	- upon succeeding, check /etc/login.access

15.					run user's shell or specified command



*********************
 8. SKEYD's PROTOCOL
*********************

The version of skey included in this package takes advantage of
skeyd in order to centralize key management. When skey is compiled
with -DSKEY then the networking features are enabled. When
compiled with -DSKEYINITINSECURE extended networking features are
enabled and skey.init is permitted to init keys using skeyd. In
other words, the -DSKEYINITINSECURE feature enables key initialization
a la skey.init and the skeykeys file is updated without checking
that key Xn is equal to f(Xn-1). Use -DSKEYINITINSECURE with great
caution, and only with systems you trust; by enabling this option you
trust all the clients, that is, the security of the server depends
upon the security of all clients. For istance, if some malicious hacker
gains root privilegies on a client system, he/she can skey.init root
and thus get root access to all the systems in the cluster.

As usual, the protocol is composed by some steps. They are
briefly and higly informally explained as follows:

		CLIENT				SERVER

1. networking is used by means of libskey.a. it is transparent to
   application; if /etc/skeydconf is set then networking is used;
   else local /etc/skeykeys is used as usual. Caveat emptor: the syntax
   of skeylookup() is slightly changed when skey is compiled with
   -DSKEYD

2. read /etc/skeydoconf file. cache it for later perusal.

3. connect to server				accept connection

4. build skeymessage

skey message is a struct. it contains the following information:

	- initialization variable, used for DES CBC
	- operation flag. it is an integer. possible flags:
		GIVEMEINFO
		UPDATEKEYS
		SKEYDOK
		SKEYDFAILED
		FORCEKEYUPDATE (only used #ifdef SKEYINITINSECURE)
	- data buffer, used for challenges, responses
	- MD5 checksum
	- padding, used for DES CBC

5. encrypt skeymessage

6. send skeymessage to server			receive skeymessage

7.						decrypt skeymessage

8.						evaluate skeymessage
						eventually update skeykeys

9.						build skeymessage

10.						encrypt skeymessage

11. receive skeymessage				send skeymessage to client



*******************
 9. ONE FINAL NOTE
*******************

   We, as CERT-IT, really appreciate your interest and your efforts!

		THANK YOU IN ADVANCE!







				stel-authors@@idea.dsi.unimi.it

					David Vincenzetti
					Stefano Taino
					Fabio Bolognesi
@


1.9
log
@safety
@
text
@d3 1
a3 1
 1. WHAT IS THIS REAMDE FILE FOR?
d8 2
a9 2
by STEL beta testers only. I apologize for the poor quality of
this guide, but I have very little time indeed and I hope to
d12 3
a14 3
Anyway, before starting istalling stel please read the extended
abstract carefully. This will help you to understant how stel
works and you will save time and energies in your beta testers's
d33 1
a33 1
		(non necessarly in this order!) to the following
d38 4
a41 4
		Also, a temporary mailing list have been set. All beta
		testers have been automatically subscribed to the
		list. It is possibile to reach all the beta testers
		by using the following address:
d46 3
a48 3
		than 50 people should be subscribed to the list.
		Write to stel-list only if you feel that lsomething
		should really be known by all the testers.
d50 2
a51 2
	o	if you are a system administrators, install stel in
		your system(s) and let your users play with it. collect
d55 8
a62 9
	o	please try to follow author's instructions about
		where to port stel to and what kind of test to
		perform. Please keep in mind that you are a selected
		set of skilled and experienced users. Most of you
		have higly specialized skills: it is important that you
		do not duplicate your efforts and take advantage of
		your most particular skills (i.e., a crypto guy should not
		cope too much with interface details or with porting
		details).
d77 1
a77 1
		that the crypo algorithms should be improved / extended,
d79 2
a80 2
		authentication tecniques should be supported by stel,
		and you have experience with such tecniques please
d82 4
a85 4
		stel. You have selected according to your skills and
		experience; your are surely in the position to suggest
		us how stel should be improved and what to do to make
		it more secure, user friendly, et cetera.
d98 1
a98 1
improve stel and to fix all the bugs and weaknesses that would be
d107 1
a107 1
those who have severely contributed with useful advise, C code and
d152 1
a152 1
many differences betweeen Bellcore's skey package and this one.
d155 1
a155 1
supports a skey daemon (skeyd) intended for centralized keys
d157 1
a157 1
MJR mode and given in skey/REAMDE.MJR; more details about
d160 1
a160 1
Some files come from Hobbit's skey distribution, mdx files come
d170 1
a170 1
previse acknoledgement to all of the above.
d175 1
a175 1
-DSECURID in the Makefile: changes should be obvius.
d185 1
a185 1
To install stel, just copy it to your favorite binary directory:
d191 1
a191 1
experimental feature (see below), you may make stel SUID to root
d200 1
a200 1
If you want to use steld as a standalone you just need to run it:
d218 1
a218 1
If you plan to use skeyd to centralize keys in a distribute environment,
d263 2
a264 2
STEL: Secure TELnet, BETA VERSION -- bugs to stel-beta-test@@dsi.unimi.it
@@(#) $Id: README,v 1.8 1995/05/01 10:42:14 vince Exp vince $
d419 1
a419 1
of steps; they are briefly and higly informaly described as follows:
d431 1
a431 1
first ack is an integer used to trasmit the following flags:
d433 1
a433 1
	FLG_NO_ENCRYPTION	do no use any enmcryption
d509 2
a510 2
	- compare authenticators; if different a man in the middle
	  exists or client's secret does no match server's secret
d540 5
a544 5
care, and only with systems you trust; by enabling this option you
trust all the clients, that is, if some malicious hacker gains
root privilegies on a skeyd client system he/she can skey.init root
and thus get root access to all the systems in the cluster, being
included the server system.
d552 2
a553 2
   application; if /etc/skeydconf is set networking is used; else
   local /etc/skeykeys is used as usual. Caveat emptor: the syntax
d597 3
a599 1
   THANKS IN ADVANCE!
@


1.8
log
@'.
@
text
@d28 1
a28 1
		the Internet with a decent tool harder.
d233 1
a233 1
stel/skeydconf is a copnfiguration example.
d265 1
a265 1
@@(#) $Id: README,v 1.7 1995/05/01 10:31:49 vince Exp vince $
@


1.7
log
@*** empty log message ***
@
text
@d2 3
a4 3
********************************
1. WHAT IS THIS REAMDE FILE FOR?
********************************
d19 3
a21 3
**************************************************
2. WHAT DO STEL's AUTHORS EXPECT FROM BETATESTERS?
**************************************************
d25 5
d33 1
a33 1
		(non necessarily in this order!) to the following
d91 3
a93 3
*******************************
3. WHAT DO THE AUTHORS WILL DO?
*******************************
d113 3
a115 3
***************************************
4. OK, I GOT THAT. HOW TO COMPILE STEL?
***************************************
d180 3
a182 3
*********************************
5. INSTALLATION AND CONFIGURATION
*********************************
d244 3
a246 3
**********
6. TESTING
**********
d265 1
a265 1
@@(#) $Id: README,v 1.4 1995/04/29 15:54:20 vince Exp vince $
d414 3
a416 3
*******************
6. STEL's PROTOCOLS
*******************
d529 3
a531 3
****************
SKEYD's PROTOCOL
****************
d591 20
@


1.6
log
@*** empty log message ***
@
text
@d415 1
a415 1
of steps; they are briefly and informaly described as follows:
d501 4
a504 3
	- exchange them, one at a time (note: a plaintext attack is
	  possibile in the current implementation of the protocol.
	  this stel will be slightly changed in the near future)
d512 1
a512 1
the basic steps of the authnetication phase are:
d517 1
a517 1
	- else, if skey.access allows this, use unix passwords
d520 1
a520 1
15.					run user's shell
d533 1
a533 1
other words, the latter feature enables key initialization
d535 6
a540 1
that key Xn is equal to f(Xn-1).
d543 1
a543 1
briefly explained as follows:
d547 5
a551 1
1. networking is used by means of libskey.a
d553 1
a553 1
2. read /etc/skeydoconf file. cache it
d559 1
a559 1
skey messages contains the following information
d562 8
a569 3
	- operation flag, see below
	- a data buffer, used for challenges, responses
	- MD5 digest of skey message
a570 8

operation flags are:

	GIVEMEINFO
	UPDATEKEYS
	SKEYDOK
	SKEYDFAILED
	FORCEKEYUPDATE (only used #ifdef SKEYINITINSECURE)
@


1.5
log
@*** empty log message ***
@
text
@d73 1
a73 1
		that the crypo algorithm should be improved / extended,
d243 1
a243 2
If using skeyd please test it by means of the try program, in the
skey directory:
d249 1
d251 4
a254 5
Try tests the networking features of the skey system.
It reads the /etc/skeydconf skeyd configuration file then
attempts a connection to the system specified in the
configuration file. More information about skeyd's protocol
are given below.
d256 1
a256 1
Now, let us look at the options:
d274 1
d306 2
a307 2
We have used MJR mode (see above for more info). MJR is available
if the SKEYPADFILE environment variable is set.
d309 3
a311 4
Now we connect from aliace to bob using IDEA encryption, using 1024
bits for perform DH key exchange, disabling escapes (in case we want
to use stel with kermit, for istance), directly providing a source of
randomness.
d314 1
a314 1
Enter a random string:
d329 1
a329 1
feature (see the extended abstract and see below for more details).
d367 1
a367 1
Enter stelsecret:
d405 1
d408 1
d415 1
a415 1
of steps; they are briefly described as follows:
d427 1
a427 1
first ack is used to trasmit the following flags:
d437 1
a437 1
5. DH key exchange		DH key exchange
d439 1
a439 1
the basic steps of the DH phase are:
d443 1
a443 1
	- use 3DES and MD5 to distill randomness from the random buffer
d445 2
a446 2
        - calculate 3**random (3**X)
	- receive 3**random (3**Y)
d448 1
a448 1
	- MD5 digest shared secret and extract sessions keys
d452 1
a452 1
7. encrypt user packet
d456 2
a457 1
user packets contains some information aout the user:
d460 4
a463 4
	environment variables (TERM, LINES, sessionCOLUMNS, DISPLAY, WINDOWID)
	command to be executed
	MD5 digest of user packet
	session modes (only FLG_DONTUSE_PTY for now)
d470 1
a470 1
second ack is used to trasmit the following flags:
d472 2
a473 2
	MSG_OKAY_DATA		all right
	MSG_CORRUPTED_DATA	communication patch is garbles
d477 1
a477 1
				directory. mutual authentication is
d480 7
a486 8
				where the server is running on. mutual
				authentication between system is
				required.
	MSG_MUST_AUTH		mutual authentication is required, by
				means of ~/.stelsecret or /etc/stelsecret,
				but the client has requested not to use
				any encryption (FLG_NO_ENCRYPTION is set).
				the connection is thus dropped by the server.
d493 3
a495 1
the basic steps of the mutual authentication are:
d497 2
a498 2
	- read /etc/stelsecret or ask ~/.stelsecret to user
	- MD5 digest secret
d500 6
a505 5
	- divide authenticator in two halves
	- exchange them, one at a time
	- compare results; if there is a man in the middle then
	  the results (AX, AY) are different. in that case drop
	  the connection
@


1.4
log
@*** empty log message ***
@
text
@d15 1
a15 1
struggles!:-)
d19 3
a21 3
***********************************************
2. WHAT DO THE AUTHORS EXPECT FROM BETATESTERS?
***********************************************
d23 1
a23 1
What we would like the beta testers to do is:
d27 1
a27 1
		send comments, remarks, flames, and but reports
d31 18
a48 1
			stel-beta-test@@dsi.unimi.it
a49 6

	o	if system administrators, install stel to your system(s)
		and let your users play with it. collect their comments
		and bug reports, and send them to the above address


d52 2
a53 2
		perform. The betatesters, that is you, are a selected
		team of skilled and experienced users. Most of you
d56 3
a58 2
		your most selected skills (i.e., a crypto guy should not
		deal with interface design).
d60 9
a68 5

	o	cooperate each the other. All beta testers can be
		reached by means of the following address:

			stel-testers@@idea.sec.dsi.unimi.it
d70 12
a81 12

	o	please try hard to solve a problem yourself before
		writing to stel-beta-test@@dsi.unimi.it (that is, to
		stel's authors) or to stel-testers@@idea.sec.dsi.unimi.it
		(that is, to all betatesters). If you have a problem
		please read the extended abstract.  If you still have
		a problem, please read the sources. After then, feel
		free to send email to the list. I hope to keep all of
		you up to date about all the bug fixes and the patches.
		In other words, I will mail to stel-testers as soon as I
		receive a new patch from the betatesters of write myself
		a patch.
d93 1
a93 1
software often depends on its testing degree. We will do our best to
d101 4
a104 3
All the names the betatesters will be included in the ``Acknowlegments''
and special thanks will be given to those who have effectively
contributed with useful advise, code and constructive criticism.
d108 3
a110 3
*****************************
4. OK, I GOT THAT. WHAT NEXT?
*****************************
d112 1
a112 1
This is the compilation phase.
a113 1
Stel is an integrated package; it is composed by different parts:
a114 1

d126 4
a129 1
I used gcc, and GNU nake. Using gcc is higly reccomended.
d134 1
a134 1
original from Eric's distribution. It appempts to create
d136 5
a140 4
If it fails compiling, let us say, des(1), do not bother: you
just need the DES library, that is, libdes.a.
I changed one single file: des.h. I just commented out crypt(3)'s
proto since it was conflicting with system's on some OSs.
d143 2
a144 2
I did not touch anything, so just type make and, voila,
you should get libgmp.a, a math library needed to do all
d150 2
a151 2
endian systems, run in MJR mode to defeat guessing attacks,
support a key daemon (skeyd), which is intended for keys
d153 8
a160 6
MJR mode and given in skey/REAMDE.MJR, more details about
skeyd and skeyd's protocol are given below.
Some files come from Hobbit, some from RSA Data Security, Inc.
To compile, first go to the Makefile. You may have to
slightly change the Makefile to compile skey on some
systems. Please look for ``CUSTOMIZE THIS'' marks.
d162 1
a162 1
STEL is where the real sources live. Some files come from the
d164 8
a171 6
University of California, some from RSA Data Security, Inc.
To compile, type make; then select your system and type
make <system>. If you do a porting please make sure to change
the makefile accordingly. If you are going to use SecurID
cards with stel please set $(SDIDIR), $(SDILIB) and define
-DSECURID in the Makefile. Changes should be obvius.
d187 1
a187 1
experimental feature (see below), you may set the SUID bit on
d192 1
a192 1
to install steld, just copy it to the system's daemon directory:
d196 1
a196 1
If you want to use steld standalone just run steld in this way:
d200 1
a200 1
Otherwise use inetd and edit the services and inetd.conf files:
d208 1
a208 1
Install skey tools:
a211 1
	# chmod 4711 /usr/local/bin/keysu
d214 2
a215 1
If you want to use skeyd, please install it in the system's daemon directory:
d227 2
a228 19
finally edit skeyd's configuration file, that is, /etc/skeydconf.
This is an example:

#
# If this file exists as /etc/skeydconf then local /etc/skeykeys is no
# longer used: a remote TCP connection to <skeyserver> on port
# <skeyport> is attempted.
#
# The <skeypwd> field specifies a password for DES encryption/authentication.
# The password can be any length and should be the same for all parties,
# that is, clients and server. It is higly advisable to use very lenghty
# pass phrases. A good password could be:
#	
#   This_is_a_Very_str000ng_password_____*###*($*&#IDF*VCCXJDSJDSjjjj
#

skeypwd: somepassword_sldkjsldkjslkdjslkdjslkd
skeyserver: 149.132.3.1
skeyport: 768
d234 2
a235 2
from Venema's logdaemon package. Please check skey.access.5,
login.access and skey.access and securid.conf for more information. 
d261 1
a261 1
@@(#) $Id: stel.c,v 1.59 1995/04/22 11:13:50 vince Exp vince $
@


1.3
log
@*** empty log message ***
@
text
@d9 2
a10 4
this guide, but I had very little time indeed, I hope to provide
better documentations in the official release.  Anyway, before
starting istalling stel please read the extended abstract. This
will help you ti understant stel's protocol and greatly improve
d12 4
d18 1
d497 1
a497 1
13. set terminal, start io		set terminal, start io
d517 48
d566 1
d568 1
@


1.2
log
@*** empty log message ***
@
text
@d2 1
d4 1
d7 2
a8 1
installing and using STEL. I apologize for the poor quality of
d10 3
a12 1
better documentations in the official release. 
d16 1
d18 1
d67 3
a69 1
3. WHAT DO AUTHORS WILL DO?
d88 1
d90 1
d92 2
d103 1
a103 1
      libdes         gmp-1.3.2         skey            stel
d106 1
a106 1
then gmp-1.3.2, then skey and finally stel.
d143 3
a145 1
the makefile accordingly.
d149 3
a151 1
5. ISTALLATION?
d153 1
a153 1
There is no automatic istallation. 
d162 1
a162 1
in orde to make /etc/stelsecret readable to users.
a165 1

d170 346
a515 1
If you want to use steld standalone
@


1.1
log
@Initial revision
@
text
@d63 5
a67 4
We would like to provide the Internet community a tool as debugged
and tested as possible. The quality of software often depends on
its testing degree. We will do our best to improve stel and to
fix all the bugs and weaknesses that would be spotted by beta testing. 
d135 20
@
