Re: Radius authentication and client configuration
Vipul Gupta <vgupta@nobel.Eng.Sun.COM> Fri, 17 April 1998 12:08 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20545 for ipsec-outgoing; Fri, 17 Apr 1998 08:08:46 -0400 (EDT)
Date: Thu, 16 Apr 1998 14:34:07 -0700
From: Vipul Gupta <vgupta@nobel.Eng.Sun.COM>
Reply-To: Vipul Gupta <vgupta@nobel.Eng.Sun.COM>
Subject: Re: Radius authentication and client configuration
To: Patrice.Calhoun@Eng.Sun.Com
Cc: smamros@BayNetworks.COM, gab@Eng.Sun.Com, ipsec@tis.com, periera@TimeStep.com, rgm-sec@htt-consult.com
Message-ID: <libSDtMail.9804161434.2238.vgupta@nobel>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: p7V7t+Wo8NW+MOsXkjEUQg==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
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
- Radius authentication and client configuration Leonard Schwartz
- Re: Radius authentication and client configuration Robert Moskowitz
- Re: Radius authentication and client configuration pcalhoun@eng.sun.com
- Re: Radius authentication and client configuration Robert Moskowitz
- Re: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration Roy Pereira
- RE: Radius authentication and client configuration pcalhoun@eng.sun.com
- Re: Radius authentication and client configuration Shawn Mamros
- Re: Radius authentication and client configuration Gabriel Montenegro
- Re: Radius authentication and client configuration Robert Moskowitz
- Re: Radius authentication and client configuration Robert Moskowitz
- Re: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration Roy Pereira
- Re: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration Roy Pereira
- RE: Radius authentication and client configuration Roy Pereira
- RE: Radius authentication and client configuration Roy Pereira
- Re: Radius authentication and client configuration Shawn Mamros
- Re: Radius authentication and client configuration Vipul Gupta
- RE: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration pcalhoun@eng.sun.com
- RE: Radius authentication and client configuration pcalhoun@eng.sun.com