O registoDNSCERT [12] quando usado com oDNSSECpermite tornar oDNSnuma PKI. Esta proposta suporta diferentes tipos de certificados podendo eles ser, PKI, SPKI, PGP, entre outros. Uma das grandes desvantagens desta proposta é que o tamanho médio de um certificado é geralmente grande e possibilidade de existir um grande número de certificados para o mesmo
FQDN, o que tende a carregar substancialmente oDNS.
A outra solução é a descrita pelo grupo Trans-European Research and Education Networking Association(TERENA) permite que os diferentes servidores de autenticação comuniquem direc- tamente entre eles sem necessidade de comunicar com um ou mais servidores proxiesRADIUS. Para esse efeito é utilizado oDNSSECque averigua se o domínio desejado ao qual o supplicant se quer autenticar pertence ao conjunto de domínios ao qual oASestá autorizado a fazer roaming. Esta solução apesar de utilizar o DNSSECpara a verificação do domínio, recorre na mesma ao
PKIpara verificação dos certificados, logo é sempre necessário ter-se o certificado doASremoto instalado para verificar a autenticidade dos certificados.
Capítulo 4
Solução proposta
Com vista a resolver os problemas da correcta identificação do servidor de autenticação, bem como da validação do servidor de autenticação, foi criada uma arquitectura que possui como per- missas a autenticação e validação mútua do cliente e servidor de autenticação bem como um tipo de construção especial doSSID.
Essa arquitectura permite validar os certificados usados durante a autenticação e no geral pos- sui 2 fases distintas, nas quais é inicialmente efectuada uma autenticação mútua, ocorrendo de seguida uma validação da autenticação. Podem ser identificados na figura4.1os blocos básicos que consituem uma autenticação ScalSec.
Figura 4.1: Princípios da arquitectura ScalSec
Pretende-se com a introdução desta arquitectura tornar a identificação das rede Wi-Fi única, resolvendo também o problema dos certificados que actualmente são caros e de díficil gestão.
Tendo como meta o alcançar os objectivos traçados, foram criadas e desenvolvidas duas soluções que podem operar em separado uma da outra, mas que quando operam em conjunto complementam-se, são estas, oSSIDglobal e a arquitectura ScalSec.
A soluçãoSSIDglobalque se desenvolveu permite tornar a identificação da rede Wi-Fi única possibilitando também a correcta identificação do servidor de autenticação.
O modelo actualmente vigente na certificação, o PKIX possui alguns problemas.Devido à sua arquitectura e premissas, a framework é rígida e não muito viável em certos cenários de uso, como no caso de single sign-on ou na gestão das chaves públicas. Veja-se por exemplo o modo de revogação de uma chave que é um método complexo, de difícil execução e que traz custos ao cliente, sendo que a arquitectura ScalSec possui outras premissas e procedimentos que tornam o processo de validação mais simples, eficiente, seguro e versátil.
A arquitectura ScalSec foi pensada pelo co-orientador desta dissertação o Eng. Jaime Dias, ele é o grande mentor desta nova arquitectura que visa aproveitar ao máximo as funcionalidades doDNSSECnas mais diversas vertentes. Aqui é apresentada uma parte da arquitectura ScalSec, sendo que neste caso específico é utilizada para autenticação de redes Wi-Fi possuindo esta um modelo de abrangência maior. Tem na sua base os mesmos princípios doDNSSECe introduz um novo conceito de certificação. Para tal, a validação dos certificados é feita através da utilização de novos registosDNSSEC.
Desta forma a arquitectura ScalSec consegue tornar o servidor deDNSlocal numaPKIglobal, sem que os utilizadores deste serviço necessitem ter o certificado de CA localmente instalado no cliente. Os novos registos permitem ainda ter um âmbito de acção mais alargado e dotar a arquitectura de um espectro de acção mais amplo.
A certificação ScalSec resolve o problema dos certificados serem caros e de difícil gestão, pois com esta certificação é possível utilizar certificados self sign (certificados que se assinam a si próprios) de baixo custo.
Na figura4.2é possível identificar o cenário de autenticação em que se utilizam as duas solu- ções em simultâneo, tanto a solução doSSIDglobalcomo a solução ScalSec.
Figura 4.2: Processo de autenticação que utiliza a arquitectura desenvolvida
Uma das permissas da arquitectura ScalSec é identificar oFQDNde cada organização como sendo um nó. Cada nó pode conter diversos serviços possuindo apenas um certificado de raiz de
CA, o qual é responsável pela assinatura dos certificados dos serviços aí disponíveis, chamado de certificado do nó.
4.1 SSID global 61
Em paralelo à adopção da arquitectura ScalSec é possível providenciar o serviço deDNSSEC
à rede infra-estruturada da organização.
4.1
SSID global
Após na secção3.6ter sido feita uma descrição da forma como as redes Wi-Fi são identifica- das, foi constatado que existe um problema na identificação das redes Wi-Fi (ESS).
Normalmente esse problema pode ser evitado através de um planeamento correcto da rede Wi-Fi. Verificando-se a existência de umSSIDigual ao que se pretende nas redes vizinhas, essa regra diminui os problemas que possam vir a surgir. Mas no entanto não impede que uma pessoa mal intensionada crie uma rede com o mesmoSSID.
A solução encontrada para a correcta identificação do servidor de autenticação e criação de umSSIDúnico ocorreu com a introdução de uma nova semântica noSSID.
Com a introdução do SSIDglobal, oSSID passa agora a conter um caracter especial, neste caso o ’@’, que delimita logicamente oSSID(normal) de umFQDNo qual corresponde ao nome no domínio do servidor de autenticação. Desta forma, consegue-se associar oSSID de uma rede
ESS ao seu servidor interno de autenticação. O SSID ao conter a identificação do servidor de autenticação através doFQDNpassa a ser único e por isso a denominação de global.
Figura 4.3: Identificação da solução 1/1 des- crita na secção4.1
Figura 4.4: Identificação da solução 2/2 des- crita na secção4.1
No entanto, de modo a melhorar a verificação do servidor de autenticação adicionou-se uma regra suplementar na verificação dos certificados. Tendo em conta o processo de autenticação que utiliza o PEAP e por consequência certificados X.509, torna-se obrigatório que o campo Alter- native Subject Name, especifique oFQDNque está atribuído aoNAS. Desta forma, associam-se formas de identificação alternativas ao titular do certificado.
Este campo permite especificar cinco tipos de identificação URI. Aquele que será aqui utili- zado é do tipoDNS(podendo ser outro). Sendo assim o Alternative Subject Name será do género: DNS:«FQDN». Foi assim feito para manter compatibilidade com as regras estabelecidas pela PKI.
Desta modo é possível identificar o servidor de autenticação pretendido de forma correcta, baseando-se apenas na informação que o utilizador costuma inserir/seleccionar do SSID. Esta solução pode ser utilizada em separado da solução ScalSec.
Parte de um certificado que segue estas regras:
X509v3 Subject Key Identifier:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX X509v3 Authority Key Identifier:
keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX X509v3 Subject Alternative Name:
DNS:radius.porto.pt
Em suma, esta solução mantém a compatibilidade com o formato anterior que não possuía qualquer regra, não requerendo qualquer alteração ao protocolo 802.11, nem ao APou servidor de autenticação. O único software que necessita de ser alterado é do lado o cliente, sendo ne- cessário alterar o supplicant para que este reconheça a nova semântica e lhe atribua o seu devido significado.
Uma falha que pode ser apontada a esta solução é o facto doFQDNpoder ter até 255 bytes, mas oSSID ser limitado a 32 bytes. A acrescentar a este facto é utilizado obrigatoriamente um caracter separador ’@’ restingindo assim oFQDNa um máximo de 31 bytes (caractéres) o que pode em certos casos ser demasiado restritivo.
Com a introdução desta regra no processo de criação doSSIDconsegue-se suplantar o pro- blema da identificação do servidor de autenticação, mantendo-se no entanto o problema da vali- dade do mesmo.