[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Radius authentication and client configuration
> > 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
Follow-Ups: