Title: Re: EAP-TLS re-keying
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: CF5B6848011DD247172F4628C84E
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
