Hi,
In short, this mail is about EAP methods
accessing/using the EAP identifier field.
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.
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.
I see basically three ways to do so:
1) RADIUS tells the EAP method the value of the EAP
Identifier field of the EAP request packet it will
send. Pros: simple and logical Cons: I don't see any
apart from that this is not the way it works under
Freeradius.
2) The EAP method guesses the value of the EAP
Identifier field of the EAP request packet it will
send. Pros: this is the easiest tweak I have found to
make things work under Freeradius (details given
below). Cons: this is not portable and if Freeradius
changes its behavior my method will make the wrong
guesses.
3) The EAP method is allowed to choose the value of
the EAP Identifier field of the EAP request packet it
will be sent in. Pros: it works and is portable Cons:
the EAP method has to make sure the identifier it
chooses does not collide with the previous identifier…
I made some investigations before coming to solution
#2. After testing the id field in the EAP_PACKET
structure (defined in eap_types.h), it appeared that
this field didn't match with the EAP identifier which
was in the sent EAP request (precluding solution #3).
I did not find how to have solution #1 work under
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.
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. 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."
Any feedback is of course most welcome.
Aurélien
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
