[229] in Kerberos_V5_Development
Smartcards
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Mon Apr 23 12:48:49 1990
Date: Mon, 23 Apr 90 09:46:37 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
To: jis@MIT.EDU
Cc: krbdev@ATHENA.MIT.EDU, geer@CRL.DEC.COM, lstans@SANDIA.GOV
In-Reply-To: Jeffrey I. Schiller's message of Fri, 20 Apr 90 19:41:45 -0400 <9004202341.AA27821@osiris.MIT.EDU>
Date: Fri, 20 Apr 90 19:41:45 -0400
From: Jeffrey I. Schiller <jis@MIT.EDU>
Subject: Smartcards
I suspect that the SmartCard type you are referring to is the
product available from Security Dynamics, which is of the
kind you described.
I think it is the Security Dynamics card. Your approach looks like it
would work. Presumably, the additional field which I suggested could
be generalized so that it can contain any additional information
needed for authentication. In your scheme, it would be used to pass
the shift (+1, -1, +2, -2, etc). For the TGT request, it would be
used to bass the TGT and authenticator. If someone used a different
mechanisms for "pre-authentication", the field could hold that data.
As to the question of how the Kerberos server knows which response was
used, I see some minor problems. If a client has not used a smartcard
for a long time, then the key could potentially be significantly out
of sync. If an exchange were started, but the client crashed after
the first request (or if the network is so congested that packets only
make it through intermittently), then the server might think that the
client successfully decrypted the first response, and update its
database inappropriately. The result would be that the next time the
client tried using the smartcard, it would be out of sync, AND the
allowable skew would have been reset to a value that is too low for it
to compensate.
Some kind of positive acknowledgment is needed before the database can
be updated. The positive acknowledgment is implicit in the use of
the ticket granting ticket obtained in the initial request. The
Kerberos server can keep track of the last several time shift values
issued for each client (several in case there is more than one
session), each keyed on the timestamp in the ticket that was issued.
When a ticket granting ticket is received, the Kerberos server looks
at the timestamp, determines if it is more recent than that for the
last update to the clients record, and if so, it uses the timestamp to
find the time shift value that was used in issuing the ticket, and
updates the client's record.
One issue that must be considered in either approach is that of how to
deal with multiple Kerberos servers for the same realm. These
approaches blur the distinction between read only copies, and copies
that accept updates. By responding to an authentication request, a
replica is, in fact, accepting an update. Either each replica will be
required to distribute its updates to other replicas periodically
(perhaps nightly), or those replicas which a client doesn't use
frequently will end up with an acceptable skew that is so great, it
would allow an attacker to reuse a key that the client used on a
different server. If a master/slave model is used for replication (as
is currently the case), then if a client uses only the slaves for
authentication, the databases for all the replicas will be overwritten
by the database on the master which has not been updated. Again, the
allowable skew would grow to too great a value.
Finally, a question on the nature of the clock drift in these
smartcards. Is the drift itself relatively stable. In other words,
given a single card, does the clock speed change significantly from
time to time, or is the difference in clock speeds primarily from card
to card. If the drift in a particular card is fairly stable, then
presumably one could calculate a correction factor and store it in the
database entry for each card. This would allow the database to do a
better job of tracking the card, thus decreasing the average number of
messages needed for initial authentication, and tightenting the window
of vulnerability for an attacker. Conceivably the algorithm used
already does this, but someone should look into it just in case.
~ Cliff
