hi
> I'm not misunderstanding you, I'm agreeing with you! :) finally good news :-) > My terminology sucks, so I'll use laymans terms here, but what does the > EAP-TLS module support? it supports exactly one of the EAP-authentication types, notably EAP/TLS. it has been released as standard track RFC in '99, i.e. before any EAPoL and 1X stories and was also originally meant for PPP "and upcoming purposes"... the TLS authentication exchange is pretty wellknown. EAP/TLS is exactly that, i.e. TLS transported in EAP-frames + fragmentation/reassembly support (TLS messages can become much bigger than the MTU which EAP-frames are naturally limited to since they are always transported directly in the link layer frames). so, with the help of EAP/TLS, your user and your server can proceed with the complete mutual TLS auth + master key negotiation/exchange and during that time the port at the AP basically remains closed. of course you _should_ use the negotiated master key in some way later since otherwise you could be easily attacked just by hijacking the line to the (now) authenticated and open port. > Dynamic/Rotating (wep?!) keys ( Cisco TKEP (Temporal Key Exchange > Protocol-like, or other methods?) to provide encrypted data between the > supplicant and the AP, aswell as radius authen/author. I know the > EAP-TLS module for FR works to authenticate the supplicant, but I'm not > sure about the encryption and key rotation mechanisms that this module > implements (if any) and how it compares to LEAP's version. well, it's actually not like that (i was also surprised): it's not the server which is rotating the WEP keys. really, it doesn't know anything about WEP or about the needed lengthes etc. WEP is actually something (generally a crypto-suite) which server doesn't carry much about since it is not implemented on the server. the WEP methods are implemented in the hardware of the AP and of the network adapter. So, AP has to be responsible for the key rotation (or dynamic keys - this is the same mechanism but applied periodically). however, the AP doesn't know anything about the negotiated secret at this stage since during its negotiation AP wasn't much more than a wire, a medium or a man-in-the-middle. against all those TLS is meant to protect you (no sniffing, no packet exchanging, no interception, etc. should give you any ideas). so, there is a (proprietary but still standardized - informational RFC) way how to give a derivate of the TLS master secret to the AP. it's done with some radius VSAs since the AP is a radius client. and the good news is: we have a shared secret between the server and the client in radius. so, the derivate (NSSSK) can be tranported more or less securily over the wire till to the client (radius and especially radius-attribute security is another issue). the AP then creates some random WEP key according to its current setting (it could be 40bit, 128bit or whatever - it takes exactly the setting of the installed crypto-method). this WEP key is barely random (how good can that possibly be?) and has nothing to do with the derivate. AP uses the derivate for signing and encrypting the freshly produced WEP-key (it even produces two of them, one for the bcast and one for ucast). it sends the keys in EAPoL-Key frames to the user (=supplicant). the user can derive the NSSSK itself and can decrypt and verify the signature of the received key. if it's good it can install it as the WEP-key in its card. we were discussing a bit with raghu why the guys didn't take another approach. e.g. they could have taken the received NSSSK (which is a lot of stuff, 256bytes or something) for WEP-key creation and just begin to crypt immediately, the user could have done it at his side. actually the EAPoL-key transport stuff is theoretically completely unnecessary and IMHO pretty ugly: some secret goes over the wire although the both already have one pre-shared secret, namely the NSSSK (user by deriving and AP by receiving from its server). you would need less exchanges and the key stuff wouldn't be sent around without sense. but well, i think for the guys who developped it, it was really important to separate wep from whichever software methods on the server. now the AP can always produce some new WEP-key, give it to all concerned clients (to 1 client for ucast and for all associated & authenticated clients for bcast), even if the radius server is not responding anymore. the wish to change the keys comes from the AP, the key also. and the radius-server can force the complete re-auth by including a Session-Timeout attribute or similiar. so, now i don't know at all how exactly LEAP works (if anybody knows, please post) but it's a sure thing that there is some additional LEAP-password configuration in the AP and you still have some user config in the server. and it does provide dynamic keys. so :-) from now on everybody can read this mail in the archive, i'm done with it. i hope it's correct... and i think, there is now a complete description of that (by raghu) somewhere in the server docs... (i'm not sure if he finished it or not). ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
