Re: Radius authentication and client configuration

["[e-mail]" <[e-mail]>]

> > By placing policy/configuration setup in ISAKMP (between Phases 1 and 2)
> > under protection of the ISAKMP SA, Roy's proposal for an ISAKMP Configuration
> > Method addresses the security needs quite nicely.  That's not to say that
> > one couldn't base the payload/exchange format on DIAMETER or whatever else
> > is already out there.  But the ISAKMP SA only protects ISAKMP, and until the
> > IPSEC SAs are set up, ISAKMP may very well be all you can trust.
> 
> Agree.
> 
> 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