Re: Radius authentication and client configuration

"pcalhoun@eng.sun.com" <Patrice.Calhoun@Eng.Sun.Com> Thu, 16 April 1998 21:54 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14990 for ipsec-outgoing; Thu, 16 Apr 1998 17:54:40 -0400 (EDT)
Date: Thu, 16 Apr 1998 15:07:16 -0700
From: "pcalhoun@eng.sun.com" <Patrice.Calhoun@Eng.Sun.Com>
Reply-To: "pcalhoun@eng.sun.com" <Patrice.Calhoun@Eng.Sun.Com>
Subject: Re: Radius authentication and client configuration
To: Vipul Gupta <vgupta@nobel.Eng.Sun.COM>
Cc: Patrice.Calhoun@Eng.Sun.Com, smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com
In-Reply-To: "Your message with ID" <libSDtMail.9804161434.2238.vgupta@nobel>
Message-ID: <Roam.SIMCSD.2.0.4.892764436.9201.pcalhoun@hsmpka>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

> 
> 
> > > It seems like the *cfg* and *xauth* drafts  may just take existing
> payloads > > defined elsewhere to achieve their purposes. For example, xauth
> > > could just say: let's use EAP payloads (as I suggested
> > > in LA). EAP did start in ppp land, but has since been applied to
> > > (that is, its payloads have been reused in) SOCKS, RADIUS, DIAMETER.
> > > 
> > > So yes, if a good payload exists, reuse it.
> > > 
> > > -gabriel
> > > 
> > I would like to second Gabriel's statement here. I also would strongly favor
> > the use of EAP as opposed to another mechanism. If you take a look at
> > draft-calhoun-diameter-eap-01.txt and draft-ietf-radius-eap-02.txt you will
> > see how EAP fits into the Policy infrastructure.
> > 
> > In addition, my draft draft-ietf-aft-socks-eap-00.txt proves that EAP is not a
> > PPP-only protocol and can be re-used in a variety of services. I would hope
> > that IPSEC would be a good candidate. (btw, there already exists an ISAKMP
> > extension to EAP that you may want to take a look at -
> > draft-ietf-pppext-eapisakmp-00.txt).
> > 
> > PatC
> > 
> 
>   IMO, draft-ietf-pppext-eapisakmp-00.txt solves a different problem
>   than what Roy's *xauth* draft is addressing. With most other
>   EAP methods (e.g. token cards), only one of the parties is authenticated
>   (client to the server but not mutual authentication) and
> *pppext-eapisakmp-* 
>   and *pppext-eaptls-02.txt are attempts to fix that.
> 
>   Roy's draft, on the other hand, is trying to tie in existing
>   *user authentication* mechanisms (like OTPs and Token cards) with
>   IPSec.
> 
>   vipul

Agreed. I threw out the eap-isakmp draft in order to make the list aware of
it. As for Roy's intent to tie it in with existing token/smart cards I would
not recommend this. The problem that we are currently faced with is that it
requires vendors to include proprietary code from token/smart card vendors and
ties them into a single solution. EAP will provide vendors with the ability to
support ANY token/smart cards that support EAP.

PatC