On 05/24/2013 09:12 AM, Pieter Hulshoff wrote:
Hello all,
I'm new to the list, relatively new to authentication, and I'm trying to figure out some details regarding the RFCs. I was hoping some of you might be able and willing to help me out here.
As I understand it, using TLS you can authenticate the server and optionally the client, negotiate the encryption/signing algorithm(s) for the TLS record protocol, and exchange the key information before switching to the selected encryption/signing algorithm(s) for secure data transport. EAP-TLS however seems focused on authorization and exchanging the key information, leaving the actual data encryption to be determine by other means (e.g. IEEE 802.1X MKA i.c.w. MACsec).
My questions: 1. Is this understanding correct?
Sort of. You've focussed on EAP-TLS, but that's misleading. *All* EAP methods are solely for authentication; the EAP protocols are not used to forward traffic, they merely authenticate and, if the link-layer requries it, derive encryption keys. By way of illustrating the implications - note that, on a non-MACSEC 802.1x wired connection, you can (but shouldn't!) use EAP-MD5 which does not derive key material, because there's no link-layer encryption. Similarly, on wireless 802.1x, you can use EAP-PWD or EAP-EKE, both of which derive key material and both of which have nothing to do with TLS.
2. Does this imply that the negotiated encryption/signing algorithm(s) are only used for the EAP-TLS Finished messages?
For *all* EAP methods, the only output is success/failure and optionally key material, and the key material is just a securely-derived set of bits. The cryptographic primitives used by the EAP method have no bearing on the cryptographc primitives used by the link layer. Also - this not not a FreeRADIUS question really, and if you have more questions, they might be better off in another forum.