Estudo do Protocolo RADIUS

Transcrição

Instituto Politécnico do Cávado e do Ave, EST – ESI 2º Ano. Comunicações de Dados, Grupo 2. Março 2013
1
Remote Authentication Dial-In User Service
RADIUS
Adélio C. de Miranda, Carlos D. D. Pereira, Luís M. F. Barreto, ESI-PL, IPCA
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
ERIR sistemas 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
G
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:
[email protected]).
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:
[email protected]).
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:
[email protected])..
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
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 palavrapasse, 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çabruta”. 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
2
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.
3
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 sponseAuthenticator = MD5(Code + Identifier+ Length+
(1)
Re questAuthenticator + Atributes+ SharedSecret)
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.
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 palavrapasse do utilizador.
Response-Authenticator é o nome do campo Authenticator
nos pacotes do tipo Access-Accept, Access-Reject e AccessChallenge. 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
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 RequestAuthenticator ú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 palavrapasse 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 AccessRequest 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 AccessChallenge 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 AccesChallenge.
Na Fig. 3, mostramos o algoritmo do processo de autenticação
do protocolo RADIUS.
4
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: UserPassword, CHAP-Password, Reply-Message, State e CHAPChallenge
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
Fig. 3. Processo de Autenticaçã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-
5
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 ProxyState 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 ResponseAuthenticator 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 ResponseAuthenticator 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 Accounting-Request e AccountingResponse. 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.
TABELA I
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 AccessRequest 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 ResponseAuthenticator é 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 ResponseAuthenticator é 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 AccessChallenge. Apenas os atributos State, Vendor-Specific, IdleTimeout, Session-Timeout e Proxy-State podem também fazer
parte do pacote Access-Challenge. O pactode AccountingRequest 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 RequestAuthenticator é 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
6
pacote Accounting-Response com o mesmo Identifier que o
Accounting-Request para o NAS. O pacote AccountingResponse 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 AccountingRequest. 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 eU 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.
7
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
Fig. 7. Fluxo das mensagens RADIUS na hierarquia
Intercontinental
O autor A.M. agradece à entidade patronal o fato
facultar agenda para frequentar o curso de E.S.I. do
U.C. de Comunicações de Dados faz parte.
O autor C.P. agradece à entidade patronal o fato
O autor L.B. agradece à entidade patronal o fato
de lhe
qual a
de lhe
qual a
de lhe
qual a
REFERÊNCIAS
[1]
J. Vollbrecht, (2007). The History of the RADIUS Server. Disponível:
http://www.interlinknetworks.com/app_notes/History_of_RADIUS.htm
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
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
IEEE Taxonomy Version 1.01 IEEE (2009). Disponível:
http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
RADIUS (n.d.), (2013, Março). Em Wikipedia. Disponível:
http://en.wikipedia.org/wiki/RADIUS
J. Hassell (2002, Outubro). RADIUS, O’Reilly Media.
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
Cisco (2006, Janeiro).How does RADIUS work? Disponível:
http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0
0800945cc.shtml
Microsoft. RADIUS Protocol Security and Best Practices (2002,
Janeiro). Disponível: http://technet.microsoft.com/enus/library/bb742489.aspx
IANA. Radius Types (2012, Outubro). Disponível:
http://www.iana.org/assignments/radius-types/radius-types.xml
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
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
Y Bhaiji, (2008). Network Security Technologies and Solutions, Cisco
Press, pp. 267-287
K. Wierenga, et al. Inter-NREN Roaming Architecture: Description and
Development Items. (2006, Setembro) Disponível:
https://www.eduroam.org/downloads/docs/GN2-06-137v5Deliverable_DJ5-1-4_InterNREN_Roaming_Technical_Specification_20060908164149.pdf
8
9
APÊNDICE – ATRIBUTOS RADIUS
Type
Name
1 User-Name
2 User-Password
3 CHAP-Password
Length
VDT
NoF
RFC
A-R
A-A
A-R
A-C
Acc
>=3 String
18-130 String
3 2865
3 2865
0-1
0-1
0-1
0
0
0
0
0
0-1
0
19 String
4 2865
0-1
0
0
0
0
4 NAS-IP-Address
5 NAS-Port
6 Address
6 Integer
3 2865
3 2865
0-1
0-1
0
0
0
0
0
0
0-1
0-1
6 Service-Type
6 Integer
3 2865
0-1
0-1
0
0
0-1
7 Framed-Protocol
8 Framed-IP-Address
6 Integer
6 Address
3 2865
3 2865
0-1
0-1
0-1
0-1
0
0
0
0
0-1
0-1
9 Framed-IP-Netmask
6 Address
3 2865
0-1
0-1
0
0
0-1
6 Integer
>=3 Text
3 2865
3 2865
0
0
0-1
0+
0
0
0
0
0-1
0+
12 Framed-MTU
6 Integer
3 2865
0-1
0-1
0
0
0-1
13 Framed-Compression
14 Login-IP-Host
6 Integer
6 Address
3 2865
3 2865
0+
0+
0+
0+
0
0
0
0
0+
0+
15 Login-Service
6 Integer
3 2865
0
0-1
0
0
0-1
16 Login-TCP-Port
18 Reply-Message
6 Integer
>=3 Text
3 2865
3 2865
0
0
0-1
0+
0
0+
0
0+
0-1
0
19 Callback-Number
>=3 String
3 2865
0-1
0-1
0
0
0-1
20 Callback-Id
22 Framed-Route
>=3 String
>=3 Text
3 2865
3 2865
0
0
0-1
0+
0
0
0
0
0-1
0+
3 2865
0
0-1
0
0
0-1
10 Framed-Routing
11 Filter-Id
23 Framed-IPX-Network
6 Integer
24 State
25 Class
>=3 String
>=3 String
3 2865
3 2865
0-1
0
0-1
0+
0
0
0-1
0
0
0+
26 Vendor-Specific
>=7 String
4 2865
0+
0+
0
0+
0+
27 Session-Timeout
28 Idle-Timeout
6 Integer
6 Integer
3 2865
3 2865
0
0
0-1
0-1
0
0
0-1
0-1
0-1
0-1
29 Termination-Action
6 Integer
3 2865
0
0-1
0
0
0-1
30 Called-Station-Id
31 Calling-Station-Id
>=3 String
>=3 String
3 2865
3 2865
0-1
0-1
0
0
0
0
0
0
0-1
0-1
32 NAS-Identier
>=3 String
3 2865
0-1
0
0
0
0-1
33 Proxy-State
34 Login-LAT=-Service
>=3 String
>=3 String
3 2865
3 2865
0+
0-1
0+
0-1
0+
0
0+
0
0+
0-1
35 Login-LAT=-Node
>=3 String
3 2865
0-1
0-1
0
0
0-1
34 String
6 Integer
3 2865
3 2865
0-1
0
0-1
0-1
0
0
0
0
0-1
0-1
38 Framed-AppleTalk-Network
6 Integer
3 2865
0
0+
0
0
0-1
39 Framed-AppleTalk-Network
40 Acct-Status-Type
>=3 String
6 Integer
3 2865
3 2866
0
0
0-1
0
0
0
0
0
0-1
1
6 Integer
3 2866
0
0
0
0
0-1
36 Login-LAT=-Group
37 Framed-AppleTalk-Link
41 Acct-Delay-Time
10
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
3 2866
0
0
0
0
1
A-R
A-A
A-R
A-C
Acc
44 Acct-Session-Id
Type
Name
>=3 Text
Length
VDT
NoF
RFC
45 Acct-Authentic
46 Acct-Session-Time
6 Integer
6 Integer
3 2866
3 2866
0
0
0
0
0
0
0
0
0-1
0-1
47 Acct-Input-Packets
6 Integer
3 2866
0
0
0
0
0-1
48 Acct-Output-Packets
49 Acct-Terminate-Cause
6 Integer
6 Integer
3 2866
3 2866
0
0
0
0
0
0
0
0
0-1
0-1
3 2866
0
0
0
0
0+
50 Acct-Multi-Session-Id
>=3 String
51 Acct-Link-Count
52 Acct-Input-Gigawords
6 Integer
6 Integer
3 2866
3 2869
0
0
0
0
0
0
0
0
0+
0-1
53 Acct-Output-Gigawords
6 Integer
3 2869
0
0
0
0
0-1
3 2869
3 2865
0
0-1
0
0
0
0
0
0
0-1
0
6 Integer
3 2865
0-1
0
0
0
0-1
6 Integer
>=3 String
3 2865
3 2865
0-1
0-1
0-1
0-1
0
0
0
0
0-1
0-1
55 Event-Timestamp
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT=-Port
64 Tunnel-Type
6 Time
>=7 String
6 Integer
4 2868
0+
0+
0
0
0-1
65 Tunnel-Medium-Type
66 Tunnel-Client-Endpoint
6 Integer
>=3 String
4 2868
4 2868
0+
0+
0+
0+
0
0
0
0
0-1
0-1
67 Tunnel-Server-Endpoint
>=3 String
4 2868
0+
0+
0
0
0-1
68 Acct-Tunnel-Connection
69 Tunnel-Password
>=3 String
>=5 String
3 2867
5 2868
0
0
0
0+
0
0
0
0
0-1
0
70 ARAP-Password
18 String
3 2869
0-1
0
0
0
0
71 ARAP-Features
72 ARAP-Zone-Access
16 String
6 Integer
3 2869
3 2869
0
0
0-1
0-1
0
0
0-1
0
0
0
73 ARAP-Security
74 ARAP-Security-Data
75 Password-Retry
76 Prompt
6 Integer
3 2869
0-1
0
0
0-1
0
>=3 String
6 Integer
3 2869
3 2869
0+
0
0
0
0
0-1
0+
0
0
0
6 Integer
3 2869
0
0
0
0-1
0
77 Connect-Info
78 Conguration-oken
>=3 Text
>=3 String
3 2869
3 2869
0-1
0
0
0+
0
0
0
0
0+
0
79 EAP-Message
>=3 String
3 2869
0+
0+
0+
0+
0
80 Message-Authenticator
81 Tunnel-Private-Group-ID
18 String
>=3 String
3 2869
4 2868
0-1
0+
0-1
0+
0-1
0
0-1
0
0
0-1
82 Tunnel-Assignment-ID
>=3 String
4 2868
0
0+
0
0
0-1
6 Integer
10 String
4 2868
3 2869
0+
0
0+
0-1
0
0
0
0-1
0
0
6 Integer
3 2869
0
0-1
0
0
0
86 Acct-Tunnel-Packets-Lost
87 NAS-Port-Id
6 Integer
>=3 Text
3 2867
3 2869
0
0-1
0
0
0
0
0
0
0-1
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
83 Tunnel-Preference
84 ARAP-Challenge-Response
85 Acct-Interim-Interval
91 Tunnel-Server-Auth-ID
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
97 Framed-IPv6-Prefix
98 Login-IPv6-Host
99 Framed-IPv6-Route
100 Framed-IPv6-Pool
>=3 String
11
Length
VDT
A-R
A-A
A-R
A-C
Acc
5 3162
0+
0+
0
0
0+
3 3162
0+
0+
0
0
0+
>=3 Text
3 3162
0
0+
0
0
0+
>=3 String
3 3162
0
0-1
0
0
0-1
4-20
18 Address
NoF
RFC

Estudo do Protocolo RADIUS

Transcrição

Documentos relacionados

impressão com cabeçaos

ano letivo 2.016 - maternal ii - Colégio Gato Xadrez

Pacote Romântico Premium Pacote Romântico

jardim i - Cantinho Mágico

Segurança de acesso Redes Wireless e Cabeadas - MUM

Histórias de Terror - Clássicos - Janaina Spolidorio Janaina Spolidorio

condições

POLÍTICA DE PRIVACIDADE

Gatlinburg, TN / EUA

Trabalho Pratico de Organização de Eventos

6º ano EFII