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. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
