...
EAP and RADIUS have support for a great variety of features or different methods that can be encapsulated there-in to perform authentication (e.g. it is possible to use different protocols that authenticate the user using a username and password, or using client certificates, or even SIM cards), but it is still up to the supplicant, NAS and authentication server implementations to choose which ones they support or not (even different NASes have been seen to send MAC addresses in different format, e.g. TP-Link Archer C20 sends 01-23-45-67-89-AB, while TP-Link TD-W8968 sends 0123456789ab. TP-Link TL-WR740N, in the case of the NAS MAC address, sends 01-23-45-67-89-AB:SSID, where SSID is the configured wireless SSID). EAP, being a tunneling protocol inside which a suitable protocol for performing authentication needs to be used, gives flexibility in usable authentication protocols without requiring specific support for that protocol by the NAS, as long as it is supported by both the supplicant and authentication server.
Misc. Information
- The RADIUS protocol also includes the possibility for the NAS to send accounting information to the authentication server for the purpose of logging user activity, this is on a separate port, UDP 1813, this has not been investigated as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.
The RADIUS protocol also includes the possibility for the authentication server to initiate a connection to the NAS and inform it to disconnect a currently logged in user, but again, this has not been investigated much as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.
- In absence of the above mentioned feature, once a user has connected, there is no way to disconnect them other than rebooting the NAS. If the system administrator chooses to disable a user account on the authentication server, the user will be denied access only from the next time they try to connect, if they are already connected at the time of disabling the account, they will remain connected for the moment. It is possible for the authentication server to specify with the "Session-Timeout" and "Termination-Action" attributes of the Access-Accept packet for how long a user is allowed to remain connected without repeating authentication (again subject to NAS supporting). Depending on the NAS and supplicant models it has been observed that there can be a new authentication request, in the case of wifi, when the supplicant moves out of range of the wifi and then comes back, or when the user switches wifi off and on again on the supplicant, but might also not be the case.
- A "User-Name" attribute is usually provided in both the outer and inner tunnels, often referred to as outer identity and inner identity, respectively. It is often suggested to send the real username only in the inner tunnel for privacy reasons as it is encrypted, and send the string 'anonymous' as User-Name in the outer tunnel, it was found, however, to be unreasonably difficult, if at all possible, to configure Mac OS, Windows and iPhone clients to do so. The 'User-Name' attribute in the outer tunnel is still necessary as a realm for the user may be specified which might need to be accessed by a RADIUS server which might forward '@@@' the request and be unable to read the encrypted part. If the user name is anonymized and a realm needs to be specified, the attribute would read 'anonymous@realm'.
- It is possible for a FreeRADIUS server to forward a request to an upstream RADIUS server to handle. The answer then gets sent back and the local FreeRADIUS server forwards it to the client. '@@@'Usually intermediary RADIUS servers are not able to decrypt the data within the SSL tunnel, and do not have access to it. One way for a RADIUS server to determine whether it should answer a given query itself or forward it upstream is to look at the domain part of the outer identity provided in the outer tunnel.
- According to Wikipedia, there is a similar protocol evolved from RADIUS, called Diameter: https://en.wikipedia.org/wiki/Diameter_(protocol)
- In Debian, the FreeRADIUS daemon is called freeradius. Apparently, in many other environments it is called radiusd.
- When debugging, it is recommended to stop the FreeRADIUS daemon and run freeradius -X in a terminal. A lot of debug information is then printed on the screen, which can be used to see what's happening. This is stressed a lot on the FreeRADIUS wiki and users' mailing list.
- A system called RSN pre-authentication (sometimes called WPA2 pre-authentication) can be used, when multiple NASes are installed in a network, which allows the NASes to talk amongst themselves and inform other NASes about supplicants that have authenticated through them. This allows a wireless supplicant that moves within the building to connect to a different NAS without having to repeat RADIUS authentication. I have not explored this feature much. It might be that it is only available on wireless LAN NASes. '@@@' It is suspected that this feature is the cause of the Session-Timeout / Termination-Action attributes not working in some corner cases (observed when the supplicant roamed between different NASes in a particular order), resulting in the supplicant remaining connected to the network longer than the specified limit, without repeating authentication to the RADIUS server.
- Through a rather limited amount of research in this regards, it is my understanding that for each supplicant a different key is used to encrypt traffic between it and the NAS, and is generated partly '@@@' using information provided by the RADIUS, partly using the supplicant's and NAS MAC addresses, and presumably more information. A supplicant, during authentication specifies its MAC address as well as login credentials, which is logged in the RADIUS server along with user details. After authentication, the NAS does not allow the supplicant to send packets with a source MAC address other than the one specified during authentication. '@@@' (to be verified) This protects against MAC spoofing once a user is logged into the network.
- There are two different WPA standards, WPA and WPA2. The latter is the proper one, and the former was released as an interim solution to be applied on existing devices with inadequate hardware for running WPA2 due to the urgency of upgrading from WEP which was at the time discovered to be significantly insecure. Similarly there are two encryption algorithms '@@@', TKIP and AES, where AES is the proper one, and TKIP the interim one.
- Please see the "Supplicant configuration" section of the "802.1X secured wifi installation" page's "Installation" child page for more information about features supported by and behavior specific to some NAS models.
- EAP-TLS is an authentication method that can be used to authenticate supplicants based on client certificates.
Things to mention:
Re-auth undesired behavior
Protocols used: EAP, MSCHAP, PEAP, TTLS, TLS Difference between auth systems: PEAP, TTLS, TLS - Done
features supported by TP-Link NASes - Done
Certificates - Done
SSL tunnel - Done
Proxying - Done
Terminology: NAS, RADIUS, FreeRADIUS, Authenticator, Supplicant, Authentication server - Done
Diameter - Done
Terminology: AP, wifi router - Done
Wifi keying, session timeout, etc. protections against MAC-spoofing, etc. - Done
Outer and inner identity and MAC/Windows support - Done
What RADIUS/802.1X is able to provide and not and in which situations. - Done
RADIUS is the protocol, it can be used for many purposes and many authentication methods can be used. - Done
MAC address format differences - Done
Difference between 802.1X and RADIUS and FreeRADIUS - Done
What EAP is - Done
Varying implementation of features - Done
Re-auth, accounting, request from server, - Done
freeradius -X. radiusd vs freeradius - Done
WPA/WPA2 - Done
TKIP/AES - Done
FreeRADIUS configuration files
FreeRADIUS configuration files are many. They are located in /etc/freeradius/3.0 on Debian systems. Other distributions use a slightly different location. Most of them contain plenty of comments explaining what the configuration does and advice and warnings, but some understanding of the protocols, or getting used to, is often necessary to understand them. Here are some of the configuration files/folders:
clients.conf - List of clients that will be connecting to the FreeRADIUS server, including their IP addresses and passwords that they will use to authenticate to FreeRADIUS. What is called a FreeRADIUS client is actually a NAS, not a supplicant. Supplicants do not speak directly to RADIUS servers.
mods-available - Folder containing config files of modules that can be used with FreeRADIUS
mods-enabled - Folder containing symlinks to files in the mods-available folder, for modules that should be enabled
mods-config - Folder containing more config related to modules and things like, e.g. .sql files containing empty schemas for initial creation of databases for use with the sql module
certs - Folder containing certificates usable by FreeRADIUS and respective configuration files/makefile/etc. needed to generate them
sites-available - "Sites" that can be served by FreeRADIUS.
sites-enabled - Folder containing symlinks to files in the sites-available folder, for sites that should be enabled
mods-available/eap - Configuration file for EAP module
users - In the default configuration, a text file based user database
By default, the 'default' and 'inner-tunnel' sites are enabled. 'default' is the outer tunnel, it listens for incoming requests from the NASes, 'inner-tunnel' receives requests tunneled in the TLS encryption over EAP over RADIUS, forwarded by the outer-tunnel.
The site files contain multiple sections, here are some of them:
authorize - This section lists modules/code that are run when a request is received, in preparation for authentication. One of the important tasks is to find out which authentication method/protocol the supplicant is trying to use and which FreeRADIUS module is appropriate to deal with it. When one of the listed modules finds that it is able to deal with the request, it informs FreeRADIUS. Another important task is to load in memory information that might be needed for authentication. For example, the sql module loads the relevant credentials from the SQL database so that the appropriate authentication module that later runs in the authenticate section can access them in order to compare them with what the supplicant sent.
authenticate - After the authorize section ran, this section takes care of the actual authentication. In here modules are called that assess the information made available to them and answer in regards of what action should be taken.
...
FreeRADIUS configuration files
FreeRADIUS configuration files are many. They are located in /etc/freeradius/3.0 on Debian systems. Other distributions use a slightly different location. Most of them contain plenty of comments explaining what the configuration does and advice and warnings, but some understanding of the protocols, or getting used to, is often necessary to understand them. Here are some of the configuration files/folders:
clients.conf - List of clients that will be connecting to the FreeRADIUS server, including their IP addresses and passwords that they will use to authenticate to FreeRADIUS. What is called a FreeRADIUS client is actually a NAS, not a supplicant. Supplicants do not speak directly to RADIUS servers.
mods-available - Folder containing config files of modules that can be used with FreeRADIUS
mods-enabled - Folder containing symlinks to files in the mods-available folder, for modules that should be enabled
mods-config - Folder containing more config related to modules and things like, e.g. .sql files containing empty schemas for initial creation of databases for use with the sql module
certs - Folder containing certificates usable by FreeRADIUS and respective configuration files/makefile/etc. needed to generate them
sites-available - "Sites" that can be served by FreeRADIUS.
sites-enabled - Folder containing symlinks to files in the sites-available folder, for sites that should be enabled
mods-available/eap - Configuration file for EAP module
users - In the default configuration, a text file based user database
By default, the 'default' and 'inner-tunnel' sites are enabled. 'default' is the outer tunnel, it listens for incoming requests from the NASes, 'inner-tunnel' receives requests tunneled in the TLS encryption over EAP over RADIUS, forwarded by the outer-tunnel.
The site files contain multiple sections, here are some of them:
authorize - This section lists modules/code that are run when a request is received, in preparation for authentication. One of the important tasks is to find out which authentication method/protocol the supplicant is trying to use and which FreeRADIUS module is appropriate to deal with it. When one of the listed modules finds that it is able to deal with the request, it informs FreeRADIUS. Another important task is to load in memory information that might be needed for authentication. For example, the sql module loads the relevant credentials from the SQL database so that the appropriate authentication module that later runs in the authenticate section can access them in order to compare them with what the supplicant sent.
authenticate - After the authorize section ran, this section takes care of the actual authentication. In here modules are called that assess the information made available to them and answer in regards of what action should be taken.
post-auth - After it has been determined what action should be taken '@@@', this section takes care of any extra tasks required to be carried out, for example logging, and can also add/modify attributes to be sent back to the NAS as part of the Access-Accept/Access-Reject packet.
Misc. Information
- The RADIUS protocol also includes the possibility for the NAS to send accounting information to the authentication server for the purpose of logging user activity, this is on a separate port, UDP 1813, this has not been investigated as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.
The RADIUS protocol also includes the possibility for the authentication server to initiate a connection to the NAS and inform it to disconnect a currently logged in user, but again, this has not been investigated much as it seems to be not supported by the NASes we have, and presumably is not on any NAS in the price range.
- In absence of the above mentioned feature, once a user has connected, there is no way to disconnect them other than rebooting the NAS. If the system administrator chooses to disable a user account on the authentication server, the user will be denied access only from the next time they try to connect, if they are already connected at the time of disabling the account, they will remain connected for the moment. It is possible for the authentication server to specify with the "Session-Timeout" and "Termination-Action" attributes of the Access-Accept packet for how long a user is allowed to remain connected without repeating authentication (again subject to NAS supporting). Depending on the NAS and supplicant models it has been observed that there can be a new authentication request, in the case of wifi, when the supplicant moves out of range of the wifi and then comes back, or when the user switches wifi off and on again on the supplicant, but might also not be the case.
- A "User-Name" attribute is usually provided in both the outer and inner tunnels, often referred to as outer identity and inner identity, respectively. It is often suggested to send the real username only in the inner tunnel for privacy reasons as it is encrypted, and send the string 'anonymous' as User-Name in the outer tunnel, it was found, however, to be unreasonably difficult, if at all possible, to configure Mac OS, Windows and iPhone clients to do so. The 'User-Name' attribute in the outer tunnel is still necessary as a realm for the user may be specified which might need to be accessed by a RADIUS server which might forward '@@@' the request and be unable to read the encrypted part. If the user name is anonymized and a realm needs to be specified, the attribute would read 'anonymous@realm'.
- It is possible for a FreeRADIUS server to forward a request to an upstream RADIUS server to handle. The answer then gets sent back and the local FreeRADIUS server forwards it to the client. '@@@'Usually intermediary RADIUS servers are not able to decrypt the data within the SSL tunnel, and do not have access to it. One way for a RADIUS server to determine whether it should answer a given query itself or forward it upstream is to look at the domain part of the outer identity provided in the outer tunnel.
- According to Wikipedia, there is a similar protocol evolved from RADIUS, called Diameter: https://en.wikipedia.org/wiki/Diameter_(protocol)
- In Debian, the FreeRADIUS daemon is called freeradius. Apparently, in many other environments it is called radiusd.
- When debugging, it is recommended to stop the FreeRADIUS daemon and run freeradius -X in a terminal. A lot of debug information is then printed on the screen, which can be used to see what's happening. This is stressed a lot on the FreeRADIUS wiki and users' mailing list.
- A system called RSN pre-authentication (sometimes called WPA2 pre-authentication) can be used, when multiple NASes are installed in a network, which allows the NASes to talk amongst themselves and inform other NASes about supplicants that have authenticated through them. This allows a wireless supplicant that moves within the building to connect to a different NAS without having to repeat RADIUS authentication. I have not explored this feature much. It might be that it is only available on wireless LAN NASes. '@@@' It is suspected that this feature is the cause of the Session-Timeout / Termination-Action attributes not working in some corner cases (observed when the supplicant roamed between different NASes in a particular order), resulting in the supplicant remaining connected to the network longer than the specified limit, without repeating authentication to the RADIUS server.
- Through a rather limited amount of research in this regards, it is my understanding that for each supplicant a different key is used to encrypt traffic between it and the NAS, and is generated partly '@@@' using information provided by the RADIUS, partly using the supplicant's and NAS MAC addresses, and presumably more information. A supplicant, during authentication specifies its MAC address as well as login credentials, which is logged in the RADIUS server along with user details. After authentication, the NAS does not allow the supplicant to send packets with a source MAC address other than the one specified during authentication. '@@@' (to be verified) This protects against MAC spoofing once a user is logged into the network.
- There are two different WPA standards, WPA and WPA2. The latter is the proper one, and the former was released as an interim solution to be applied on existing devices with inadequate hardware for running WPA2 due to the urgency of upgrading from WEP which was at the time discovered to be significantly insecure. Similarly there are two encryption algorithms '@@@', TKIP and AES, where AES is the proper one, and TKIP the interim one.
- Please see the "Supplicant configuration" section of the "802.1X secured wifi installation" page's "Installation" child page for more information about features supported by and behavior specific to some NAS models.
- EAP-TLS is an authentication method that can be used to authenticate supplicants based on client certificates.
Sources
https://en.wikipedia.org/wiki/IEEE_802.1X
...