Hi, Dan: Thanks for your comments. Please check my comments inline which is identified by [Richard].
2009/7/28 Dan Harkins <[email protected]> > > Hi Richard, > > [Dan] On slide 11 you say you want to reuse the AAA architecture. > But EAP is not a AAA protocol. RADIUS is but you don't want to > use RADIUS. So I don't understand what reuse you're hoping to > take advantage of. ////////////////////////////////////////////////////////////////////////// [Richard] Yes, I want to reuse the AAA architecture. This is a main objective and the reason for it is described on the slide 9. For the reusing, there are two methods. One is the Radius property extension and it is a direct way to reuse the AAA; Another way is to make the WAI over EAP. As the Radius has a EAP property, so WAI over EAP establish a bridge to reuse the AAA. > > [Dan]Since EAP doesn't have a transport how do you propose to send > EAP packets from the AP to the server? Over UDP port 3810? The > same port you send WAI packets to now? If that's the case then > all EAP is doing is providing a needless encapsulation of your > WAI packet. You gain nothing by encapsulating your WAI packet > with an EAP header. //////////////////////////////////////////////////////////////////////// > [ Richard] When using the WAI over EAP, the AP would transport EAP packet (contains WAI) over Radius. Also, Please check my last email: It compares the solutions of the Radius Property extension with the WAI over EAP. The main advantage of WAI over EAP is to keep the loose coupling between the AAA and the WAPI. The reason is: Radius server need not check things going on with WAPI. (EAP-WAI). There is a standard interface (EAP-SUCCESS or EAP-FAILURE) to let Radius know the result of the authentication. From the AAA server perspective, like the other authentication methods such as EAP- TLS, there is no any special handle required for EAP-WAI. [Dan] I do have a suggestion to fix this problem. Just get rid of the "certificate authentication" exchange and have the client validate the AP's certificate and the AP validate the client's certificate. It is not necessary to have a central authority to approve of certificates, that's the whole point in using certificates. /////////////////////////////////////////////////////////////////// [ Richard] Yes, your suggestion could work well without a a central authority involved. While the current problem I try to resolve is: The WAPI protocol already exist (it needs a central authority to valide the certificate), to support (follow) it and enable it work well under the AAA architecture, I brougt forward the method of WAI over EAP. To avoid the change of the station, and minimize the influnce to the customers, the solution would only change the packet between AP (authenticator) and AAA server. To achieve this objective and avoid the influnce to the AAA, the AP should minic the station. For the WAPI protocol, please see the slide 7. > > > regards, > > Dan. > > On Mon, July 27, 2009 7:54 am, Richard wrote: > > Hi, all: > > > > The link to the slide: > > http://www.ietf.org/proceedings/75/slides/emu-10.ppt > > Thanks for your comments in the EMU session. > > > > Yes, the Radius property extension could be one solution. > > The problem to it is: > > The Radius has to handle the WAPI packet (Certificate authentication > > response), > > it would lead to the tight coupling between Radius and WAPI (ASE). > > > > Compared to it, the EAP solution is simple and make it loose coupling > with > > WAPI. > > Radius server need not check things going on with WAPI. (EAP-WAI). > > There is a standard interface to let Radius to know the result > > of authentication (EAP-SUCCESS or EAP-FAILURE). > > From the AAA server perspective, there is no any special for EAP-WAI > > to the other authentication methods such as EAP-TLS. > > The loose coupling for EAP solution is a main advantage to the Radius > > extension > > method. > > > > Yes, the EAP framework is to authenticate the station (supplicant). I > > guess > > the > > main reason is that most authentication methods are to authenticate the > > supplicant, > > and the behavior of Authenticator is pass-through. > > Now, WAPI is a use case of authenticating the authenticator (the behavior > > of > > Authenticator > > is not Pass-through). And it may have more protocols which have similar > > behavior > > (use cases) like the WAPI. > > Could we allow the EAP method behavior like the WAI over EAP instead of > > forbidding it? > > > > Any way, the problem I am trying to resolve is to reuse the AAA and > > avoid the tight coupling between Radius and WAPI (ASE). > > > > Do you have any better solution to it? > > > > Regards > > Richard > > _______________________________________________ > > Emu mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/emu > > > > >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
