RE: Question about Extended Authentication in IKE
Tim Jenkins <tjenkins@TimeStep.com> Mon, 22 February 1999 16:37 UTC
Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20287; Mon, 22 Feb 1999 08:37:49 -0800 (PST)
Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13041 for ipsec-outgoing; Mon, 22 Feb 1999 08:13:23 -0500 (EST)
Message-Id: <319A1C5F94C8D11192DE00805FBBADDF83EE0B@exchange>
From: Tim Jenkins <tjenkins@TimeStep.com>
To: Waters Stephen <stephen.Waters@cabletron.com>, ipsec@tis.com
Subject: RE: Question about Extended Authentication in IKE
Date: Mon, 22 Feb 1999 08:35:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
To address scalability and not use pre-shared keys, you could use one of the hybrid authentication mechanisms described in <draft-ietf-ipsec-isakmp-hybrid-auth-01.txt>. This allows the gateway (the responder) to have a certificate, and be authenticated using that. The client (the initiator) would use extended authentication to be authenticated by the gateway. While the client implementation still has to know how to deal with certificates, it does not actually have to have certificates, allowing remote users to be authenticated using only (perhaps existing) legacy mechanisms. Distribution and management of client certificates becomes unnecessary. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Waters Stephen [mailto:stephen.Waters@cabletron.com] > Sent: Monday, February 22, 1999 5:21 AM > To: ipsec@tis.com > Subject: Question about Extended Authentication in IKE > > > An extract from the draft : > "This protocol can therefore be used in conjunction with any > existing basic > ISAKMP authentication method as defined in [IKE]. If mutual > authentication > is not required, then the phase 1 negotiation SHOULD use an > authentication > method of shared-secret and have that shared-secret be null. This, is > however, NOT suggested since the edge-device is NOT authenticated. > This authentication MUST be used after a phase 1 exchange has > completed and > before a phase 2 exchange. The Transaction exchange is > therefore attached > (appended) to the phase 1 exchanges (MainMode, AggressiveMode). If the > extended authentication fails, then the phase 1 SA MUST be deleted." > > Hi, > If I want to use RADIUS to scale my IPSEC remote access, I > could use IKECFG > messages to do that. Since the draft suggests that NULL Phase-1 > authentication is "NOT suggested", then the problem is how > to scale the > Phase-1 authentication? > Assuming I still use pre-sharded secret, then I would HAVE to use > Aggresvice-mode, AND have a way of finding the appropriate > pre-shard secret > for each client. Can I use this same mechanism to retrieve > pre-sharded > secret information (which I may cache I guess)? > If I went for signature authentication (certificates), why > should I consider > using any other form of authentication? > Cheers, Steve. > > > * Stephen Waters > Cabletron Systems Ltd. - R&D > Unit 1, Heron Industrial Estate > Basingstoke Road, Spencers Wood > Reading, Berkshire, RG7 1PJ > > * External number: +44 118 988 0024 > Internal extension: 12024 > External fax: +44 118 988 0001 > > * Stephen.Waters@ctron.com > >
- Question about Extended Authentication in IKE Waters Stephen
- RE: Question about Extended Authentication in IKE Tim Jenkins