O WPA2 Enterprise é baseado em partes do 802.11i que são baseadas no 802.1X. O 802.1X NÃO requer um servidor RADIUS, mas é assim que é comumente feito por motivos legados.
A função do servidor RADIUS é apenas no início da conexão, mas faz uma pequena coisa a mais do que você mencionou. Como parte do mecanismo de autenticação, o material de codificação é gerado com segurança no servidor RADIUS (e o mesmo material de codificação também é gerado no cliente WPA2). Depois que o servidor RADIUS informa ao AP para aceitar essa solicitação de conexão, o servidor RADIUS envia esse material de chave em uma mensagem "chave" RADIUS (eles reutilizaram uma mensagem / atributo RADIUS MPPE-KEY da qual a Microsoft foi pioneira) para o AP. sabe quais as chaves por usuário por sessão (incluindo a Pairwise Temporal Key ou PTK) para usar nessa sessão. Isso encerra o envolvimento do servidor RADIUS.
Você está absolutamente certo de que não é preciso muita potência de servidor para rodar um servidor RADIUS. Assim como um servidor DHCP ou um servidor DNS para uma pequena rede ou domínio, você realmente não precisa de hardware de "classe de servidor" para executá-lo. Provavelmente qualquer pequena caixa de rede incorporada de baixo consumo de energia servirá. Existem muitos protocolos em redes modernas onde o "servidor" não requer muita potência pelos padrões atuais. Só porque você ouve o termo "servidor", não assuma que requer hardware de servidor pesado.
História de fundo
Você vê, o RADIUS era originalmente uma maneira de mover a autenticação de seus servidores PPP de modem dial-up e para um servidor centralizado. É por isso que significa "Serviço de Usuário de Discagem de Autenticação Remota" (deve ser "Serviço de Autenticação Remota de Usuário de Discagem", mas DIURAS não soa tão bem quanto o RADIUS). Quando o PPP começou a ser usado para autenticação DSL (PPPoE, PPPoA) e autenticação VPN (PPTP e L2TP-over-IPSec são ambos "PPP dentro de um túnel criptografado"), era natural continuar a usar os mesmos servidores RADIUS para autenticação centralizada para todos os "Servidores de acesso remoto" da sua empresa.Os mecanismos de autenticação originais do PPP estavam faltando e precisaram de muito envolvimento de padrões de corpo para criar novos, assim, eventualmente, o protocolo EAP foi criado para ser um sistema plug-in do tipo auth para o PPP. autenticação. Naturalmente, os servidores RADIUS e os clientes PPP foram os primeiros lugares que precisaram para suportar o EAP. Você poderia, é claro, ter seu modem discado / servidor PPP, ou seu servidor VPN, ou seu servidor PPPoE / PPPoA (na verdade, L2TP PPP), ou qualquer outro, implementar EAP localmente, mas agora o RADIUS era tão amplamente implementado que era principalmente servidores RADIUS que o implementaram.
Eventualmente, alguém queria uma maneira de exigir autenticação sempre que alguém se conecta a uma porta Ethernet desprotegida no lobby ou em uma sala de conferência, então "EAP over LANs" foi criado para isso. "EAPoL", como era conhecido, foi padronizado como 802.1X. O 802.1X foi posteriormente aplicado a redes 802.11 no IEEE 802.11i. E a Wi-Fi Alliance criou um programa de certificação / branding / marketing de interoperabilidade em torno do 802.11i e o chamou de Wi-Fi Protected Access 2 (WPA2).
Assim, enquanto o seu AP 802.11 em si pudesse preencher toda a função "Autenticador" do 802.1X (WPA2-Enterprise) por si só (sem a ajuda de um servidor RADIUS), isso não é comumente feito. Na verdade, em alguns APs capazes de executar o 802.1X autônomo, eles realmente construíram e abriram o servidor RADIUS em seu firmware, e fizeram a autenticação 802.1X via RADIUS via loopback, porque é mais fácil conectá-lo dessa maneira do que tentar implemente seu próprio código de autenticador EAP ou copie o código de algum software de servidor RADIUS de código-fonte aberto e tente integrá-lo diretamente nos daemons relacionados ao 802.11 do seu firmware AP.
Dado que o backstory, e dependendo de quantos anos o seu servidor RADIUS proposto é, a questão importante é saber se ele implementa o (s) tipo (s) EAP que você deseja usar para autenticação em sua rede. PEAP? TTLS?
Além disso, observe que o RADIUS tradicionalmente usa um "Shared Secret" conhecido pelo cliente RADIUS (o cliente RADIUS é o "Network Access Server": o AP nesse caso, ou um servidor VPN ou PPP ou outro "Servidor de Acesso Remoto" "em outros casos) e o servidor RADIUS, para autenticar o cliente e o servidor RADIUS entre si e para criptografar sua comunicação. A maioria dos servidores RADIUS permite que você especifique diferentes segredos compartilhados para cada AP, com base no endereço IP do AP. Assim, um invasor em sua rede teria que ser capaz de assumir esse endereço IP e adivinhar esse segredo compartilhado, para que o servidor RADIUS fale com ele. Se o invasor ainda não estivesse na rede, o invasor só poderia tentar enviar mensagens EAP especialmente criadas / corrompidas que o AP transmitisse via RADIUS para o servidor RADIUS. Se o problema de segurança que você está preocupado pode ser explorado por meio de mensagens EAP mal-formadas, você ainda pode ter um problema.