> From: BUTTI Laurent FTRD/DTL/ISS [mailto:laurent.butti@;rd.francetelecom.com]
> Sent: den 13 november 2002 18:43
> To: [EMAIL PROTECTED]
> Subject: EAP-TLS re-keying
> I have an Orinoco AP-2000 (2.0.2) and a windows XP client SP1.
> MPPE-{Send/Recv}-key seems to be successfully interpreted by the
> AP-2000, as 3 EAPOL-Key frames are sent to the client.
The access points we have tested seem to send two EAPOL-Key messages,
one with the unicast key and one with a broadcast (default) key.
What are key index fields in the three messages you see? Does the AP
send two broadcast (default) keys with different indexes?
> So this scheme is
> different than Cisco's scheme that seems to send only one EAPOL-Key
> according to Lars Viklund.
Not quite. It will send (at least) two EAPOL-Key messages but the unicast
one does not include the actual key.
> Moreover, re-keying seems to work by configuring a short key lifetime on
> AP-2000, every time t : 3 new EAPOL-Key frames are sent from AP-2000 to
> WinXP client.
> What i'm trying to do is : validating that the new WEP key sent by
> AP-2000 using EAPOL-Key is really used.
> I have several questions / remarks :
> * Sending a new WEP key doesn't prove that it is really used on both
> client and access point sides. It should be dependent on both hardware
> (as WEP ciphering should be done in firmware WLAN card, so WLAN card
> drivers must support 802.1X) and software in Windows XP.
True, although if your traffic is WEP encrypted and still gets through after
the rekeying then either the new keys are used on both sides or not at all.
> * I didn't tested re-keying on Cisco, but if Cisco use MPPE-Send-Key to
> have data-link ciphering with WEP (truncating the MPPE-Send key); it is
> necessary to have a full re-authentication if we want a real
> "re-keying", am i wrong ?
I think you're correct. One could think of other schemes that would handle
this though, see this thread for instance:
http://www.mail-archive.com/freeradius-users@;lists.cistron.nl/msg07532.html
> * Do you know any tip to validate that ?
> - By using NDIS hooking ?
Probably possible but I have no idea how.
> - By any debug mode on AP-2000 ?
Since you obviously don't trust the AP-2000 to use the new keys after it has
sent the new EAPOL-Key messages, would you trust debug output from it? :-)
> - Any other idea ?
You could:
Test with xsupplicant instead of Win XP. That way you can easily
verify that the supplicant actually changes the keys when it receives
the new EAPOL-Key messages.
or
Get the MPPE-{Send/Recv}-Keys generated by the RADIUS server, e.g.
by having the rlm_eap_tls module log them. Capture the EAPOL-Key
messages sent by the AP and decrypt the key fields to get the WEP
keys. Capture data frames sent between the AP and the STA, decrypt
them and verify the ICV (or verify that the MSDU is correct some
other way).
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html