Resumo

  • O draft-cel-nfsv4-rpc-tls-othername-04, datado de 5 de setembro de 2026, propõe colocar uma identidade de usuário RPC em um otherName do subjectAltName X.509. É um Internet-Draft individual, não uma RFC, consenso do IETF ou relatório de implantação.
  • No servidor que aplica o mecanismo, a identidade validada do certificado substitui a alegação AUTH_NONE ou AUTH_SYS do cabeçalho. Falha de validação, mapeamento ou autorização leva a AUTH_TOOWEAK, sem retorno ao cabeçalho.
  • Um servidor sem suporte, ou com a função desligada, ignora o mesmo campo e segue a política RPC usual. O cliente não consegue distinguir os dois casos; emitir o certificado não prova que a redução aconteceu.

Considere um agente de backup cujo certificado determina uma única conta. Em um nó, a chamada pode alegar outro UID no cabeçalho e ainda assim será executada como backup. Em outro nó, mais antigo, a autenticação TLS termina normalmente, o novo tipo de nome é ignorado e o UID declarado volta a participar da decisão.

A assinatura é a mesma. A autoridade efetiva não é.

A revisão 04 parte de uma fronteira consciente da RFC 9289. RPC sobre TLS protege confidencialidade e integridade e autentica os pares, mas não redefine a autenticação do usuário de cada chamada RPC. O rascunho tenta aproximar essas camadas para serviços que devem atuar como um usuário só: registrar esse usuário no certificado cliente, validá-lo ao abrir a sessão e empregá-lo no lugar de credenciais fracas do cabeçalho.

Três formas são definidas. RPCAuthSys carrega UID e GIDs numéricos. GSSExportedName carrega um nome exportado específico do mecanismo; a RFC 4121 descreve o formato pertinente ao Kerberos. NFSv4Principal usa o user@domain da RFC 8881, resolvido pelo owner mapping do NFS.

Elas não são três traduções garantidamente equivalentes. UID numérico exige cadastros compatíveis, nome GSS exige um mecanismo integralmente suportado e user@domain exige uma política local de domínio. Se o SAN trouxer mais de uma forma de identity squashing, o certificado deve ser rejeitado. Ambiguidade autenticada continua sendo ambiguidade.

O controle está no caminho que impede o recuo

O servidor aplicador começa validando a cadeia X.509 segundo a RFC 5280 e as regras de RPC-with-TLS. Depois analisa uma única identidade, deriva o usuário local e verifica se aquele par pode usá-lo. ACLs ligadas ao subject, intervalos aceitáveis de UID/GID, grupos, padrões de domínio e confiança no mecanismo GSS podem compor essa autorização local.

Quando aprovada, a identidade fica vinculada à sessão TLS. Em toda chamada AUTH_NONE ou AUTH_SYS, o servidor desconsidera a credencial do cabeçalho da RFC 5531. RPCSEC_GSS não sofre a redução: o contexto da RFC 2203 já comprovou seu próprio principal.

O comportamento de falha é a trava essencial. Identidade malformada, impossível de mapear ou não autorizada gera AUTH_TOOWEAK nos procedimentos não NULL abrangidos. O servidor não pode aceitar, em seguida, o usuário do cabeçalho. Fazer isso reabriria o acesso que o certificado deveria limitar.

Essa obrigação, porém, não alcança software que não a implementou. O perfil exige subject não vazio e SAN não crítico; o significado novo vive no type-id do otherName. Um servidor antigo pode entender a extensão SAN e não entender o tipo interno, ignorando-o conforme a expectativa de interoperabilidade. Um servidor novo com a política desligada acaba no mesmo ponto, e o cliente não sabe se encontrou ausência ou desativação.

Marcar todo o SAN como crítico poderia fazer sistemas antigos rejeitarem também os outros nomes válidos. A opção por convivência reduz atrito de migração. Em troca, o campo assinado não é uma garantia transportável de mínimo privilégio: é um pedido que precisa de um executor.

Um recibo por nó, não uma confiança por frota

O inventário real cruza perfil do certificado, propósito de emissão, âncora de confiança, versão do nó, chave de ativação, escopo da política, dados de mapeamento, flavor RPC e sessão. O rascunho permite aplicar a regra ao servidor inteiro, a um export ou a outra unidade local. O rótulo “tem suporte” não revela quais recursos estão protegidos.

Atrás de um balanceador, duas sessões sucessivas podem cair em decisões opostas: uma substitui o UID, a outra o conserva. Os dois nós respondem com baixa latência, e os painéis de disponibilidade nada denunciam. A diferença está em quem ganhou autoridade sobre o arquivo.

Validade e revogação também são necessárias, mas parciais. Onde o campo funciona, o certificado concede acesso no nível de usuário, por isso importam a propagação de CRL/OCSP e a duração da credencial. A revisão recomenda separar as âncoras desses certificados das usadas só para autenticar pares TLS. Uma revogação recente não atesta que o OID foi lido; um parser correto não atesta que o UID ou grupo local foi autorizado.

O documento registra uma implementação FreeBSD da forma user@domain como completa segundo seus contribuidores. A mesma seção diz que a listagem não é endosso do IETF, não foi verificada de modo independente e não é catálogo de produtos; nenhuma experiência de implementação é relatada. A RFC 7942 mostra por que expor running code ajuda o debate, sem transformar o relato em evidência de produção.

É uma aplicação direta das camadas de realidade de Heng Lu: o campo assinado, a decisão do servidor e o efeito no recurso não ocupam a mesma camada. A primazia do código em execução desloca o teste para o binário que serviu. Uma especificação inicial mínima pode dar um ponto de partida comum, sem alegar que a publicação instalou a prática.

A pergunta correta deixa de ser “o certificado contém o usuário?” e passa a ser: qual nó comprovou que usou esse usuário nesta sessão e rejeitou a identidade concorrente do cabeçalho?

Fontes