Hello everyone, I've recently set-up EAP-TLS on my home access point using freeradius, it works perfectly fine and everything went smoothly. However, I have some questions regarding the protocol and I hope someone on this list will clear things up for me: 1- Before the supplicant sends any certificates to the server, it usually verifies the server's identity. After it does, how can it ensure that it's still talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity? 2- If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext? In Android for example, if you choose to not verify the server's identity, it warns: "No certificate specified. Your connection will not be private". What does it mean here? Does it mean that it's potentially not private because an attacker might impersonate the server because it'll accept whatever cert the server provides? If that's the case, then why does authentication with this method generate way fewer lines in `radiusd -X`? RFC 5216 Section 2.1.4 says that privacy (protecting client certificate information and stuff like that) is optional, yet Section 5.5 says that there's integrity protection in the protocol. How does that work if the privacy mode is optional? Does the supplicant sign the information somehow without encrypting it? 3- Since the privacy mode is optional, does freeradius enable it by default? If not, how do I enable it? 4- After the client has been authorized, what happens exactly? How is the shared symmetric key derived? How is it passed along to the Access Point/Client so that it can receive/send data from/to the supplicant (since the RADIUS server's part ends after doing the authentication)? (Resending because my last e-mail doesn't seem to be posted)
On 08.10.20 18:52, mramadany wrote:
After it does, how can it ensure that it's still talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity?
Establishing a tunnel is the whole point of TLS. The Client encrypts the next message using server's public key. So only the appropriate receiver can get anything useful out of this message. In theory, you could send the payload traffic encrypted like that, but in reality you get much better performance by sending the symmetric key over the link (which is secure in this direction now) and use the symmetric key for the payload.
2- If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext?
In Android for example, if you choose to not verify the server's identity, it warns: "No certificate specified. Your connection will not be private". What does it mean here? Does it mean that it's potentially not private because an attacker might impersonate the server because it'll accept whatever cert the server provides?
Exactly. If the client wrongly accepts the server's public key, it will still encrypt things, but exclusively for the fraud. In the case of EAP-TLS, at least it won't give client side WiFi credentials away as would happen with the same mistake in a PEAP/MS-CHAPv2 or EAP-TTLS/PAP conversation. However, your traffic now passes through the attacking/impersation/rogue AP. The attacker could give you false DNS replies and e.g. try to fool your Browser into a connection to a fraudulent banking site or the like. Good idea, doing EAP-TLS (and yes, you still need to configure the clients). Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
On Oct 8, 2020, at 12:52 PM, mramadany <mramadany1@gmail.com> wrote:
Hello everyone, I've recently set-up EAP-TLS on my home access point using freeradius, it works perfectly fine and everything went smoothly. However, I have some questions regarding the protocol and I hope someone on this list will clear things up for me:
Most of these questions are about the EAP-TLS protocol, and not FreeRADIUS. The short answer is that the protocol is described in the RFCs. You may need to read many in order to fully understand things. The longer answer is that unless you're creating a new standard, it doesn't really matter how EAP-TLS works. The spec describes it, multiple systems implement it. The protocol lets you get online safely and securely. If you want to know "what happens when something goes wrong", or "what happens if...", then it's all answered in the RFCs.
1- Before the supplicant sends any certificates to the server, it usually verifies the server's identity.
After it does, how can it ensure that it's still talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity?
For EAP-TLS, no. Note that RFC 5216 does not mention establishing a tunnel.
2- If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext?
In Android for example, if you choose to not verify the server's identity, it warns: "No certificate specified. Your connection will not be private". What does it mean here? Does it mean that it's potentially not private because an attacker might impersonate the server because it'll accept whatever cert the server provides? If that's the case, then why does authentication with this method generate way fewer lines in `radiusd -X`?
It means that the certificate chain hasn't been verified. See the TLS specs for what this means. There are many, many, resources available which describe TLS.
RFC 5216 Section 2.1.4 says that privacy (protecting client certificate information and stuff like that) is optional, yet Section 5.5 says that there's integrity protection in the protocol. How does that work if the privacy mode is optional? Does the supplicant sign the information somehow without encrypting it?
Privacy is not encryption. See RFC 7542 for more discussion on this topic.
3- Since the privacy mode is optional, does freeradius enable it by default? If not, how do I enable it?
You don't enable it. "privacy mode" is not part of the spec. RFC 5216 Section 2.1.4 (which you say you've read) has a long discussion on privacy. Which answers your questions about it.
4- After the client has been authorized, what happens exactly? How is the shared symmetric key derived?
Read RFC 5216. The spec explains exactly how this works.
How is it passed along to the Access Point/Client so that it can receive/send data from/to the supplicant (since the RADIUS server's part ends after doing the authentication)?
See RFC 3579. If you want to learn about the specs, the best way is by reading the standards. This list is about FreeRADIUS, so further discussion of how EAP-TLS works is off topic. Alan DeKok.
On October 8, 2020 10:10:57 p.m. GMT+03:00, Alan DeKok <aland@deployingradius.com> wrote:
Most of these questions are about the EAP-TLS protocol, and not FreeRADIUS. The short answer is that the protocol is described in the RFCs. You may need to read many in order to fully understand things.
Sorry then, I thought that this question was relevant here.
If you want to know "what happens when something goes wrong", or "what happens if...", then it's all answered in the RFCs.
Yep, that's what I was trying to figure out since I was worried that a malicious server could take over the connection once the client verifies the server (since as you mentioned, there are no tunnels involved). Anyway, thank you for providing the numbers of the relevant RFCs, I will make sure to give them a read.
On Oct 8, 2020, at 3:34 PM, mramadany <mramadany1@gmail.com> wrote:
Sorry then, I thought that this question was relevant here.
Questions about FreeRADIUS, yes. But questions about "how does EAP-TLS work" are not FreeRADIUS. They're common standards, documented in many places.
If you want to know "what happens when something goes wrong", or "what happens if...", then it's all answered in the RFCs.
Yep, that's what I was trying to figure out since I was worried that a malicious server could take over the connection once the client verifies the server (since as you mentioned, there are no tunnels involved).
It's TLS. Just like HTTPS. So the answer is "no".
Anyway, thank you for providing the numbers of the relevant RFCs, I will make sure to give them a read.
There are many, many of them. :( Alan DeKok.
participants (3)
-
Alan DeKok -
Martin Pauly -
mramadany