I have an added worry in that an additional "attacker" that I worry about is a stupid or slightly incorrectly encoded client. This means that part of what I worry about is what happens if the client decides to drop an EAP message for some unknown reason that may or may not be a correct thing for it to do.
A RADIUS server will not cause a re-transmission on a timeout because it only operates in a response mode. That is the client is always the entity that sends a request that RADIUS server responds to. However the RADIUS server will have cached the last message it sent out. The acceptor (GSS-API RP) is not currently setup to deal with re-transmission of EAP messages in either direction. The initiator is the one which dropped the EAP message on the floor when it received the GSS-API wrapper on the message. It is not clear that it has anything to send to the acceptor to trigger the RADIUS messages from the acceptor to the RADIUS server. It is not clear that the GSS-API acceptor would send a new RADIUS message to the RADIUS server unless there is an EAP component to the GSS-API message sent from the initiator to the acceptor. Jim -----Original Message----- From: Alan DeKok [mailto:[email protected]] Sent: Monday, October 29, 2012 7:30 AM To: Sam Hartman Cc: Alper Yegin; Jim Schaad; [email protected] Subject: Re: [abfab] EAP Applicability: retransmissions Sam Hartman wrote: > As part of writing this reply I realized that I don't fully understand > how this works at the AAA layer. > Alan, what happens when a RADIUS server gets an access request and the > EAP layer doesn't produce an EAP message? I'm presuming that this is the EAP side on the RADIUS server. The answer is that the RADIUS server really *should* respond to the Access-Request. Without any EAP data, the only thing it can return is Access-Reject. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
