RAIO - RADIUS

RADIUS ( Remote Authentication Dial-In User Service ) é um protocolo de rede que fornece autenticação centralizada, autorização e gerenciamento de contabilidade ( AAA ) para usuários que se conectam e usam um serviço de rede. O RADIUS foi desenvolvido pela Livingston Enterprises em 1991 como um protocolo de autenticação e contabilidade de servidor de acesso. Posteriormente, foi incorporado aos padrões IEEE 802 e IETF .

RADIUS é um protocolo cliente / servidor executado na camada de aplicativo e pode usar TCP ou UDP . Os servidores de acesso à rede, que controlam o acesso a uma rede, geralmente contêm um componente cliente RADIUS que se comunica com o servidor RADIUS. O RADIUS costuma ser o back-end de escolha para autenticação 802.1X . Um servidor RADIUS é geralmente um processo em segundo plano executado no UNIX ou Microsoft Windows .

Componentes de protocolo

RADIUS é um protocolo AAA (autenticação, autorização e contabilidade) que gerencia o acesso à rede. O RADIUS usa dois tipos de pacotes para gerenciar todo o processo AAA: Access-Request, que gerencia a autenticação e autorização; e Accounting-Request, que gerencia a contabilidade. A autenticação e a autorização são definidas no RFC 2865, enquanto a contabilidade é descrita pelo RFC 2866.

Autenticação e autorização

O usuário ou máquina envia uma solicitação a um Servidor de Acesso à Rede (NAS) para obter acesso a um recurso de rede específico usando credenciais de acesso. As credenciais são passadas para o dispositivo NAS por meio do protocolo de camada de link - por exemplo, Protocolo ponto a ponto (PPP) no caso de muitos provedores de discagem ou DSL ou postadas em um formulário da web seguro HTTPS .

Por sua vez, o NAS envia uma mensagem de solicitação de acesso RADIUS ao servidor RADIUS, solicitando autorização para conceder acesso por meio do protocolo RADIUS.

Essa solicitação inclui credenciais de acesso, geralmente na forma de nome de usuário e senha ou certificado de segurança fornecido pelo usuário. Além disso, a solicitação pode conter outras informações que o NAS conhece sobre o usuário, como seu endereço de rede ou número de telefone, e informações sobre o ponto físico de conexão do usuário com o NAS.

O servidor RADIUS verifica se as informações estão corretas usando esquemas de autenticação como PAP , CHAP ou EAP . O comprovante de identificação do usuário é verificado, juntamente com, opcionalmente, outras informações relacionadas à solicitação, como endereço de rede ou número de telefone do usuário, status da conta e privilégios específicos de acesso ao serviço de rede. Historicamente, os servidores RADIUS verificavam as informações do usuário em um banco de dados de arquivo simples armazenado localmente. Os servidores RADIUS modernos podem fazer isso ou podem consultar fontes externas - geralmente servidores SQL , Kerberos , LDAP ou Active Directory - para verificar as credenciais do usuário.

Fluxo de autenticação e autorização RADIUS

O servidor RADIUS retorna uma das três respostas ao NAS: 1) Rejeição de acesso, 2) Desafio de acesso ou 3) Aceitação de acesso.

Rejeitar acesso
O usuário é incondicionalmente negado o acesso a todos os recursos de rede solicitados. Os motivos podem incluir o não fornecimento de prova de identificação ou uma conta de usuário desconhecida ou inativa.
Desafio de acesso
Solicita informações adicionais do usuário, como uma senha secundária, PIN, token ou cartão. O desafio de acesso também é usado em diálogos de autenticação mais complexos, onde um túnel seguro é estabelecido entre a máquina do usuário e o servidor Radius de forma que as credenciais de acesso sejam ocultadas do NAS.
Acesso Aceito
O acesso é concedido ao usuário. Depois que o usuário é autenticado, o servidor RADIUS geralmente verifica se o usuário está autorizado a usar o serviço de rede solicitado. Um determinado usuário pode ter permissão para usar a rede sem fio de uma empresa, mas não seu serviço VPN, por exemplo. Novamente, essas informações podem ser armazenadas localmente no servidor RADIUS ou podem ser consultadas em uma fonte externa, como LDAP ou Active Directory.

Cada uma dessas três respostas RADIUS pode incluir um atributo Reply-Message que pode dar um motivo para a rejeição, o prompt para o desafio ou uma mensagem de boas-vindas para aceitar. O texto no atributo pode ser passado para o usuário em uma página da web de retorno.

Os atributos de autorização são transmitidos ao NAS estipulando os termos de acesso a serem concedidos. Por exemplo, os seguintes atributos de autorização podem ser incluídos em uma aceitação de acesso:

  • O endereço IP específico a ser atribuído ao usuário
  • O pool de endereços a partir do qual o endereço IP do usuário deve ser escolhido
  • O tempo máximo que o usuário pode permanecer conectado
  • Uma lista de acesso, fila de prioridade ou outras restrições ao acesso de um usuário
  • Parâmetros L2TP
  • Parâmetros VLAN
  • Parâmetros de qualidade de serviço (QoS)

Quando um cliente é configurado para usar RADIUS, qualquer usuário do cliente apresenta informações de autenticação ao cliente. Isso pode ser com um prompt de login personalizável, onde o usuário deve inserir seu nome de usuário e senha. Como alternativa, o usuário pode usar um protocolo de enquadramento de link, como o protocolo ponto a ponto (PPP), que possui pacotes de autenticação que transportam essas informações.

Depois de obter essas informações, o cliente pode optar por autenticar usando RADIUS. Para isso, o cliente cria uma "Solicitação de Acesso" contendo atributos como o nome do usuário, a senha do usuário, o ID do cliente e o ID da porta que o usuário está acessando. Quando uma senha está presente, ela é ocultada usando um método baseado no RSA Message Digest Algorithm MD5.

Contabilidade

Fluxo de contabilidade RADIUS

A contabilidade é descrita no RFC 2866.

Quando o acesso à rede é concedido ao usuário pelo NAS , um início de contabilidade (um pacote de solicitação de contabilidade RADIUS contendo um atributo Acct-Status-Type com o valor "start") é enviado pelo NAS ao servidor RADIUS para sinalizar o início de o acesso do usuário à rede. Os registros "Iniciar" normalmente contêm a identificação do usuário, endereço de rede, ponto de conexão e um identificador de sessão exclusivo.

Periodicamente, os registros de atualização provisória (um pacote RADIUS Accounting Request contendo um atributo Acct-Status-Type com o valor "interim-update") podem ser enviados pelo NAS para o servidor RADIUS, para atualizá-lo no status de uma sessão ativa. Os registros "provisórios" normalmente transmitem a duração da sessão atual e informações sobre o uso de dados atual.

Finalmente, quando o acesso à rede do usuário é fechado, o NAS emite um registro final de interrupção de contabilidade (um pacote de solicitação de contabilidade RADIUS contendo um atributo Acct-Status-Type com o valor "stop") para o servidor RADIUS, fornecendo informações sobre o uso final em termos de tempo, pacotes transferidos, dados transferidos, motivo da desconexão e outras informações relacionadas ao acesso do usuário à rede.

Normalmente, o cliente envia pacotes de solicitação de contabilidade até receber uma confirmação de resposta de contabilidade, usando algum intervalo de repetição.

O objetivo principal desses dados é que o usuário possa ser cobrado de acordo; os dados também são comumente usados ​​para fins estatísticos e para monitoramento geral da rede.

Roaming

Roaming usando um servidor proxy RADIUS AAA.

RADIUS é comumente usado para facilitar roaming entre ISPs , incluindo por:

  • Empresas que fornecem um único conjunto global de credenciais que podem ser usadas em muitas redes públicas;
  • Instituições independentes, mas colaboradoras, que emitem suas próprias credenciais para seus próprios usuários, que permitem que um visitante de uma para outra seja autenticado por sua instituição de origem, como no eduroam .

O RADIUS facilita isso pelo uso de domínios , que identificam para onde o servidor RADIUS deve encaminhar as solicitações AAA para processamento.

Reinos

Um domínio é comumente anexado ao nome de usuário de um usuário e delimitado com um sinal '@', semelhante a um nome de domínio de endereço de e-mail. Isso é conhecido como notação pós-fixada para o reino. Outro uso comum é a notação de prefixo , que envolve acrescentar o domínio ao nome do usuário e usar '\' como delimitador. Os servidores RADIUS modernos permitem que qualquer caractere seja usado como um delimitador de domínio, embora na prática '@' e '\' sejam normalmente usados.

Os reinos também podem ser compostos usando notação prefixada e pós-fixada, para permitir cenários de roaming complicados; por exemplo, somedomain.com \ username@anotherdomain.com pode ser um nome de usuário válido com dois domínios.

Embora os realms muitas vezes se assemelhem a domínios, é importante observar que os realms são, na verdade, um texto arbitrário e não precisam conter nomes de domínio reais. Os formatos de domínio são padronizados no RFC 4282, que define um identificador de acesso à rede (NAI) na forma de 'usuário @ domínio'. Nessa especificação, a parte 'realm' deve ser um nome de domínio. No entanto, nem sempre essa prática é seguida. O RFC 7542 substituiu o RFC 4282 em maio de 2015.

Operações de proxy

Quando um servidor RADIUS recebe uma solicitação AAA para um nome de usuário contendo um domínio, o servidor fará referência a uma tabela de domínios configurados. Se o domínio for conhecido, o servidor, então, fará o proxy da solicitação para o servidor inicial configurado para esse domínio. O comportamento do servidor proxy em relação à remoção do domínio da solicitação ("remoção") depende da configuração da maioria dos servidores. Além disso, o servidor proxy pode ser configurado para adicionar, remover ou reescrever solicitações AAA quando eles são proxy novamente.

O encadeamento de proxy é possível no RADIUS e os pacotes de autenticação / autorização e contabilidade geralmente são roteados entre um dispositivo NAS e um servidor doméstico por meio de uma série de proxies. Algumas das vantagens de usar cadeias de proxy incluem melhorias de escalabilidade, implementações de políticas e ajustes de capacidade. Mas em cenários de roaming, NAS, Proxies e Home Server podem ser normalmente gerenciados por diferentes entidades administrativas. Conseqüentemente, o fator de confiança entre os proxies ganha mais importância em tais aplicações Interdomínio. Além disso, a ausência de segurança ponta a ponta no RADIUS aumenta a importância da confiança entre os proxies envolvidos. As cadeias de proxy são explicadas no RFC 2607 .

Segurança

O roaming com RADIUS expõe os usuários a várias questões de segurança e privacidade. De forma mais geral, alguns parceiros de roaming estabelecem um túnel seguro entre os servidores RADIUS para garantir que as credenciais dos usuários não sejam interceptadas durante o proxy na Internet. Isso é uma preocupação, pois o hash MD5 integrado ao RADIUS é considerado inseguro.

Estrutura do pacote

Formato de dados de pacote RADIUS.

O RADIUS é transportado por UDP / IP nas portas 1812 e 1813.

O formato de pacote de dados RADIUS é mostrado à direita. Os campos são transmitidos da esquerda para a direita, começando com o código, o identificador, o comprimento, o autenticador e os atributos.

Os códigos RADIUS atribuídos (decimais) incluem o seguinte:

Código Atribuição
1 Pedido de Acesso
2 Acesso-Aceitar
3 Acesso-Rejeitar
4 Pedido de Contabilidade
5 Contabilidade-Resposta
11 Desafio de acesso
12 Status-Server (experimental)
13 Status-Cliente (experimental)
40 Solicitação de desconexão
41 Desconectar-ACK
42 Disconnect-NAK
43 Solicitação CoA
44 CoA-ACK
45 CoA-NAK
255 Reservado

O campo Identifier auxilia na correspondência de solicitações e respostas.

O campo Comprimento indica o comprimento de todo o pacote RADIUS, incluindo os campos Código, Identificador, Comprimento, Autenticador e Atributo opcionais.

O Autenticador é usado para autenticar a resposta do servidor RADIUS e é usado para criptografar senhas; seu comprimento é de 16 bytes.

Pares de valores de atributos

Layout RADIUS AVP

Os pares de valor de atributo RADIUS (AVP) carregam dados na solicitação e na resposta para as transações de autenticação, autorização e contabilidade. O comprimento do pacote radius é usado para determinar o final dos AVPs.

Atributos específicos do fornecedor

O RADIUS é extensível; muitos fornecedores de hardware e software RADIUS implementam suas próprias variantes usando Atributos específicos do fornecedor (VSAs). A Microsoft publicou alguns de seus VSAs. As definições de VSA de muitas outras empresas permanecem proprietárias e / ou ad hoc; no entanto, muitos dicionários VSA podem ser encontrados baixando o código-fonte de implementações RADIUS de código aberto, por exemplo, FreeRADIUS .

Segurança

O protocolo RADIUS transmite senhas ofuscadas usando um segredo compartilhado e o algoritmo de hash MD5 . Como essa implementação específica fornece proteção fraca das credenciais do usuário, proteção adicional, como túneis IPsec ou redes de data center fisicamente protegidas, deve ser usada para proteger ainda mais o tráfego RADIUS entre o dispositivo NAS e o servidor RADIUS. Além disso, as credenciais de segurança do usuário são a única parte protegida pelo próprio RADIUS, mas outros atributos específicos do usuário, como IDs de grupos de túneis ou associações de VLAN passadas por RADIUS podem ser considerados confidenciais (úteis para um invasor) ou privados (suficientes para identificar o cliente individual) também. O protocolo RadSec afirma resolver os problemas de segurança mencionados acima.

História

À medida que mais clientes dial-up usavam a NSFnet, uma solicitação de proposta foi enviada pela Merit Network em 1991 para consolidar seus vários sistemas proprietários de autenticação, autorização e contabilidade. Entre os primeiros entrevistados estava a Livingston Enterprises e uma versão inicial do RADIUS foi escrita após uma reunião. O servidor RADIUS anterior foi instalado em um sistema operacional UNIX . A Livingston Enterprises foi adquirida pela Lucent e, junto com a Merit, foram tomadas medidas para obter a aceitação da indústria para o RADIUS como um protocolo. Ambas as empresas ofereceram um servidor RADIUS gratuitamente. RADIUS foi publicado em 1997 como RFC 2058 e RFC 2059, as versões atuais são RFC 2865 e RFC 2866.

O padrão RADIUS original especificava que o RADIUS não tem estado e deve ser executado no protocolo UDP ( User Datagram Protocol ). Para autenticação, previu-se que o RADIUS deveria suportar o protocolo de autenticação de senha (PAP) e o protocolo de autenticação de handshake de desafio (CHAP) sobre o protocolo ponto a ponto . As senhas são ocultadas pegando o hash MD5 do pacote e um segredo compartilhado e, em seguida, fazendo o XOR desse hash com a senha. O RADIUS original também fornecia mais de 50 pares de valor de atributo, com a possibilidade de os fornecedores configurarem seus próprios pares.

A escolha do modelo de segurança salto a salto, em vez da criptografia ponta a ponta , significa que, se vários servidores RADIUS proxy estiverem em uso, cada servidor deverá examinar, executar a lógica e passar todos os dados em uma solicitação. Isso expõe dados como senhas e certificados a cada salto. Os servidores RADIUS também não tinham a capacidade de interromper o acesso aos recursos depois que uma autorização era emitida. Padrões subsequentes, como RFC 3576 e seu sucessor RFC 5176, permitiram que os servidores RADIUS alterassem dinamicamente a autorização de um usuário ou desconectassem um usuário completamente.

Agora, existem vários servidores RADIUS comerciais e de código aberto. Os recursos podem variar, mas a maioria pode pesquisar os usuários em arquivos de texto, servidores LDAP , vários bancos de dados, etc. Os registros contábeis podem ser gravados em arquivos de texto, vários bancos de dados, encaminhados para servidores externos, etc. SNMP é frequentemente usado para monitoramento remoto e verificação keep-alive de um servidor RADIUS. Os servidores proxy RADIUS são usados ​​para administração centralizada e podem reescrever pacotes RADIUS dinamicamente por motivos de segurança ou para converter entre dialetos de fornecedores.

O protocolo de diameter foi concebido como um substituto para o RADIUS. Embora ambos sejam protocolos de autenticação, autorização e contabilidade (AAA), os casos de uso dos dois protocolos divergem desde então. O diameter é amplamente utilizado no espaço 3G . RADIUS é usado em outro lugar. Uma das maiores barreiras para que o diameter substitua o RADIUS é que os switches e os pontos de acesso normalmente implementam o RADIUS, mas não o diameter. Diameter usa SCTP ou TCP, enquanto RADIUS normalmente usa UDP como camada de transporte . A partir de 2012, o RADIUS também pode usar TCP como camada de transporte com TLS para segurança.

Documentação de padrões

O protocolo RADIUS está atualmente definido nos seguintes documentos RFC da IETF .

RFC Título Data de publicação Artigo relacionado RFCs relacionados Notas
RFC 2058 Serviço de usuário de discagem com autenticação remota (RADIUS) Janeiro de 1997 RAIO Obsoleto por RFC 2138
RFC 2059 Contabilidade RADIUS Janeiro de 1997 RAIO Obsoleto por RFC 2139
RFC 2138 Serviço de usuário de discagem com autenticação remota (RADIUS) Abril de 1997 RAIO Obsoleto por RFC 2865
RFC 2139 Contabilidade RADIUS Abril de 1997 RAIO Obsoleto por RFC 2866
RFC 2548 Atributos RADIUS específicos do fornecedor da Microsoft Março de 1999 RAIO
RFC 2607 Encadeamento de proxy e implementação de política em roaming Junho de 1999
RFC 2618 MIB de cliente de autenticação RADIUS Base de informações de gestão Obsoleto por RFC 4668
RFC 2619 Servidor de autenticação RADIUS MIB Base de informações de gestão Obsoleto por RFC 4669
RFC 2620 RADIUS Accounting Client MIB Junho de 1999 Base de informações de gestão Obsoleto por RFC 4670
RFC 2621 MIB do servidor de contabilidade RADIUS Junho de 1999 Base de informações de gestão Obsoleto por RFC 4671
RFC 2809 Implementação de túnel obrigatório L2TP via RADIUS Abril de 2000
RFC 2865 Serviço de usuário de discagem com autenticação remota (RADIUS) Junho de 2000 RAIO Atualizado por RFC 2868, RFC 3575, RFC 5080 Este padrão descreve a autenticação e autorização RADIUS entre um Servidor de Acesso à Rede (NAS) e um servidor de autenticação RADIUS compartilhado. Este protocolo também é usado para transportar informações de configuração do servidor RADIUS para o NAS.
RFC 2866 Contabilidade RADIUS Junho de 2000 RAIO Este padrão descreve como as informações de contabilidade são transportadas do NAS para um servidor de contabilidade RADIUS compartilhado.
RFC 2867 Modificações de contabilidade RADIUS para suporte de protocolo de túnel Junho de 2000 RAIO Atualiza RFC 2866
RFC 2868 Atributos RADIUS para suporte de protocolo de túnel Junho de 2000 Atualiza RFC 2865
RFC 2869 Extensões RADIUS Junho de 2000 Atualizado por RFC 3579, RFC 5080
RFC 2882 Requisitos de servidores de acesso à rede: Práticas RADIUS estendidas Julho de 2000
RFC 3162 RADIUS e IPv6 Agosto de 2001
RFC 3575 Considerações IANA para RADIUS Julho de 2003
RFC 3576 Extensões de autorização dinâmica para RADIUS Julho de 2003 Obsoleto por RFC 5176
RFC 3579 Suporte RADIUS para EAP Setembro 2003 Protocolo de Autenticação Extensível Atualiza RFC 2869
RFC 3580 Diretrizes de uso RADIUS IEEE 802.1X Setembro 2003 802.1X
RFC 4014 Subopção de atributos RADIUS para a opção de informações do agente de retransmissão DHCP Fevereiro de 2005
RFC 4372 Identidade de usuário cobrável Janeiro de 2006
RFC 4590 Extensão RADIUS para Autenticação Digest Julho de 2006 Obsoleto por RFC 5090
RFC 4668 Cliente de autenticação RADIUS MIB para IPv6 Agosto de 2006 Base de informações de gestão
RFC 4669 Servidor de autenticação RADIUS MIB para IPv6 Agosto de 2006 Base de informações de gestão
RFC 4670 RADIUS Accounting Client MIB para IPv6 Agosto de 2006 Base de informações de gestão
RFC 4671 RADIUS Accounting Server MIB para IPv6 Agosto de 2006 Base de informações de gestão
RFC 4675 Atributos RADIUS para LAN Virtual e Suporte Prioritário Setembro de 2006
RFC 4679 Atributos RADIUS específicos do fornecedor do fórum DSL Setembro de 2006
RFC 4818 Atributo de prefixo IPv6 delegado RADIUS Abril de 2007
RFC 4849 Atributo de regra de filtro RADIUS Abril de 2007
RFC 5080 Problemas comuns de implementação do RADIUS e correções sugeridas Dezembro de 2007 Atualiza RFC 3579
RFC 5090 Extensão RADIUS para Autenticação Digest Fevereiro de 2008
RFC 5176 Extensões de autorização dinâmica para RADIUS Janeiro de 2008
RFC 5607 Autorização RADIUS para gerenciamento NAS Julho de 2009
RFC 5997 Uso de pacotes de servidor de status no protocolo RADIUS Agosto de 2010 Atualiza RFC 2866
RFC 6158 Diretrizes de design RADIUS Março de 2011
RFC 6218 Atributos RADIUS específicos do fornecedor da Cisco para a entrega de material de codificação Abril de 2011
RFC 6421 Requisitos de cripto-agilidade para serviço de usuário discado com autenticação remota (RADIUS) Novembro de 2011
RFC 6613 RADIUS sobre TCP Maio de 2012 Experimental
RFC 6614 Criptografia TLS (Transport Layer Security) para RADIUS Maio de 2012 Experimental
RFC 6911 Atributos RADIUS para redes de acesso IPv6 Abril de 2013 Trilha de padrões
RFC 6929 Extensões do protocolo RADIUS (Remote Authentication Dial-In User Service) Abril de 2013 Atualiza RFC 2865, RFC 3575, RFC 6158
RFC 7360 Datagram Transport Layer Security (DTLS) como uma camada de transporte para RADIUS Setembro de 2014 Experimental
RFC 7585 Descoberta de pares dinâmicos para RADIUS / TLS e RADIUS / DTLS com base no identificador de acesso à rede (NAI) Outubro 2015 Experimental
RFC 8044 Tipos de dados em RADIUS Janeiro de 2017 Atualizações: 2865, 3162, 4072, 6158, 6572, 7268
RFC 8559 Proxying de autorização dinâmica no protocolo RADIUS Abril de 2019 Trilha de padrões

Veja também

Referências

Bibliografia

links externos