[1722] in Kerberos
Re: protocol question
daemon@ATHENA.MIT.EDU (marantz@cs.rutgers.edu)
Thu Jan 16 17:06:16 1992
Date: Thu, 16 Jan 92 16:15:07 EST
From: marantz@cs.rutgers.edu
To: tytso@Athena.MIT.EDU
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: <9201162101.AA05291@tsx-11.MIT.EDU> (tytso@athena.mit.edu)
Oh I think I see. The ENC-TKT-IN-SKEY only encrypts the new ticket in
the SKEY and since that new ticket is unknown to the pwdauthd it
doesn't help. I thought something that the caller (pwdauthd) knows
would have also been encrypted in the SKEY. Then pwdauthd could have
checked that and assumed the ticket was valid iff the info was valid.
Oh well back to the drawing board :-)
Roy
Date: Thu, 16 Jan 92 16:01:51 -0500
From: tytso@athena.mit.edu (Theodore Ts'o)
Reply-To: tytso@athena.mit.edu
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 16 Jan 92 12:22:20 EST
From: marantz@cs.rutgers.edu
I thought (now I see that isn't default, I'd need to set
ENC-TKT-IN-SKEY) that I could get the reply (or at least a part of it)
encrypted in my key which a bogus TGS shouldn't know. [If it does
know my key then I'm lost anyway] I'd use the encrypted stuff to
verify the TGS to me and then be able to believe the ticket for the
user.
No, the problem is this: how does the pwauthd know that it's been
encrypted in "your key"? All it can tell is whether or not it's been
encrypted in the password which some entity has typed into the login
screen. If the attacker controls what's being typed into your keyboard
and what the bogus TGS sends, he/she will be able to login your system.
Now, if your system is a public workstation ala Project Athena, where
the root password is public knowledge and anyone could throw the power
switch and boot in single user mode anyway, this may not be a big deal.
However, if this login program is running on your master source machine
or some other machine which has important information on its local hard
disks, you don't want to do this. It is a very bad idea.
- Ted
