Resumo

  • O RFC 2444 trocou a interpretação improvisada de senhas descartáveis em cada aplicação por um mecanismo SASL nomeado e formatos de troca definidos.
  • O mecanismo autenticava com uma resposta OTP, mas não oferecia camada de segurança, privacidade de sessão, autenticação do servidor nem defesa contra ataques ativos.

Um quiosque público podia receber uma senha e, ainda assim, não deveria ganhar uma sessão inteira sob a identidade de outra pessoa. Essa distinção ajuda a entender o RFC 2444. O documento de 1998 descreve um modo de levar One-Time Password (OTP) ao Simple Authentication and Security Layer (SASL): em vez de cada aplicação acrescentar a senha de um jeito improvisado e tentar interpretá-la por heurísticas, o protocolo poderia solicitar um mecanismo definido.

O ganho era de integração. Não era uma camada de proteção para tudo o que vinha depois. O RFC 2222 separava autenticação da negociação opcional de uma camada de segurança para interações posteriores. O RFC 2444 deixa explícito que o mecanismo OTP não fornece essa camada. Também não promete privacidade da sessão, autenticação do servidor ou proteção contra ataques ativos. Portanto, uma resposta positiva no diálogo de autenticação não comprova que o restante da conexão esteja cifrado nem que o cliente saiba quem está do outro lado.

O perfil usa o sistema OTP do RFC 2289 e as respostas estendidas do RFC 2243. Um servidor deve aceitar hex, word, init-hex e init-word. As duas primeiras formas enviam a resposta; as variantes init- também reinicializam a sequência. O suporte a MD5 é obrigatório e o de SHA-1 é recomendado. Se o número da sequência estiver baixo demais, o cliente deve indicar a falha e deveria oferecer uma forma de reinicialização. Cada uso atualiza o registro correspondente na base de autenticação. A interoperabilidade depende, assim, de formatos comuns e de uma atualização de estado bem administrada.

O exemplo do cliente não confiável — como um terminal público — é deliberadamente estreito: uma senha OTP capturada só deveria permitir uma oportunidade de agir pelo usuário. Isso não protege as mensagens posteriores. O próprio RFC observa que uma base de autenticação comprometida pode sofrer ataques de dicionário, ainda que não precise ser equivalente a uma base de senhas em texto claro. A especificação também considera ataques passivos de dicionário e exige proteção contra a corrida descrita pelo sistema OTP subjacente. “Uso único” reduz uma possibilidade; não apaga as outras.

O SASL ainda separa identidade de autenticação e identidade de autorização. A primeira fornece as credenciais; a segunda indica a conta ou o conjunto de privilégios solicitado. Um agente pode apresentar as próprias credenciais e pedir acesso em nome de outra identidade. Quando a identidade de autorização fica vazia, o servidor pode derivá-la das credenciais. A resposta correta resolve a prova pedida pelo mecanismo, mas não decide sozinha se o pedido de acesso é legítimo. Nome do mecanismo, codificação dos desafios no protocolo anfitrião, proteção do transporte, autenticação do servidor e autorização continuam sendo camadas distintas.

O RFC 2444 atualizou a especificação SASL de 1997 e tornou obsoleto o uso pretendido do mecanismo S/Key no SASL. Mais tarde, o RFC 4422 substituiu a estrutura original do SASL; o RFC 5034 documentou um perfil POP3, e o RFC 5802 especificou outro mecanismo, SCRAM. Essas referências mostram a evolução do arcabouço, não adoção universal do RFC 2444 nem validade atual das recomendações criptográficas de 1998. Uma RFC registra um projeto normativo; não é levantamento de software instalado.

Sua contribuição histórica é específica: tornar a integração do OTP previsível o bastante para um protocolo chamar um mecanismo conhecido, sem obrigar cada aplicação a inventar um parser. O restante do trabalho não desapareceu. O perfil do protocolo precisava definir como transportar tokens SASL; a implementação precisava preservar a coerência da sequência; a operação precisava proteger os comandos seguintes; e a aplicação precisava mapear identidade a permissões. A senha podia ser descartável. A obrigação de proteger a sessão, não.

Fontes