Resumo

  • A RFC 3652 separou um Message Envelope fixo de 20 octetos, usado para entrega e remontagem, de um Header de 24 octetos e um Body específico de cada operação. A assinatura digital em Message Credential não cobria o Envelope, mas cobria Header e Body.
  • Credential podia conter uma assinatura do originador ou um código de autenticação de mensagem baseado em uma chave de sessão previamente estabelecida. Esse limite descreve o escopo de integridade do protocolo — não um ataque documentado, falha de implementação ou impossibilidade de proteção nas camadas inferiores.

Uma mensagem, superfícies de confiança diferentes

Em 2003, a especificação do protocolo Handle precisava definir mais do que uma consulta. O cliente tinha de localizar o servidor responsável, pedir a resolução ou administração de um Handle e interpretar a resposta. Também era preciso transportar mensagens por redes que não apresentavam os dados da mesma forma. A versão 2.1 da RFC 3652 distribuiu essas funções em quatro partes contíguas: Envelope, Header, Body e Credential. RFC 3652

O Envelope era obrigatório e tinha exatamente 20 octetos. A RFC o descreve como uma camada de entrega, não como informação da aplicação. Seus campos incluem versão e sinalizadores do protocolo, identificador de sessão, identificador de solicitação, número de sequência e comprimento da mensagem. O Header obrigatório tinha 24 octetos e carregava campos comuns, entre eles códigos de operação e resposta. O Body trazia dados específicos da operação e podia estar vazio. RFC 3652

A fronteira de confiança não coincidia com a fronteira do pacote. A RFC 3652 afirma que a assinatura digital de Message Credential não protegia o conteúdo do Envelope, mas protegia Header e Body. Uma Credential não vazia podia conter uma assinatura digital do originador ou um MAC unidirecional baseado em uma chave de sessão já estabelecida. A especificação apresenta a Credential como meio para autenticar uma mensagem e verificar a integridade dos dados em trânsito. MAC depende de segredo compartilhado; assinatura digital usa outro modelo de chaves. RFC 3652 RFC 2104

Essa divisão acompanhava o papel do Envelope. Um cliente Handle podia usar datagramas UDP ou um fluxo de bytes TCP. A RFC 3652 limitava a 512 octetos as mensagens transportadas por UDP, sem contar os cabeçalhos IP e UDP. Mensagens maiores precisavam ser fragmentadas; cada fragmento levava seu número de sequência no Envelope para a remontagem. TCP oferecia um fluxo de bytes, mas não definia as fronteiras de mensagem do Handle. O protocolo ainda podia dividir mensagens maiores e recompô-las do lado receptor. RFC 3652 RFC 768 RFC 793

Já Header e Body descreviam o que cliente e servidor faziam. O código de operação solicitava um tipo de tarefa Handle; o código de resposta indicava sucesso, valor inexistente, encaminhamento a outro serviço, falta de autorização ou necessidade de autenticação. O protocolo seguia um modelo de nomes e dados definido em outra especificação; a RFC 3650 descrevia a arquitetura geral do serviço. Assim, o conteúdo semântico protegido começava depois da embalagem de entrega: remontar um fragmento não significava autorizar a operação que ele carregava. RFC 3652 RFC 3650 RFC 3651

Autenticação não era autorização

A RFC 3652 também separava a prova do cliente da decisão de permissão do servidor. Em ações administrativas, o servidor podia enviar um desafio; o cliente respondia provando que possuía a chave privada ou o segredo compartilhado pertinente. Mesmo depois da validação, o servidor ainda precisava verificar se o administrador tinha privilégios suficientes para a operação solicitada. Passar pelo desafio não aprovava, por si só, a alteração de um Handle. Uma sessão também podia compartilhar estado e chaves entre várias operações. RFC 3652

A RFC 3552 trata integridade, autenticação do interlocutor, confidencialidade e segurança do sistema como objetivos distintos: assinatura ou MAC não fornece automaticamente todos eles. A seção de segurança da RFC 3652 discute assinaturas de servidor e autenticação de cliente, mas a definição de formato é mais precisa: Credential cobre Header e Body, não o Envelope de entrega. Isso, isoladamente, não demonstra que uma mensagem foi alterada em algum sistema implantado. Um canal de camada inferior pode acrescentar outras proteções; a RFC é uma especificação, não um relato de incidente. RFC 3552 RFC 3652

A Credential Handle tampouco deve ser confundida com o perfil de assinatura X.509. A RFC 3279 define identificadores e formatos para assinaturas em certificados e listas de revogação daquela PKI; não amplia os octetos assinados pela RFC 3652 nem transforma o Envelope em conteúdo autenticado. Os termos criptográficos não bastam: é preciso dizer qual objeto está sendo autenticado. RFC 3279 RFC 3652

A RFC 3652 é Informational, e sua nota do IESG registra que as discussões não produziram consenso do IETF sobre o Handle System nem sobre sua posição na arquitetura de identificadores do IETF. O texto descreve um protocolo proposto, não prova adoção universal. Sua lição é mais restrita: enquadramento, remontagem e autenticação podem obedecer a regras diferentes; qualquer alegação de integridade deve dizer quais bytes a Credential realmente cobre. RFC 3652

Fontes