[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on a second IPSec algorithm
At 03:19 PM 7/17/99 -0400, William Allen Simpson wrote:
>It seems I'm missing some of the messages in this thread, or the thread was
>renamed too many times, but while I agree that From owner-ipsec Thu Jul 22 17:19:07 1999
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01393
Thu, 22 Jul 1999 17:17:54 -0400 (EDT)
Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBE64@new-exc1.ctron.com>
From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org,
"Bussiere, Dick"
<bussiere@cabletron.com>,
"Bassett, John Robert"
<john.bassett@cabletron.com>,
"Holland, Gary"
<Gary.Holland@cabletron.com>
Subject: RE: Secret public keys
Date: Thu, 22 Jul 1999 22:17:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
David, (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.
Something must be wrong! At the very least, a lot of people are going to be
miffed it this works :) Sorry, I'm not being flippant, it's just late here
and I've started to giggle at the apparent relief this offers. I know it
won't last long.
Steve.
-----Original Message-----
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
> From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
>
> 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.
It seems to me that the client must pass some sort of ID to the server,
and that the server must have some sort of client-specific data that is
*not* contained in a public certificate to enable XAUTH to work. You
mentioned a large shared-secret value which could be unlocked on the
client by use of a short password; how is that shared-secret made known
to the server, in a manageable way? If shared-secrets are manageable,
then a certificateless secret public key is just as manageable, using
the identical procedures.
Please describe exactly the steps you proposed for enabling a secondary
authentication exchange (XAUTH). What data is stored on the client,
what is stored on the server, and what flows between them during the
IKE and XAUTH exchanges?
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.
References: