Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  RSA Encryption on the Internet
Summary: Kerberos addresses this
Message-ID: <29046@bu-cs.BU.EDU>
Date: 29 Mar 89 19:03:38 GMT
References: <8903222040.AA03642@braden.isi.edu> <10061@bloom-beacon.MIT.EDU> <7432@phoenix.Princeton.EDU> <10159@bloom-beacon.MIT.EDU>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Distribution: usa
Organization: Boston U. Information Technology
Lines: 45

In article <10159@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
>
>Nope, you can't do it with just one directory server.  You still need
>something additional to provide trustability of the public key someone
>hands you, and that something can not be just a simple
>public-key-signed handshake, because any such handshake assumes you
>already know the other guys' key.  There is no point in worrying about
>security of encryption algorithms until you can solve the distribution
>problem. 
>
>----Don Alvarez,   boomer@space.mit.edu


	I'm not an expert on Kerberos, but I have been reading up on
it and it seems to me that it addresses this particular problem.
Kerberos uses DES keys, but conceptually I think that this model could
be used with RSA algorithms.

	You first have to authenticate yourself to Kerberos by sending
your username to a Kerberos authentication server.  This creates a
"ticket" [Kerberos terminology] that is encrypted so the user cannot
alter it.  This ticket is used by the user to gain further tickets
from the ticket-granting server (step two).  This ticket and some
other information is further encrypted with a key derived from your
password.  This is sent back to the user.
	The user then enters his password into the workstation and a
decryption key is derived and the ticket-granting-server ticket is
produced. 
	Further transactions are conducted without user intervention
or re-entering of password with the ticket-granting server for session
keys for use of networks services.
	There are time-outs on session keys and the
ticket-granting-server ticket to limit exposure.  The user password is
only required in the system for the time it takes to decrypt the
authentication response.
	I think this addresses most of the issues that have been
raised in this thread.
	Following all these Kerberos tickets around can give you
brain-pain, but everything is transparent to the user.  In fact, you
only login to Kerberos, not every machine on the net, so user
perception of service is improved over rlogin w/o .rhosts.
	Kerberos can be used only for authenticating the start of a
connection, like Athena uses for Kerberos NFS, or it can be used to
authenticate every message, or it can be used to encrypt messages.
You choose your level of security and performance hit.
	Neat stuff in other words.