[3674] in Kerberos
Re: S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (Thor Lancelot Simon)
Mon Aug 8 18:29:55 1994
To: kerberos@MIT.EDU
Date: 8 Aug 1994 17:53:58 -0400
From: tls@panix.com (Thor Lancelot Simon)
In article <199408081629.AA02609@cym.isi.edu>,
Clifford Neuman <bcn@ISI.EDU> wrote:
>
>The advantage of integration of S/Key (or any other one time passcode
>mechanisms including your stored X0 example) and Kerberos is that the
>passphrase changes, so that a spoofed kinit does not provide an
>attacker with information that may be used to perform subsequent
>initial authentication as the user. When integrated with S/Key, the
I don't see this as the substantial win in using s/key to obtain Kerberos
tickets.
I work in an environment in which *I* am in a position to securely use
Kerberos, but the vast majority of the customers I support aren't. They
either telnet in to our machines or dial in to our terminal servers. With
the exception of our IP customers (a minority), almost all of our users can be
assumed to be on dumb terminals or equivalent.
And as we all know, dumb terminals and Kerberos don't mix. So far as I know,
when I'm in Boston and dial 258-7096 to talk to the Athena terminal servers,
logging in to any Athena machine leaves my password floating out there
cleartext on the wire for all to see.
Panix is in a similar situation. A much larger problem than password exposure
by spoofed kinit is *password exposure cleartext on the network* -- the very
problem Kerberos was intended to solve!
But since dumb terminals don't speak Kerberos, there are a lot of users out
there for whom Kerberos is at best a partial solution, and at worst a
deceptive placebo.
Providing a method of acquiring a TGT using S/KEY would solve this problem.
--
Thor Lancelot Simon tls@panix.COM
But as he knew no bad language, he had called him all the names of common
objects that he could think of, and had screamed: "You lamp! You towel! You
plate!" and so on. --Sigmund Freud
