Resumo

  • O DASS previa que credenciais acompanhassem processos iniciados por um usuário, para que um serviço pudesse solicitar outro recurso em seu nome.
  • A delegação apoiava uma identidade de rede, mas o RFC 1507 limitava o acesso delegado principalmente pelo tempo; não restringia o servidor aos direitos mínimos de uma tarefa específica.
  • A especificação foi publicada como Experimental em 1993. Ela descreve uma arquitetura de segurança, não uma medição de uso ou adoção.

Uma sessão podia ter mais de um destino

Imagine um usuário que entra em um computador, inicia um processo e, por meio dele, consulta um serviço remoto. Esse serviço talvez precise acessar outro servidor. A senha digitada no primeiro nó não deveria atravessar a rede a cada chamada. Mas, sem algum tipo de credencial reutilizável, cada novo salto exigiria outra autenticação manual ou uma relação de confiança configurada à parte.

Esse problema aparece logo no início do RFC 1507, publicado em setembro de 1993. Charles Kaufman descreve o Distributed Authentication Security Service (DASS) como uma forma de autenticar usuários e computadores em ambientes distribuídos. A ideia era associar credenciais aos processos iniciados por um usuário e permitir que um serviço remoto recebesse uma credencial delegada quando precisasse agir em nome dele.

O sistema operacional tinha papel central. Ao fazer login, criaria credenciais para o usuário e as vincularia aos processos que ele iniciou ou autorizou. Quando um serviço recebesse uma delegação, o sistema remoto deveria criar o próximo processo com aquelas credenciais. O RFC não trata isso como um detalhe de interface: são as regras do sistema operacional que determinam onde a credencial vive, quem consegue usá-la e quando ela deve ser eliminada.

O usuário e a máquina não eram a mesma identidade

DASS tratava tanto pessoas quanto nós de rede como principais. Uma credencial podia carregar segredos associados ao usuário e à máquina de origem. Ambos podiam assinar uma requisição. O servidor receptor conseguiria distinguir quem pediu o serviço e qual nó levou o pedido até ele.

Essa separação dava ao recurso uma escolha mais precisa. Ele poderia aceitar determinado usuário, mas apenas quando a solicitação viesse de um host autorizado. Também podia considerar a identidade do nó mesmo quando o usuário não tivesse uma identidade global própria. O nome da pessoa não precisava ser substituído pelo nome da conta local onde ela estava logada.

O RFC explicava o problema com a multiplicação de contas: se uma pessoa tivesse acesso a dez computadores, cada recurso precisaria reconhecer dez nomes locais, além de acompanhar mudanças. DASS propunha um nome global reconhecível pelos nós, mantendo a conta local onde o sistema operacional ainda precisava dela. Regras semelhantes a .rhosts serviriam de ponte entre o principal de rede e as contas existentes.

A portabilidade não eliminava a administração local. O usuário podia ser identificado de modo consistente em vários nós, mas cada destino ainda precisava mapear essa identidade a uma conta e decidir o que ela podia fazer. O certificado demonstrava uma relação entre nome e chave; não concedia automaticamente permissão para abrir qualquer arquivo ou executar qualquer operação.

Delegar era entregar uma capacidade real

Para fazer chamadas em cadeia, o usuário podia permitir que um serviço usasse credenciais capazes de representá-lo. O DASS procurava limitar a exposição da chave: os segredos do usuário seriam necessários brevemente no início da sessão e deveriam ser esquecidos ao logout. A delegação remota valeria por um período limitado.

Mas um limite de tempo não equivale a limitar a tarefa. A versão descrita no RFC não reduzia a credencial aos direitos estritamente necessários para um serviço específico. Quem recebesse os dados poderia tentar agir como o usuário enquanto a credencial permanecesse válida. A proposta reconhecia a possibilidade de delegação mais estreita no futuro, mas não a oferecia naquele desenho.

A exceção começava no primeiro login. Antes que cartões inteligentes estivessem disponíveis, o usuário ainda podia digitar uma senha observável pela rede local. O texto projetava que, depois da autenticação inicial, a senha não precisaria seguir para outros nós. Um cartão poderia conservar a chave privada e assinar a sessão. Isso era uma possibilidade arquitetural, não prova de que a proteção estivesse instalada em sistemas reais.

A delegação também dependia de saber a quem a chave pertencia. DASS usava certificados públicos assinados por autoridades de certificação (CAs). A hierarquia de CAs seguia a hierarquia de nomes X.500: cada autoridade cuidava dos principais do seu diretório, e certificados parentais ou cruzados ligavam diferentes partes da árvore. Uma CA comprometida poderia se passar por nomes de seu escopo. A hierarquia limitava essa área de impacto, mas não impedia uma emissão fraudulenta dentro dela.

Revogar credenciais exigia estado compartilhado

O RFC expõe dois caminhos para retirar certificados. O primeiro era expirar e renovar. Certificados de uso comum poderiam valer cerca de um ano, com renovações em intervalos de meses para que a carga administrativa permanecesse manejável. Esse ritmo era previsível, mas lento para responder quando uma chave fosse comprometida.

O segundo caminho colocava no serviço de nomes apenas os certificados ainda válidos. O verificador aceitaria a credencial enquanto a encontrasse na árvore. O atraso poderia ser curto, mas dependia da propagação e dos caches. O documento reconhecia as consequências: a disponibilidade da autenticação ficava ligada à disponibilidade do diretório, e a segurança da revogação dependia da segurança desse mesmo serviço. DASS ainda não suportava listas de revogação X.509.

A própria autenticação tinha dependência de tempo. DASS usava marcas de tempo para detectar replay sem adicionar a rodada de mensagens de um desafio e resposta. O servidor rejeitaria solicitações antigas e lembraria as que já haviam sido recebidas na janela permitida. A validação de certificado podia tolerar algumas horas de imprecisão; a detecção de replay exigia uma fonte monotônica e sincronizada em minutos. Desvio excessivo podia recusar uma sessão legítima; um relógio atrasado podia reabrir mensagens antigas.

Assim, uma credencial delegada só podia ser interpretada dentro de vários estados: usuário, nó, processo, certificado, CA, diretório, relógio e conta local. Uma assinatura correta não mostrava sozinha se o certificado havia sido revogado, se o servidor tinha consultado uma cópia atual ou se a operação estava autorizada no recurso final.

O que o RFC permite afirmar

O cabeçalho do RFC 1507 classifica o DASS como Experimental e diz que ele não especifica um padrão da Internet. O apêndice descreve suporte ao Generic Security Service API; o RFC 1508 define separadamente uma interface genérica, e o RFC 1509 especifica suas ligações para C. O RFC 1510 registrou outra abordagem contemporânea, Kerberos V5, baseada num serviço confiável de distribuição de chaves. O RFC 1704 fez um panorama posterior de mecanismos de autenticação.

Esses textos demonstram que havia propostas diferentes para proteger identidades distribuídas. Eles não demonstram quantos sistemas adotaram DASS, se ele foi implantado em larga escala ou por que teria sido abandonado. A data e o status normativo de um documento não substituem evidência de software em execução.

A contribuição específica do DASS foi tratar a identidade como algo que acompanharia uma sessão de trabalho, e não como um atributo preso a uma única conta de máquina. A delegação fazia essa continuidade funcionar para chamadas de serviço em cadeia. Ao mesmo tempo, ela colocava chaves e decisões de confiança em processos, hosts, CAs e diretórios. O protocolo descrevia como conectar esses elementos; ainda seria preciso verificar separadamente quem usou cada credencial e qual operação foi executada.

Fontes