Períodos de Actualização e Revogação

Uma das fases deste trabalho que mereceu um pouco mais de reflexão foi este capítulo, uma vez que é necessário o correcto planeamento das mudanças (rollovers) das chaves e certificados para evitar possíveis problemas no DNSe na autenticação das estações. A seguir é descrito o processo utilizado para fazer o rollover dos certificados. São também apresentadas soluções alter- nativas e comparação das mesmas com a solução escolhida.

5.2.4.1 Processo de Actualização do RADIUS e do DNS

O processo de actualização dos certificados do servidor de autenticação está separado em três fases distintas. Na primeira é gerada o certificado do nó para o servidor deAAA, na segunda fase, é feita a actualização do certificado do nó e de seguida é feita a actualização do registo H a que o certificado estava associado, por último, a remoção dos registos e certificados obsoletos.

O modo de implementação do processo de actualização é planeado de forma a existir uma separação lógica e física dos serviço deAAA, do serviço deDNS. Assim, dois métodos surgem como alternativas válidas na actualização dos registo deDNS, por método remoto ou por método “local“. Se se optar pelo método remoto é utilizada a funcionalidade de DDNS, se se utilizar

5.2 DNSSEC 85

o método local, as zonas no servidor deDNSsão actualizadas localmente e o servidor deDNS

recarrega as configurações da zona sempre que necessário. Este último é de execução um pouco mais complexa pois a sincronização dos registos locais pode dar origem a outros problemas que o método remoto não sofre. Possui no entanto outras vantagens que tornam este método mais atractivo.

Optou-se por utilizar o método ”local“, que tem como maior vantagem no reínicio do ser- viço deDNS(quer seja um reinício administrativo ou outro) não perde o último registo válido, garantindo-se que os registos vão-se manter em sincronia com os certificados presentes no ser- vidor de autenticação, excepto nos casos em que a comunicação directa entre os dois não for possível. Aí o método remoto é um bom complemento do método ”local“.

Uma vez que os servidores se encontram físicamente afastados é necessário definir um método de actualização dos registos do serviço deDNScom os novos registos H sempre no servidor de autenticação um novo certificado do nó é gerado. Para a passagem dos registos H entre o servidor de autenticação e o servidor deDNSé utilizando o ssh, existem outras opcções mas esta foi a que se decidiu adoptar, pois o ssh é um protocolo seguro, amplamente usado e que permite a execução das diversas operações de forma transparente para o administrador da rede.

Nas fases seguintes, após a recepção dos novos registos, é feita a sincronia de registos da zona alvo, actualizando-os e reassinando todo a zona, sendo por último forçado um reload no servidor deDNSpara que este recarregue a zona deDNS.

A implementação do processo da rotação dos certificados do servidor de autenticação consiste na criação diária do certificado do servidor (validade de 24h) e na mudança mensal do certificado do nó bem como na consequente geração de um novo certificado do servidor. Apesar de parecer ser uma periocidade curta, este facto, tem como objectivo permitir que os certificados tenham um baixo número de bits, tentando manter a porpocionalidade entre validade vs profundidade de bits regra sempre presente aquando do uso de chaves digitais.

Como, após a mudança do certificado do nó os registos H do servidor deDNSnecessitam de ser actualizados, é necessário associar a geração de novos certificados à actualização dos registos H ao longo das cadeias de topo deDNS. Para este processo é necessário salientar, que apesar da sincronia necessária tratam-se de sistemas independentes. Assim, pode-se separar o processo de actualização mensal em três fases distintas, englobando nelas as accções a serem tomadas tanto no servidor deDNScomo no servidor de autenticação:

Novos certificados/registos – Estas acções deverão ocorrer 2 TTLs antes do fim do prazo dos registos só assim se consegue garantir um rollover eficiente obedecendo às recomendações doIETF.

• Geração de novos certificados do nó para serem utilizados pelo servidor de autentica- ção.

• Geração dos registos H baseados nos novos certificados.

• Os novos registos são colocados nas zonas doDNSa que servidor de autenticação está associado.

• É gerada uma nova chave ZSK e adicionada ao ficheiro da zona. Os períodos de actualização das chaves de ZSKcoincidiram com a actualização dos certificados do servidor de autenticação.

• É adicionado o novo registo H à zona, contendo ela agora dois registos H sendo reas- sinada com a chaveZSKantiga, tendo a validade de doisTTLs, ou seja, é mantida a validade do registo com a chaveZSKantiga.

• É forçado o recarregar das zonas ao servidor deDNSe assim propaga a zona ao servi- dores slave no próximo pedido.

Mudança de certificados/Assinatura nova – UmTTLantes do fim do registo são efectuadas as seguintes acções:

• Nesta fase o certificado do nó é mudado no servidor de autenticação, bem como o certificado do nó. A substituição é feita pelos certificados gerados na fase precedente. • A zona deDNSé reassinada usando a chaveZSKgerada na fase anterior, possuindo a

validade de 2TTLs

Remoção dos certificados/registos antigos – As acções são executadas on time, ou seja, preci- samente quando passou 1 mês após o lançamento do todo este processo.

• Os certificados antigos são removidos.

• Os registos H caducados são removidos e é actualizado o ficheiro da zona.

• A chaveZSKantiga é removida com a consequente actualização do ficheiro de zona. Na figura5.2é possível identificar o período de validade no espaço temporal de um certifi- cado através das linhas a cheio, enquanto que as linhas a tracejado indicam que o certificado é criado mas ainda não é utilizado, por fim, é também possível identificar uma linha mais fina que indica que o certificado ainda é válido mas já se encontra em processo de substituição. Esta fi- gura também pode ser transposta para o rollover dos registos de DNS, no qual, a linha a cheio indica a validade da assinatura de um registo, sendo possível identificar os períodos de rollover em que existem dois registos em simultâneo. Pretende-se tornar a ilustração o mais perceptível e possibilitar a correcta identificação das fases em que ocorrem em cada ciclo.

Assim e analisando a escala é possível ver que no inicio do processo o certificado possui uma validade de 24h a partir das quais é iniciado o processo de mudança de certificados de raiz sendo para isso necessário dois períodos deTTLextra. Desta forma, o período de validade de um certificado tem que ter sempre este facto em conta, no momento em que o certificado é gerado deve ser adicionada à data de validade doisTTLsextra necessários para que a troca de registos de

DNSseja feita de forma transparente e obedecendo às melhores práticas.

Um resumo com mais detalhes acerca das características dos certificados pode ser consultado na tabela5.1.

A definição do período temporal de actualização dos registos deDNSreveste-se de extrema importância, pois, se o tempo definido for muito alto implica a utilização de chaves maiores, bem

5.2 DNSSEC 87

Figura 5.2: Escala cronológica de geração de certificados de raiz de CA (caso tenha actualização diária)

Tipo de Certificado Profundidade Duração Certificado de raiz de CA 512 bits 1 mês

Certificado de nó 384 bits 1 dia

Tabela 5.1: Detalhes dos certificados utilizado pelo servidor de RADIUS

como, um aumento do tamanho das zonas assinadas, por outro lado se oTTL for muito baixo, gerar-se maior tráfego no servidor de DNS. Assim, decide-se definir o valor do TTL para 6h, este período de tempo é o que melhor se adapta à profundidade da chave (ZSK) vs entropia da chave (ZSK), cumprindo ainda todas as recomendações dadas no manual de boas políticas na aplicação do DNSSEC [14]. Sendo por isso necessário, que o TTL de um registo tenha uma fracção do tempo do registo, evitando assim, uma maior congestionamento de tráfego por parte dos servidores deDNSsecundários ”slaves“. A validade dos registos de zona é de 24h ao fim das quais são reassinados, ao definir-se oTTLcom 6h, consegue-se partir o dia em quatroTTLso que facilita a gestão das zonas deDNS.

Os períodos de mudança da chaveZSKdoDNScoincidem com os períodos de revogação dos certificados de raiz deCAdo servidor de autenticação para facilitar e agilizar o processo de gestão permitindo desta forma que os actos são executados de uma vez só, sem desperdicio de recursos, doutra forma seriam feitas muitas mais assinaturas criando grande latência na correcta propagação dos registos.

5.2.4.2 Processo de RollOver usado no DNS

O processo de rollover da chave deZSKimplementado neste trabalho, segue os passos identi- ficados na figura5.3.

As acções na figura5.3foram extrapoladas do manual de boas políticas na aplicação doDNS- SECem [14], são explicitados um conjunto de regras a ter em conta quando se usa o DNSSEC. Algumas das regras lá existentes já foram abordadas no decorrer deste capítulo, no entanto existe outra que quero referenciar, prende-se com o tempo doTTLque deve ser suficientemente grande para garantir que todos os RRs podem ser validados ao longo de toda a cadeia, isso garante a sanidade dos registos de uma zona permitindo validar essa zona em tempo útil.

Figura 5.3: Accções executadas no rollover de uma chave ZSK

Este processo de rollover tem o nome de Pré Publicação da chave (”Pre-Publish Key“) e permite que a nova chave seja publicada mais cedo para os servidores de DNS secundários, neces- sitando por isso de quatro passos.

Na tabela5.2é possível identificar as chaves e a sua duração para o sistemaDNSidealizado. Domínio Tipo de Chave Profundidade Duração

. (root) KSK 4096 bits 1 ano ZSK 2048 bits 6 meses

.pt KSK 1536 bits 1 ano

ZSK 1024 bits 3 meses porto.pt KSK 1280 bits 1 ano

ZSK 1024 bits 1 mês

Tabela 5.2: Rotação das chaves KSK e ZSK do sistema de DNS idealizado.

Um método alternativo de rollover que pode ser usado é o descrito na figura5.4. A este tipo de rollover é referenciado no manual [14] como de dupla assinatura (”Double signature“).

Figura 5.4: Accções executadas no rollover alternativo de uma chave ZSK

Para isso deve-se seguir os passos definidos na figura5.4, como é possível verificar este tipo de rollover implica menos um passo que no outro rollover. A assinatura da zona é executada duas