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

From: "David P. Kemp" <[email-masked]>
Date: Wed, 21 Jul 1999 11:49:14 -0400 (EDT)

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 <[email-masked]>
> 
> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jul 1999 16:29:18 -0400

David,

If one does not want to treat the public key as public info, then we can
certainly make life much harder for an attacker.  The measures I described
work even better under such circumstances, as the atacker has no reference
against which to compare guesses.

A company called Arcot has a patented approch to doing this, in which they
pass the public key as an encrypted extension in an X.509 cert, which would
allow continued use of the current mechanisms in IKE for cert exchange. A
paper on their approach was published in the 1999 IEEE Security and Privacy
Symposium.

Of course, Lynn's cert-less approach to using public key cryptography also
provides ways to avoid such attacks.

At this point, the discussion really seems more appropriate for the IPsec,
not PKIX, mailing list, don't you think?

Steve