Resumo

  • No modo mútuo, o cliente assinava o desafio do servidor junto com um valor que acabara de gerar. A assinatura final do servidor cobria ambos, mas incluía um terceiro valor porque o cliente já conhecia o primeiro desafio antes de escolher o próprio.
  • Esse terceiro valor vinculava a resposta do servidor a uma nova contribuição aleatória. Não transformava o mecanismo em um canal seguro: a RFC 3163 não fornece integridade ou confidencialidade e admite que ataques ativos continuam possíveis.

O detalhe que parece repetido

À primeira vista, a troca da RFC 3163 repete uma etapa. O servidor envia um desafio aleatório; o cliente assina um registro que o inclui; depois, o servidor também assina um registro que contém esse desafio. Por que o token final do servidor precisa de um terceiro valor?

A RFC de agosto de 2001, “ISO/IEC 9798-3 Authentication SASL Mechanism”, responde olhando para a ordem das escolhas. A questão não é quantas mensagens existem, mas quem já conhecia o desafio da outra parte quando escolheu seu próprio valor aleatório. Essa ordem limita o que uma assinatura consegue demonstrar sobre a troca.

O documento Experimental define duas famílias de mecanismos SASL. 9798-U-<algorithm> autentica o cliente perante o servidor. 9798-M-<algorithm> acrescenta autenticação mútua: o cliente assina um desafio do servidor, e o servidor assina um desafio do cliente. Os dois modos usam assinaturas de chave pública e certificados X.509; o fluxo de verificação descrito inclui o processamento do caminho do certificado.

A ordem dos valores assinados

Em ambos os modos, o servidor começa gerando R_B. Em seguida, o cliente escolhe R_A e envia TokenAB, que contém dados de certificado e uma assinatura sobre R_A e R_B. O cliente também pode incluir um identificador do servidor. O servidor verifica a assinatura, confere se o R_B recebido corresponde ao desafio enviado e valida o identificador, se houver.

No modo unilateral, esse token do cliente completa a troca principal. O modo mútuo acrescenta uma resposta do servidor: TokenBA2 contém o certificado do servidor e uma assinatura sobre R_A, R_B e um novo valor, R_C. O cliente verifica o certificado e a assinatura, confirma que os dois valores anteriores correspondem às etapas já vistas e verifica o identificador opcional do cliente.

A seção 7 explica o papel de R_C. Ao incluir R_A nos dados assinados pelo cliente, o servidor não consegue obter essa assinatura sobre dados que ele mesmo escolheu antes do início do mecanismo. A direção inversa não é simétrica: o cliente conhecia R_B antes de escolher R_A. A assinatura do servidor precisa incluir R_B para que o cliente confira o registro, mas esse valor, sozinho, não oferece a mesma proteção ao servidor. Por isso, a RFC 3163 inclui R_C no TokenBA2 assinado pelo servidor.

Esse é o motivo específico descrito pela RFC, não uma prova geral contra todo intermediário, repetição ou ataque ativo. Os valores aleatórios precisam vir de um gerador criptograficamente forte; se forem previsíveis, o mecanismo pode ser atacado. O terceiro valor trata da diferença de ordem apresentada no texto, sem corrigir propriedades que ficam fora do registro assinado.

Assinatura não é proteção da sessão

A fronteira é explícita. A RFC 3163 diz que o mecanismo oferece apenas autenticação. Não garante a integridade das mensagens posteriores nem a confidencialidade do conteúdo. A seção de segurança limita a proteção à escuta passiva e afirma que ataques ativos, inclusive sequestro de sessão, continuam possíveis. A nota da IESG é ainda mais direta: o mecanismo assume a complexidade da PKI, mas descarta a integridade de cada transmissão; TLS pode oferecer efeito semelhante com benefícios de integridade.

Os certificados não juntam essas camadas. authID em TokenAB pode indicar uma identidade de controle de acesso diferente da identidade de quem assinou o certificado. Aceitação do caminho do certificado, autenticação pelo mecanismo, mapeamento de identidade e autorização da aplicação são decisões distintas. Uma assinatura válida confirma que determinada chave assinou os dados cobertos; não decide o que a aplicação deve permitir.

O exemplo IMAP da RFC não demonstra o modo mútuo. É um exemplo de autenticação unilateral 9798-U e diz que Base64 e o prefixo + vêm do perfil IMAP, não do mecanismo SASL. Trata-se de uma ilustração de protocolo, não de evidência de implantação ou interoperabilidade.

A Nota 20 de Lu Heng serve aqui apenas como lente interpretativa: separar o que o protocolo verifica de afirmações mais amplas sobre identidade ou autoridade. A correspondência dos desafios e as assinaturas verificadas pertencem ao registro; proteção do canal e permissão da aplicação dependem de outros controles. Essa leitura não é atribuída aos autores da RFC 3163.

Fontes

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. Registro da RFC Editor para a RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. Registro de mecanismos SASL da IANA
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng, Nota 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile