Resumo

  • O nome serviço [AT] domínio [AT] host — em que [AT] representa o sinal de arroba ASCII literal da sintaxe do RFC — mantém a finalidade do domínio junto do servidor descoberto, mas passa por interfaces ACE/UTF-8, canonização e mapeamento de mecanismo antes da autenticação.
  • A string que um operador lê não prova, sozinha, qual nome interno foi comparado, qual principal Kerberos foi derivado nem qual credencial respondeu. As duas visões precisam permanecer ligadas.

Uma investigação pode ter duas capturas aparentemente conclusivas. Na primeira, a configuração mostra o domínio que a organização pretendia atender. Na segunda, o log informa que a autenticação GSS terminou com sucesso. Entre elas, porém, o nome foi importado, normalizado, associado a um tipo, convertido para uma forma do mecanismo e talvez exibido de outro jeito.

Se esse caminho não foi registrado, as duas imagens não fecham a prova.

RFC 5178 criou nomes baseados em domínio para resolver outro problema concreto: uma descoberta insegura pode apontar para um servidor que se autentica legitimamente como ele próprio, mas não tem autoridade para prestar o serviço do domínio procurado. A solução acrescenta o escopo que faltava — serviço, domínio atendido e hostname — e, por isso, torna a fidelidade da representação parte da autorização.

O nome carrega um mandato

GSS_C_NT_DOMAINBASED_SERVICE usa a forma service [AT] domain [AT] hostname. O serviço nomeia a função. O domínio define em favor de quem ela é prestada. O host identifica o acceptor concreto. A IANA registra esse tipo como gss-domain-based-services, valor 5.

O cliente pode receber o host por DNS SRV sem DNSSEC. A resposta é uma indicação de caminho, não uma nomeação final de autoridade. Ao exigir que o host autentique uma credencial para o triplo completo, o cliente testa se alguém com poder de emissão o autorizou a representar aquele serviço de domínio.

Isso não torna o DNS correto. Também não torna a credencial infalível. Uma credencial copiada, roubada, emitida para o host errado ou deixada ativa depois da retirada pode satisfazer o protocolo e violar a política. O valor está em localizar a decisão: a autoridade vem do ato de emitir e manter a credencial do triplo.

Importar e exibir não são operações inversas

O RFC 5178 foi publicado no contexto do IDNA2003. A função tradicional de importação deve aceitar nomes internacionalizados em ACE nas posições de domínio e host. A variante UTF-8 recomendada deve aceitar UTF-8 ou ACE. A exibição tradicional produz ASCII ou ACE. A variante UTF-8 deve produzir UTF-8 e não pode produzir ACE.

É tentador imaginar um ciclo reversível: entra Unicode, sai Punycode, volta o mesmo Unicode. A arquitetura GSS não promete isso. RFC 2743 separa o nome interno opaco, o nome do mecanismo, a forma exibida e a forma exportada. GSS_Display_name() aplicado a um resultado de importação não garante reproduzir a string original nem o mesmo identificador de tipo.

GSS_Compare_name() existe para responder se dois nomes internos se referem à mesma entidade dentro das capacidades da implementação. A canonização para um mecanismo e a exportação produzem formas próprias para comparação persistente. Comparar duas strings de interface com memcmp, ou dois rótulos mostrados na tela, pode trocar semântica por aparência.

A mudança posterior de RFC 3490 para IDNA2008 torna o recibo ainda mais importante. RFC 5890 distingue A-label e U-label e enquadra uma geração diferente de processamento. Essa atualização histórica não reescreve o texto de RFC 5178. Uma implementação atual precisa registrar qual perfil aplicou, qual forma entrou, qual forma foi exibida e qual nome canônico acabou autenticado.

O operador precisa enxergar o Unicode para reconhecer a intenção humana. A auditoria precisa do ACE e do principal para reproduzir a execução. Guardar só um lado sacrifica uma das duas perguntas.

O mapeamento Kerberos adiciona outra decisão

RFC 5179 mapeia o nome de domínio para Kerberos V. O serviço vira o primeiro componente do principal, o hostname o segundo e o domínio o terceiro. O tipo NT-SRV-HST-DOMAIN, valor 12, é recomendado, embora NT-UNKNOWN seja permitido.

O realm não é simplesmente o texto do campo domain. O documento exige, por segurança, que ele seja derivado do hostname. Assim, a string que declara o escopo do serviço não escolhe livremente a autoridade Kerberos que validará sua própria declaração.

Na prática, uma evidência completa precisa mostrar o triplo de entrada, o principal gerado, o realm contatado, a credencial encontrada e o nome devolvido no contexto. Uma biblioteca pode aceitar a sintaxe e mesmo assim produzir um principal diferente do esperado pela política.

RFC 5179 também manda usar ACE nos componentes internacionalizados porque o trabalho de internacionalização do Kerberos ainda era incompleto. Essa escolha histórica reforça a necessidade de testar a pilha efetiva em vez de deduzir comportamento moderno pela aparência do nome.

Um host válido ainda pode ser o servidor errado

Antes de qualquer questão de codificação existe o motivo do triplo. Um atacante que altera descoberta não precisa falsificar a credencial do servidor legítimo. Pode direcionar o cliente a um host sob seu controle que possui uma credencial host-based válida. Se o cliente autentica apenas serviço [AT] host, ele confirma exatamente o host que a descoberta falsa indicou.

Com o domínio incluído, o host precisa provar que foi autorizado para aquele recurso coletivo. A distinção é especialmente útil em clusters: vários hosts podem servir o mesmo domínio, sem que qualquer host autenticado na infraestrutura possa entrar no conjunto.

RFC 6641 emprega a construção para raízes NFSv4 encontradas por SRV. DNSSEC deve ser usado quando disponível; o principal baseado em domínio acrescenta uma ligação entre a organização e o servidor selecionado. O cliente autentica algo como nfs [AT] example.net [AT] nfs2.example.net, não apenas o nome de nfs2.

Ainda restam etapas. NFS negocia seus mecanismos, autoriza operações e entrega — ou não — o namespace correto. Um contexto GSS bem-sucedido é um recibo de controle da credencial, não uma prova do conteúdo montado.

Fallback precisa de uma equivalência documentada

Nem todo mecanismo ou servidor aceita o tipo. LDAP antigo pode depender de nomes host-based. Ativar o novo formato sem credenciais correspondentes quebra interoperabilidade.

RFC 5178 não transforma essa limitação em licença para confiar na descoberta. Ao voltar ao nome do host, o iniciador deve verificar por outra fonte que aquele host está autorizado para o serviço do domínio. O mesmo vale para clientes sem suporte ao tipo.

Uma lista local assinada, uma política distribuída ou uma configuração revisada podem servir de prova alternativa. A própria resposta SRV insegura não pode confirmar a autorização que está em dúvida. O motivo, a fonte e a validade do fallback devem aparecer no registro da sessão.

Os estados necessários são diferentes: nome de domínio usado; fallback com autorização equivalente; fallback sem escopo equivalente; falha de compatibilidade. Colocá-los todos sob “GSS conectado” esconde a decisão de risco.

O recibo precisa atravessar todas as formas

Uma operação reproduzível conserva o domínio pretendido antes da descoberta, a resposta e seu estado de validação, o host escolhido, o OID do tipo, o buffer de entrada, as formas Unicode e ACE, o nome canônico, o principal Kerberos e realm, o emissor e prazo da credencial, o status GSS, a regra de aplicação e o resultado observado.

Esse registro não centraliza a autoridade. Ele permite que cada parte responda por sua decisão. DNS publica localização. O emissor delega. O mecanismo autentica. A aplicação autoriza. O teste observa o serviço.

A clareza é operacional: quando a tela e o principal divergem, a equipe não precisa escolher em qual relato acreditar. Ela pode reconstruir a transformação e identificar onde o mandato mudou.

Fontes