Lars Viklund wrote:
> > From: BUTTI Laurent FTRD/DTL/ISS [mailto:[EMAIL PROTECTED]]
> > 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?
My Orinoco AP-2000 seems to send 2 broadcast and 1 unicast WEP keys.
Here are the traces for an initial keying after a successfull EAP-TLS
authentication.
802.1x Authentication
Version: 1
Type: Key (3)
Length: 57
Descriptor Type: RC4 Descriptor (1)
Key Length: 13
Replay Counter: 3844640523
Key IV: FF5A8453760BA763EB1A04070B77DD47
Key Index: broadcast, index 1
0... .... = Key Type: Broadcast
.000 0001 = Index Number: 1
Key Signature: EEEB7687AA424A123EE20FC34AD53FB6
Key: 375A03B7BB970A56ACEC7092A5
802.1x Authentication
Version: 1
Type: Key (3)
Length: 57
Descriptor Type: RC4 Descriptor (1)
Key Length: 13
Replay Counter: 3844640524
Key IV: 1111CF5B6848011DD247172F4628C84E
Key Index: broadcast, index 2
0... .... = Key Type: Broadcast
.000 0010 = Index Number: 2
Key Signature: 79E049C2817466D9881D19C05C9622EB
Key: 11783D8CCB33AB3180A58F788A
802.1x Authentication
Version: 1
Type: Key (3)
Length: 57
Descriptor Type: RC4 Descriptor (1)
Key Length: 13
Replay Counter: 3844640525
Key IV: 862BA342195D65012B13015690511703
Key Index: unicast, index 3
1... .... = Key Type: Unicast
.000 0011 = Index Number: 3
Key Signature: F6CB7F53149B4B375224020B6424805B
Key: F272AC9CBFF69589D11805C94C
>
>
> > 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.
Ok.
Do you have any traces ? I would want to know how different EAPOL-Key frames are
different from
Orinoco and Cisco...
>
>
> > 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
So supplicants must support these different scheme, for migitating
interoperability issues. It is
probably the case for WindowsXP, what about Xsupplicant ?
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 ?
>
>
> > * 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? :-)
I shouldn't trust Microsoft as well ;)
>
>
> > - 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.
I will test it as soon as possible.
>
>
> 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.
- 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.
- Decrypt data link WEP-protected frames by using previously recovered keying
material.
This should work with every Supplicant <=> Authenticator <=> Authentication
Server, without any trust of any entity.
Thank you,
Best Regards,
Laurent.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Laurent BUTTI
& france telecom / FTR&D / DTL / SSR
Research Engineer - Internet/Intranet Security
38-40 Rue du Général LECLERC
92794 Issy les Moulineaux Cedex 9 - FRANCE
Tel : ( + 33 ) 1 45 29 68 99
Fax : ( + 33 ) 1 45 29 65 19
Email : [EMAIL PROTECTED]
