On Thu, 2002-11-14 at 13:22, BUTTI Laurent FTRD/DTL/ISS wrote: > My Orinoco AP-2000 seems to send 2 broadcast and 1 unicast WEP keys.
ok. I don't really see the point in distributing more than one broadcast key, but of course it nothing wrong with doing it. > > Not quite. It will send (at least) two EAPOL-Key messages but the > unicast > > one does not include the actual key. > > Ok. > Do you have any traces ? I would want to know how different EAPOL-Key > frames are > different from > Orinoco and Cisco... I don't have the traces handy right now. I'll dig them out and send them tomorrow. > > > * 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.h > tml > <http://www.mail-archive.com/freeradius-users@;lists.cistron.nl/msg07532. > html> > > So supplicants must support these different scheme, for migitating > interoperability issues. It is > probably the case for WindowsXP, what about Xsupplicant ? What I meant to say is that the problem _could_ be solved in other ways. As far as I know the scheme discussed in the thread I referenced isn't actually implemented by anyone. > Moreover, firmware and drivers of WLAN cards should be critical for > re-keying, as > 802.1X support > must be acheived, but not re-keying in my opinion (only i/o instructions > to > change/delete/bind keys, but no management of 802.1X > state). Am i wrong ? You are right. > > 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). > > Ok. > > Validation of re-keying should work as follows : > - Decrypt MPPE-Send-key in RADIUS frames by using shared secret. Yes. Although it may be quicker to modify the rlm_eap_tls module to log the keys it sends instead (just a couple of lines of code). > - Find WEP keys : > - If Cisco : Truncate MPPE-Send-Key previously found to the WEP key > lenght, > for Unicast WEP key. And decrypt EAPOL-Key {Broadcast}with > MPPE-Send-Key, to find > WEP broadcast key. > - If Orinoco : Decrypt EAPOL-Key { Unicast | Broadcast } with > MPPE-Send-Key. Or rather, if the Key field is present decrypt it to find the WEP key, otherwise truncate the MS-MPPE-Send-Key to the correct length to get the WEP key. Also, if the Key field is present it is encrypted with the Key IV field concatenated with the MS-MPPE-Recv-Key (not with the MS-MPPE-Send-Key). > - Decrypt data link WEP-protected frames by using previously recovered > keying > material. Yes. > This should work with every Supplicant <=> Authenticator <=> > Authentication > Server, without any trust of any entity. Yes. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
