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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
