[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Secret public keys
At 02:08 PM 7/23/99 +0100, Stephen Waters wrote:
>Can you explain this bit "Maybe XAUTH doesn't get us there. But IKE as-is
>doesn't seem
>to do it either."
>
>IKE supports (today) the concept of "secret public keys". It's just a
>signature exchange.
Simple. IKE doesn't yet use secret public keys in a way that protects
low-entropy private keys.
More specifically, IKE does not support a zero-knowledge password
proof, which prevents network disclosure of a small password and at
the same time authenticate the key exchange with the password.
It can be done in several ways, and I thought that the philosophy
motivating XAUTH and the technology of IKE fit particularly well
with EKE-style techniques.
>You are right that password protecting the private information is still the
>weak point, but if the private information is stored in such a way that it
>is not obvious when you have cracked it, the attacker won't know when he has
>the right password.
That's a big IF. Storing the information in a "non obvious" way
still sounds weak to me. Better to not store it locally at all.
I can do this today with well-built password systems, and I'd
rather not be encouraged to take a step backwards to use IPSEC.
To be conservative, one should presume that if software can find
even an obscured locally stored private key, then then an attacker
can too. One should also presume that if it's a user-chosen
key, then it's crackable.
>This is an improvement on what we had before with all the tools (public key
>/cracked-private key) available, but it still relies on the sensible use of
>passwords. Whatever can be used to improve this weakness would be welcome.
What you suggest is not an improvement over all systems.
And your implied meaning of "sensible use" misses the point.
The entire concept of "sensible use of passwords" is relative
to the system in which they're used. Take an ATM machine. A four-digit
password seems to work fine there with appropriate revocation rules.
With better password systems, it becomes much easier to enforce
sensible use rules, which makes it possible for more users to
operate securely.
Deploying a new crypto system that relies on cryptographically-long
passwords for security is a step in the wrong direction, and
introduces unnecessary risk for users in many situations.
>-----Original Message-----
>From: David Jablon [mailto:dpj@world.std.com]
>Sent: Friday, July 23, 1999 1:15 PM
>To: Waters, Stephen
>Cc: David P. Kemp; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org;
>Bussiere, Dick; Bassett, John Robert; Holland, Gary
>Subject: RE: Secret public keys
>
>
>XAUTH notwithstanding, the value of shared secret passwords
>and "secret public keys" is that they allow strong one-to-one
>agreements between a user and a service provider that is
>easy to set up with existing tools, with a large base
>of pre-existing relationships.
>
>Of course, shared-secrets alone, without a complementary PKI,
>don't scale to solve the world's e-commerce problems with
>establishing mutual trust between strangers. But this just
>isn't everyone's goal. Passwords and secret-public-keys are
>immensely practical and useful for securing user-to-provider
>relationships, especially when the number of highly-secure
>provider relationships needed by the typical user is small.
>Think about protecting the one most important site in your
>"single-sign-on" solutiuon.
>
>I believe IKE should be extended to permit strong mutual
>authentication based on low-entropy shared secrets.
>
>Maybe XAUTH doesn't get us there. But IKE as-is doesn't seem
>to do it either.
>
>At 10:17 PM 7/22/99 +0100, Waters, Stephen wrote:
>>David [Kemp], (your note copied below)
>>
>>I am trying to avoid using XAUTH, if possible. If I can get offline
>>cracking protection using an IKE Phase mechanism, that's what I want.
>>
>>We have plans to allow RADIUS servers to provide per-user pre-shared
>secrets
>>for IKE Phase-1 authentication, if that is what the customer wants. If the
>>customer wants legacy, they are probably not going to like PKI in the
>>picture, so our recommendation will be to use per-user pre-shared phase-1
>>and XAUTH for the legacy.
>>
>>If the customer will tolerate PKI, I would like to be able to offer it in a
>>way that was comparable to the strongest legacy authentication they may be
>>using today.
>>
>>The proposal to not load the VPN client with the public key (just private)
>>COULD be handles with RADIUS I guess, with RADIUS used by the VPN server to
>>collect the appropriate public key, but the security manager would need
>some
>>handy way to 'copy' the users' public key from the certificate (or key
>>generation point) to the RADIUS management tool. Not impossible I guess.
>>
>>O.K., so here's a 'from ground up' Private Key Infrastructure:
>>
>>1) Go to RADIUS tool. Add client stephen.waters@ctron.com
>>2) Push 'generate key pair' and public key is stored in association with
>new
>>client
>>3) Push 'build client file' and a file is generated with the private-key
>>(password protected), appropriate VPN server public key and ID (also
>>password protected), and client id to present when connecting
>>(stephen.waters@ctron.com), VPN server address, other stuff on
>>policy/proposals maybe.
>>
>>Client device is now loaded with the file. Connects to VPN server,
>presents
>>id and engages in a signature exchange. VPN server calls to RADIUS using
>>provided id to collect public key to complete Phase1.
>>
>>Revoking involves deleting the RADIUS entry. The VPN server keeps no cache.
>>
>>I think I like it :) No off-line cracking, no CRL problems, no new
>>protocols, no XAUTH/legacy, no Smartcards, no trust trees, no real password
>>problem, no CA.
>
>Here's one problem: Password-encrypted local data may be inadequate
>protection for the safety of locally stored credentials.
>
>David Kemp wrote:
>>From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
>>Sent: Thursday, July 22, 1999 8:41 PM
>>To: dpkemp@missi.ncsc.mil; Stephen.Waters@cabletron.com
>>Cc: ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org
>>Subject: RE: Secret public keys
>> [...]
>>The question that began this thread was "does IKE+XAUTH have any
>>value-added over IKE alone?" It's obvious that managing secrets
>>is more difficult than managing public data. But I believe that
>>regardless of whether you choose to use secret information on the
>>server to eliminate the possibility of offline password guessing
>>attacks on the client, a secondary authentication exchange is
>>superfluous. Whatever the requirements are, they can be satisfied
>>within IKE.
>
>Even if we ignore obvious out-of-scope issues that IKE was
>never designed to solve, I think the last statement goes too far.
>IKE can certainly be further extended or improved to better use
>and protect low-entropy shared secrets.
>
>I have no opinion on whether IKE+XAUTH has value over IKE as-is.
>I do know that XAUTH doesn't address the mutual authentication
>issue in using low-entropy shared-secrets to strengthen the
>key exchange. IKE could be extended to use "legacy" credentials
>in a stronger way, with a password-authenticated key exchange.
>This would provide another factor for mutual authentication,
>and at the same time prevent yet another potential path
>for disclosure of these secrets.
>
>I think these are worthy goals.
>
>-- dpj
>
>---------------------------------------------------
>David P. Jablon dpj@IntegritySciences.com
>President +1 508 898 9024
>Integrity Sciences, Inc. www.IntegritySciences.com
Follow-Ups:
References: