You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by g....@hurderos.org on 2007/01/31 07:03:09 UTC
One Time Identification, a request for comments/testing.
Good evening, I hope this note finds everyone's day going well.
Its becoming increasingly obvious that the utility of passwords are
becoming problematic. If users are forced into passwords with
sufficient entropy they write them down. Products such as PRTK are
making it increasingly difficult to select passwords which can be
easily remembered and yet are secure.
Common solutions to this problem include One Time Password systems and
pre-authentication strategies such as PKINIT. While effective these
systems each have their own issues ranging from diminished entropy to
complexity.
For the last several months we have been working on an alternative
strategy for a system which combines two-factor authentication with
strong single use passwords. The primary focus of this work was to
develop a system which integrated naturally with desktop based
Kerberos authentication and was freely implementable.
The purpose of this note is to introduce the work and get
comments/feedback from the community.
The proposal is referred to as OTI or One Time Identification. The
system is based on an identity token which can be carried on a
standard USB flash disk. The identity token is included in an
identification payload which is symmetrically encrypted and included
in the AS_REQ authorization field. The KDC decrypts and verifies the
identity upon receipt of the AS_REQ. If the OTI identity matches that
of the principal requesting the service the AS_REP proceeds.
The identity token consists of a DER encoded structure of the
following information:
1.) 32-bit identity epoch time.
2.) RSA encrypted 160-bit user identity.
The epoch time is randomly chosen when the user's identity token is
generated. RSA encryption is done against a private key held by the
KDC.
When the AS_REQ is composed a DER encoded data structure of the
following elements is created:
1.) Authentication request time.
2.) IP address of target KDC server.
3.) RSA encrypted identity.
A time interval dependent key scheduler is used to derive a symmetric
encryption key using the following information:
1.) Epoch time of identity.
2.) Offset of authentication time from identity epoch time.
3.) SHA256 hash of the RSA encrypted identity.
4.) User password key.
The key scheduler uses the authentication epoch time differential to
perturb the generation of two separate vectors. These vectors are
combined and then fed into an N-round iteration of feedback hashing to
generate the final encryption key.
Vector 1 is generated as follows:
|| = Concantenation.
Ukey = User's authentication key (des3-hmac-sha1 in reference imp).
Etime = 32-bit identity epoch time.
Eoffs = Authentication/epoch time offset (network byte order).
Ihash = SHA256 hash of RSA encrypted identity.
Nrnd = Iteration round count.
V1 = Hmac256(K, Etime)
| K = (Ukey || Eoffs)
The Etime is decomposed into a UNIX time structure with a
gmtime call. The day of the month represented by the Etime is
used as an offset into the V1 vector to obtain an 8-bit round
count value (Nrnd).
Vector 2 is generated as follows:
V2 = Hmac256(K, Ukey)
| K = (Ihash || Eoffs)
The first 16 bytes of the V2 vector are retained to serve as
the IV (Initialization Vector) for AES-256-CBC symmetric
encryption of the OTI payload.
Iteration rounds:
A seed vector for the iteration rounds is formed as follows:
Seed = (V1 || V2)
The Seed vector (512 bits) is reduced to a 256 bit vector by
the first SHA256 hashing round. The 256 bit output vectors
are then iteratively fed back for Nrnd-1 iterations.
The output of the final round is used as an AES-256-CBC encryption key
with the IV abstracted from the V2 vector.
Upon receipt of the AS_REQ payload the KDC re-creates the key and IV
by running the same key scheduler using the authentication start time
from the AS_REQ. In the prototype implementation the identity epoch
time and the SHA256 hash of the RSA encrypted identity token are
stored in an LDAP directory object indexed by the user's Kerberos
principal. Appropriate access controls are assumed on the directory
object.
If decryption is successful the payload is ASN decoded. The
authentication time from the OTI payload is matched to the
authentication start time of the AS_REQ. The encoded IP address is
verified to match one of the IP addresses the KDC is listening on.
The KDC then uses its private RSA key to decrypt the identity
payload. The 160-bit intrinsic identity is verified to match the
identity assigned to the principal. The AS_REP is then issued to the
user if all validation checks pass.
The take away from all this is that the authentication request is
processed if and only if the user can supply an identity token which
is unique in time and valid to the KDC. The time dependent key
scheduler generates a unique password at one second granularity
intervals given a specific user password and identity token.
>>From the user's perspective the interface is identical to a standard
login attempt with the exception that a USB dongle with the identity
token needs to be available to generate the AS_REQ. No additional
prompts, button pushes, pin numbers, certificate slot selection, PKI
infra-structure etc. are needed.
Since timing is based on a quantity agreed to by both the client and
KDC (authn start time) there are no issues with clock cadence and or
re-synchronization windows. Standard KDC clock skew issues are still
present but that is a well understood issue.
As I noted earlier this system was designed specifically to meet the
needs of Kerberos based authentication. Beyond user convenience a
primary concern was avoidance of replay attacks.
Adding the authentication time and the IP address of the target KDC
server in the encryped OTI payload locks the request to a specific KDC
for a specific instant in time. No coordination is required between
master and slave KDC's.
At the level of an individual KDC a potential reply attack is now
slaved to the clock skew window of the KDC. A natural benefit of OTI
is that each authentication attempt now has a unique footprint, the
checksum of the encrypted payload.
In order to avoid reply attacks within the clock skew window the KDC
caches the hash of the encrypted payload along with the authentication
request time indexed by principal name upon issuance of an AS_REP.
The cache entries only need to be maintained until the authentication
time associated with the payload expires from the clock skew window.
Finally it goes without saying that failure throttling needs to be
integrated into the KDC for full security.
So, in a nutshell... :-), thats the strategy.
As I noted at the start we have a working implementation of all this.
A primary concern, of course, is on the strength and randomness of the
time unique OTI encryption keys.
I put together a tarball which will generate two utilities which
people can use to play around with this a bit. The following URL will
pull the tarball:
ftp://ftp.hurderos.org/pub/Hurderos/src/OTI-test.tar.gz
Typing make should suffice to build it on most Linux systems. The
only thing which may need some tweaking are the locations for Kerberos
and OpenSSL which are configurable at the top of the Makefile.
Compiling will produce the following two binaries:
genOTI
decryptOTI
The tarball also contains a sample identity token. Running genOTI
will cause several questions to be asked. These are basically to
supply information which the AS_REQ would normally have. The utility
will then read the token and begin printing encryption keys and their
corresponding times.
The genOTI utility also supports a -o switch. This will cause
encrypted payloads to be generated and written to files tagged by
authentication time. The decryptOTI utility will ask for several
pieces of information and then attempt to decrypt the designated
payload file.
The OTI-test tarball contains two pre-compiled .a files of all the
library code for simplicity purposes. If anyone wants to validate
that the test utilities are not going to do anything evil full sources
can be pulled from:
ftp://ftp.hurderos.org/pub/Hurderos/src/Hurderos-0.1.5-rc2.tar.gz
Please feel free to forward any comments or questions you may have on
all this. Everything is GPL/OpenSSL exception.
Apologies for the length of the introduction. I would be happy to
entertain more in depth discussion in private e-mail if anyone is
interested in all this.
Best wishes for a pleasand and productive remainder of the week.
As always,
Greg Wettstein
------------------------------------------------------------------------------
The Hurderos Project
Open Identity, Service and Authorization Management
http://www.hurderos.org
"My thoughts on trusting Open-Source? A quote I once saw said it
best: 'Remember, Amateurs built the ark. Professionals built the
Titanic.' Perhaps most significantly the ark was one guy, there were
no doubt committees involved with the Titanic project."
-- Dr. G.W. Wettstein
Resurrection
Re: One Time Identification, a request for comments/testing.
Posted by Nicolas Williams <Ni...@sun.com>.
On Thu, Feb 01, 2007 at 08:21:49AM +1100, Andrew Bartlett wrote:
> > What do you mean by "cross-platform"?
>
> Works with windows desktops too :-)
But I think this means that you want the format of the softtoken to be
open and implementable by multiple implementors.
> Love also has a PKCS#11 softtoken. The details that I think might need
> work are integration so that the logon systems on various platforms
> 'know' that the token is there, and the softtoken driver should be used.
Certainly those details should be worked out. But if my softtoken
should work when plugged into a Solaris sytem, a Linux system or a
Windows system then the format must be agreed by all, or else users will
have to resort to installing one cross-platform implementation on all
those systems.
Nico
--
Re: One Time Identification, a request for comments/testing.
Posted by Andrew Bartlett <ab...@samba.org>.
On Wed, 2007-01-31 at 15:17 -0600, Nicolas Williams wrote:
> On Thu, Feb 01, 2007 at 07:51:47AM +1100, Andrew Bartlett wrote:
> > I think developing a cross-platform USB 'tumb drive' based soft token
> > would be an immense benefit. It could make PKINIT real for many small
> > sites that do not yet wish to invest in a token stack, and perhaps more
> > importantly, make PKINIT and smart-card login something that developers
> > and interested technical users can test with resources to hand.
>
> What do you mean by "cross-platform"?
Works with windows desktops too :-)
> OpenSolaris has an OSS (CDDL'ed) PKCS#11 softtoken provider that does
> pretty much what you want. It stores its files in a filesystem, by
> default in a sub-directory of the user's home directory; filesystem type
> does not matter. Since you can put filesystems on a USB flash drive
> that should suffice for a "cross-platform" softtoken.
>
> The specifics of the Solaris softtoken's directory layout and file
> formats are project private interfaces IIRC, but if there's interest I
> imagine that we could document them, make them committed public
> interfaces and help establish a standard for a cross-platform softtoken.
Love also has a PKCS#11 softtoken. The details that I think might need
work are integration so that the logon systems on various platforms
'know' that the token is there, and the softtoken driver should be used.
Andrew Bartlett
--
Andrew Bartlett <ab...@samba.org>
Re: One Time Identification, a request for comments/testing.
Posted by Nicolas Williams <Ni...@sun.com>.
On Thu, Feb 01, 2007 at 07:51:47AM +1100, Andrew Bartlett wrote:
> I think developing a cross-platform USB 'tumb drive' based soft token
> would be an immense benefit. It could make PKINIT real for many small
> sites that do not yet wish to invest in a token stack, and perhaps more
> importantly, make PKINIT and smart-card login something that developers
> and interested technical users can test with resources to hand.
What do you mean by "cross-platform"?
OpenSolaris has an OSS (CDDL'ed) PKCS#11 softtoken provider that does
pretty much what you want. It stores its files in a filesystem, by
default in a sub-directory of the user's home directory; filesystem type
does not matter. Since you can put filesystems on a USB flash drive
that should suffice for a "cross-platform" softtoken.
The specifics of the Solaris softtoken's directory layout and file
formats are project private interfaces IIRC, but if there's interest I
imagine that we could document them, make them committed public
interfaces and help establish a standard for a cross-platform softtoken.
Nico
--
Re: One Time Identification, a request for comments/testing.
Posted by Andrew Bartlett <ab...@samba.org>.
On Wed, 2007-01-31 at 07:02 -0500, Sam Hartman wrote:
> So, the USB flash stores the 160-bit RSA encrypted user identity?
>
>
>
>
> I think that this approach or something like it could be useful. I'm
> not sure I'm happy with your key schedule, or some of the crypto
> details. I'd prefer to think about whether RFC 3961 might provide
> better options. Similarly, I'm not sure what you get out of RSA
> encryption.
>
> An alternative proposal that seems like it would do the same thing
> from a security standpoint would be a way to combine a password key
> with pkinit. You could store a soft certificate on a USB token.
I think developing a cross-platform USB 'tumb drive' based soft token
would be an immense benefit. It could make PKINIT real for many small
sites that do not yet wish to invest in a token stack, and perhaps more
importantly, make PKINIT and smart-card login something that developers
and interested technical users can test with resources to hand.
Andrew Bartlett
--
Andrew Bartlett <ab...@samba.org>
Re: One Time Identification, a request for comments/testing.
Posted by Sam Hartman <ha...@mit.edu>.
So, the USB flash stores the 160-bit RSA encrypted user identity?
I think that this approach or something like it could be useful. I'm
not sure I'm happy with your key schedule, or some of the crypto
details. I'd prefer to think about whether RFC 3961 might provide
better options. Similarly, I'm not sure what you get out of RSA
encryption.
An alternative proposal that seems like it would do the same thing
from a security standpoint would be a way to combine a password key
with pkinit. You could store a soft certificate on a USB token.
Ultimately, though, I think that the important thing is the user
experience. I agree with you that providing stronger authentication
when someone provides a USB flash disk with some secret information is
desirable. I think the specific details of how to do this should be
worked out in the Kerberos working group of the IETF. I encourage you
to take your proposal there.
--Sam
Re: One Time Identification, a request for comments/testing.
Posted by "Douglas E. Engert" <de...@anl.gov>.
I was trying to get the authors of the note to say this, as
it appears that their approach is equivalent to soft tokens
but may have some advantages with regard to password policies.
Nicolas Williams wrote:
> On Wed, Jan 31, 2007 at 08:42:43AM -0600, Douglas E. Engert wrote:
>> What keeps a user from copying the identity token from the USB
>> device to a local or shared file system to avoid having to insert
>> the USB device all the time?
>>
>> What are the security implications if the identity token is
>> stolen?
>>
>> How does this compare to using cert and key on the USB
>> device with PKINIT rather then your identity token?
>>
>> How does this compare to using a smart card or USB equivelent
>> of a smartcard with PKINIT? To the user they still have to insert
>> the card or USB device, and have to enter a pin or password?
>
> You're correct -- softtokens aren't a replacement for real smartcards.
>
> That doesn't stop a softtoken from being useful though.
>
> Compare softtokens to passphrase-protected ssh private key files in
> users' home directories :)
These suffer form policy control of the passphase used to encrypt the
key. The user can change the passphrase, or remove it all together!
This is a problem for oraganizations that need to enforce password
quality rules. It all so allows for offline guessing attacks.
(A smart card at least enforces some rules on the pin, and
defeats the guessing attack buy turring off the card after some small
number of guesses.)
It sounded like the identity token approach required the use of a
password as well, so it might get around some of the password policy
issues, as the KDC gets to enforce the policies. I would like the authors
to comment more on this.
>
> Nico
--
Douglas E. Engert <DE...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Re: One Time Identification, a request for comments/testing.
Posted by Nicolas Williams <Ni...@sun.com>.
On Wed, Jan 31, 2007 at 08:42:43AM -0600, Douglas E. Engert wrote:
> What keeps a user from copying the identity token from the USB
> device to a local or shared file system to avoid having to insert
> the USB device all the time?
>
> What are the security implications if the identity token is
> stolen?
>
> How does this compare to using cert and key on the USB
> device with PKINIT rather then your identity token?
>
> How does this compare to using a smart card or USB equivelent
> of a smartcard with PKINIT? To the user they still have to insert
> the card or USB device, and have to enter a pin or password?
You're correct -- softtokens aren't a replacement for real smartcards.
That doesn't stop a softtoken from being useful though.
Compare softtokens to passphrase-protected ssh private key files in
users' home directories :)
Nico
--
Re: One Time Identification, a request for comments/testing.
Posted by "Douglas E. Engert" <de...@anl.gov>.
What keeps a user from copying the identity token from the USB
device to a local or shared file system to avoid having to insert
the USB device all the time?
What are the security implications if the identity token is
stolen?
How does this compare to using cert and key on the USB
device with PKINIT rather then your identity token?
How does this compare to using a smart card or USB equivelent
of a smartcard with PKINIT? To the user they still have to insert
the card or USB device, and have to enter a pin or password?
g.w@hurderos.org wrote:
> Good evening, I hope this note finds everyone's day going well.
>
> Its becoming increasingly obvious that the utility of passwords are
> becoming problematic. If users are forced into passwords with
> sufficient entropy they write them down. Products such as PRTK are
> making it increasingly difficult to select passwords which can be
> easily remembered and yet are secure.
>
> Common solutions to this problem include One Time Password systems and
> pre-authentication strategies such as PKINIT. While effective these
> systems each have their own issues ranging from diminished entropy to
> complexity.
>
> For the last several months we have been working on an alternative
> strategy for a system which combines two-factor authentication with
> strong single use passwords. The primary focus of this work was to
> develop a system which integrated naturally with desktop based
> Kerberos authentication and was freely implementable.
>
> The purpose of this note is to introduce the work and get
> comments/feedback from the community.
>
> The proposal is referred to as OTI or One Time Identification. The
> system is based on an identity token which can be carried on a
> standard USB flash disk. The identity token is included in an
> identification payload which is symmetrically encrypted and included
> in the AS_REQ authorization field. The KDC decrypts and verifies the
> identity upon receipt of the AS_REQ. If the OTI identity matches that
> of the principal requesting the service the AS_REP proceeds.
>
> The identity token consists of a DER encoded structure of the
> following information:
>
> 1.) 32-bit identity epoch time.
> 2.) RSA encrypted 160-bit user identity.
>
> The epoch time is randomly chosen when the user's identity token is
> generated. RSA encryption is done against a private key held by the
> KDC.
>
> When the AS_REQ is composed a DER encoded data structure of the
> following elements is created:
>
> 1.) Authentication request time.
> 2.) IP address of target KDC server.
> 3.) RSA encrypted identity.
>
> A time interval dependent key scheduler is used to derive a symmetric
> encryption key using the following information:
>
> 1.) Epoch time of identity.
> 2.) Offset of authentication time from identity epoch time.
> 3.) SHA256 hash of the RSA encrypted identity.
> 4.) User password key.
>
> The key scheduler uses the authentication epoch time differential to
> perturb the generation of two separate vectors. These vectors are
> combined and then fed into an N-round iteration of feedback hashing to
> generate the final encryption key.
>
> Vector 1 is generated as follows:
>
> || = Concantenation.
> Ukey = User's authentication key (des3-hmac-sha1 in reference imp).
> Etime = 32-bit identity epoch time.
> Eoffs = Authentication/epoch time offset (network byte order).
> Ihash = SHA256 hash of RSA encrypted identity.
> Nrnd = Iteration round count.
>
> V1 = Hmac256(K, Etime)
> | K = (Ukey || Eoffs)
>
> The Etime is decomposed into a UNIX time structure with a
> gmtime call. The day of the month represented by the Etime is
> used as an offset into the V1 vector to obtain an 8-bit round
> count value (Nrnd).
>
> Vector 2 is generated as follows:
>
> V2 = Hmac256(K, Ukey)
> | K = (Ihash || Eoffs)
>
> The first 16 bytes of the V2 vector are retained to serve as
> the IV (Initialization Vector) for AES-256-CBC symmetric
> encryption of the OTI payload.
>
> Iteration rounds:
>
> A seed vector for the iteration rounds is formed as follows:
>
> Seed = (V1 || V2)
>
> The Seed vector (512 bits) is reduced to a 256 bit vector by
> the first SHA256 hashing round. The 256 bit output vectors
> are then iteratively fed back for Nrnd-1 iterations.
>
>
> The output of the final round is used as an AES-256-CBC encryption key
> with the IV abstracted from the V2 vector.
>
> Upon receipt of the AS_REQ payload the KDC re-creates the key and IV
> by running the same key scheduler using the authentication start time
> from the AS_REQ. In the prototype implementation the identity epoch
> time and the SHA256 hash of the RSA encrypted identity token are
> stored in an LDAP directory object indexed by the user's Kerberos
> principal. Appropriate access controls are assumed on the directory
> object.
>
> If decryption is successful the payload is ASN decoded. The
> authentication time from the OTI payload is matched to the
> authentication start time of the AS_REQ. The encoded IP address is
> verified to match one of the IP addresses the KDC is listening on.
>
> The KDC then uses its private RSA key to decrypt the identity
> payload. The 160-bit intrinsic identity is verified to match the
> identity assigned to the principal. The AS_REP is then issued to the
> user if all validation checks pass.
>
> The take away from all this is that the authentication request is
> processed if and only if the user can supply an identity token which
> is unique in time and valid to the KDC. The time dependent key
> scheduler generates a unique password at one second granularity
> intervals given a specific user password and identity token.
>
>>>From the user's perspective the interface is identical to a standard
> login attempt with the exception that a USB dongle with the identity
> token needs to be available to generate the AS_REQ. No additional
> prompts, button pushes, pin numbers, certificate slot selection, PKI
> infra-structure etc. are needed.
>
> Since timing is based on a quantity agreed to by both the client and
> KDC (authn start time) there are no issues with clock cadence and or
> re-synchronization windows. Standard KDC clock skew issues are still
> present but that is a well understood issue.
>
> As I noted earlier this system was designed specifically to meet the
> needs of Kerberos based authentication. Beyond user convenience a
> primary concern was avoidance of replay attacks.
>
> Adding the authentication time and the IP address of the target KDC
> server in the encryped OTI payload locks the request to a specific KDC
> for a specific instant in time. No coordination is required between
> master and slave KDC's.
>
> At the level of an individual KDC a potential reply attack is now
> slaved to the clock skew window of the KDC. A natural benefit of OTI
> is that each authentication attempt now has a unique footprint, the
> checksum of the encrypted payload.
>
> In order to avoid reply attacks within the clock skew window the KDC
> caches the hash of the encrypted payload along with the authentication
> request time indexed by principal name upon issuance of an AS_REP.
> The cache entries only need to be maintained until the authentication
> time associated with the payload expires from the clock skew window.
>
> Finally it goes without saying that failure throttling needs to be
> integrated into the KDC for full security.
>
> So, in a nutshell... :-), thats the strategy.
>
> As I noted at the start we have a working implementation of all this.
> A primary concern, of course, is on the strength and randomness of the
> time unique OTI encryption keys.
>
> I put together a tarball which will generate two utilities which
> people can use to play around with this a bit. The following URL will
> pull the tarball:
>
> ftp://ftp.hurderos.org/pub/Hurderos/src/OTI-test.tar.gz
>
> Typing make should suffice to build it on most Linux systems. The
> only thing which may need some tweaking are the locations for Kerberos
> and OpenSSL which are configurable at the top of the Makefile.
>
> Compiling will produce the following two binaries:
>
> genOTI
>
> decryptOTI
>
> The tarball also contains a sample identity token. Running genOTI
> will cause several questions to be asked. These are basically to
> supply information which the AS_REQ would normally have. The utility
> will then read the token and begin printing encryption keys and their
> corresponding times.
>
> The genOTI utility also supports a -o switch. This will cause
> encrypted payloads to be generated and written to files tagged by
> authentication time. The decryptOTI utility will ask for several
> pieces of information and then attempt to decrypt the designated
> payload file.
>
> The OTI-test tarball contains two pre-compiled .a files of all the
> library code for simplicity purposes. If anyone wants to validate
> that the test utilities are not going to do anything evil full sources
> can be pulled from:
>
> ftp://ftp.hurderos.org/pub/Hurderos/src/Hurderos-0.1.5-rc2.tar.gz
>
> Please feel free to forward any comments or questions you may have on
> all this. Everything is GPL/OpenSSL exception.
>
> Apologies for the length of the introduction. I would be happy to
> entertain more in depth discussion in private e-mail if anyone is
> interested in all this.
>
> Best wishes for a pleasand and productive remainder of the week.
>
> As always,
> Greg Wettstein
>
> ------------------------------------------------------------------------------
> The Hurderos Project
> Open Identity, Service and Authorization Management
> http://www.hurderos.org
>
> "My thoughts on trusting Open-Source? A quote I once saw said it
> best: 'Remember, Amateurs built the ark. Professionals built the
> Titanic.' Perhaps most significantly the ark was one guy, there were
> no doubt committees involved with the Titanic project."
> -- Dr. G.W. Wettstein
> Resurrection
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
--
Douglas E. Engert <DE...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Re: One Time Identification, a request for comments/testing.
Posted by "Douglas E. Engert" <de...@anl.gov>.
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@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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
--
Douglas E. Engert <DE...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Re: One Time Identification, a request for comments/testing.
Posted by Nicolas Williams <Ni...@sun.com>.
On Fri, Feb 02, 2007 at 10:16:28AM -0800, John Rudd wrote:
> 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.
The advantage of softtokens over hardtokens is that they are
software-based, and when you don't have a smartcard around they can be
useful in debugging, testing, or even as a cheap alternative to
smartcards. And yes, softtokens are susceptible to offline dictionary
and brute-force attacks by any attacker that can get their hands on
them. But have you ever used passphrase-protected ssh private key
files? I bet you have. It's darn useful because there's no need to buy
a new piece of hardware -- you just have to be more careful than you
might have to be with a smartcard.
There's not much new here. This thread is starting to repeat itself.
The only new questions here are:
- should MIT krb5 have softtoken support?
(And note that if it has PKCS#11 support for PKINIT and/or PA-ENC-
TIMESTAMP long-term symmetric keys then it will have softtoken
support wherever PKCS#11 softtoken providers are available.)
- should there be a standard for softtoken formats?
Since there are at least two PKCS#11 softtoken providers this is an
interesting question. Where should such thing be standardized, if at
all? Perhaps informally would be best.
> 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:
This stuff exists. Google it. And it is just a smartcard. Using
bimetrics instead of PINs is interesting and a subject for another
thread, probably on a different forum.
Nico
--
Re: One Time Identification, a request for comments/testing.
Posted by John Rudd <jr...@ucsc.edu>.
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.
Re: One Time Identification, a request for comments/testing.
Posted by Jeffrey Hutzelman <jh...@cmu.edu>.
On Friday, February 02, 2007 10:05:09 AM -0500 Jim Rees <re...@umich.edu>
wrote:
> So would it be fair say this is sort of like using a smartcard in that you
> need both possession of the token and knowledge of a PIN? And that the
> KDC guards the PIN against brute force guessing, because each guess
> requires a transaction against the KDC? So stealing the token gets the
> attacker nothing?
No. Smart cards are not (generally) simple storage devices. What guards a
smartcard PIN against brute force guessing is that you only get a limited
number of tries before the card locks itself and becomes useless. And what
protects the private key is the fact that only the card knows the key, so
if the card is not physically present (or has been locked out due to too
many wrong PIN's), it is impossible to perform crypto operations with the
private key.
What we're talking about here is something completely different. Yes, you
need both posession of a physical object and a password. But the
similarity ends there.
-- Jeff
Re: One Time Identification, a request for comments/testing.
Posted by Jim Rees <re...@umich.edu>.
So would it be fair say this is sort of like using a smartcard in that you
need both possession of the token and knowledge of a PIN? And that the KDC
guards the PIN against brute force guessing, because each guess requires a
transaction against the KDC? So stealing the token gets the attacker
nothing?
Re: One Time Identification, a request for comments/testing.
Posted by Ken Renard <kd...@wareonearth.com>.
> The identity token is included in an identification payload which
> is symmetrically encrypted and included in the AS_REQ authorization
> field.
Any reason why this couldn't be implemented as a preauthentication
type (especially with the PAL in 1.6)? Might give you more
flexibility with respect to multiple exchanges or when a principal
requires this type of authentication. This might even fit into the
SAM(2) preauth type.
Operationally, users might just stick their USB key in and leave it
there (same as copying to filesystem). From there, it's just
filesystem privileges that separate an attacker from the real user.
-Ken Renard