[EMAIL PROTECTED] wrote:
> Well, I would like to have further details:
See the source code.
> 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 ?
Yes.
> And more generally,
> how this "garbage collector" works ?
See the source code in rlm_eap/
> > > 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 ?
I've fixed it in the latest CVS snapshot.
> 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.
See the data structures in rlm_eap. You have access to the previous
EAP packet, so you can re-send it.
As for updating the ID, you have access to the source. Update the
EAP_PACKET structure with information as to whether or not the main
eap code should set the identifier, and then modify that code to check
for the new flag.
> 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 ?
Not if you set it to something using the above method.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
