Resumo

  • RFC 1446 submetia a mensagem SNMPv2 a uma verificação de digest MD5 com segredo compartilhado e, separadamente, a um teste de tempo de vida. Um digest correto não bastava para estabelecer que a mensagem ainda era atual.
  • Enquanto uma parte usasse a mesma chave privada de autenticação, partyAuthClock não poderia diminuir. O recuo isolado reabria uma faixa de timestamps já encerrada e podia tornar tráfego capturado novamente admissível.
  • A recuperação precisava preservar uma época formada por identidade, geração de chave e tempo monotônico. Mais tarde, RFC 3414 representou essa época com o identificador do mecanismo autoritativo, o contador persistente de inicializações e o tempo dentro da inicialização, sem fundir autenticidade e tempestividade.

O relógio também era material de segurança

Um agente para quando seu relógio de autenticação marca 25.000. Antes da parada, alguém gravou uma mensagem com timestamp 24.500. Com tempo de vida de 300 segundos, a cópia já não era aceita quando a noção local do receptor ultrapassava 24.800.

Na recuperação, o agente encontra em armazenamento persistente um registro mais antigo: 24.400. A chave privada, contudo, foi preservada na versão mais recente. A mensagem gravada volta a caber na janela. Ela não ganhou bytes novos nem recebeu outro digest. O receptor perdeu a prova de que aquela parte do tempo já havia sido consumida.

Essa cena revela uma propriedade que interfaces de administração tendem a esconder. O relógio de RFC 1446 não era apenas telemetria sobre horário. Ele participava do significado de cada autenticação. A chave permitia reconhecer a relação criptográfica do pacote; o relógio determinava se aquela relação ainda podia ser usada. Preservar um e restaurar o outro a um ponto anterior criava um estado coerente para o operador, mas incoerente para a defesa contra repetição.

O documento impunha então uma invariável: o relógio de autenticação de uma parte deve ser não decrescente enquanto estiver associado a determinada chave privada. Se for necessário diminuí-lo, a chave muda no mesmo instante. A identidade de segurança completa não residia em nenhum campo sozinho, mas no conjunto parte, geração da chave e trajetória monotônica do tempo.

O pacote passava por provas diferentes

Publicado em abril de 1993 como Standards Track e hoje classificado como Historic, RFC 1446 especificava um protocolo de autenticação e um de privacidade para SNMPv2. Para uma parte configurada com v2md5AuthProtocol, o perfil interoperável usava 16 octetos de material privado de autenticação e MD5 para produzir um digest de 128 bits.

Na origem, o segredo ocupava provisoriamente o campo do digest. A forma autenticada da mensagem era serializada e processada; o resultado substituía o segredo antes da transmissão. No destino, o digest recebido era retirado, a cópia local da chave era recolocada na estrutura e um novo cálculo era feito. Diferença entre os resultados incrementava snmpStatsWrongDigestValues e encerrava a autenticação.

Antes de tratar a mensagem como aceitável, porém, o receptor também consultava o relógio e o tempo de vida da parte de origem. A condição de expiração podia ser expressa assim:

authSrcTimestamp + tempo de vida < relógio de autenticação local

Quando a desigualdade era verdadeira, snmpStatsNotInLifetimes aumentava e a mensagem era recusada. O digest podia coincidir perfeitamente; a falha estava em pertencer a um passado que o receptor já não aceitava. Da mesma forma, um timestamp novo não compensava um digest errado.

Essa separação evita que a palavra “autenticado” absorva afirmações demais. A comparação criptográfica pode sustentar que certos bytes passaram pelo teste de integridade e origem do receptor sob uma chave conhecida. A comparação temporal pode sustentar que aqueles bytes estavam dentro da janela aplicada. Em seguida vêm controle de acesso, processamento da operação e eventual evidência externa de mudança. Cada etapa pode ter sucesso ou fracasso próprios.

Uma resposta SNMP também não comprova, por si só, que uma alteração chegou ao equipamento físico ou persistiu. Para essa conclusão são necessárias observações independentes. O desenho de RFC 1446 ensina a não usar a força de um teste para preencher os vazios dos testes seguintes.

A largura da janela era uma escolha administrativa

As mensagens autenticadas carregavam timestamps de origem e destino com granularidade de um segundo. partyAuthLifetime definia o atraso máximo aceitável. RFC 1446 recomendava escolher o menor valor compatível com a precisão dos relógios, a demora de ida e volta e a frequência com que o sincronismo pudesse ser verificado.

Uma janela curta rejeita mais prontamente o passado, mas pode confundir atraso legítimo com repetição. Uma janela longa absorve desvio e lentidão, ao custo de manter a captura útil por mais tempo. Aumentar o tempo de vida para eliminar erros de operação altera o risco, mesmo quando é apresentado como simples ajuste de tolerância.

Estar dentro da janela tampouco demonstrava unicidade. Duas cópias da mesma mensagem podiam estar igualmente no prazo. Para operações que modificassem estado, o RFC recomendava esperar uma confirmação positiva ou a expiração do intervalo antes de enviar a sucessora. O cuidado reconhecia que autenticação e tempestividade não forneciam, sozinhas, a ordem de um registro transacional.

Somente depois dos testes de tempo e digest vinha a decisão de acesso. Caso algum acesso fosse permitido, timestamps autenticados superiores podiam avançar seletivamente as noções locais dos relógios das partes. Isso restringia quem podia ensinar tempo ao receptor, mas não transformava a atualização do relógio em autorização, execução ou prova de efeito.

Uma chave nova impedia a segunda vida do digest

Ao retroceder o relógio e conservar o segredo, o operador recompunha as duas condições originais do pacote capturado. Seu timestamp voltava à faixa numericamente recente e seu digest continuava reconhecido pela chave antiga. O replay não precisava vencer a criptografia; bastava esperar que o receptor revogasse sua própria memória temporal.

A troca simultânea da chave quebrava essa interseção. O timestamp antigo poderia se aproximar do novo “agora”, porém o digest produzido sob o segredo anterior não passaria no cálculo com o segredo novo. A troca não corrigia o relógio: declarava que a mesma leitura numérica passava a pertencer a outra época.

RFC 1447 registrou a obrigação na definição de partyAuthClock: seu valor não deveria ser reduzido a menos que a chave privada de autenticação da parte mudasse simultaneamente. partyAuthLifetime fornecia a duração em segundos. O MIB tornava administrável o pacto entre estado temporal e estado secreto.

Mesmo assim, pedir uma troca e concluí-la eram coisas diferentes. A estação responsável precisava escolher o novo valor, enviar a solicitação, saber que chegou, confirmar que o agente o adotou, coordenar outras estações e só então aposentar a chave anterior. Durante a transição, podia ser necessário guardar os dois segredos, inclusive através do reinício da própria estação.

Uma linha de auditoria dizendo “alteração aceita” não prova que todos os participantes vivem na nova época. Descartar cedo a chave velha causa indisponibilidade. Mantê-la sem prazo prolonga a sobreposição de confiança e dificulta saber qual geração validou cada mensagem.

Um valor não autenticado podia orientar sem provar

O funcionamento partia de relógios aproximadamente sincronizados e de pelo menos uma estação de gerenciamento responsável por coordenar relógios e distribuir segredos. Sem mudança de chave, o procedimento normal avançava a noção mais lenta até a mais rápida. Não fazia a mais adiantada recuar sob o mesmo segredo.

Havia uma exceção instrutiva. Quando a estação não sabia se sua noção de tempo concordava com a do agente, podia começar por uma leitura não autenticada. O número recebido servia como candidato para sincronização. Depois de adotá-lo, a estação tinha de realizar uma leitura autenticada e confirmar a base escolhida.

A primeira observação era necessária, mas não ganhava autoridade por necessidade. Ela dizia o que um interlocutor apresentara sem prova criptográfica. A segunda anexava outro tipo de procedência. Manter as duas etapas separadas evita reescrever descoberta como verificação.

Com mais de uma estação responsável, surgia uma questão de controle. Elas podiam divergir sobre o relógio de uma parte ou a geração da chave. Uma transição concluída por uma estação podia deixar outra presa ao passado. A especificação exigia coordenação local; nenhuma variável do protocolo escolhia por si só quem tinha autoridade para iniciar a época, confirmar a adoção e encerrar a sobreposição.

A monotonicidade precisava sobreviver à pane

RFC 1446 exigia representações não voláteis e incorruptíveis da identidade de cada parte, do relógio de autenticação, da chave privada de autenticação e da chave privada de privacidade. O tempo de vida deveria receber proteção semelhante quando possível. A simples existência de uma coluna persistente não demonstrava que a última época válida sobreviveu.

Uma implementação poderia manter um relógio alimentado por bateria. Outra poderia gravar pontos periódicos e, no reinício, avançar conservadoramente além do maior valor plausível desde a última gravação. Não era necessário reconstruir cada segundo perdido; era essencial não retornar a uma faixa já usada pela mesma chave.

Se o agente permanecesse inativo até o relógio de uma parte alcançar o máximo, o relógio parava no máximo. A única solicitação autenticada de gerenciamento que deveria ser enviada então era uma que alterasse pelo menos o relógio e a chave privada. O máximo encerrava a época; não autorizava zerar o contador.

Se parâmetros protegidos fossem perdidos ou destruídos, o RFC mandava substituí-los por valores aleatórios, tornando necessária a redistribuição manual. A decisão sacrificava retomada automática para não simular continuidade. A estação responsável que detectasse o reinício ainda poderia precisar restaurar outros atributos, inclusive um tempo de vida não retido, e avançar artificialmente um timestamp para tornar admissível a mensagem autenticada de recuperação.

O contador de inicializações mudou a forma da época

Mais tarde, o User-based Security Model de RFC 3414 organizou a tempestividade em torno de um mecanismo SNMP autoritativo. snmpEngineID identificava esse mecanismo, snmpEngineBoots contava reinicializações e snmpEngineTime contava segundos na inicialização corrente. O identificador e o contador de boots precisavam persistir em armazenamento não volátil.

O temporizador interno podia recomeçar em zero porque o contador avançava primeiro. Uma mensagem do boot anterior carregava outra época, mesmo que seu número de segundos se parecesse com o atual. O receptor autoritativo recusava um contador divergente ou um tempo fora da janela fixa de 150 segundos.

O novo arranjo não tornou o valor de autenticação uma prova de atualidade. A verificação criptográfica e a temporal continuaram distintas. Se o mecanismo não pudesse determinar o último contador de inicializações, deveria prendê-lo ao valor máximo. Mensagens autenticadas falhariam na tempestividade até uma intervenção manual estabelecer nova identidade de mecanismo ou novos segredos de usuário.

RFC 3414 não substituiu RFC 1446 diretamente; houve etapas intermediárias na evolução do SNMP. A continuidade está no princípio. O primeiro protegeu um relógio contínuo exigindo nova chave quando ele recuasse. O segundo permitiu zerar o tempo de boot porque um contador durável distinguia as épocas. Ambos recusaram a ideia de que um digest válido, sozinho, localizasse uma mensagem no presente.

Fontes