[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Secret public keys
Yes, I believe your suggestion (copied below) would fix the off-line
cracking problem, and is supported in IKE today. BUT, it has problems in
that, to a large extent, it will through VPN role into confusion!
The model would be:-
Client is loaded with:
a) private key (password protected still, just for laughs)
b) certificate of VPN server
c) certificate of VPN server signer (CA certificate)
I can deliver all this information to the client in a PKCS#12 file.
As you say, the private key can now be impossible (very hard) to crack,
because the client's public key is not accessible (hopefully).
The client now 'connects' to the VPN server to engage in a signature
authentication passing some id.
The problem I have now is mapping that id to the client's public key or
certificate in a manageable way. I hope we can agree that managing
public-key to id mapping can only be handled by using the CA/certificate
approach. For me to be able to find the appropriate certificate, I would
need most of the information typically passed (by the client) in a
certificate.
To back-track a bit. My previous model was to have the VPN client send their
certificate as part of the IKE exchange. This allows me greater flexibility.
If the client did not send their certificate, a simple id (DN, IP, DNS..)
may not be sufficient to resolve the correct certificate.
I think (just made it up, so this is probably tosh but..) what is needed to
fix this is a new type of certificate, a certificate with no public key in
it!
When I enrol, the CA would now generate two sister certificates: one
'public' one, and one 'private' one. The 'public' one would contain now
public key, but would allow the 'private' certificate to be found using the
contain DN/Signer/Serial number.
The VPN client is then loaded with the 'public' certificate, and presents
this to the VPN server. The VPN server uses this certificate (once tested
for trustworthiness) to retrieve the 'private' certificate that does have
the public key.
Even if this makes sense, is it too late?
Steve.
-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Thursday, July 22, 1999 2:39 PM
To: Stephen.Waters@cabletron.com
Cc: dpkemp@missi.ncsc.mil; kent@bbn.com
Subject: Secret public keys
It's not relevant to PKIX anymore, and since I'm not currently subscribed
to IPSEC, I won't start a thread there.
I was suggesting that the client be loaded with the entire private key,
transformed (encrypted) using the password as the encryption key. Assuming
private keys are uniformly distributed, there is no way to tell offline
when the right password is guessed.
And I was suggesting that the "public key" corresponding to the
client's private key not be placed in a certificate or be made public -
it is kept secret as part of the VPN server's user database. This is
precisely Lynn Wheeler's "certificateless account" idea. The server
can authenticate the client using the stored public key without ever
sending it in a cert over the wire. The user may actually have a
certificate and private key which he could use once to sign up for VPN
service, but after that initial enrollment, the enrollment-generated
keypair would be used in the IKE handshake. The user's certified
keypair wouldn't need to be retained on the laptop at all for VPN
purposes, and keeping it there for other purposes would not compromise
the VPN authentication.
Jeff Schiller's procedure mentioned by Steve Kent may increase the
cracking effort by 1000x or 10,000x, but it is only a constant (O(1))
increase. I tend to view subexponential processes with caution, and
an O(1) process as a band-aid. Increasing the length of the password
gives an exponential (O(2^n)) increase in effort, so forcing the user
to remember a longer password has big payoffs, but has even bigger
pushback from users and marketers. Keeping the VPN public key secret
completely precludes offline cracking even with user-friendly short
passwords and without any artificial performance degraders.
Regards,
Dave
> From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
>
> 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.
Follow-Ups: