[227] in Kerberos_V5_Development
Smartcards
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Fri Apr 20 13:43:35 1990
Date: Fri, 20 Apr 90 10:42:51 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
To: krbdev@ATHENA.MIT.EDU
Cc: geer@CRL.DEC.COM, lstans@SANDIA.GOV
In-Reply-To: geer@crl.dec.com's message of Tue, 10 Apr 90 15:23:46 EDT <9004101923.AA11827@thames.crl.dec.com>
I spoke to Leonard Stans at Sandia about their desire to use hand held
authenticators with Kerberos. The authenticators which he wants to
use are commercially available. Each is unique, and will generate a
time dependent password when a PIN is entered into the card. For the
rest of this message, I will refer to the hand held authenticator as a
smartcard.
The problem which is to be addressed is that an attacker who has
compromised a workstation can modify the software to store the keys of
subsequent users, and these keys can then be used to impersonate those
users. The solution is to make the key (password) change so that the
same password is never used more than once.
It is not desirable to use the smartcard directly (without a network
authentication scheme). The smartcard was designed for a timesharing
environment where the channel between where the user enters the
password, and where it is checked, is secure. This is not the case on
a network. Further, it is desirable to to authenticate a login
session to each of the servers at the time the the service is
requested (after the initial login). It is not practical to require
the user to enter his changing password for each request.
We came up with two ways to accomplish what he wants. One would
involve very little work, but is not quite as secure. The other is
more secure, but doesn't quite fit the model for which the smartcard
that he is using was designed. With a little work (on the Kerberos
server and client), it might be made to work.
---
Option 1, Simple, but not necessarily secure. This is what they have
in mind. An additional field would be added to the initial request to
Kerberos. The field would contain the password obtained from the
smartcard. The field would not be encrypted. When kerberos receives
the request, it checks the field before it replies. If valid, the
reply would still be encrypted in a separate (non changing) key.
Thus, the user would have to enter two keys. His normal Kerberos key,
and the one from the smartcard.
The disadvantage of this scheme is that it doesn't solve the problem.
An attacker could still modify a workstation to save keys. The
attacker could then wait for the client to log in from another
workstation, steal the time-varying key off the net, and authenticate
himself. Note that the attacker would require both pieces of
information, and one of them changes. Thus, we have limited the
damage somewhat. An attacker could only use the stolen key at the
time that the legitimate user is also logging in, and to do so would
require additional active network attacks. Presumably, things could
be set up such that the legitimate user would notice.
The reason for using the scheme described above is that the algorithm
for validating the time-varying password will actually accept more
than one password. This is necessary since the card might display a
value at one instance, but time may pass before the value is entered
into the computer. Otherwise, the algorithm would incorrectly reject
passwords entered across quanta.
---
Option 2, more difficult, but also more secure. This is what I
suggest. Instead of sending the password from the smartcard to the
Kerberos server, the password should be used as the key under which
the response is encrypted. If an attacker modifies a workstation to
collect passwords, those passwords would only continue to work for a
short period of time (presumably shorter than the life of the
credentials which were received for the current session).
The problem with this approach is implementation. Both the smartcard and
the Kerberos server must be in sync with respect to the key that is to
be used. Keeping things in sync is not as easy as it seems since the
user must read the password from the card, then type it in, and one is
thus talking about a delay on a human order of magnitude.
One possible approach is to send multiple responses if the time is
near a quantum boundary. One response would be sent in the old key, and
one in the new, and the key entered by the user would be tried on each
response.
If using this approach, it is important that the password generated by
the smartcard algorithm are chosen from a sufficiently large address
space that it not make it any easier for an attacker to mount a brute
force attack. If this condition is not met, it would be desirable
that the key generated by the card be further modified by a fixed key
known to the user.
---
Option 3, is the most secure, but not practical for present purposes.
It requires a smartcard that would perform the encryption and
decryption required by the Kerberos protocol on its own. The user's
key would never leave the smartcard (the key might be a compound key,
part of which is in the card, and part of which the user has to enter
directly into the card as a PIN). A smart card reader would allow the
workstation software to request the decryption of the initial response
from the Kerberos server. This approach is most secure because the
technology in the card (encryption algorithm) is the same as that used
by the Kerberos protocol, thus there is only one point of weakness.
If one can break the card, they can also break the encryption used in
Kerberos directly.
---
In any case, one change that I would suggest for the Kerberos protocol
is to add a field in the initial request that can be used for
authentication to the Kerberos server. This would allow option one to
be implemented easily. The field should have a type associated with
it so that different forms of pre-authentication information can be
included. This would allow several other options to be implemented.
In particular, it allows one to require an encrypted timestamp in this
field if so desired, thus making it difficult for an attacker to make
a request, then use brute force attacks against the response. In the
V5 rewrite, we decided not to support this ourselves, but adding the
field would make it easier to do so within the protocol, should
someone else decide it is needed.
Another advantage of adding the field is that it allows us to unify
the two messages to the KDC (AUTH and TGT). The pre-authentication
field would hold the authenticator in the TGT request (in fact, I would
suggest naming the fields "authenticator", and "authenticator-type").
~ Cliff
