[4918] in Kerberos
Re: terminal server questions
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Mon Apr 3 17:37:52 1995
To: kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 03 Apr 1995 16:19:34 GMT."
<bbosenD6Gw0M.Cq4@netcom.com>
Date: Mon, 03 Apr 1995 17:24:18 -0400
From: "Donald T. Davis" <don@cam.ov.com>
Stephen Tittel wrote:
st: In general, how do people solve authentication of users working only with
st: a terminal? Is it possible that a PC connected with the terminal server
st: handles all the Kerberos request between the terminal and the Krb server?
Bob Bosen replied:
bb: ... the path between the terminal and the nearest Kerberized application
bb: is probably going to be unsecure... [you can] implement a non-replayable
bb: user authentication system that relies on something in the possession of
bb: the user, such as a super-smart card authenticator.
this is the second time this idea has come up recently
(the first was in the recent securid revival), so i'd
like to comment on this notion that smartcards can protect
terminal access to kerberized networks. smartcard proponents
claim that such a scheme will allow the user to log in
without exposing a password to eavesdropping. i suggest that
this particular combination of smartcards with kerberos
is nevertheless a bad idea, because only the login step
will be protected, and because in such a setup, the user's
kerberos credentials will be vulnerable to abuse.
i'm really concerned here with terminal links that are not secure
enough for the traffic they're carrying, as with wireless modems
or insecure telnet sessions. i'm not as worried about normal phone
lines, unless the application's data are particularly sensitive.
in such a setup, the insecure tty link will still be insecure
after the user has logged in; kerberos can do nothing to protect
the tty link. this means that anything that the terminal receives
can be eavesdropped, and it also means that an attacker can insert
commands as if the user had typed them. so far, this is just like
an insecure network with smartcard-mediated login: passwords aren't
travelling in the clear, but connections are still vulnerable.
the presence of kerberos introduces two problems, though:
1) because the attacker has full control of the tty's keyboard,
he also has control of the user's kerberos credentials,
even though he can't necessarily steal them outright. the
only thing he can't do in the user's name is log in at will.
2) if the kerberized applications encrypt sensitive data,
users and administrators will tend to entrust sensitive data
to the applications, and will forget that the tty links are
completely unprotected. after all, the smartcard will seem
very secure.
thus, krb + tty adds faith in security, with adding security itself.
both problems are particularly disastrous for admin sessions.
on the whole, the network would be better off if you installed
just a smartcard system, and left kerberos out of the picture,
until the terminals are replaced with krb-capable pc's or
workstations.
here are some steps to help make smartcards + tty + krb work:
1) enforce access-controls on sensitive data, so as to block tty
access. this is only necessary for data that get encrypted
transport from the server to the client.
2) grant only AS tickets, but not TGS tickets, to tty users,
so that they have to use the card for every service connection
they make. this is a hassle for tty users, but it limits an
attacker to the servers that the legitimate user has requested.
3) forbid administrative access via tty.
if you don't do these things, then you're just using kerberos as
window-dressing, and you're wasting the money and effort you've
invested in it.
-don davis, boston
