EAP-TLS and TLS record protocol

[Phil Mayers]

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.