Protocols and services required for the WiFi authentication process

Aguilera

Protocols and services required for the WiFi authentication process [Copy link]

What is a RADIUS server
RADIUS is a document protocol for authentication, authorization, and accounting information between a network access server (NAS) that needs to authenticate its connection and a shared authentication server.

The key functional components of RADIUS are:
Client/Server Architecture Network Access Server (NAS) operates as a RADIUS client. The client is responsible for passing subscriber information to the specified RADIUS server and then acting based on the returned response. The
RADIUS server is responsible for receiving the subscriber's connection request, authenticating the subscriber, and then returning all the necessary configuration information to the client to send services to the subscriber. RADIUS servers
can act as agents for other RADIUS servers or other types of authentication servers.

Network security:
Transactions between the client and the RADIUS server are authenticated by using encrypted shared secret information. Confidential information is never sent over the network. In addition, any subscriber password is encrypted when it is sent between the client and the RADIUS server. Flexible authentication mechanisms:
RADIUS servers can support multiple methods of authenticating subscribers. When the subscriber provides the subscriber name and original password, RADIUS can support Point-to-Point Protocol (PPP), Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and other authentication mechanisms.
Extensible protocol:
All transactions consist of variable-length triples of "attribute-length-value". New attribute values can be added without affecting existing protocol implementations.

How to configure a RADIUS server
In the console tree of ISA Server Management, click General: For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click General. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click General. In the details pane, click Define RADIUS Servers. On the RADIUS Servers tab, click Add. In Server Name, type the name of the RADIUS server that you want to use for authentication. Click Change, and then in New Secret, type the shared secret that you want to use for secure communications between the ISA Server and the RADIUS server. The same shared secret must be configured on both the ISA Server and the RADIUS server for RADIUS communication to succeed. In Port, type the User Datagram Protocol (UDP) that you want the RADIUS server to use for incoming RADIUS authentication requests. The default value of 1812 is based on RFC 2138. For older RADIUS servers, set the port value to 1645. In Timeout (seconds), type the amount of time, in seconds, that the ISA server will try to get a response from the RADIUS server before it tries another RADIUS server. If a message authenticator based on a shared secret is sent with each RADIUS message, select Always use message authenticator.
Note:
To open ISA Server Management, click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management. When you configure ISA Server for RADIUS authentication, the RADIUS server configuration applies to all rules or network objects that use RADIUS authentication. The shared secret is used to verify that RADIUS messages (except Access-Request messages) are sent by a RADIUS-enabled device that has the same shared secret configured. Be sure to change the default pre-shared key on the RADIUS server. Configure a strong shared secret and change it frequently to prevent dictionary attacks. A strong shared secret is a long (more than 22 characters) string of random letters, numbers, and punctuation marks. If you select Always use Message Authenticator, make sure that the RADIUS server is capable of receiving and is configured to receive Message Authenticator. For VPN clients, Extensible Authentication Protocol (EAP) messages are always sent with Message Authenticator. For Web Proxy clients, only Password Authentication Protocol (PAP) is used. If the RADIUS server is running Internet Authentication Service (IAS), and the RADIUS clients configured for this server have the Request must contain the Message Authenticator attribute option selected, you must select Always use Message Authenticator.

EAP (Extensible Authentication Protocol)
　　PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication that supports multiple authentication methods. EAP does not specify the authentication method in the link establishment phase, but postpones this process to the authentication phase. In this way, the authenticator can decide what authentication method to use after obtaining more information. This mechanism also allows the PPP authenticator to simply pass the received authentication message to the authentication server behind it, and the authentication server behind it actually implements various authentication methods. 1. After the link phase is completed, the authenticator sends one or more request messages to the peer. There is a type field in the request message to indicate the type of information requested by the authenticator, such as the peer's ID, MD5 challenge word, one-time password (OTP), and universal token card. The MD5 challenge word corresponds to the challenge word of the CHAP authentication protocol. Typically, the authenticator first sends an ID request message and then sends other request messages. Of course, it is not necessary to send this ID request message first. This step can be skipped when the identity of the peer is known (such as leased lines, dial-up lines, etc.). 2. The peer responds to each request message with a response message. Like the request message, the response message also contains a type field that corresponds to the type field in the request message to which it is responding. 3. The authenticator ends the authentication process by sending a success or failure message. Advantages: EAP can support multiple authentication mechanisms without having to specify them during the pre-negotiation process in the LCP phase. Some devices (such as network access servers) do not need to care about the true meaning of each request message, but instead act as a proxy to pass authentication messages directly to the backend authentication server. The device only needs to care about whether the authentication result is success or failure, and then end the authentication phase. Disadvantages: EAP requires adding a new authentication protocol to LCP, so existing PPP implementations must be modified to use EAP. At the same time, the use of EAP is inconsistent with the existing model of specifying authentication methods during the LCP negotiation phase.