Hi again, On 8/23/20 7:12 PM, Alan DeKok wrote: > On Aug 23, 2020, at 9:48 AM, Mohit Sethi M <[email protected]> wrote: >> 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": > Ok. > >>> 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). > FreeRADIUS allows EAP-Request, largely for LEAP. Tho TBH that should > probably be deleted. > >> 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. > Yes, I haven't seen EAP -Request sent to RADIUS servers, other than for > LEAP. > > I'm not sure what you mean by "protection against retransmissions" though.
Well. I am referring to the text from the RFC 3579: "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 is clear that hostap does not (yet) implement this SHOULD. I suspect that FreeRADIUS doesn't either. Maybe that's because it needs to allow role reversal (i.e. peer sending an EAP-Request) for LEAP? --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
