Resumo

  • Na RFC 1446, uma parte SNMPv2 podia trocar o próprio segredo antes de produzir a resposta, autenticando-a com uma chave que o gerenciador ainda não havia adotado.
  • A falta de resposta admitia dois estados: pedido perdido e chave antiga preservada, ou pedido aplicado e apenas a resposta perdida; o segredo privado não podia ser lido.
  • Um marcador público permitia verificar a mudança sem expor a chave, enquanto valores antigo e novo precisavam sobreviver até à reconciliação, inclusive após reinício.

O agente avançou primeiro

A RFC 1446 separava a mudança de um segredo já existente em passos. A estação responsável gerava o novo valor e enviava um setRequest protegido. O destino processava o pedido e respondia. Só depois de receber a resposta o gerenciador alterava seu banco local.

Quando a parte modificava o próprio segredo, o destino gravava a nova chave antes de montar a resposta. O pacote de volta usava o valor novo, enquanto o verificador ainda tinha o antigo. Sem tratamento explícito da transição, a confirmação correta poderia parecer inautêntica.

Envio, entrega, commit remoto, geração da resposta, retorno e aceitação eram eventos distintos. A proteção criptográfica do pacote não apagava a ordem em que os estados mudavam.

Uma resposta ausente abria duas histórias

Se nada voltasse, talvez o pedido nunca tivesse chegado. Nesse caso, ambos continuavam com o segredo anterior. Ou o agente poderia ter feito a troca e perdido apenas a resposta. Então as duas bases discordavam.

Repetir com a chave velha não esclarecia automaticamente. A nova tentativa poderia ser rejeitada porque a primeira havia sido aplicada. O erro seguinte não identificava sozinho falha de rede, ataque ou queda do agente.

O segredo privado não podia ser consultado. Permitir sua leitura destruiria a propriedade que justificava tratá-lo como segredo. A reconciliação precisava de um sinal diferente, público sem ser revelador.

O registro da RFC 1446 a classifica como histórica. MD5 e DES pertencem ao desenho de 1993 e não são recomendação atual. A fronteira entre commit remoto e conhecimento do controlador, porém, independe desses algoritmos.

Um marcador observável acompanhava a escrita opaca

O método recomendado incluía um valor público novo e reconhecível na mesma alteração. Na troca do segredo de autenticação, mudava-se o campo público correspondente; na de privacidade, o outro campo público. Depois de uma resposta perdida, o gerenciador lia esse valor.

A Party MIB mantinha separados segredo privado, valor público, relógio e tempo de vida. O marcador não continha a chave. Ele vinculava uma transação a um vestígio legível, permitindo descobrir se o destino avançara.

Ainda assim, o alcance era limitado. O marcador comprovava o processamento daquela mudança no modelo. Não provava atualização do gerenciador, persistência após falha, autorização de pedidos futuros nem o efeito pretendido no ambiente gerenciado.

O estado incerto tinha de ser durável

Entre o envio e a confirmação, a estação guardava o segredo antigo e o novo. O atraso podia resultar de falha de rede e durar bastante. RFC 1446 exigia prontidão para reter os dois inclusive através de reinícios.

Persistir apenas o resultado desejado era perigoso. Apagar a chave velha quando o pedido não chegou eliminava o acesso. Perder a nova quando somente a resposta havia sumido produzia o mesmo risco. A fila de recuperação precisava representar a bifurcação.

Identidade da parte, relógio de autenticação e chaves privadas deviam possuir representações não voláteis e incorruptíveis. O relógio precisava continuar monotônico após falta de energia. Um processo restaurado sem esse contexto podia recusar tráfego legítimo por tempo ou exigir intervenção da estação responsável.

Reinício não era reconciliação. Recuperar significava tornar comuns novamente identidade, tempo, duas candidatas, tempo de vida e marcador.

Segurança da mensagem não ordenava os comandos

O digest compartilhado sustentava origem e integridade; relógio e vida útil limitavam atraso e replay excessivos. Mas não impediam apagar ou suprimir mensagens. A própria RFC dizia que ausência de resposta autenticada não concluía falha do agente ou da rede. Até o aviso de autenticação podia se perder por relógios ou segredos divergentes.

SNMP tampouco impunha uma ordem geral a mudanças de estado. A orientação era esperar confirmação positiva ou expiração antes do próximo comando. O snmpSetSerialNo na MIB SNMPv2 oferecia uma ferramenta separada de ordenação, sem provar durabilidade ou efeito.

O modelo administrativo organizava partes, contextos e políticas de acesso. Uma origem autenticada não recebia por isso autorização universal, e uma escrita aceita não demonstrava resultado operacional.

A testemunha pública reapareceu no USM

O modelo de partes não foi o fim da arquitetura. A RFC 1910 experimentou usuários, identidade de agente, contagem de inicializações, tempo e acesso. A RFC 2574 e a RFC 3414 definiram o USM do SNMPv3.

O desenho posterior mudou identidades e derivação, mas preservou a verificação. Objetos KeyChange aplicavam a troca em uma direção, um spin lock protegia concorrência e usmUserPublic recebia um valor aleatório. Sem resposta, sua leitura informava se a nova chave estava ativa.

Essa continuidade não torna atual a criptografia de RFC 1446. Ela confirma que trocar um segredo ilegível por um canal sujeito a perda exige prova independente da resposta.

Fontes