Hello Jason
> How does EAP/MD5 compare with EAP/TLS in regards to data encryption over the air >between the > Client and the AP? Is it the > same, just using a different mechanism to do the encryption (MD5 challenge, verses a > Certificate)? Short answer: NO, it's not the same! EAP/TLS can negotiate dynamic WEP-keys which EAP/MD5 simply *can't*. FreeRADIUS now begins to support this dynamic WEP keys using Henrik and Lars patch and thanks to the recent changes. This patch is/will be integrated into 0.7. Explanation; Every EAP mechanism being part of 802.1x basically defines the authentication scheme. So, neither of both has a direct regard to the air encryption, i.e. the RFCs of both specification do not talk about the used WEP encryption and WEP keys. The problem generally is that from the point of view of the supplicant (user) the EAP-communication ends at the server during the WEP encryption takes place between the supplicant and the AP. According to the idea of 802.1x the AP will not participate at the whichever EAP conversation. (It even couldn't in the case of TLS, that's the sense of TLS). So, what to do? However, EAP/TLS has a great advantage over EAP/MD5 because it negotiates the master keys (every TLS does). EAP/MD5 can't negotiate anything, it only verifies the identity with a rather weak method, cryptoanalitically spoken and compared to the PK-based TLS. Anyway, some negotiated key material is available at the supplicant (user) and the authentication server after the TLS exchange. This material could be used to derive some other keys, which could then be sent to the AP (radius-client) using some (new) attributes. The supplicant already has the necessary key material since it participated at the TLS exchange. This advantage is used by MS and Cicso in their MPPE definition for WLANs (s. e.g. RFCs 3078 and 3079 and cisco documentation at www.cisco.com). The server adds the MPPE-Send-Key and MPPE-Recv-Key attributes, puts in these the derived key material and sends them to the client (AP). AP has to understand these attributes. It then derives the unicast and broadcast keys, encrypts them with the negotiated key and sends those in the EAPOL-Key message to the user. The user uses its own key to decrypt the received EAPOL keys. These keys are setup as dynamic WEP keys on the user side and at by the AP. An exact description of the exchange is being prepared for as far as I know. Ask Raghu or Henrik in case of doubt (or look in the RFCs :-)) The patch provided by Henrik and Lars adds the MPPE attributes to the server Accept message. There are people reporting that it works. In my case, with a Cicso AP340 I currently fail to activate it correctly: setting up dynamic WEP results in a communication breakdown. I'm currently on it, I hope the guys will help me ;-) That's it. Artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
