Resumo

  • O NTS usa TLS para negociar e derivar chaves, fornece cookies e fecha a conexão; depois, cada consulta NTP devolve um cookie opaco que permite ao servidor reconstruir a associação.
  • O servidor elimina o registro individual, não toda memória: ele ainda mantém gerações compartilhadas de chaves de cookie, configuração, fontes de tempo e política de rotação.
  • A coautoria de Dieter Sibold e suas funções atuais na IETF comprovam participação em uma obra coletiva, não domínio sobre o consenso, implementações ou a verdade do relógio.

Há duas maneiras de escalar um serviço seguro. Uma é ampliar o banco que guarda o estado de cada cliente. A outra é reduzir o que precisa permanecer no servidor. Network Time Security escolheu a segunda.

Ao final do estabelecimento, o servidor coloca a associação num objeto que só ele consegue interpretar e pede ao cliente que o leve. A consulta seguinte traz o objeto de volta. A continuidade deixa de depender de uma linha individual num banco central, mas continua dependente das chaves que dão sentido ao recibo.

Essa arquitetura é elegante porque admite a descontinuidade. O canal TLS não precisa sobreviver para que a confiança negociada seja usada em pacotes NTP posteriores. Também é perigosa se uma organização transformar “pacote autenticado” em sinônimo de “horário verdadeiro”.

O NTS foi desenhado como duas etapas

NTS-KE ocorre por TCP na porta 4460 e usa o protocolo de aplicação ntske/1 dentro de TLS. O cliente verifica o serviço, as partes negociam NTPv4 e um algoritmo AEAD, e a resposta pode indicar outro servidor e outra porta para o tráfego de tempo.

O exporter de TLS produz duas chaves: C2S para o caminho cliente-servidor e S2C para o caminho servidor-cliente. O estabelecimento também entrega um estoque inicial de cookies. Em seguida, requisição, resposta e canal TLS terminam; não sobra estado específico daquele cliente no lado servidor.

Na etapa recorrente, o NTP continua em datagramas. O cabeçalho normal de 48 octetos é autenticado, mas não cifrado. Campos de extensão transportam o cookie, um identificador aleatório da requisição e o autenticador.

Separar as etapas concentra certificado e criptografia assimétrica onde são necessários e deixa a transferência frequente com proteção simétrica mais leve. NTS-KE e NTP podem até operar em componentes diferentes. O pré-requisito é uma gestão coerente das chaves de cookie.

O recibo de produção precisa fazer a ponte: identidade e validade do certificado, ALPN, protocolo, AEAD, geração exportada, destino NTP, cookies emitidos e primeiro pacote protegido bem-sucedido. TLS sem a segunda etapa não prova serviço de tempo utilizável.

Stateless não quer dizer sem chaves

No formato sugerido pela RFC, o servidor reúne o identificador do AEAD e as chaves S2C e C2S. Esse conteúdo é cifrado com uma terceira chave, usada para cookies. O resultado carrega o identificador da chave de cifragem, um nonce e o texto cifrado.

O cliente não lê o conteúdo. Ele guarda os bytes e os apresenta depois. O servidor usa o identificador para localizar a geração correta, verifica o selo e restaura as chaves da associação.

O que desaparece é o cadastro por cliente. O serviço ainda conserva chaves compartilhadas, versões anteriores durante a transição, parâmetros e fontes. Em um cluster, todos os nós que recebem consultas precisam acessar gerações compatíveis. Um nó desatualizado produz NAK contra cookies que outros nós aceitam.

Também não há transferência de autoridade. O cliente é depositário, não editor. Carregar uma declaração selada não permite alterar o algoritmo, inventar chaves nem decidir o que o servidor deve interpretar.

Três identificadores cumprem funções diferentes

O cookie traz um identificador da chave que o servidor usa para abri-lo. A requisição traz outro valor, o Unique Identifier aleatório, para ligar a resposta àquela consulta. E a implementação pode manter um identificador interno de geração para operação e auditoria.

Confundi-los enfraquece o diagnóstico. O Unique Identifier é autenticado, ecoado e descartado; protege o cliente contra uma resposta antiga reproduzida. Não é identidade persistente da máquina. C2S e S2C também não são intercambiáveis: cada uma comprova um sentido.

Nesse perfil, o servidor não mantém um histórico de toda requisição processada para impedir repetição. Reprocessar uma solicitação válida é aceitável se a resposta não criar amplificação. Por isso a especificação cobre os modos 3 e 4 de NTP, e não todos os modos existentes.

Uma boa telemetria separa chave de cookie ausente, falha ao decifrar, autenticador de pacote inválido, resposta sem correlação e amostra de tempo rejeitada. “Erro de segurança” não é uma causa operacional.

O cliente reserva espaço para receber reposição

Reusar sempre o mesmo cookie pode permitir correlação quando um dispositivo muda de rede. O servidor, portanto, devolve cookies novos. O problema é impedir que uma consulta pequena peça uma resposta grande a um endereço falsificado.

Cookie Placeholders são espaço reservado na própria consulta. O servidor transforma esse orçamento em novos cookies. A orientação busca manter oito cookies ainda não usados e evita mais de sete placeholders por consulta; se o tamanho ameaça fragmentar o datagrama, o cliente deve pedir menos.

O mecanismo dá lastro ao tamanho da resposta. Não basta observar quantos cookies existem: tamanho individual, placeholders, reposições, perdas e tamanho do pacote mostram se a continuidade está funcionando sem criar um vetor de amplificação. O estoque oito é orientação, não certificado universal.

Rotação e NAK definem a recuperação

O formato recomendado não depende de uma data universal gravada dentro do cookie. Ele continua válido enquanto o servidor retém a chave de cifragem indicada. A RFC recomenda rotacionar, apagar gerações antigas para limitar comprometimentos e manter apenas algumas anteriores para uma passagem gradual.

Sem a chave correta, o servidor envia NTS NAK. O cliente volta a NTS-KE. Perder as chaves num reinício, distribuí-las mal entre nós ou rotacioná-las depressa demais pode transformar uma falha de estado numa tempestade de novas conexões TLS.

A separação também protege parte do serviço. Se apenas NTS-KE ficar indisponível, clientes com cookies aceitos ainda podem obter pacotes autenticados. Clientes novos ou com cookies antigos ficam bloqueados. Há, portanto, duas disponibilidades distintas e uma ponte compartilhada.

A documentação atual do chrony expõe essa ponte. authdata mostra geração de estabelecimento, AEAD, tamanho de chave, último sucesso, tentativas, NAK, quantidade e comprimento de cookies. A configuração descreve persistência e rotação. Esses detalhes pertencem ao chrony e à versão em uso; servem como exemplo de observabilidade, não como regra universal.

Uma escolha real entre desvinculação e resiliência

Quando possível, cada cookie deveria ser usado uma vez. Um valor repetido pode ligar tráfego observado antes e depois de uma mudança de endereço. Receber reposição reduz essa pista adicional.

Se NTS-KE cai por muito tempo, o estoque termina. A RFC permite reuso quando manter o serviço é mais importante. A decisão preserva autenticação às custas de maior possibilidade de correlação. Deve ter gatilho, prazo e condição de retorno.

O objetivo não é anonimato total. O servidor de tempo continua vendo os clientes que o procuram, o estabelecimento TLS não ganha a mesma propriedade de desvinculação e o cabeçalho NTP permanece legível. O registro precisa indicar primeira utilização ou reuso e a justificativa.

Segurança da mensagem não é qualidade da hora

Uma resposta autenticada prova posse da chave esperada e integridade do conteúdo protegido. Não prova que o oscilador do servidor está correto, que suas referências são independentes nem que o cliente deve adotar a amostra.

RFC 8633 recomenda pelo menos quatro fontes independentes e diversas para quem precisa de boa exatidão. Os algoritmos de NTPv4 ainda filtram, comparam e escolhem fontes. A disciplina do relógio local continua sendo decisão do cliente.

Ataques de atraso preservam todos os bytes. O adversário segura um sentido por mais tempo e distorce o cálculo de offset baseado em latência aproximadamente simétrica. A autenticação passa. Múltiplas fontes, caminhos e limites de distância ajudam, mas não removem o atraso físico.

Existe ainda o início circular: o certificado TLS tem datas, enquanto o relógio do cliente pode estar errado. A RFC sugere último horário persistido, relógio com bateria, política estrita onde possível, comparação de fontes e checagem posterior. Não promete uma solução perfeita.

O comprovante deve chegar até offset, atraso, distância, fontes aceitas e descartadas, estado do sistema e ajuste efetivo. O selo criptográfico é uma evidência de origem, não um laudo metrológico.

Dieter Sibold aparece com limites claros

RFC 8915 foi publicada em setembro de 2020 com Daniel Fox Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie e Ragnar Sundblad como autores. É um documento Standards Track resultante de revisão pública e consenso da IETF.

O Datatracker atual lista Sibold como presidente do grupo Network Time Protocols e revisor do Internet Area Directorate, além de associá-lo às RFCs 8633 e 8915. A página do grupo o nomeia ao lado de Karen O'Donoghue e registra trabalho contínuo em NTP, NTS, resistência a atraso e futuras especificações.

A PTB, instituto nacional de metrologia da Alemanha, identifica o Dr. Dieter Sibold como responsável pela segurança da informação. Uma notícia oficial sobre sincronização segura também o apresenta como contato para NTS.

Os registros sustentam participação duradoura entre metrologia, operação e padrões. Não sustentam invenção solitária, controle da IETF, comando sobre chrony ou decisão sobre cada serviço de tempo. Autoria permite atribuir contribuição; não transforma consenso em propriedade.

Um único encadeamento, quatro recibos

O primeiro recibo é NTS-KE: endpoint, certificado, política de validade, TLS, ALPN, protocolo, AEAD, geração e destino NTP. Segredos não entram no log; identificadores protegidos de ciclo, sim.

O segundo é o cookie: geração de cifragem, estoque, uso ou reuso, placeholders, reposição, NAK, rotação e novo estabelecimento. Em cluster, cada resultado precisa do nó que o produziu.

O terceiro é o pacote: hash seguro do identificador, direção, autenticação, correlação, offset, atraso e motivo de rejeição. O quarto é o relógio: conjunto de fontes, escolha, correção aplicada e saúde posterior.

O encadeamento impede que uma etapa fale pelas outras. TLS pode passar e NTP falhar. NTP pode ser autêntico e a amostra ser ruim. O relógio pode estar certo enquanto as chaves de cookie não sobreviverão ao próximo reinício. Dar primazia ao código em execução é guardar a transição real, não confiar no rótulo.

Fontes