=?iso-8859-1?q?Aurelien=20Magniez?= <[EMAIL PROTECTED]> wrote:
> In details, 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."), I wondered how
> the EAP Identifier field was managed under FreeRADIUS.Internally, automatically. > Indeed, I'm working on a pre-shared key EAP method and > I would like to protect the EAP header thanks to a MAC > calculated by my method. To do so, my method needs to > know the value of the EAP Identifier field of the EAP > request packet it will be sent in. The data structures give you access to the previous identifier, so you can use that to calculate the next one. If your method always uses an incrementing identifier, you can use that knowledge to calculate the MAC. > Freeradius. Solution #2 works out fine since > Freeradius seems to calculate the value of the EAP > Identifier field of the EAP request packet it will > send by incrementing the previous one by one. Yes. > Practically in a WLAN scenario, the first EAP message > received by Freeradius is generally an EAP > Response/Identity sent by the AP. Thus the AP dictates > the intial value FreeRADIUS increments later on. Yes. > This > behavior of Freeradius, though allowed, is however not > the one recommended by RFC 2284bis : "The value of the > EAP Identifier field of the EAP request packet it will > send. One way to achieve this is to start the > Identifier at an initial value and increment it for > each new Request. Initializing the first Identifier > with a random number rather than starting from zero is > recommended, since it makes sequence attacks somewhat > harder." The problem is that the client sends the initial EAP packet, with a particular identitifier value. It then *also* expects a particular identifier value back from FreeRADIUS. So the "incrementing" by FreeRADIUS isn't done to follow the RFC's, it's done to match the clients expectations. If FreeRADIUS were to send *another* identifier back, many clients wouldn't like it, and would discard it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
