[4911] in Kerberos
Re: Proposal for a SmartCard-Kerberos Implementation
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Sat Apr 1 23:26:35 1995
To: Mike Muuss <mike@arl.mil>
Cc: don@cam.ov.com, kerberos@MIT.EDU
In-Reply-To: Your message of "Fri, 31 Mar 1995 19:19:10 EST."
<9503311919.aa14850@wolf.arl.mil>
Date: Sat, 01 Apr 1995 23:17:52 -0500
From: "Donald T. Davis" <don@cam.ov.com>
mike muuss writes:
> How do you propose accessing a Kerberos-capable host ... from a
> non-Kerberos machine, such as when attending a conference..., or
> when using a PC to run regular TELNET? ... A single-use password
> ... is a *must* to enter the realm, in that case.
you're mistaken in two ways, here:
1. kerberos cannot protect you if you don't have a local krb client.
in that situation, token + krb is no stronger than the token alone.
in fact, i argue that token + krb is weaker than the token alone
in this situation, because it confers the tgs' single-signon
flexibility on a client whose integrity can't be trusted.
2. it's not a good idea to use the securid display to encrypt the
kerberos credentials, anyway, because 10^8 keys is too small a
keyspace to prevent guessing attacks.
if it weren't for the keyspace problem (#2 above), your scheme
would be ok for granting non-tgs access to "no-privacy" services.
for example, if your nfs servers didn't support encrypted transfer,
and if the user had to use his card anew for each server he called,
and if securid cards had 18-digit displays, then it'd be ok for
securid-card-holders to come in from insecure sites.
as it is, though, giving insecure users tgs access, or access to
privacy services, would be a bad idea. if an attacker gets control
of the insecure link between the user and his tickets & keys,
the attacker will have control of those tickets and keys.
in short, i argue that the problem you want to solve, of extending
kerberos access to insecure clients who lack kerberos, not only can't
be solved, but shouldn't be solved. if a client can only use securid
or some other "encryptionless" authentication scheme to access a
krb-secured net, that client should be denied access to any service
(including the tgs) that requires privacy encryption. if you want
your net to give access to clients that support securid, your
servers should support securid, too. the result won't be as secure
as if you'd installed krb everywhere, but maybe for you, the extra
flexibility you'll gain is worth that sacrifice.
i realize that my hard line sounds impractical, but the fact is
that kerberos, like the other security systems, was designed to be
pervasive. when you try to daisy-chain pieces of different security
technologies together like this, you're violating important design
constraints, and the security holes you introduce can be subtle.
btw, when i worked at openvision (and before), i did work on
securid/krb integration, but it wasn't for the purpose you describe.
also, when i worked at athena, i designed part of the krb v5 protocol,
and i helped implement the v5 server. i currently do not work for
openvision (despite my e-mail address), and i don't speak for ov.
-don davis, boston
