Introdução

Uma das bases fundamentais da rede eduroam são os elevados padrões de segurança que nela são aplicados e a confidencialidade dos dados dos utilizadores. Para isso é feito uso dos mais modernos protocolos de autenticação e de transmissão de dados.

A necessidade de melhorar os mecanismos de autenticação da rede eduroam, garantindo os melhores níveis de segurança na rede e da sua utilização, leva a que seja necessário proceder a atualizações periódicas na sua estrutura.

A maior incidência destas atualizações tem estado centrada nos mecanismos e protocolos de comunicação entre os pontos de acesso e os equipamentos dos utilizadores, por este ser o ponto mais vulnerável e com menor grau de controlo de todo o processo de autenticação.

Os mecanismos autenticação e autorização atualmente em uso na rede eduroam assentam no protocolo Radius. Este protocolo tem identificado duas limitações que podem contribuir para o surgimento de problemas na sua utilização.

Audiência

Este documento é dirigido aos gestores dos diferentes hotsports eduroam de todas as instituições ligadas a esta rede.

Objetivos

Pretende-se com este documento apresentar a alternativa que está a ser aplicada na rede eduroam a nível internacional para contornar as limitações detetadas na forma como o protocolo de Radius transmite as informações de autenticação dos utilizadores, através da implementação do protocolo de transmissão de dados de autenticação e registo de sessão (accounting) do Radius RadSec.

Estrutura do Documento

Este documento está dividido em três capítulos. O primeiro apresenta o documento e o que é pretendido com ele.

O segundo capítulo apresenta o que é o protocolo de transmissão de dados de autenticação e registo de sessão (accounting), fazendo também uma breve descrição da forma como os diferentes elementos envolvidos neste processo comunicam entre si.

O terceiro capítulo detalha o estado da implementação do RadSec a nível internacional e a forma proposta para implementação deste protocolo a nível das federações nacionais e a nível dos servidores de topo da hierarquia eduroam.

Radsec

O que é o Radsec

Um dos maiores problemas na transmissão de dados entre servidores de Radius está no protocolo de comunicação usado, o UDP.

Este protocolo não usa quaisquer mecanismos de controlo de transmissão, o que leva a que em processos de autenticação, que passem por diversos servidores de Radius, se possam perder pacotes e estes não são reenviados.

Esta perda de dados inviabiliza o processo de autenticação, obrigando a que este seja repetido, o que gera tráfego desnecessário na rede e, em certas situações, à passagem de grandes volumes de dados na estrutura de autenticação eduroam.

Para ultrapassar estes problemas foi desenvolvido o RadSec, que é um protocolo de transmissão dos dados de autenticação e autorização Radius. Este assenta na utilização de TCP e TLS.

As principais vantagens do protocolo RadSec são as seguintes:

• TCP – Garantia de mecanismos de controlo de transmissão de dados
• TLS – Garantia de segurança na comunicação entre servidores

A utilização destes dois métodos consegue dotar o Radius de mecanismos de transporte mais fiáveis e com controlo de transmissão de dados ao mesmo tempo que adiciona a este processo uma camada adicional de segurança na transmissão de dados entre os servidores de Radius.

O protocolo TCP garante a existência de mecanismos de controlo nos dados transmitidos entre os diferentes servidores de Radius envolvidos num processo de autenticação e em caso de falha na entrega de um pacote a um determinado servidor este é reenviado, evitando o repetir de todo o processo de autenticação.

No cenário atual os mecanismos de segurança associados ao processo de autenticação são demasiado primários, assentando apenas numa chave e na utilização de um endereço IP específico.

A utilização de TLS e de certificados de servidor, com base numa única CA autorizada, permite garantir a autenticidade e a segurança no processo de comunicação entre os servidores de Radius.

No RadSec a introdução do TLS permite ainda a comunicação direta entre os servidores de Radius, através do recurso a mecanismos de DNS, garantindo uma otimização de todo o processo de autenticação.

O processo de descoberta dos servidores de autenticação assenta em mecanismos de DNS que disponibilizam, via registos SRV, o nome/IP do respetivo servidor.

Modelo de funcionamento do RadSec

A tabela abaixo mostra a forma como os servidores de Radiu comunicam sob o protocolo RadSec.

Ilustração 1 - Funcionamento do RadSec

Compatibilidade

A implementação do RadSec na rede eduroam pressupõe a manutenção das atuais estruturas de autenticação e autorização, minimizando assim o impacto da implementação deste novo mecanismos de comunicação.

Para isso foi averiguada a possibilidade de utilização dos atuais softwares de Radius, garantindo a compatibilidade dos atuais sistemas.

Na impossibilidade de suporte por parte dos atuais softwares de Radius a implementação de novos sistemas deverá ser tão transparente quanto possível e ter o menos impacto na estrutura montada.

Atualmente apenas dois dos softwares de Radius em utilização na rede eduroam têm suporte nativo para RadSec. Esses softwares são:

• Radiator
• FreeRadius

Por forma a dotar os restantes softwares de suporte para RadSec foi desenvolvido o software RadSecProxy, que funciona como um proxy entre o servidor de Radius da instituição e os restantes servidores da rede eduroam.

O RadSecProxy tem a capacidade de comunicar com os restantes servidores de Radius na forma tradicional ou através de RadSec, implementado os mecanismos TCP e de descoberta dinâmica.

Radsec eduroam – Internacional

Ponto Situação

A rede eduroam tem estado, quer a nível dos ETLR e dos FLR's, a implementar o, estabelecendo-o como protocolo de comunicação principal entre nos servidores de proxy de topo (ETLR) e os servidores nacionais de proxy Radius (FLRs).

Os planos pretendem implementar este protocolo de forma descendente na hierarquia, sendo colocados em funcionamento no topo da hierarquia e alargando a sua implementação de forma gradual para os níveis inferiores.

Próximos passos

Estando já praticamente terminada a implementação a nível central do RadSec, entre os ETLR e os FLR's, é necessário que as instituições eduroam se comecem a preparar para a sua implementação a nível dos SP's (Hotspots) e Idp's (servidores de Radius).

Os servidores de Radius da componente eduroam Portuguesa estão já a comunicar com os ETLR através da utilização do RadSec, usando TCP, SSL e a a Dynamic Dicovery dos servidores de destino dos pedidos.

Foi no entanto mantida a comunicação Radius tradicional entre os servidores de Radius de topo de Portugal e os ETLR, por questões de redundância e de garantia de serviço.

A implementação do RadSec em Portugal pretende-se que seja feita de forma gradual e faseada, por forma a preparar as instituições para este novo cenário e para as capacitar para as alterações a implementar.

RadSec eduroam – Portugal

Modelo

O modelo de implementação do RadSec em Portugal está pensado para ser feita em três fases distintas.

Este modelo foi o que foi seguido na implementação do RadSec a nível internacional e entre os ETLR e os FLRs.

O modelo assenta em três fases distintas e pretende testar o RadSec numa escala gradualemte maior e validar o modelo pensado para a sua implementação.

Não é pretendido fazer uma implementação one-time, mas sim dar alguma liberdade às instituições de, segundo o seu ritmo a sua disponibilidade, implementar o RadSec a nível nacional.

A proposta de implementação e o modelo a ser seguindo encontra-se detalhado abaixo.

Proposta implementação

Detalhes da Implementação

Abaixo apresentamos uma descrição detalhada das diferentes fases a implementar pelos diferentes participantes da rede eduroam.

Fase 1

Este passo prevê que os servidores de proxy radius nacionais (FLRs) passem a comunicar com os servidores europeus de radius (ETLR) através do protocolo RadSEc. Fica também a cargo destes a capacidade de receber e enviar pedidos pedidos de autenticação diretamente para outros servidores de nível nacional que estejam capacitados para comunicar em RadSec.

A implementação deste passo está já parcialmente realizada. Atualmente os FLRs estão já a comunicar com os servidores estrangeiros através de RadSec sempre que estes suportem este protocolo e que existam respostas de DNS.

O que está em falta para o fim deste passo é a criação dos registos de DNS, quer a nível central quer a nível das instituições.

É necessário que sejam criados os registos de DSN (SRV e NAPTR) que vão indicar que os pedidos de autenticação gerados por utilizadores Portugueses, em instituições estrangeiras, devem ser encaminhados para os servidores de Proxy Nacional de Radius.

• FCCN – Criação dos registos de DNS para os proxys nacionais

_radsec._tcp.eduroam.pt    SRV    cv-radius.fccn.pt
_radsec._tcp.eduroam.pt    SRV    cv2-radius.fccn.pt

• Instituições – Criação dos registos de DNS pelas instituições

inst1.pt  NAPTR  x-eduroam:radius.tls_radsec._tcp.eduroam.pt
foo.pt    NAPTR  x-eduroam:radius.tls_radsec._tcp.eduroam.pt
bar.pt    NAPTR  x-eduroam:radius.tls_radsec._tcp.eduroam.pt

Fase 2

Pretende-se neste passo identificar um conjunto de instituições que possam participar nos testes de configuração do serviço RadSec na rede eduroam.

Estes testes passam pela análise do suporte pelo software de Radius e a instalação de alternativas (RadSec Proxy) no caso de inexistência de suporte – cenário A.

No caso de o software de Radius suportar RadSEc de forma nativa (Radiator ou FreeRadius), os passos a serem seguidos são apenas a atualização da versão e a configuração para este novo serviço – cenário B.

Estes testes vão permitir que as instituições passem a comunicar entre si através do protocolo RadSec, sempre que possível. A ligação aos FLRs será mantida para a comunicação com instituições que não tenham suporte para RadSec.

Será necessário pedir certificados específicos para a comunicação RadSec entre os servidores de Radius. Esta tarefa ficará ao cargo da FCCN.

É suposto este piloto produzir documentação para suporte às restantes instituições eduroam. A produção desta documentação ficará a cargo de cada uma das instituições que participarem nos testes e será referente ao seu cenário de implementação (A ou B) e do software de Radius em utilização (FreeRadius, Radiator, IAS/NPS ou ACS).

• FCCN – Pedido de novos certificados na eduPKI. Estes certificados devem ser pedidos após manifestação de interesse por parte das instituições.
• Instituições(Piloto) – Avaliação do suporte para RadSec no software de Radius em utilização:
  • Cenário A – Instalação e configuração do RadSec Proxy.
  • Cenário B – Atualização do software de Radius e configuração do módulo de RadSec.
• Instituições (Piloto) – Alterações de DNS necessárias para a receção dos pedidos diretamente nos seus servidores de Radius
• Instituições (Piloto) – Produção de documentação para implementação no cenário e software em utilização.

Fase 3

Após os testes e com a documentação disponibilizada, espera-se que as instituições aderentes ao eduroam iniciem o processo de instalação e configuração do RadSec nos seus servidores de Radius.

O apoio a essa instalação e configuração será feito através da documentação que foi produzida no passo anterior e que será disponibilizada a todos os administradores dos hotspots eduroam.

A FCCN prestará todo o apoio adicional necessário e realizará os testes necessários para garantir o correto funcionamento do roaming entre instituições.

De notar que a ligação aos proxys nacionais deverá ser mantida para que possa haver um caminho alternativo de envio/receção dos pedidos de autenticação e accounting.