Tech Insider					     Technology and Trends

		      Kerberos Mailing List Archives

From mtc@ATHENA.MIT.EDU  Tue Jun  3 17:14:23 1986
To: geer, bcn, spm
Cc: charlie, saltzer, noah, jis
Subject: Kerberos Support for Remote Services, Project Description (long)
Date: Tue, 03 Jun 86 17:12:41 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>


	I have been asked to put Kerberos support into the remote services
	rlogin, rsh, and rcp.  The task has evolved as I have proceeded;
	therefore, the purpose of this project is to document what I'm
	doing with this project, to identify and resolve conflicts with what 
	other people think should be done, and to give a status report on
	the project.  
	Comments on this report are encouraged.

	A feature of my approach is that it requires a new port number for
	the Kerberos-authenticated services.  These port numbers should
	be assigned by SRI-NIC so that they can become "well-known"; if
	we do not do this, it may break rlogin to foreign hosts (ie, if
	the host thinks the port means something other than Kerberos).

The Problem

	In the Athena environment we lose control over the administration of
	individual workstations.  This fact allows a workstation user to
	capitalize on a hole in the rlogin (etc) "host trusting" mechanism,
	possibly to destructive ends, assuming that the user has the root 
	password for the workstation, which is likely.

	For example, I (mtc) have the machines I use regularly set up to
	trust each other.  "menelaus" is a VAX750 and "goanna" is my uVax II
	workstation.  If goanna goes down, it creates an opportunity for an
	evil hacker to use any workstation to masquerade as mtc logged in on
	goanna: all he has to do is name the workstation "goanna" and create
	an account for "mtc", then rlogin to menelaus.  Menelaus cannot tell
	that the hacker is not me, and because of the way I have trusting set
	up, allows the hacker full access to my menelaus resources.  The only
	alternative to this security hole that exists now is removal of 
	"trusting" from my ~/.rhosts file; this causes the nuisance of having 
	to type my password each time I begin an rlogin session.

The Solution

	Kerberos can be used to prevent this kind of illicit access.  To
	start an authenticated rlogin session, a user creates a set of encrypted 
	tickets (via vxlogin) that absolutely identify him to a remote host.
	With this kind of security, it is possible to trust a session, since
	Kerberos can detect tampering, re-use, etc, of the tickets.

Goals of the Project

	The services to be modified to use Kerberos authentication are rlogin,
	rsh, and rcp.  The changes must be made in such a way as to not break
	the existing function for use without Kerberos.  For example, for the
	rlogin service:

	1) An external user (eg, on a client without Kerberos) must still
	   be able to rlogin to a Kerberos host, provided that that host
	   is set up to allow the access.
	2) A user of a Kerberos host must be able to rlogin to a host 
	   that does not support Kerberos.
	A change to the format of the ~/.rhosts and /etc/hosts.equiv files
	have been proposed to allow some new flexibility in tailoring the
	Kerberos environment; these changes are described later.

	Since these services make use of a few common routines for setting up
	the connection, changes should be made to those routines which can be
	used by all targeted services.  The changes will be the minimum required
	to support authentication, to avoid breaking any other existing functions.

Changes to Permission Control Files

	Steve Miller suggested some changes to the format of the files ~/.rhosts
	and /etc/hosts.equiv for better tailoring to the Kerberos environment.
	These files allow users to rlogin without typing their password for
	each session.  Currently, the files can contain two types of specification:

	host				trust all users from the specified host
	host username		trust username from the specified host

	The proposed extensions use a special cookie, "*krb*", to indicate that
	the control applies to Kerberos logins:

	*krb*				allow Kerberos-authenticated logins from any
						user on any host.
	host *krb*			allow Kerberos-authenticated logins from any
						user on the specified host.
	host user *krb*		allow Kerberos-authenticated logins from the
						specified user on the specified host.

	At the moment, an authenticated rlogin now works without these extensions; 
	it is governed by the same restrictions as a non-kerberos login.  The main 
	difference between the authenticated and non-authenticated login is that 
	we have closed the hole of doubt as to the clients true identity.  However,
	a remote user can still gain access without authentication by using the
	standard version of rlogin.

	What the proposed extensions provide is flexibility in restricting access.
	For example, a workstation in building E40 might be willing to trust any
	workstation or host in E40 with or without Kerberos authentication, but 
	require others to authenticate their sessions.  The /etc/hosts.equiv file 
	spec is:

	(other hosts and workstations)

Changes to rlogin protocol

	Continue to support the normal rlogin protocol:

	Add alternate protocol for Kerberos support:

		KTEXT object		# count in text form, a space, and count chars
							# of the Kerberos text string.

	Note that the Kerberos protocol does not explicitly supply the 
	lusername; this is taken from the authenticated data enclosed in the
	KTEXT structure.

Changes to rcmd.c

	Added a new argument, a pointer to a KTEXT object, which controls
	the type of protocol used by remote services.  If the pointer is NULL, 
	use the normal protocol; if it points to a KTEXT object, use the
	Kerberos protocol via SendKerberosTicket().

	New routine SendKerberosTicket() sends a KTEXT structure across the
	connection from the client to the server.

	New routine GetKerberosData() snarfs the KTEXT sent by SendKerberosTicket()
	and uses rd_ap_req to extract the AUTH_DAT from the KTEXT object.
	The remote username (ie client's local username) is translated by
	antoln and returned.

	ruserok() (and its subordinate routines) will be changed to extend
	the function of /etc/hosts.equiv and ~/.rhosts, as described earlier.

Changes to rlogin.c

	Find the port number for a Kerberos login session (from /etc/services).  
	If not found, punt the Kerberos login session and try normal rlogin.  
	Otherwise, create a KTEXT object and fill it in (via mk_ap_req).

	Attempt connection to the remote host using the Kerberos port, by
	means of rcmd() with a pointer to the KTEXT object.  If the connection 
	fails, punt the Kerberos login session, release the KTEXT object, and 
	try the normal login.

	If the Kerberos login failed, find the port number for a normal
	login session.  Attempt the connection via rcmd(), using NULL for
	the KTEXT object.

Changes to rlogind.c

	Look at the command name.  If its "rlogind", spawn "login -r fromhost"
	as before.  If its "klogind", spawn "login -k fromhost" to get
	login to expect the Kerberos protocol.

Changes to login.c

	Check for the presence of "-k".  Allow only one of: "-r -h or -k"
	(instead of the first two only).  If "-r" is found, call doremotelogin()
	as before.  If "-k" is found, call doKerberosLogin() instead, to use
	the modified rlogin protocol.

	Add new routine doKerberosLogin().  It snarfs a KTEXT object off of
	the connection stream via GetKerberosData() (see rcmd.c).  Then gets
	the lusername (ie, rusername sent by rlogin) and terminal characteristics.
	ruserok() is called as before (for the time being, until the Kerberos
	extensions to /etc/hosts.equiv are implemented), but using the lusername
	enclosed in the KTEXT, which is known to be authentic.

Changes to rsh.c

	Will be changed analogous to the changes to rlogin.c.

Changes to rshd.c

	Will be changed analogous to the changes to rlogind.c and login.c.

Changes to rcp.c

	Will be changed analogous to the changes to rlogin.c.

Current Status

	rlogin now works with Kerberos authentication, and does not break
	existing function.  It is complete except for the changes to ruserok.

	Work remaining: modify rsh, rshd and rcp to use the new version
	of rcmd() etc.

			      USENET Archives

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 

Electronic mail:			       WorldWideWeb: