TCPDump, able to see tunneled credentials?
Hi All, I'm a bit confused here. I've got EAP-TTLS/PAP set up. To ensure that everything was setup correctly, I have run a PCAP from the supplicant to see if I could see any auth details being sent (I couldn't), I have also run a PCAP from an AP in sniffer mode (also couldn't see anything, only probes and broadcasts), however, I ran a TCPDump on the RADIUS server itself and while I couldn't see the password that was being sent, I could see the tunnelled username and VLAN attributes in the Access-Accept. My question is, is this expected? Want to ensure this isn't just a misconfiguration. Kind regards, Connor
Hi Again, I think I have found why it is sending the username in the Access Accept (update outer.session-state is uncommented) so that's ok but is there a way for me to be sure it's being tunneled? The debug logs state "eap_ttls: Got tunneled Access-Accept" and the logs state the final auth accept came "Via TLS Tunnel" so this would lead me to believe it's fine but is that enough to go on? Just trying to cover everything. Kind regards, Connor On Fri, Sep 13, 2024 at 9:14 AM Connor Herring <connorrjherring@gmail.com> wrote:
Hi All,
I'm a bit confused here. I've got EAP-TTLS/PAP set up. To ensure that everything was setup correctly, I have run a PCAP from the supplicant to see if I could see any auth details being sent (I couldn't), I have also run a PCAP from an AP in sniffer mode (also couldn't see anything, only probes and broadcasts), however, I ran a TCPDump on the RADIUS server itself and while I couldn't see the password that was being sent, I could see the tunnelled username and VLAN attributes in the Access-Accept.
My question is, is this expected? Want to ensure this isn't just a misconfiguration.
Kind regards,
Connor
On 13/09/2024 11:34, Connor Herring wrote:
I think I have found why it is sending the username in the Access Accept (update outer.session-state is uncommented) so that's ok but is there a way for me to be sure it's being tunneled? The debug logs state "eap_ttls: Got tunneled Access-Accept" and the logs state the final auth accept came "Via TLS Tunnel" so this would lead me to believe it's fine but is that enough to go on? Just trying to cover everything.
The TLS tunnel protects the authentication, not the full RADIUS exchange. VLAN attributes are always outside the tunnel, they are standard RADIUS attributes. If you want the whole lot hidden you'll need to configure RadSec, but most RADIUS clients won't support that. The reply User-Name is set to whatever the FreeRADIUS policy sets it to, so if you are copying the inner tunnel User-Name back to the outer reply (e.g. via session-state) then that is what will get sent. The debug output will show what is happening. Note that a lot of devices will send the reply User-Name back as the User-Name in accounting messages, so if you want accounting to make sense you may need to send something clear back in the reply. But (without seeing any debug logs), sounds like it's all working as expected. -- Matthew
Hi Matthew, Thanks for this, it does put my mind at ease. Is there any way other than various PCAPs that you would be able to tell if something sensitive like the password was being seen outside the tunnel? I think I've proved that you can't, pretty conclusively but just want to be sure. Kind regards, Connor On Fri, Sep 13, 2024 at 11:41 AM Matthew Newton via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
On 13/09/2024 11:34, Connor Herring wrote:
I think I have found why it is sending the username in the Access Accept (update outer.session-state is uncommented) so that's ok but is there a way for me to be sure it's being tunneled? The debug logs state "eap_ttls: Got tunneled Access-Accept" and the logs state the final auth accept came "Via TLS Tunnel" so this would lead me to believe it's fine but is that enough to go on? Just trying to cover everything.
The TLS tunnel protects the authentication, not the full RADIUS exchange. VLAN attributes are always outside the tunnel, they are standard RADIUS attributes. If you want the whole lot hidden you'll need to configure RadSec, but most RADIUS clients won't support that.
The reply User-Name is set to whatever the FreeRADIUS policy sets it to, so if you are copying the inner tunnel User-Name back to the outer reply (e.g. via session-state) then that is what will get sent. The debug output will show what is happening.
Note that a lot of devices will send the reply User-Name back as the User-Name in accounting messages, so if you want accounting to make sense you may need to send something clear back in the reply.
But (without seeing any debug logs), sounds like it's all working as expected.
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 13, 2024, at 7:10 AM, Connor Herring <connorrjherring@gmail.com> wrote:
Thanks for this, it does put my mind at ease. Is there any way other than various PCAPs that you would be able to tell if something sensitive like the password was being seen outside the tunnel? I think I've proved that you can't, pretty conclusively but just want to be sure.
Look at the debug output, or pcap files. But the protocol designers aren't dumb. Anything *truly* sensitive (like Tunnel-Password) is protected by design. The contents of the Access-Accept *must* be in the clear (mostly), because otherwise the NAS can't see them. There's no point in sending reply attributes inside of the TLS tunnel for TTLS, because the TLS tunnel goes to the supplicant, and not to the NAS. If you truly want privacy in RADIUS, use RADIUS/TLS (RadSec). Nothing else will protect all of the traffic. Alan DeKok.
On 13/09/2024 12:10, Connor Herring wrote:
Thanks for this, it does put my mind at ease. Is there any way other than various PCAPs that you would be able to tell if something sensitive like the password was being seen outside the tunnel?
tcpdump, radsniff, FreeRADIUS debug output. But ultimately they'll all tell you the same thing.
I think I've proved that you can't, pretty conclusively but just want to be sure.
Literally all the RADIUS stuff is outside the tunnel. Which is why it's recommended to keep RADIUS on a private network and to use RadSec if possible. e.g. device MAC addresses etc are all in the clear. People run RADIUS over the Internet and I have no idea why you would even consider doing that. But in terms of authentication, disable all the auth stuff in the outer tunnel (sites-enabled/default) except eap, then nothing else can work. At that point you've pretty much done everything you can. -- Matthew
Hi Matthew and Alan, Many thanks for the information, you've been really helpful. I've already got everything apart from EAP disabled in sites-enabled/default > authentication so should be good! Kind regards, Connor On Fri, Sep 13, 2024 at 12:23 PM Matthew Newton via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
On 13/09/2024 12:10, Connor Herring wrote:
Thanks for this, it does put my mind at ease. Is there any way other than various PCAPs that you would be able to tell if something sensitive like the password was being seen outside the tunnel?
tcpdump, radsniff, FreeRADIUS debug output. But ultimately they'll all tell you the same thing.
I think I've proved that you can't, pretty conclusively but just want to be sure.
Literally all the RADIUS stuff is outside the tunnel. Which is why it's recommended to keep RADIUS on a private network and to use RadSec if possible. e.g. device MAC addresses etc are all in the clear. People run RADIUS over the Internet and I have no idea why you would even consider doing that.
But in terms of authentication, disable all the auth stuff in the outer tunnel (sites-enabled/default) except eap, then nothing else can work. At that point you've pretty much done everything you can.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Connor Herring <connorrjherring@gmail.com> wrote:
I'm a bit confused here. I've got EAP-TTLS/PAP set up. To ensure that everything was setup correctly, I have run a PCAP from the supplicant to see if I could see any auth details being sent (I couldn't), I have also run a PCAP from an AP in sniffer mode (also couldn't see anything, only probes and broadcasts), however, I ran a TCPDump on the RADIUS server itself and while I couldn't see the password that was being sent, I could see the tunnelled username and VLAN attributes in the Access-Accept.
My question is, is this expected? Want to ensure this isn't just a misconfiguration.
Normal. The NAS does not get to see the password -- the encrypted tunnel is built between the client and the RADIUS Server (except when he NAS is performing as a surrogate as in mac-auth-bypass setups.) But the NAS needs to know the VLAN attributes and there has to be a UserName in the packets as well, IIRC due to EAP standards. If the UserName in those packets is the one used on the inside tunnel and not the outer wrapper (they can be different), then your RADIUS server is intentionally configured to leak that username. This is fairly common when you want real usernames in your NAS administrative interfaces for visibility, or when making policy decisions based on usernames with local rules programmed into the NAS. Under typical models prevalent when RADIUS was designed, NAS and RADIUS server were connected on an isolated internal VLAN so this was not a privacy concern. As things became more cloud-based, this was no longer the case. RADIUS does protect against alteration of these attributes on the wire using a Message-Authenticator (caveat: proper countermeasures for BlastRADIUS needed.) If you do not have a protected communication channel between the NAS and RADIUS server, and you need privacy protection of the attributes, then check if the NAS supports RadSec (RADIUS/TLS). If it does not, pursue building an IPSec tunnel to protect it. In general, the recommendation these days is to move to RadSec whenever you can.
participants (4)
-
Alan DeKok -
Brian Julin -
Connor Herring -
Matthew Newton