Perhaps I'm completely wrong, but ...
It seems to me that if you're talking about a simple dumb USB thumb
drive/data stick, that you're not going to be able to do anything to
prevent an adversary from copying that data to a local host, and then
brute-forcing the data over time. So, essentially, the only advantage
over "just putting a non-protected keytab on a USB drive" and any other
dumb-data-stick process is some amount of time it takes to overcome
whatever encryption you've done on the keytab.
I think a more interesting approach would be a non- "dumb data stick"
approach. It might start to sound like a variation of a smartcard, but
why not think about a new USB device that's perhaps about the size of a
USB data stick. It might present itself to the host computer as 2 devices:
1) a small storage area which contains a java application (not an
applet: it shouldn't run in a protect environment that keeps it from
reading and storing files on the host, etc.). (it doesn't have to be
java, it could be a selection of java, perl, python, native-windows,
native-mac, native-linux, native-freebsd, and native-solaris apps if you
want; the point is, it should be some selection that allows the stick to
be used pretty much anywhere)
2) an embedded computer with a thumb scanner like the ones we're
starting to see on lots of laptops. The embedded computer should never
present the actual thumb scanning data to the host computer.
When the user plugs in the "smartstick":
a) The user runs the whichever app in device#1 is appropriate.
b) The app asks the user for a principle, and tells them to scan their
thumb.
c) The app asks the KDC (indicated in the local host config?) for the
encrypted tgt, just like it was kinit.
d) The app sends the encrypted tgt to the embedded computer.
e) The embedded computer tries to use the thumb print to decrypt the
tgt. If it is successful, it hands the decrypted tgt back to the app.
f) The app uses the host's config information to determine how and where
to store the tgt, so that it is usable by the host's kerberos applications.
Upside: The user doesn't need to remember a passphrase, nor a PIN. The
process is no more vulnerable to an adversary than kinit is already
(perhaps less, because the adversary can't run something akin to a
keyboard-logger to intercept the passphrase/thumb-print).
Downsides: It may require that a user has both passphrase based
principles/keys and thumb print based principles/keys, and some
mechanism to pick between them. And, obviously, it depends upon a
device that, as far as I know, does not yet exist.
