On Aug 21, 2020, at 3:27 AM, Mohit Sethi M <[email protected]> wrote: > Sorry for nitpicking here. But it is important to distinguish the two > components that comprise a AAA server: RADIUS server and EAP server. RFC > 3579 briefly alludes to this difference and uses different terms for a > RADIUS server and an EAP server. Sure, they will likely run on the same > machine and are tightly integrated, yet they are independent components.
Some minor nit picking here... In practice, EAP servers are tightly coupled with RADIUS servers. At least for ones which implement non-trivial EAP methods. But I agree that they need to be treated as independent components. FWIW, I've looked for EAP server implementations. As best I can tell for Open Source, it's just hostap and FreeRADIUS. Everything else is either dead, or implements only a tiny subset of EAP, such as EAP-MD5. > The text you point to in RFC 3579 doesn't imply that the NAK is sent > from the EAP server. It only says that to avoid retransmissions, a > RADIUS server should generate an Access-Reject containing a > EAP-Response/Nak on its own (without involving the EAP server). So > technically, this NAK is still not sent by the EAP server in the > so-called 'wrong direction'. In common realistic implementations, RADIUS > servers only proxy data to/from the EAP server I'm wary of the word "proxy". Proxying implies some kind of transport, as with RADIUS proxying. The public implementations of RADIUS+EAP have the two components in the same process, using shared libraries. The interaction between the two is just API calls. > and do not generally > inject EAP packets on their own. Which is why I suspect that this is not > implemented in the radius server of hostap: > https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437 The RADIUS side of hostap doesn't inject the EAP Failure. The underlying EAP implementation injects it. The eap_sm_Policy_getDecision() function returns failure if there are no compatible EAP methods. The calling function then returns EAP Failure. https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server.c#n1722 The EAP server implementation in FreeRADIUS also returns an EAP Failure packet if there are no compatible EAP methods. The underlying principle here is that silently dropping packets is considered bad. Therefore, no matter what happens inside of the EAP state machine, the outcome is one of 3 things: * more EAP negotiation * Success * Failure The only time the RADIUS side injects an EAP Failure is if the session is rejected for administrative reasons. And, the EAP state machine is bypassed. e.g. deny this particular user on this particular device, even if their EAP credentials are OK. In that case, the EAP stack is bypassed. The Access-Reject handler checks for an EAP-Message in the Access-Request. If found, the RADIUS layer synthesizes an EAP Failure inside of an EAP-Message. Since hostap doesn't really have policies in it's RADIUS server implementation, it doesn't implement this check. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
