[4898] in Kerberos
Re: Proposal for a SmartCard-Kerberos Implementation
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Fri Mar 31 16:48:24 1995
To: John Hascall <john@iastate.edu>
Cc: kdrenard@arl.mil, kerberos@MIT.EDU
In-Reply-To: Your message of "Fri, 31 Mar 1995 07:57:48 CST."
<9503311357.AA22557@pooh.cc.iastate.edu>
Date: Fri, 31 Mar 1995 16:39:00 -0500
From: "Donald T. Davis" <don@cam.ov.com>
i wrote:
> securID codes are not suitable by themselves for use as encryption
> keys, because with an 8 digit display, or even with a few digits
> of PIN added, they're too short to prevent exhaustive key-search.
hascall responded:
Didn't know their length -- they could be used
in conjuction with the key from the srvtab (say by
replacing the lower half of the key bits).
me:
client-side srvtabs defeat krb's purpose: to avoid keeping long-lived
secrets on insecure machines, where they can be stolen. it also ties
the user to the cpu on which his secret resides.
hascall:
Or you could use 2 (indep) codes as the key.
me:
this is sufficiently cumbersome that i doubt anyone will use it
if it's optional, and i doubt anyone will buy it, if it's not
optional.
hascall:
Or you could just use the secureID concept
of a time varying key and scale it up to 56 bits
since in the KDC-to-kinit communication there is no
need for an actual handheld device.
me:
you could, but i believe you'd have to sacrifice some of
krb's important features in order to do so.
i don't think securid integration matters that much, anyway;
there are other, better solutions than securid for krb's
problems. imho, securid integration's importance is as a
sales aid for krb vendors, because some customers feel better
if they buy a concrete object, rather than an abstract
algorithmic assurance of security. for that purpose, securid
integration has been a solved problem for a while.
-don davis, boston
