> -----Original Message----- > From: Richard [mailto:[email protected]] > Sent: Monday, July 27, 2009 2:57 PM > To: Dan Harkins > Cc: Joseph Salowey (jsalowey); [email protected]; > [email protected] > Subject: Re: [Emu] If we use the Radius property extension > > 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. > [Joe] EAP is a protocol to authenticate an EAP Peer that communicates between the EAP Peer and an EAP Server. EAP is not an alternative to a AAA protocol.
> > [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. > [Joe] EAP-Success and EAP-Failure are not part of RADIUS. They are part of EAP messages that are for the peer, which is the client being authenticated. RADIUS has an Access-Accept and Access-Reject messages for informing the RADIUS client of its decision. Your proposal does not appear to be an authentication mechanism like EAP-TLS since it does not communicate with the peer. Can you give an example of what you mean by loose coupling between AAA and WAPI? > [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. > [Joe] This is not the way EAP works currently. EAP is a protocol that involves the peer. If you have the authenticator mimic the peer then it is not EAP in its current form. > > > > 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
