[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: xauth requirements: vulnerabilities
-----Original Message-----
From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com]
Sent: Thursday, July 29, 1999 7:14 AM
To: Dan Harkins
Cc: ipsec@lists.tislabs.com
Subject: RE: xauth requirements: vulnerabilities
Main reason: Because the customer is happy with their investment in
the
legacy method and wants to use the same method for traditional RAS
and VPN.
The added benefit is that the token card can't be cracked off-line -
it
doesn't know what the secret, so it can't tell it to you.
All DES based token cards (i.e.. all others besides SecurID) know a
'secret', SecurID is proprietary but it must know a secret as well. All
token card vendors also have 'software' tokens which mimic hardware tokens.
The DES or proprietary key is stored some how on disk with the soft token so
it is susceptible to the same off line attacks as a shared key file, while I
don't know of any specific technique to get DES keys off of hardware tokens
I doubt they are tamper proof. I do know that unlike smartcards which
generate the private key on board, DES based hardware token cards can have
the secret downloaded via a serial port in the clear. Your GW can not
discriminate between a user with a hardware token and one using a software
token.
Now, this off-line exposure could be 'fixed' just with pre-shared,
if the
client software did the right thing, i.e. challenge for a passphrase
to
unlock the pre-shared, derive a key, unencrypt the pre-shared, and
just use
whatever it recovers, without having anyway to verify it (e.g. hash
signature). This would mean that the client would not know when you
had
answered the question correctly and prevent off-line hacking. The
problem is
that this relies on the implementation.
I am a little confused on the above statement, but for what it is worth the
same pass phrase that encrypts the shared secret file can be used to MAC the
shared key file to prevent tampering.
Bye.