One Time Identification, a request for comments/testing.

[John Rudd]

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.