Hi Alan, On 8/21/20 3:50 PM, Alan DeKok wrote: > 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. Not sure what you are nit picking. Because you essentially agree that they are independent components yet tightly integrated in most implementations. > > 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. I bow to you and Jouni for all the hard work in maintaining these excellent pieces of software. > >> 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.
Sorry, but you are missing context here. The discussion was no longer about sending an EAP failure when no suitable EAP methods are available. Terry and I were discussing the direction of NAK messages in an EAP conversation. I highlighted that a NAK is only sent by the peer to the server (and not in the reverse direction). To this, Terry pointed to the following text in RFC 3579 Section 2.6.2 titled "Role Reversal": > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction. Both peers > may act as authenticators and authenticatees at the same time. > > However, role reversal is not supported by this specification. A > RADIUS server MUST respond to an Access-Request encapsulating an > EAP-Request with an Access-Reject. In order to avoid retransmissions > by the peer, the Access-Reject SHOULD include an EAP-Response/Nak > packet indicating no preferred method, encapsulated within > EAP-Message attribute(s). It may seem from this text that a NAK is sent in the reverse direction (i.e. from server to peer). But I was pointing to Terry that this NAK is sent by the RADIUS server (and not the EAP server). So the fact that NAK messages are sent by the EAP peer only still holds true. This protection against retransmissions is not implemented in hostap ( as you can see in https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437) or FreeRADIUS. I suspect because deployments don't encounter this kind of role reversal in practice. --Mohit > > Alan DeKok. > > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
