Resumo

  • RFC 3631 ensina que o nome de um mecanismo não define sozinho o objeto protegido; camada, granularidade, endpoints, política, chaves e cobertura mudam a alegação.
  • Uma associação IPsec ativa ou um handshake TLS válido demonstra um estado delimitado. Não prova que o pacote contestado foi protegido, que o principal interno foi autorizado ou que a aplicação concluiu a operação.
  • A evidência útil liga classificação de tráfego, parâmetros negociados, identidade e confiança, ciclo de chaves, bytes cobertos, decisão da aplicação e observação final.

A pergunta é sobre este pacote, não sobre o túnel

Um túnel pode estar operacional enquanto determinados fluxos são descartados, ignorados pela política ou enviados por outro caminho. Seu contador agregado pode crescer com tráfego legítimo e ainda não conter o pacote que originou a disputa. A diferença parece pequena, mas muda o sujeito da prova: “existe proteção entre estes gateways” não equivale a “este pedido atravessou essa proteção”.

A arquitetura de RFC 4301 torna a diferença explícita. Os serviços IPsec dependem do protocolo, do modo, dos endpoints da Security Association, das chaves e da política. A Security Policy Database classifica tráfego para proteger, descartar ou permitir sem IPsec. Por isso, o recibo exige versão da política, seletores, SA, identificadores de fluxo ou pacote, contadores e correlação com o destino.

Mesmo quando o pacote foi protegido, os endpoints do túnel podem ser gateways. Isso autentica uma fronteira de rede, não o usuário, processo ou organização que emitiu a instrução dentro dela. A aplicação ainda precisa identificar o principal e decidir se a operação é permitida.

RFC 3631 descrevia um método, não uma lista eterna

RFC 3631 saiu em dezembro de 2003 pelo fluxo do Internet Architecture Board, com status Informational. Não é Internet Standard. A ficha do RFC Editor e o Datatracker registram essa condição. O histórico é história editorial, e a consulta de erratas não avalia implantações.

As escolhas algorítmicas do texto pertencem ao seu período. A geração moderna de IPsec está em RFC 4301; TLS 1.3 está em RFC 8446; as recomendações atuais de TLS e DTLS estão em RFC 9325. O valor duradouro de RFC 3631 é anterior ao algoritmo: uma implementação correta não compensa premissas semânticas falhas, e nenhum mecanismo serve a todas as ameaças, camadas e objetos.

O modelo de ameaça decide qual recibo importa

RFC 3631 pergunta primeiro quem ataca qual recurso, por qual meio e em qual posição. A mesma máquina pode ter valor diferente numa rede troncal e numa ponta isolada. Um serviço público talvez não precise esconder conteúdo, mas precisa impedir adulteração porque sua reputação e decisões dependem da integridade.

RFC 3552 formaliza o modelo como conjunto de capacidades presumidas e ameaças incluídas ou excluídas. Também rejeita a suposição de que todo atacante esteja fora do caminho e manda considerar a expansão além do domínio original. O relatório do workshop de arquitetura de segurança, RFC 2316, já exigia que RFCs descrevessem ameaças, tratamento e limites.

Antes de escolher tecnologia, o operador deve registrar ativo, ação, consequência, atacante on-path, off-path, interno e endpoint comprometido; duração; e propriedades requeridas: confidencialidade, integridade, autenticação, antirreplay, disponibilidade ou autorização. “Criptografia forte” não identifica nenhum desses vínculos.

Camada ampla não significa identidade fina

RFC 3631 observa que mecanismos inferiores cobrem mais protocolos, mas podem oferecer menos contexto. Uma proteção de enlace alcança diversos tipos de quadro, porém só naquele enlace. IPsec pode ser transparente a muitas aplicações, mas normalmente trabalha com granularidade de host ou gateway. TLS se integra a cada aplicação e pode usar políticas de certificado mais específicas. Uma assinatura de objeto sobrevive a armazenamento e encaminhamento, mas cobre o objeto, não toda a sessão.

O inventário deve nomear a unidade: enlace, classe de pacote, host, gateway, conexão, principal, mensagem ou objeto. Depois deve registrar lacunas. Um arquivo pode chegar por túnel protegido e ser alterado após a extração. Um objeto assinado pode transportar uma ordem inválida de modo perfeitamente íntegro. Um canal autenticado pode terminar num intermediário que cria outra conexão.

A arquitetura não pede uma camada única. Pede que o alcance não seja alargado por linguagem de marketing ou por um painel agregado.

Obrigatório para o implementador não é obrigatório no fluxo

RFC 3631 explica mandatory-to-implement como piso de interoperabilidade. Sem uma opção comum, duas implementações podem selecionar mecanismos incompatíveis. A exigência assegura disponibilidade do recurso, não seu uso em todas as instalações.

RFC 3365, BCP 61, exige mecanismos fortes nos protocolos IETF e separa implementar de usar. Um algoritmo antigo pode continuar no código e ser corretamente desabilitado; uma política pode exigir um modo que ainda não foi implantado.

Conformidade operacional precisa de estados distintos: capacidade presente, configuração habilitada, oferta, seleção, uso no fluxo e aderência à política vigente. Um certificado de produto cobre no máximo a capacidade. Até a palavra “padrão” é insuficiente se uma configuração herdada ou exceção altera a escolha.

Negociação pode ser correta e inadequada

RFC 3631 diz que SASL herda as propriedades do mecanismo negociado e que GSS-API depende do mecanismo subjacente. O framework não torna equivalentes as opções. É necessário guardar conjunto ofertado, escolha, channel binding, parâmetros, fallback e propriedades resultantes.

TLS 1.3 preserva a composição. RFC 8446 é independente do protocolo de aplicação; a aplicação decide como iniciar TLS e como interpretar identidades. Versão, suíte, autenticação de cliente, ALPN, retomada e 0-RTT alteram o resultado. Dados 0-RTT têm limites de replay, então uma operação não idempotente precisa de decisão adicional antes de produzir efeito.

O encerramento também importa. Se a aplicação precisa distinguir fluxo completo de truncado, o tratamento de close_notify e de uma conexão interrompida faz parte do recibo. Registros íntegros podem formar uma transação incompleta.

Certificado válido não escolhe o destino pretendido

RFC 9325 ressalta a validação do hostname. Uma cadeia pode ser válida e o peer pode provar a posse da chave sem ser o endpoint desejado. A referência nasce da intenção da aplicação antes da conexão; não pode ser inferida apenas do certificado apresentado.

Guardar nome de referência, nomes do certificado, regra de correspondência, trust anchors, instante, dados de status, exceções e veredito. Separar depois a identidade do usuário ou serviço da autorização. Autenticar servidor, cliente, dispositivo ou gateway não define automaticamente quem pode alterar um recurso.

RFC 3631 comparava hierarquia X.509 e rede de confiança PGP. Em ambos os casos, o receptor escolhe um ponto de partida e depende dos elos relevantes. A assinatura comprova uma ação da chave; a política local decide por que essa ação tem autoridade para determinado uso.

Uma MAC no início não protege o fim

O exemplo de HMAC em RFC 3631 mostra uma lacuna temporal. Um desafio com segredo compartilhado pode autenticar o início da conexão e evitar reaproveitamento de sessões antigas. Se as unidades seguintes não recebem proteção, a sessão ainda pode ser tomada após a autenticação.

Mapear exatamente os campos cobertos: método, destino, headers, corpo, nonce, sequência e resposta. Verificar cada alteração de estado, a herança após reconexão e a confirmação final. “MAC válida” afirma uma relação entre bytes e chave. Não afirma principal, escopo, política ou autorização.

O mesmo vale para assinatura de objeto. Integridade pode preservar com perfeição uma instrução emitida por ator sem direito. A decisão de negócio precisa consumir a identidade e a regra corretas, não apenas o bit de validação.

Chaves são parte do estado de produção

RFC 4107, BCP 107, distingue gestão automatizada e manual. Automação pode confirmar vivacidade, estabelecer chaves frescas e renovar em escala. Gestão manual só cabe em situações limitadas e ainda precisa de identificador, transição, substituição e resposta a comprometimento.

Registrar geração, armazenamento, distribuição, peers, finalidade, idade, rotação, revogação, destruição e estado de comprometimento. A mesma cifra com chave efêmera e com segredo copiado por anos não entrega a mesma proteção. Chaves de tickets TLS e retomadas também afetam sigilo futuro sem mudar o rótulo do protocolo.

Sem plano de troca e retirada, a primeira chave vira autoridade indefinida. O mecanismo continua verde enquanto ninguém consegue dizer quem deixou de ter acesso.

Firewall é uma afirmação sobre topologia

RFC 3631 chama firewall de defesa topológica. Ele depende de uma fronteira entre dentro e fora e não barra sozinho o atacante interno. Túnel, Wi-Fi, conexão direta, rota alternativa ou endpoint comprometido pode redesenhar a fronteira sem alterar a regra.

Autenticação por endereço ou nome depende de roteamento, DHCP, proxies, spoofing e DNS. DNSSEC protege origem e integridade de dados DNS assinados, mas não torna verdadeiro um vínculo incorreto nem transforma resolução em autorização.

Versionar mapas, caminhos alternativos, domínios administrativos e exceções junto à política criptográfica. Uma regra textual intacta pode perder seu significado quando o tráfego encontra outro trajeto.

O recibo liga realidade formal e execução

Os ensaios de Lu Heng sobre camadas de realidade e primazia do código em execução separam especificação, capacidade, configuração, seleção, validação, decisão e efeito. Minimum Initial Specification permite um mínimo comum sem tomar a autoridade futura da aplicação. Authority and Belief obriga a identificar emissor, escopo e limite de cada afirmação.

Para cada ação relevante, preservar recurso e ameaça; propriedade requerida; build; configuração; oferta e seleção; identidade de referência, credencial, anchors e validação; chaves; pacotes, registros ou objetos cobertos; principal e regra de autorização; decisão; observação de rede e negócio. Alertas, downgrade, fallback, bypass, replay, expiração, erro de nome, truncamento e exceção têm o mesmo valor probatório.

O túnel do início continuava saudável. O que faltava era o elo que colocasse o pacote dentro dele e o principal dentro da autorização. Sem esses dois vínculos, o verde só descrevia o mecanismo.

Fontes

  1. RFC 3631 — Security Mechanisms for the Internet
  2. RFC 3631 em texto simples
  3. Informações do RFC Editor sobre RFC 3631
  4. Registro IETF de RFC 3631
  5. Histórico IETF de RFC 3631
  6. Busca de erratas de RFC 3631
  7. RFC 2316 — workshop de arquitetura de segurança
  8. RFC 3365 — requisitos de segurança forte
  9. RFC 3552 — considerações de segurança
  10. RFC 4107 — gestão de chaves criptográficas
  11. RFC 4301 — arquitetura IPsec
  12. RFC 8446 — TLS 1.3
  13. RFC 9325 — uso seguro de TLS e DTLS
  14. Lu Heng — Running Code Primary
  15. Lu Heng — Minimum Initial Specification
  16. Lu Heng — On Reality Layers
  17. Lu Heng — On Authority and Belief