One Time Identification, a request for comments/testing.

[Douglas E. Engert]

John Rudd wrote:
> 
> 
> Perhaps I'm completely wrong, but ...
> 
>...
> 
> 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)
>

That sounds like:
http://www.computerlinks.de/open/datasheet/ActivKey_DS_A4_EN.pdf

There are other devices like this, basically combine the smart card
and the reader into one USB device and support some other
applets too.  With the Java smart cards, one of the applets is the
traditional "smart card" applet. Other applets could also be on the card.

Its the middle ware to use these that is so hard to get straight.
Thats why PKINIT sounds so attractive, Its already in Windows, and
now Heimdal and MIT.


> 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.
> 

Sounds like the http://www.tri-dsystems.com/
BIOMETRIC 3-FACTOR AUTHENTICATION

Finger print reader, smartcard and OTP in one.
(fcusack at fcusack.com author of a popular pam_krb5 works for them.)



> 
> 
> 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.

See above, it may be.

> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444