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

RE: Secret public keys



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.

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. 

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.

Any comments from Smartcard folk on the prospect of bomb-proof biometric
cards? 

Cheers, Steve.

-----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: