> > 1) When the client doesn't respond, the AP will > > dissassociate it 30 seconds after and end the > > authentication procedure. During this time, > FreeRADIUS > > is sleeping So, I would like to know if there is a > > sort of "garbage collector" which frees unfinished > > authentications ? > > Yes.
Well, I would like to have further details: The AP doesn't signal to the FreeRADIUS server that an authentication has failed. Is there a timer which is armed when a session is created ? And more generally, how this "garbage collector" works ? > > > 2) My EAP module must return 0 or 1 to FreeRADIUS. > If > > it is 1, it siginifies that there is an EAP > Request to > > send. I tried to send an EAP Message with the code > > equal to 5: FreeRADIUS detected correctly that the > EAP > > Code was invalid : it sent an Access-Reject but > the > > included EAP message was corrupted : 0x05050004 ! > > Why not sending an EAP Failure in this case ? > > It looks like a bug. About this bug, would you like more precisions in order to solve it ? Is it planned to fix this bug ? > > > 3) It seems that it's impossible to silently > discard a > > packet under FreeRADIUS ? > > The RFC's say you're not allowed to silently > discard Access-Request > packets. > > > In case of a client bad EAP Response, my EAP > method > > has to choose between two solutions : discard it > > silently or re send the previous EAP Request. > > Which EAP method are you implementing? Why is > this necessary? > > Note that you also have access to the previous EAP > request. > We're implementing a Pre-Shared Key (PSK) method whose name is EAP-PSK. EAP-PSK is a new EAP method which performs mutual authentication and session key derivation. Using a pre-shared key, EAP-PSK is intended to be easy to deploy and well-suited for authentication over insecure networks such as 802.11. Another goal is to motivate work on replacing EAP-MD5 which is deprecated due to security reasons in wireless context. For more detail: http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK.htm We intend to publish the first EAP-PSK implementation in the next weeks. Silently discard the bad EAP Response isn't the best solution. As you wrote, the EAP method could easily re send the previous packet: it's well suited ! But how is managed the EAP identifier in this case ? The RFC 2284bis specifies that the EAP identifier MUST be the same in case of retransmissions. > > 4) I succeeded to modify the EAP Identifier on the > > client side, but I didn't arrive in my EAP module. > It > > seems that FreeRADIUS choses the EAP Identifier by > > incrementing by one the previous sent EAP > Identifier. > > Is it really that ? > > Yes. > > Why do you need it different? After reading the Packet modification attacks paragraph in the RFC 2284bis ("It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type and Type-Data fields."), we would like to protect the EAP header. Doing that implies the EAP method will have to guess the value of the EAP Identifier field of the next EAP Request packet ? Aurelien Magniez Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Cr�ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr�ce � Yahoo! Messenger !T�l�chargez Yahoo! Messenger sur http://fr.messenger.yahoo.com - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
