Resumo

  • A resposta 480 recusava o comando no estado atual da conexão; ela não guardava a operação para execução depois do login.
  • Uma autenticação bem-sucedida alterava identidade e capacidades, mas o cliente ainda precisava emitir uma solicitação nova.
  • 281 não concedia acesso geral: a política local podia devolver 502 ao comando repetido.

A identidade mudou; a operação não voltou

Considere GROUP local.research. Na primeira tentativa, o servidor responde 480 Permission denied. O cliente consulta as capacidades, escolhe AUTHINFO e conclui a autenticação com 281 Authentication accepted. O servidor, porém, não seleciona o grupo.

Para isso ocorrer, chega uma segunda linha GROUP local.research. A primeira já terminou. Não ficou suspensa em uma fila privada, esperando que alguma identidade aceitável aparecesse na mesma conexão.

Essa diferença distribui responsabilidade. O servidor pode exigir prova de identidade. O cliente conserva a decisão sobre continuar ou abandonar o que havia pedido. A credencial responde quem se apresenta; a repetição responde o que esse sujeito ainda quer fazer.

A extensão de uso corrente registrou o reenvio

RFC 2980 descreveu extensões comuns que já faziam parte das implementações NNTP. No fluxo original de AUTHINFO USER e AUTHINFO PASS, 480 pedia autenticação, 381 podia pedir a senha e 281 confirmava a combinação. Em seguida, o cliente deveria tentar novamente o comando original, que seria processado normalmente.

O advérbio importa: normalmente. A autenticação não carregava a decisão da operação anterior. O novo comando enfrentava o estado atual e podia obter um resultado diferente. O usuário talvez tivesse desistido, a lista de funções poderia ter mudado ou o recurso poderia continuar proibido.

O mecanismo antigo também transmitia toda a informação de autenticação em texto claro, segundo o próprio RFC. A fronteira de repetição organizava autoridade, mas não escondia senhas. Sem proteção de transporte, o segredo continuava exposto.

Autenticação e autorização ficaram em mãos diferentes

RFC 4643 formalizou AUTHINFO, preservou USER/PASS para compatibilidade, aposentou SIMPLE e GENERIC e definiu um perfil SASL. O documento deixa a autorização fora da extensão: a política do site decide quais recursos um usuário autenticado pode utilizar.

Assim, 480 informa que o cliente precisa se autenticar e/ou obter autorização antes de usar aquela instalação. É uma condição que pode mudar, não uma promessa de mudança. Depois de reconhecer a identidade, o servidor pode negar o grupo com 502.

281 prova somente que o intercâmbio de autenticação foi aceito naquela sessão. Não prova direito de leitura em todos os grupos, permissão para postar, autoridade de transferência entre pares nem autoria de um artigo. Também não assina conteúdo nem transfere privilégios para o próximo servidor.

CAPABILITIES era uma fotografia do momento

Antes de iniciar AUTHINFO, o cliente deveria pedir CAPABILITIES. Os mecanismos oferecidos dependiam do estado da conexão. Uma lista observada antes de TLS não precisava ser igual à lista dentro do canal protegido; uma lista anônima não precisava revelar o que estaria disponível após a autenticação.

Quando AUTHINFO tinha sucesso, o servidor deixava de anunciar AUTHINFO e recusava nova autenticação com 502. Outras capacidades podiam mudar. Portanto, o cliente precisava atualizar a observação antes de decidir se e como repetiria o objetivo original.

A lista de mecanismos SASL permanecia igual após a autenticação por uma razão específica: permitir a detecção de possível redução ativa das opções vistas antes. Essa permanência era uma evidência de comparação, não autorização para autenticar outra vez. O caminho AUTHINFO já estava encerrado.

Executar o comando antigo automaticamente ignoraria essa mudança de contexto. A operação ocorreria sob um conjunto de capacidades que o cliente ainda não havia aceitado nem sequer observado.

O diálogo de credenciais também tinha limite

AUTHINFO podia começar depois de 480 ou de forma espontânea, quando anunciado. Mas o cliente só podia continuar além do primeiro passo se uma resposta 38x autorizasse a próxima etapa. Qualquer outra resposta encerrava o intercâmbio e impedia o envio de mais material de autenticação.

O servidor jamais podia responder 480 ao próprio AUTHINFO. Isso criaria um ciclo em que a ordem destinada a satisfazer a autenticação exigiria nova autenticação. O histórico 381 tinha um significado especial: solicitava o comando separado AUTHINFO PASS, e não apenas mais dados para a linha USER.

Depois do sucesso, não era permitido trocar de identidade dentro da mesma sessão. Para apresentar outro principal, era preciso estabelecer outra conexão. O limite evitava que trabalho relacionado a um usuário passasse sem marca para outro.

Privacidade vinha por outra transição

O código 483 tratava da falta de proteção adequada na conexão. RFC 4642 definiu STARTTLS e exigiu reconstruir o estado da aplicação após a negociação criptográfica. O cliente consultava as capacidades de novo; USER/PASS podia aparecer apenas dentro do canal seguro, e os mecanismos SASL também podiam variar.

O protocolo mantinha quatro perguntas separadas. O enlace está protegido? A identidade foi aceita? Esse principal tem permissão sobre o recurso? O cliente enviou a operação de novo nesse estado? TLS, AUTHINFO, política local e reenvio respondiam a questões diferentes.

Nem TLS nem AUTHINFO forneciam prova ponta a ponta sobre a matéria publicada. TLS protegia uma ligação NNTP. AUTHINFO identificava o cliente da sessão. Nenhum dos dois autenticava automaticamente o autor do artigo ou os relés posteriores.

O registro operacional precisava mostrar duas ordens

RFC 3977 inclui um exemplo de instalação protegida: a primeira solicitação de grupo recebe 480; depois vem a autenticação; então a solicitação de grupo é enviada novamente. A repetição demonstra que a negativa anterior era final para aquela tentativa.

Uma trilha de auditoria útil guarda a primeira ordem, o 480, as capacidades prévias, a situação de TLS, o método escolhido, o resultado da identidade, as capacidades posteriores, a nova ordem e a decisão do recurso. Esses eventos podem compartilhar um identificador de conexão, mas não devem virar um único rótulo “login concluído”.

O segundo comando pode ter os mesmos caracteres e ainda assim ser um evento novo. Ele tem outro instante, outro principal e outro conjunto de funções. Pode ser aceito, receber 502, encontrar uma falha temporária diferente ou não ser emitido porque a intenção desapareceu.

O registro da IANA nomeou mecanismos, não direitos

O registro de parâmetros NNTP da IANA lista AUTHINFO, SASL e STARTTLS como capacidades distintas, ligadas a documentos diferentes. Esse vocabulário comum permite negociar transições sem confundi-las.

O registro não garante suporte atual, segurança de USER/PASS em qualquer canal nem autorização de uma conta. A lista de capacidades desta conexão e a resposta ao novo comando continuam sendo as provas do que era possível e permitido.

A escolha do NNTP oferece uma regra aplicável a sistemas modernos: quando uma operação foi recusada por falta de identidade, fortalecer a identidade pode mudar o contexto, mas não deve roubar do cliente o controle da repetição. Saber quem fala não é o mesmo que saber o que ainda deseja fazer.

Fontes