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
