Abstrato—Este documento tem como objetivo apresentar o protocolo Remote Access Dial-In User Service (RADIUS) assim como o seu funcionamento.
Com o início da massificação de acesso a recursos remotos (Internet, Empresas, etc.) no início dos anos 90, tornou-se impraticável gerir este crescente número de necessidades de acesso, recursos a disponibilizar e respetiva contabilização. (tráfego, pacotes, tempo gasto, etc.) Além disto, tornou-se necessário conseguir gerir de forma prática e eficaz os recursos estritamente necessários aos quais estes utilizadores teriam acesso para desenvolver o seu trabalho.
O protocolo RADIUS veio fornecer mecanismos conhecidos como AAA - Authentication, Authorization and Accounting (Autenticação Autorização e Contabilização). A Autenticação garante a identidade do utilizador, a Autorização define quais os recursos que estarão acessíveis ao utilizador e a Contabilização permite manter o registo do que cada utilizador faz em cada acesso.
Palavras-Chave— RADIUS, Autenticação, Autorização, Contabilização, Redes de Computadores, Sistemas Distribuídos.
I. INTRODUÇÂO A. Motivação
ERIRsistemas de informação com múltiplos utilizadores e recursos partilhados requer obrigatoriamente meios de autenticação e autorização centralizados. Se a esta realidade juntarmos a necessidade de interligação de redes através de acessos remotos via VPN, redes sem fios (Wi-Fi) ou outras, os problemas de segurança tornam-se cada vez mais sérios. Para responder a estas necessidades, foi solicitado o desenvolvimento do protocolo RADIUS.
Inicialmente desenvolvido pela Livingston Enterprises1 no início da década de 90, tinha o objetivo de centralizar os mecanismos de autenticação para as ligações de acesso Documento submetido em 4 de Abril de 2013, no âmbito dos termos definidos para avaliação do primeiro trabalho prático da Unidade Curricular de Comunicações de Dados.
Autor A. M. é aluno do segundo ano do curso de Engenharia de Sistemas Informáticos-P. L. no Instituto Politécnico do Cávado e do Ave (e-mail: a7820@alunos.ipca.pt).
Autor C. P. é aluno do segundo ano do curso de Engenharia de Sistemas Informáticos-P. L. no Instituto Politécnico do Cávado e do Ave. (e-mail: a8140@alunos.ipca.pt).
L. B. é aluno do segundo ano do curso de Engenharia de Sistemas Informáticos-P. L. no Instituto Politécnico do Cávado e do Ave. (e-mail: a7812@alunos.ipca.pt)..
1 A Livingston Enterprises foi adquirida em 1997 pela Lucent Technologies, de quem faz hoje parte.
telefónico usadas nas ligações de acesso à Internet, nessa altura. A crescente necessidade de gerir e suportar cada vez maior número de utilizadores, plataformas e fabricantes (interoperabilidade), fez com que o uso deste protocolo fosse massificado de tal forma que ainda hoje é a referência e o mais usado em processos de autenticação remota e distribuída. Um bom exemplo da utilização do protocolo RADIUS é a rede eduroam. A rede eduroam, utiliza como componente central para a autenticação de todos os seus utilizadores a nível mundial, o protocolo RADIUS. Além desta grande rede que comporta milhares de utilizadores, a gestão de acesso a hotspot’s Wi-Fi é normalmente garantida por servidores RADIUS, apenas para referir alguns dos mais conhecidos. O protocolo RADIUS foi inicialmente definido no RFC 2058 em Janeiro de 1997 em conjunto com o RFC 2059 que se refere os processos de contabilização (Accounting) do protocolo RADIUS. Depois de inúmeros melhoramentos descritos ao longo de vários RFC, vigora atualmente o RFC 2865 no que respeita ao protocolo RADIUS e o RFC 2866 relativamente à contabilização RADIUS, ambos de Junho de 2000.
B. Estrutura do documento
Este documento apresenta a seguinte estrutura:
- Introdução: Neste capítulo descrevemos a origem do protocolo RADIUS e a motivação para o seu desenvolvimento.
- Descrição do Protocolo: Neste capítulo fazemos uma análise às caraterísticas e funcionamento do protocolo RADIUS.
- Tipos de Pacotes: Neste capítulo estudamos os vários tipos de pacotes usados pelo protocolo RADIUS.
- Atributos: Neste capítulo exploramos os tipos de atributos e sua utilização.
- Aplicações: Neste capítulo falamos um pouco sobre a rede eduroam que faz uso extensivo do protocolo RADIUS.
- Bibliografia: Aqui, enumeramos as fontes que usamos para elaboração do presente trabalho.
II. DESCRIÇÃO DO PROTOCOLO A. Operação
O protocolo RADIUS usa o modelo Cliente-Servidor e as suas comunicações são realizadas recorrendo ao protocolo User Datagram Protocol (UDP). No processo de autenticação, o Network Access Server (NAS) atua como um cliente RADIUS que encaminha o pedido do utilizador para o servidor
Remote Authentication Dial-In User Service
RADIUS
Adélio C. de Miranda, Carlos D. D. Pereira, Luís M. F. Barreto, ESI-PL, IPCA
RADIUS. O servidor RADIUS por sua vez, recebe o pedido do cliente, processa a autenticação do utilizador e retorna toda a informação necessárias para o cliente RADIUS de forma a que este faculte (ou não) o devido acesso ao utilizador.
Um servidor RADIUS pode também atuar como um servidor proxy (intermediário) relativamente a outros servidores RADIUS. Neste caso, o servidor RADIUS reencaminha os pedidos dos clientes RADIUS para outro servidor RADIUS e a resposta deste para os clientes.
Todas as comunicações entre o cliente e o servidor RADIUS são encriptadas recorrendo a um shared secret (segredo partilhado) do conhecimento do cliente e servidor RADIUS. De forma a aumentar o nível de segurança, este segredo nunca é enviado pela rede em nenhuma comunicação ou pedido de acesso. Esta funcionalidade é normalmente usada para dar resposta a cenários em que os utilizadores têm a necessidade de aceder a redes ou recursos a partir de várias localizações - roaming.
O servidor RADIUS suporta vários métodos de autenticação e pode ser implementado recorrendo à utilização dos mais conhecidos tipos de bases de dados para consulta e registo dos acessos dos utilizadores. São exemplo servidores: Structured Query Language (SQL) ou Lightweight Directory Access Protocol (LDAP). Nestes casos, o servidor RADIUS valida os pedidos de autenticação/autorização consultando estas bases de dados.
B. Arquitetura
Na implementação básica, o protocolo RADIUS é usado entre dois servidores: o servidor RADIUS e o Network Access Server (NAS). Há ainda pelo menos um terceiro interveniente que é o cliente que solicita algum tipo de acesso ao NAS.
Para que haja comunicação com sucesso entre o servidor RADIUS e o NAS, é necessário que exista um shared secret (segredo partilhado) que não é mais do que uma palavra-passe, do conhecimento de ambos. As características deste segredo/palavra-passe não são definidas pelo protocolo, no entanto, não pode ser nulo e as boas práticas recomendam que seja complexo de forma a atrasar ataques do tipo “força-bruta”. Este segredo tem como objetivo autenticar o NAS perante o servidor RADIUS e, ao mesmo tempo, encriptar a palavra-passe do utilizador.
O servidor RADIUS recorre a uma base de dados, que pode ser local ou remota, para validação dos utilizadores e respetivas palavras-passe e, caso necessários, outros requisitos.
Quando o servidor RADIUS atua como proxy (intermediário), este reenvia as comunicações entre o NAS e o servidor RADIUS responsável pela autenticação do utilizador em questão. Iremos abordar este cenário mais à frente, no capítulo II. F. – Proxy.
O Network Access Server (NAS) age como um cliente relativamente ao servidor RADIUS. Quando um utilizador faz a solicitação ao NAS, este solicita ao utilizador as credenciais necessárias para autenticação. Por exemplo, nome de utilizador e palavra-passe. De seguida o NAS envia o pedido de acesso ao servidor RADIUS contendo os atributos que este necessita e que têm a informação relativa
ao utilizador. Tal como descrito anteriormente, sempre que é requerida a palavra-passe, esta é encriptada antes de ser enviada pela rede. De seguida, o NAS aguarda pela resposta do servidor RADIUS. Caso o pedido seja aceite, o servidor RADIUS pode ainda fornecer dados de configuração e o tipo de acesso permitido ao utilizador. Caso o servidor RADIUS não responda em tempo útil, o NAS pode fazer nova solicitação ao mesmo servidor, ou a outro(s) servidor(es) alternativo(s), caso esteja(m) configurado(s). Na Fig. 1, apresentamos um exemplo da implementação da arquitetura necessária para a utilização do protocolo RADIUS.
Fig. 1. Arquitetura de um sistema RADIUS
O protocolo RADIUS usa o protocolo UDP como meio de transporte das suas comunicações. Atualmente é usada a porta 1812 para o servidor RADIUS, no entanto, inicialmente era usada a porta 1645. Esta alteração foi feita pelo fato de a utilização desta porta entrar em conflito com o serviço datametrics.
A escolha do protocolo UDP em detrimento do TCP, teve como principal motivação o fato de o UDP ser um protocolo mais leve do que o TCP. Além disto, a fiabilidade garantida pelo TCP poderia por exemplo, levar um utilizador a ter que esperar bastante tempo caso a ligação entre o NAS e o servidor RADIUS fosse lenta ou de má qualidade. Com o TCP, as garantias de retransmissão e da inexistência de perdas poderiam tornar o processo de autenticação muito lento. Com o recurso ao UDP, caso não haja reposta do servidor RADIUS em tempo útil, é feito um novo pedido ao mesmo, ou eventualmente a outros servidores RADIUS.
C. Formato do pacote
Tal como já vimos, o RADIUS usa UDP para troca de informação. Um datagrama UDP contém exatamente um pacote RADIUS. Por seu lado, um pacote RADIUS consiste em cinco campos distintos: Code, Identifier, Length, Authenticator e Atributes.
Fig. 2. Formato do pacote RADIUS
O primeiro campo de um pacote RADIUS é o Code. Este campo do tamanho de um octeto, define o tipo de pacote RADIUS. Inicialmente foram definidos seis valores possíveis: quatro para autenticação e autorização, dois para contabilização e os restantes 2 reservados para utilização futura. Mais tarde foram definidos mais códigos específicos para diversos fabricantes. Todos os pacotes cujo campo Code seja inválido não são processados nem dão origem a nenhuma mensagem de erro.
O segundo campo é o Identifier. Este campo ocupa um octeto e tem como objetivo combinar os pedidos e respetivas respostas. A cada novo pedido é atribuído um novo Identifier.
O terceiro campo, Length, é preenchido com a informação do tamanho do pacote e ocupa dois octetos. Cada pacote RADIUS tem no mínimo os campos Code, Identifier, Length e Authenticator, por isso, o campo Length tem no mínimo, o valor 20. O valor máximo deste campo é 4096 e, caso o pacote RADIUS seja maior, todos os dados que estejam “para lá” do tamanho máximo são ignorados. Esta medida visa prevenir overflows. Caso o pacote RADIUS seja maior do que o tamanho especificado no campo Length, o pacote não é processado nem é gerada nenhuma mensagem de erro.
O quarto campo é o Autenticator e ocupa dezasseis octetos. O octeto mais significativo aparece em primeiro lugar e é usado para duas funcionalidades de segurança: autenticar a resposta do servidor RADIUS para o NAS e encriptar a palavra-passe do utilizador. Há dois tipos de campos Authenticator:
Request-Authenticator é o nome do campo Authenticator nos pacotes do tipo Access-Request. O Request-Authenticator é gerado aleatoriamente pelo NAS a cada pedido de autenticação e serve para fazer a correspondência entre o pedido do NAS e a resposta do servidor RADIUS. Por este motivo este valor tem que ser único e imprevisível. Este campo também é usado pelo NAS para encriptar a palavra-passe do utilizador.
Response-Authenticator é o nome do campo Authenticator nos pacotes do tipo Accept, Reject e Access-Challenge. O valor do campo Response Authenticator é gerado pelo servidor RADIUS. Para este cálculo, o servidor RADIUS usa os valores dos campos Code, Identifier e Length
da resposta que esteja a ser gerada e do segredo partilhado. Estes campos são concatenados atendendo a esta ordem para de seguida ser calculado o hash MD5 de toda a string concatenada. O valor hash gerado é atribuído ao campo Response-Authenticator. A equação 1 apresenta a fórmula de cálculo do campo Response-Authenticator.
) Re ( 5 Re et SharedSecr Atributes nticator questAuthe Length Identifier Code MD enticator sponseAuth + + + + + = (1)
Além dos quarto campos base já referidos, um pacote RADIUS pode ainda conter um variado número de atributos. Estes serão analisados com maior detalhe no capítulo IV.
D. Autenticação e Autorização
Quando um NAS necessita de autenticar um utilizador via RADIUS, o NAS envia um Access-Request ao servidor RADIUS. Para este pacote o NAS define os atributos apropriados que descrevem a informação necessária relativamente ao utilizador e ao serviço solicitado ao servidor RADIUS. A palavra-passe é encriptada para que não circule na rede em texto simples. Além disto é gerado um Request-Authenticator único para o pedido em questão de forma que seja possível fazer coincidir a resposta do servidor RADIUS com cada pedido.
Ao receber este pedido, o servidor RADIUS verifica a lista de clientes válidos e para os quais detém um segredo partilhado. Caso o pedido não seja proveniente de um cliente conhecido, este é descartado e não é devolvida nenhuma mensagem de erro. Caso o cliente seja conhecido, o servidor RADIUS desencripta a palavra-passe do utilizador (caso exista) e verifica na base de dados se o utilizador em questão existe e se a palavra-passe coincide.
Caso o utilizador não exista na base de dados, a palavra-passe não esteja correta ou o utilizador não tenha permissão de acesso ao NAS em questão, o servidor RADIUS envia um pacote Access-Reject para o cliente. Caso o utilizador exista na base de dados, a palavra-passe esteja correta, o utilizador tenha permissão para aceder e não seja necessário um Challenge-Response, o acesso é concedido e então, é enviado um pacote Access-Accept.
Em cada resposta, o campo Response-Authenticator é calculado para o respetivo pacote, e o campo Identifier mantém-se igual ao do pedido. O pacote Access-Accept pode transportar informações adicionais relativas à configuração para o utilizador no campo Attributes. Por outro lado, o pacote Access-Reject apenas contém um atributo que contém a mensagem de erro a apresentar ao utilizador. A Fig. 3 mostra o procedimento da autenticação e autorização RADIUS.
Quando o NAS recebe a resposta, fá-la coincidir com o respetivo pedido através da correspondência dos valores do campo Identifier. Com isto, o NAS calcula o valor do campo Response-Authenticator usando o mesmo método usado pelo servidor RADIUS. Por fim, compara o valor obtido com o que foi transmitido. Caso os valores sejam iguais, o servidor RADIUS é autenticado e a integridade da resposta é confirmada. Todos os campos da resposta (com o Request Authenticator no lugar do Response Authenticator que está a
ser calculado) juntamente com os atributos da resposta, são concatenados juntamente com o segredo partilhado e o valor hash desta concatenação compõem o Response Authenticator. O Response Authenticator pode então ser utilizado para verificar a integridade e autenticar o servidor RADIUS, uma vez que qualquer alteração na mensagem, ou um segredo incorreto invalidariam o pacote.
O protocolo RADIUS ainda suporta um método adicional de challenge/response. Neste método, após receber o Access-Request e verificar as informações do utilizador na base de dados, o servidor RADIUS envia um pacote Access-Challenge ao cliente. Este pacote pode conter como atributo a mensagem a apresentar ao utilizador.
Quando o NAS recebe um pacote Access-Challenge, este apresenta a mensagem ao utilizado , caso exista nos atributos do pacote e aguarda a resposta do utilizador. Após a resposta, o servidor NAS reenvia o pacote original Access Request com o novo Identifier e a resposta do utilizador encriptada no atributo User-Password. Caso o NAS não suporte a funcionalidade challenge/response, irá interpretar o Access-Challenge como uma Access-Reject.
O servidor RADIUS verifica novamente na sua base de dados de utilizadores se a resposta ao desafio está correta. Caso não esteja, envia um pacote Access-Reject. Caso a resposta esteja correta, envia um pacore Access-Accept ou um novo Acces-Challenge.
Na Fig. 3, mostramos o algoritmo do processo de autenticação do protocolo RADIUS.
Fig. 3. Processo de Autenticação RADIUS
Com este método de desfio/resposta, o protocolo RADIUS torna-se extremamente flexível e extensível, podendo ser usados dispositivos especiais tais como smart cards, certificados digitais ou dispositivos de identificação biométrica para garantir um mecanismo de autenticação forte.
E. Contabilização
A contabilização de acessos via RADIUS é feita de uma forma similar ao método usado para a Autenticação e Autorização. Há no entanto algumas diferenças que importa salientar. O serviço de contabilização RADIUS usa a porta 1813. Além disto, há também dois códigos de mensagens RADIUS e doze atributos para o processo de contabilização RADIUS. O Request-Authenticator é calculado de forma ligeiramente diferente quando se trata de um processo de contabilização RADIUS.
A contabilização começa quando o NAS envia um pacote com o código Accounting-Request cujo atributo Acct-Type esteja definido como Start para o servidor RADIUS. No pedido de início de contabilização há atributos que contêm informação relativa ao utilizador e ao serviço que esteja a ser usado. Quase todos os atributos que podem ser usados no pacote Access-Request podem também ser usados no pacote Accounting-Request com a exceção dos atributos: User-Password, User-Password, Reply-Message, State e CHAP-Challenge
No momento em que o NAS pretende terminar o processo de contabilização, envia um pacote ao servidor RADIUS com o código Accounting-Request com o atributo Acct-Status-Type definido como Stop. Este pacote pode ainda transportar atributos com informação sobre o serviço que foi usado e estatísticas relativas à utilização.
Após a receção deste pacote, o servidor RADIUS regista o pacote Accounting-Request e, depois de efetuar este registo com sucesso, envia uma mensagem de confirmação ao NAS. Caso o pedido não seja registado com sucesso, não é enviada a mensagem de confirmação e neste caso, retransmite o pedido ou tenta contactar outro servidor RADIUS. No pacote Accounting-Resposnse não há atributos exceto para possíveis estados de proxy ou específicos de algum fabricante.
Na Fig. 4 apresentamos o processo de contabilização RADIUS.
Fig. 4. Processo de contabilização RADIUS
O campo Request-Authenticator é gerado de forma ligeiramente diferente para o pacote Accounting-Request relativamente ao processo usado para a criação do pacote Access-Request. Para o pacote Access-Request o campo Request-Authenticator é um número aleatório. No entanto, para o pacote Accounting-Request o campo
Request-Authenticator é o hash MD5 produzido pela concatenação dos atributos Code, Identifier, Length, desaseis octetos a zero do pedido e o segredo partilhado entre o NAS e o servidor RADIUS. O atributo Response-Authenticator para o pacote Accounting-Resposnse é calculado usando o método descrito para o Response-Authenticator.
F. Proxy
O servidor RADIUS, também pode atuar como um proxy quando reenvia pacotes RADIUS entre o NAS e outro servidor RADIUS que tratará do processo de autenticação. Para melhor perceção, iremos chamar a esse servidor, o servidor remoto. Um servidor RADIUS pode agir como proxy e servidor remoto. Não há limite para o número de servidores remotos para os quais um servidor RADIUS pode reenviar pedidos RADIUS.
Quando um servidor RADIUS recebe um pacote que necessita de ser reenviado para outro servidor, o servidor RADIUS verifica em primeiro lugar se o atributo User-Password existe. Caso exista, o servidor RADIUS desencripta a palavra-passe recorrendo ao segredo que partilha com o cliente. De seguida, encripta novamente a palavra-passe recorrendo ao segredo que partilha com o servidor para o qual vai reencaminhar a mensagem.
O servidor RADIUS adiciona um atributo chamado Proxy-State para lhe permitir identificar a resposta do servidor remoto. Caso já exista algum atributo do tipo Proxy-State no pacote RADIUS, eles mantêm-se inalterados bem como todos os outros atributos que eventualmente existam. De seguida, o servidor RADIUS define o novo valor para o atributo Identifier e envia o pacote para o servidor remoto ou para o próximo servidor RADIUS.
Quando o pacote chega ao servidor remoto, este gere o pedido tal como descrito anteriormente. O servidor remoto responde de acordo com a avaliação que faz ao pedido que lhe chegou. Caso o pedido contivesse atributos do tipo Proxy-State, eles são copiados integralmente para a resposta. Nenhum outro atributo é copiado do pedido, mas podem ser acrescentados alguns outros. Por fim, a resposta é enviada de volta ao cliente que inicialmente fez o pedido.
Assim que o servidor RADIUS que agiu como proxy para o pedido recebe a resposta, verifica-a recorrendo ao Response-Authenticator da resposta e o segredo que partilha com o servidor RADIUS do qual recebeu a resposta. Caso esta verificação falhe, o pacote é descartado e não é enviada nenhuma mensagem de erro. Caso a verificação tenha sucesso, o proxy RADIUS retira o atributo Proxy-State caso tenha adicionado algum e define o Identifier tal como estava no pedido inicial. De seguida, é calculado o novo Response-Authenticator recorrendo ao segredo partilhado com o remetente e o servidor proxy RADIUS. Por último, a resposta é enviada ao remetente do pedido.
Na Fig. 5, descrevemos a autenticação RADIUS recorrendo a um Proxy.
Fig. 5. Proxy RADIUS
III. TIPOS DE PACOTES
O protocolo RADIUS tem quatro tipos diferente de pacotes para autenticação e autorização. Estes são: Access-Request, Access-Accept, Access-Reject and Access-Challenge. Para contabilização, o RADIUS usa dois tipos de pacotes, identificados como Request e Accounting-Response. Inicialmente foram ainda definidos dois tipos para utilização futura - Status-Server e Status-Client. Além destes tipos, vários fabricantes introduziram cerca de 26 novos tipos de pacotes. A tabela 1 apresenta a lista dos tipos de pacotes adicionados ao protocolo RADIUS por vários fabricantes de forma a estender a sua funcionalidade.
TABELAI
RADIUS-TIPOS DE PACOTES INTRODUZIDOS POR FABRICANTES Cód. Nome 6 Accounting Status 7 Password Request 8 Password Ack 9 Password Reject 10 Accounting Message 21 Resource Free Request 22 Resource Free Response 23 Resource Query Request 24 Resource Query Response 25 Alternate Resource Reclaim Request 26 NAS Reboot Request
27 NAS Reboot Response 29 Next Passcode 30 New Pin 31 Terminate Session 32 Password Expired 33 Event Request 34 Event Response 40 Disconnect Request
41 Disconnect Ack 42 Disconnect Nak 43 Change Filters Request 44 Change Filters Ack 45 Change Filters Nak 50 IP Address Allocate 51 IP Address Release
O pacote Access-Request tem o código de valor 1. Este tipo de pacote é usado pelo NAS sempre que este pretenda autenticar um utilizador. O NAS envia então um pacote Access-Request com um novo Identifier e um Request-Authenticator único para o servidor RADIUS. O pacote Access-Request tem atributos que contêm informação relativa ao utilizador tais como User-Name e User-Password. Além disto, o atributo NAS-IP-Address, o NAS-Identifier ou ambos, estão também presentes. Um pacote Access-Request pode ainda conter vários outros atributos.
O pacote Access-Accept tem um código de valor 2. Caso o servidor RADIUS aprove todos os atributos do pacote Access-Request este, responde com um pacote Access-Accept que tem o mesmo Identifier que o pedido. Os atributos do pacote Access-Request contêm informação para o NAS sobre o serviço a ser disponibilizado ao utilizador. O Response-Authenticator é calculado de acordo com o descrito no ponto II. C. Formato dos Pacotes.
O pacote Access-Reject tem um código de valor 3. Caso o servidor RADIUS não aprove algum dos atributos do pacote Access-Request, o servidor RADIUS responde com um pacote Access-Reject contendo o mesmo Identifier que o pedido. O pacote Access-Reject pode conter atributos que contenham uma mensagem a apresentar ao utilizador. O Response-Authenticator é calculado de acordo com o descrito no ponto II. C. Formato do Pacote.
O pacote Access-Challenge tem um código de valor 11. Caso o servidor RADIUS necessite desafiar (challenge) o utilizador no sentido de obter determinada resposta, o servidor RADIUS envia um pacote Access-Challenge com o mesmo Identifier contido no pacote Access-Request. O desafio a apresentar ao utilizador está num ou mais atributos do pacote Access-Challenge. Apenas os atributos State, Vendor-Specific, Idle-Timeout, Session-Timeout e Proxy-State podem também fazer parte do pacote Access-Challenge. O pactode Accounting-Request tem o código de valor 4. Quando um NAS pretende iniciar ou terminar a contabilização de um serviço disponibilizado a um utilizador, é enviado um pacote Accounting-Request com um novo Identifier ao servidor de contabilização RADIUS (este, pode ou não ser o mesmo que procedeu à autenticação e autorização do utilizador). O pacote Accounting-Request tem um atributo Acct-Status.Type que pode ter o valor Start ou Stop de acordo com o que é pretendido. Para um pedido de contabilização, o Request-Authenticator é calculado de acordo com o descrito no ponto II. E. Contabilização.
O pacote Accounting-Response tem um código de valor 5. Recebendo um pacote Accounting-Request, após o seu registo com sucesso, o servidor de contabilização RADIUS envia um
pacote Accounting-Response com o mesmo Identifier que o Request para o NAS. O pacote Accounting-Response apenas pode ter atributos do tipo Proxy-State ou específicos de fabricantes. O Response-Authenticator é calculado de acordo com o descrito no ponto II. C. - Formato dos Pacotes.
IV. ATRIBUTOS
Já referimos que o protocolo RADIUS usa atributos específicos para transmitir informação adicional tal como dados de configuração, informação relativa ao utilizador e/ou ao serviço por este solicitado, etc. Um atributo RADIUS standard ocupa três campos – Type, Length, Value (TLV), no entanto alguns atributos podem ocupar mais. A Fig. 6 apresenta a estrutura dos atributos RADIUS.
Fig. 6. Estrutura dos atributos RADIUS.
Caso um atributo ocupe mais do que três campos, os campos adicionais são colocados entre o campo Length e Value. Os campos Type e Length têm ambos um octeto de tamanho e o campo Value tem um tamanho variável. O campo Length indica o tamanho total do atributo. O campo Value pode ter cinco tipos de dados diferentes, sendo eles: texto, string, address, integer e time. O tipo texto ocupa de 1 a 253 octetos de caracteres no formato UTF-8. O tipo string ocupa de 1 a 253 octetos em formato binário. O tipo address ocupa quatro octetos e o octeto mais significativo é o primeiro. Para o caso de se tratar de um endereço IPv6, são usados dezasseis octetos. O tipo inteiro é normalmente definido sem sinal de 32 bit, mas pode variar. O tipo time é um inteiro de 32 bit sem sinal expresso em segundos desde 1 de Janeiro de 1970 às 00:00:00.
A título de referência, apresenta-se no apêndice a lista dos atributos de 1 a 100 do protocolo RADIUS.
Nesta lista, o Type refere-se ao número do atributo, Name ao nome do atributo, Length representa o tamanho do atributo, VDT (Value, Data, Type) é o tipo de dados do campo Value. NoF representa o número de campos presentes no atributo, RFC é o número do RFC em que o atributo está definido. As cinco colunas seguintes definem quantos atributos do mesmo tipo podem existir num pacote. A-R significa Access-Request, A-A significa Access-Accept, A-R significa Acccess-Reject, A-C significa Access-Challenge e Acc significa Accounting-Request. Nesta tabela, o valor 0+ significa que podem existir zero ou mais atributos desse tipo no mesmo pacote.
Os atributos de 1 a 100 estão definidos e apresentados no apêndice. Os atributos entre 192 e 223 estão reservados para uso experimental e entre 224 a 240 são usados para implementações específicas. Valores entre 241 a 255 não podem ser usados por estarem reservados. Os valores 89 e 92 a 94 também não são usados.
V. APLICAÇÕES A. eduroam
Com a crescente necessidade de mobilidade das pessoas em geral, a comunidade académica, não sendo exceção deu início ao que hoje conhecemos como a rede EDUcation ROAMing (eduroam) a 30 de Maio de 2002. Com dez anos de existência, esta rede suporta o intercâmbio de estudantes, professores e investigadores entre instituições de ensino superior sem que haja a necessidade de reconfiguração de credenciais ou parâmetros de acesso à rede eduroam independentemente da instituição em que se pretenda ter acesso. Ao décimo aniversário a 30 de Maio de 2012, esta rede registava a presença em mais de 50 países de todo o mundo estando na Europa, implementada em mais de 5.000 localizações!
A utilização de serviços RADIUS federados, interligados entre si permite que, por exemplo, um estudante do IPCA possa por exemplo visitar uma qualquer instituição de ensino que esteja ligada à rede eduroam, abrir o seu computador portátil ou PDA e aceder à internet ou sincronizar o email sem que seja necessária nenhuma interação com a equipa de Sistemas de Informação da instituição visitada.
A infraestrutura eduroam tem por base a tecnologia 802.1X e servidores RADIUS (e DIAMETER) que por vezes atuam como proxy, de forma a lidar de uma forma transparente para o utilizador, com todo o processo de autenticação e autorização entre as instituições aderentes.
O serviço eduroam é suportado pela coordenação entre centenas de instituições onde normalmente cada uma gere a sua própria infraestrutura de serviços. As National Research and Education Network (NREN) são as entidades que normalmente coordenam esta infraestrutura em conjunto com os operadores dos campus e hotspots, de forma a garantir uma experiência consistente, independentemente do local em que o utilizador esteja.
Em Portugal a rede eduroam surgiu no âmbito do projeto e-U Campus Virtual, tendo o apoio do governo Português e é gerida pela Fundação para a Computação Científica Nacional (FCCN) desde 2003.
Como exemplo, apresentamos de seguida a estrutura que representa a autenticação na rede eduroam em instituições diferentes, no mesmo País.
Fig. 7. Fluxo das mensagens RADIUS na hierarquia Intercontinental
A Fig.7 representa o fluxo de mensagens recorrendo à hirearquia de servidores de cada País.
Existem três níveis de servidores RADIUS: Institucionais, Nacionais e Internacionais. As mensagens de autenticação seguem o percurso representado pelas setas. As ligações sem setas representam as relações onde é necessária a autenticação através do segredo partilhado. Cada segredo partilhado apenas deve ser do conhecimento de cada dupla NAS / Servidor RADIUS. Cada dupla pode (e deve) ter segredos diferentes para aumentar o nível de segurança.
Para uma correta autenticação, apenas é necessária
a parte do nome do utilizador composta por: tom@inst-1. Esta informação permite identificar a instituição que deve verificar as credenciais do utilizador.
VI. CONCLUSÃO
Da análise do protocolo RADIUS elaborada no presente documento, entende-se a elevada relevância que este tem para o bom funcionamento e interoperabilidade das redes de computadores. Permite-nos autenticar, autorizar e registar todos os dados relativos aos acessos realizados pelos utilizadores.
Embora a flexibilidade e extensibilidade conferida desde a sua conceção lhe tenha permitido manter-se com grandes níveis de utilização até aos nossos dias, há a necessidade de melhorar alguns aspetos deste protocolo. Com este objetivo, começou em 1998 a ser desenvolvido o protocolo Diameter por Pat R. Calhoun, Glen Zorn e Ping Pan. O Diameter está definido no RFC 3588 onde apresenta os requisitos base para os processos de Autenticação, Autorização e Contabilização. Em termos gerais, o protocolo Diameter é uma evolução do RADIUS que não é diretamente retro-compatível. Este, usa um protocolo de transporte fiável, o TCP em substituição do UDP. Define um maior espaço para os pares atributo-valor, suporta o roaming de uma forma mais robusta e implementa informações relativas a erros.
APÊNDICE
Apêndice – Tabela dos tipos de pacotes introduzidos por vários fabricantes ao protocolo RADIUS.
AGRADECIMENTO
O autor A.M. agradece à entidade patronal o fato de lhe facultar agenda para frequentar o curso de E.S.I. do qual a U.C. de Comunicações de Dados faz parte.
O autor C.P. agradece à entidade patronal o fato de lhe facultar agenda para frequentar o curso de E.S.I. do qual a U.C. de Comunicações de Dados faz parte.
O autor L.B. agradece à entidade patronal o fato de lhe facultar agenda para frequentar o curso de E.S.I. do qual a U.C. de Comunicações de Dados faz parte.
REFERÊNCIAS
[1] J. Vollbrecht, (2007). The History of the RADIUS Server. Disponível:
[2] C. Rigney, A. Rubens, W. Simpson (1997, Janeiro). Remote Authentication Dial In User Service (RADIUS). Disponível: https://datatracker.ietf.org/doc/rfc2058/?include_text=1
[3] IEEE Taxonomy Version 1.01 IEEE (2009). Disponível:
http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
[4] RADIUS (n.d.), (2013, Março). Em Wikipedia. Disponível:
http://en.wikipedia.org/wiki/RADIUS
[5] J. Hassell (2002, Outubro). RADIUS, O’Reilly Media.
[6] C. Rigney, S. Willens, A. Rubens, W. Simpson (2000, Junho). Remote Authentication Dial In User Service (RADIUS). Disponível:
http://tools.ietf.org/html/rfc2865
[7] Cisco (2006, Janeiro).How does RADIUS work? Disponível:
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0 0800945cc.shtml
[8] Microsoft. RADIUS Protocol Security and Best Practices (2002, Janeiro). Disponível:
http://technet.microsoft.com/en-us/library/bb742489.aspx
[9] IANA. Radius Types (2012, Outubro). Disponível:
http://www.iana.org/assignments/radius-types/radius-types.xml [10] L. Durnford, (2010, Outubro). How to offer eduroam support to
customer institutions. Disponível:
https://confluence.terena.org/display/H2eduroam/How+to+offer+eduroa m+support+to+customer+institutions
[11] M.J.B. Robshaw. RSA Laboratories. On recent results for MD2, MD4 e MD5 (1996, Novembro). Disponível:
ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.pdf
[12] Y Bhaiji, (2008). Network Security Technologies and Solutions, Cisco Press, pp. 267-287
[13] K. Wierenga, et al. Inter-NREN Roaming Architecture: Description and Development Items. (2006, Setembro) Disponível:
https://www.eduroam.org/downloads/docs/GN2-06-137v5-
APÊNDICE –ATRIBUTOS RADIUS
Type Name Length VDT NoF RFC A-R A-A A-R A-C Acc
1 User-Name >=3 String 3 2865 0-1 0-1 0 0 0-1 2 User-Password 18-130 String 3 2865 0-1 0 0 0 0 3 CHAP-Password 19 String 4 2865 0-1 0 0 0 0 4 NAS-IP-Address 6 Address 3 2865 0-1 0 0 0 0-1 5 NAS-Port 6 Integer 3 2865 0-1 0 0 0 0-1 6 Service-Type 6 Integer 3 2865 0-1 0-1 0 0 0-1 7 Framed-Protocol 6 Integer 3 2865 0-1 0-1 0 0 0-1 8 Framed-IP-Address 6 Address 3 2865 0-1 0-1 0 0 0-1 9 Framed-IP-Netmask 6 Address 3 2865 0-1 0-1 0 0 0-1 10 Framed-Routing 6 Integer 3 2865 0 0-1 0 0 0-1 11 Filter-Id >=3 Text 3 2865 0 0+ 0 0 0+ 12 Framed-MTU 6 Integer 3 2865 0-1 0-1 0 0 0-1 13 Framed-Compression 6 Integer 3 2865 0+ 0+ 0 0 0+ 14 Login-IP-Host 6 Address 3 2865 0+ 0+ 0 0 0+ 15 Login-Service 6 Integer 3 2865 0 0-1 0 0 0-1 16 Login-TCP-Port 6 Integer 3 2865 0 0-1 0 0 0-1 18 Reply-Message >=3 Text 3 2865 0 0+ 0+ 0+ 0 19 Callback-Number >=3 String 3 2865 0-1 0-1 0 0 0-1 20 Callback-Id >=3 String 3 2865 0 0-1 0 0 0-1 22 Framed-Route >=3 Text 3 2865 0 0+ 0 0 0+ 23 Framed-IPX-Network 6 Integer 3 2865 0 0-1 0 0 0-1 24 State >=3 String 3 2865 0-1 0-1 0 0-1 0 25 Class >=3 String 3 2865 0 0+ 0 0 0+ 26 Vendor-Specific >=7 String 4 2865 0+ 0+ 0 0+ 0+ 27 Session-Timeout 6 Integer 3 2865 0 0-1 0 0-1 0-1 28 Idle-Timeout 6 Integer 3 2865 0 0-1 0 0-1 0-1 29 Termination-Action 6 Integer 3 2865 0 0-1 0 0 0-1 30 Called-Station-Id >=3 String 3 2865 0-1 0 0 0 0-1 31 Calling-Station-Id >=3 String 3 2865 0-1 0 0 0 0-1 32 NAS-Identier >=3 String 3 2865 0-1 0 0 0 0-1 33 Proxy-State >=3 String 3 2865 0+ 0+ 0+ 0+ 0+ 34 Login-LAT=-Service >=3 String 3 2865 0-1 0-1 0 0 0-1 35 Login-LAT=-Node >=3 String 3 2865 0-1 0-1 0 0 0-1 36 Login-LAT=-Group 34 String 3 2865 0-1 0-1 0 0 0-1 37 Framed-AppleTalk-Link 6 Integer 3 2865 0 0-1 0 0 0-1 38 Framed-AppleTalk-Network 6 Integer 3 2865 0 0+ 0 0 0-1 39 Framed-AppleTalk-Network >=3 String 3 2865 0 0-1 0 0 0-1 40 Acct-Status-Type 6 Integer 3 2866 0 0 0 0 1 41 Acct-Delay-Time 6 Integer 3 2866 0 0 0 0 0-1
42 Acct-Input-Octets 6 Integer 3 2866 0 0 0 0 0-1
43 Acct-Output-Octets 6 Integer 3 2866 0 0 0 0 0-1
44 Acct-Session-Id >=3 Text 3 2866 0 0 0 0 1
Type Name Length VDT NoF RFC A-R A-A A-R A-C Acc
45 Acct-Authentic 6 Integer 3 2866 0 0 0 0 0-1 46 Acct-Session-Time 6 Integer 3 2866 0 0 0 0 0-1 47 Acct-Input-Packets 6 Integer 3 2866 0 0 0 0 0-1 48 Acct-Output-Packets 6 Integer 3 2866 0 0 0 0 0-1 49 Acct-Terminate-Cause 6 Integer 3 2866 0 0 0 0 0-1 50 Acct-Multi-Session-Id >=3 String 3 2866 0 0 0 0 0+ 51 Acct-Link-Count 6 Integer 3 2866 0 0 0 0 0+ 52 Acct-Input-Gigawords 6 Integer 3 2869 0 0 0 0 0-1 53 Acct-Output-Gigawords 6 Integer 3 2869 0 0 0 0 0-1 55 Event-Timestamp 6 Time 3 2869 0 0 0 0 0-1 60 CHAP-Challenge >=7 String 3 2865 0-1 0 0 0 0 61 NAS-Port-Type 6 Integer 3 2865 0-1 0 0 0 0-1 62 Port-Limit 6 Integer 3 2865 0-1 0-1 0 0 0-1 63 Login-LAT=-Port >=3 String 3 2865 0-1 0-1 0 0 0-1 64 Tunnel-Type 6 Integer 4 2868 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 6 Integer 4 2868 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint >=3 String 4 2868 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint >=3 String 4 2868 0+ 0+ 0 0 0-1 68 Acct-Tunnel-Connection >=3 String 3 2867 0 0 0 0 0-1 69 Tunnel-Password >=5 String 5 2868 0 0+ 0 0 0 70 ARAP-Password 18 String 3 2869 0-1 0 0 0 0 71 ARAP-Features 16 String 3 2869 0 0-1 0 0-1 0 72 ARAP-Zone-Access 6 Integer 3 2869 0 0-1 0 0 0 73 ARAP-Security 6 Integer 3 2869 0-1 0 0 0-1 0 74 ARAP-Security-Data >=3 String 3 2869 0+ 0 0 0+ 0 75 Password-Retry 6 Integer 3 2869 0 0 0-1 0 0 76 Prompt 6 Integer 3 2869 0 0 0 0-1 0 77 Connect-Info >=3 Text 3 2869 0-1 0 0 0 0+ 78 Conguration-oken >=3 String 3 2869 0 0+ 0 0 0 79 EAP-Message >=3 String 3 2869 0+ 0+ 0+ 0+ 0 80 Message-Authenticator 18 String 3 2869 0-1 0-1 0-1 0-1 0 81 Tunnel-Private-Group-ID >=3 String 4 2868 0+ 0+ 0 0 0-1 82 Tunnel-Assignment-ID >=3 String 4 2868 0 0+ 0 0 0-1 83 Tunnel-Preference 6 Integer 4 2868 0+ 0+ 0 0 0 84 ARAP-Challenge-Response 10 String 3 2869 0 0-1 0 0-1 0 85 Acct-Interim-Interval 6 Integer 3 2869 0 0-1 0 0 0 86 Acct-Tunnel-Packets-Lost 6 Integer 3 2867 0 0 0 0 0-1 87 NAS-Port-Id >=3 Text 3 2869 0-1 0 0 0 0-1 88 Framed-Pool >=3 String 3 2869 0 0-1 0 0 0 90 Tunnel-Client-Auth-ID >=3 String 4 2868 0+ 0+ 0 0 0-1
91 Tunnel-Server-Auth-ID >=3 String 4 2868 0+ 0+ 0 0 0-1
95 NAS-IPv6-Address 18 Address 3 3162 0-1 0 0 0 0-1
96 Framed-Interface-Id 10 Integer 3 3162 0-1 0-1 0 0 0-1
Type Name Length VDT NoF RFC A-R A-A A-R A-C Acc
97 Framed-IPv6-Prefix 4-20 5 3162 0+ 0+ 0 0 0+
98 Login-IPv6-Host 18 Address 3 3162 0+ 0+ 0 0 0+
99 Framed-IPv6-Route >=3 Text 3 3162 0 0+ 0 0 0+
