[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: KISS for PKIX. (Was: RE:Asymmetric authentication

This started, I think, as a debate about certificates v passwords, but does
seem to be going in the IKE direction :)

In your mail, are you suggesting that the client device is only loaded with
part of the private key, and that the remainder is entered when the client
device connects?

If so, I think this can still be cracked off-line. If we are using
certificates, the client's public certificate (with public key) is very much
available. It may take some time (I've no idea how long!), but couldn't I
still work on the portion of the private key (the majority of which is
stored on the client device somehow) until I had reconstructed the private
key to match the public key?

Cheers, Steve.

-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Wednesday, July 21, 1999 4:49 PM
To: ietf-pkix@imc.org
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication


That sounds like an interesting approach when a user's public key is
public.

But I assume from the IKE/XAUTH discussion that:

1) the VPN server authenticates itself to the client and establishes
   confidentiality for a secondary authentication of the client to the
server.

2) the VPN server has some unique secret knowledge about the user,
established
   by some enrollment process, that allows it to determine if the user has
   typed the correct password/pin.  Otherwise, the thief could set up his
   own VPN server from public information, configure the stolen client to
   authenticate the bogus server, and start guessing passwords.

My suggestion is that if the VPN server must have some secret knowledge
of the user, then that secret might as well be the larger component of a
keypair generated during enrollment.  The client would get the smaller
component, a private key which can not be determined by offline trial
decryption.

This eliminates the need for a secondary XAUTH protocol, since the normal
IKE handshake provides the benefit claimed for XAUTH.  KISS.

Dave Kemp

(Why are we discussing IKE on the PKIX list?)



> From: Stephen Kent <kent@bbn.com>
> 
> Stephen and David,
> 
> There is another approach here, that I first heard suggested by Jeff
> Schiller a number of years ago. One could remember a pass phrase and use
it
> as the seed for a PRNG, which then feeds into a key pair selection
> algorithm, thus recreating one's private key, rather than storing it. It
> occurs to me that some additonal entropy could be provided by a second
seed
> value, saved in encrypted form and decrypted with the pass phrase.
because
> this second value would be random (preferavly from a non-deterministic
> source) attempts to decrypt it do not yield quick confirmation of gusses.
> Instead, one has to try to use the pair of values (the pass phrase guess
> and the decrypted second seed), to genreate a key pair, and then check to
> see if the result yields the public key for the user. This approach is
> clearly much, much slower that just decrypting a stored key, but it allows
> a greater degree of security vs. a stored private key encrypted with a
> password, and makes offline guessing attacks more costly.  Also, because
> one hash complete freedom in choosing the pass phrase, it should be easier
> to remember than a string of words formed from the bit pattern of a
private
> key.
> 
> Just a thought,
> 
> Steve