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

RE: Secret public keys

On Fri, 23 Jul 1999, David Jablon wrote:

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

Strong authentication may often be necessary in one way in e-Commerce.
When a consumer buys soemthing, it's important to authenticate the seller 
online.  However, only the buyer's payment (credit card num) is important 
to the seller.

> 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@xxxxxxxxx
> >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@xxxxxxxxx), 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@xxxxxxxxxxxxxx]
> >Sent: Thursday, July 22, 1999 8:41 PM
> >To: dpkemp@xxxxxxxxxxxxxx; Stephen.Waters@xxxxxxxxxxxxx
> >Cc: ipsec@xxxxxxxxxxxxxxxxx; ietf-ipsra@xxxxxxxx
> >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@xxxxxxxxxxxxxxxxxxxxx
> President                 +1 508 898 9024
> Integrity Sciences, Inc.  www.IntegritySciences.com