> > 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.
Yes, I understand that TLS negotiates WEP keys dynamically based on the certificate information shared between the AAA server and the supplicant. I don't think I explained myself well enough in my first reply, as my terminology is lacking due to the fact that I am not extreamely familiar with all of this quite yet. Basically, I was wondering if the EAP/MD5 combination does infact encrypt the data between the client and AP, period. Correct me if I am wrong, but this method encrypts a preshared WEP key shared between the supplicant and the AP using MD5? That same MD5 challenge is used to encrypt the data between the AP and the supplicant? If yes, I know it's not as secure as negotiated dynamic keys but none the less, it's encryption of some sort, which is better than just a wep key and unencrypted data between supplicant and AP. Your explaination below is a little over my head, so please forgive me if I've asked a question or made an assumption which is contrary to the explaination you gave below in the first place :) > > 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
