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

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