[2597] in Kerberos
Re: Kerberos 5 & login
daemon@ATHENA.MIT.EDU (Ganesan)
Thu Feb 25 13:30:47 1993
From: bf4grjc@socrates.MIT.EDU (Ganesan)
To: bcn@ISI.EDU (Clifford Neuman)
Date: Thu, 25 Feb 1993 13:15:50 -0500 (EST)
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: <9302251634.AA10034@tgo.isi.edu> from "Clifford Neuman" at Feb 25, 93 08:34:05 am
Reply-To: bf4grjc@bell-atl.com
Re. Cliff's message...
> I do not know if your comments is related to the message to which it
> is a followup.
Not really. the previous message was related to the login fired up by
say a telnetd, as opposed to user logging into workestation.
(BTW: Ted's suggestion was to find an appropriate login from the
BSD dist. Another alternative, which we used, was to use the Kerberos
Version 4 distribution login, which has the appropriate options. You
do need to change it slightly though)
My question was solely concerned with initial login. What Cliff says
below is
> However, it is important to distinguish between the
> protocol, and the software that implements it. The Kerberos protocol
> as it stands is quite capable of supporting initial login.
technically correct.. BUT
> In particular, you use the password entered by the user to decrypt
> initial credentials, and you then use those credentials to obtain
> subsequent credentials for logging into the local machine.
This above two step "dance" to do what is a very fundamental, very
often used, operation, simply needs to be implemented more cleanly,
perhaps with OPTIONAL additions to the protocol. i.e. I claim that
"in practice", logging into the local machine, is a sufficiently
distinguished process, which ought to be treated differently from
other services.
The biggest threat I see is that, in practice, a vendor who supplies
login/xdm/etc. might well eliminate Step 2 of the dance, leaving
unwary clients (Let the buyer beware?) vulnerable to the "well known"
spoofing problem. On the other hand, if either:
- ONE particular 2-step-dance was standardized.
or
- The protocol modified to optionaly, encrypt the TGT with
a service key to be used only by login/xdm/etc.,
then it is likely that vendors will provide a secure version to begin with.
Further, once X-Terminals, start acquiring local disk space or some sort
of "user-settable" local static storage, they too can implement the same
protocol, and become invulnerable to the spoofing attack.
So I guess what I'm saying is that a little bit of over specifying at the
protocl level, may help deal with problems of when the protocol hits the
software....
Ravi
--
*******************************************************************************
Ravi Ganesan e-mail: ravi@socrates.bell-atl.com
IS SAS Corporate Network Planning v-mail: (301) 595-8439
Bell Atlantic Fax: (301) 595-1341
Note: If your e-mail reply to me bounces, try sending it explicitly to
ravi@socrates.bell-atl.com instead of using the 'reply' feature.
******************************************************************************
