Resumo

  • O RFC 9918 mantém a autenticação X.509 mútua no NETCONF sobre TLS e alerta que uma CA confiável para esse acesso deve emitir apenas para partes autorizadas a usar servidores NETCONF.
  • Uma cadeia válida ainda precisa encontrar uma regra ordenada, produzir um nome de usuário, atravessar NACM, executar um RPC e deixar provas do datastore e do efeito no equipamento.
  • A trilha auditável deve registrar cada decisão; “mTLS concluído” não prova finalidade do certificado, permissão de controle nem mudança operacional.

O problema começa antes de qualquer comando. Uma empresa escolhe uma CA já integrada ao inventário, à rotação e aos módulos de segurança. A decisão é economicamente compreensível. Mas a CA também emite certificados para agentes que nunca deveriam tocar a configuração da rede. Se o servidor NETCONF aceita a CA de modo amplo, o limite técnico pode ficar maior que o limite organizacional.

RFC 9918 atualiza o transporte NETCONF. TLS 1.2 com autenticação mútua continua obrigatório; TLS 1.3 mútuo é recomendado e preferido quando disponível; early data é proibido. As regras de conexão, framing, encerramento e identidade permanecem ligadas ao RFC 7589.

A advertência central é simples: CAs incluídas na lista confiável deveriam emitir certificados somente para quem tem autorização de acesso ao NETCONF. Uma CA que também serve a outros propósitos pode levar o servidor a aceitar certificados inadequados. Não é necessário haver assinatura falsa ou cadeia quebrada. A falha pode ser uma cadeia perfeitamente válida representando um grupo maior do que o grupo autorizado.

O RFC 5280 oferece o processo de validação de caminho X.509. Assinaturas, validade temporal, restrições, políticas, nome e revogação compõem esse juízo. Mesmo assim, o resultado não contém por si só a decisão local “este sujeito pode operar este dispositivo”. A âncora autentica uma relação de emissão; não define automaticamente uma função administrativa.

O RFC 7589 mostra a etapa seguinte. O servidor percorre uma lista ordenada que associa certificado a nome. A correspondência pode usar a impressão digital do certificado final ou a de uma CA confiável presente na cadeia. A regra escolhida pode devolver um usuário explícito ou derivá-lo de rfc822Name, dNSName, endereço IP, do primeiro subjectAltName compatível ou do Common Name, hoje desaconselhado.

Essa lista não é documentação passiva. A ordem altera o comportamento. Uma regra ampla de CA colocada antes de uma regra exata pode produzir outro usuário sem que o certificado mude. Se uma correspondência não gerar nome válido, a avaliação continua; se nenhuma conseguir, a sessão termina. RFC 7407 modela essa superfície em YANG e ajuda a tratá-la como configuração que precisa de versão, revisão e recibos.

Para reconstruir a decisão, o registro deve conter hashes do leaf e da cadeia, instante e âncora de validação, políticas e consulta de revogação; a regra e sua posição; se o match foi no leaf ou na CA; o tipo de mapa, o campo de origem e o usuário derivado. Registrar apenas “certificado aceito” elimina exatamente as escolhas que distinguem finalidade de autoridade.

O usuário resultante entra em outro sistema de decisão. RFC 6241 exige que o transporte forneça uma identidade autenticada e que o servidor conheça e imponha suas permissões. RFC 8341 descreve NACM, onde usuário, grupos, operação, dados ou ação e regras vigentes determinam a autorização.

Autenticação aceita e RPC negado podem coexistir. Do mesmo modo, um RPC permitido não significa que toda operação futura está liberada. O recibo precisa conservar a regra NACM específica, o grupo resolvido e o alvo da solicitação. Isso impede que a palavra “confiável” migre silenciosamente da PKI para uma permissão que pertence à política do servidor.

Ainda há uma sequência depois da autorização. message-id e resposta correlacionam o RPC. O datastore escolhido, locks, validação, commit ou confirmed-commit e uma leitura posterior comprovam o estado de configuração. Programação do dispositivo, encaminhamento e resultado de serviço exigem observação independente. Um <ok> não é captura de pacotes, e um readback não é uma garantia de experiência fim a fim.

RFC 9525 reforça, para a identidade do servidor, que o cliente forma identificadores de referência aceitáveis antes de comparar o certificado recebido. Expiração, revogação e autoridade para prestar o serviço continuam separadas. RFC 9325 reúne recomendações contemporâneas para TLS; RFC 9846 explica as propriedades mais fracas de early data. Proibi-la no NETCONF evita antecipar operações, mas não reduz uma CA mal delimitada.

O registro da IANA associa netconf-tls ao TCP 6513 e referencia os RFCs 7589 e 9918. A entrada prova o registro do serviço, não um listener real, origem autorizada, versão TLS, regra de mapa, decisão NACM ou tráfego alterado.

A Especificação Inicial Mínima de Heng Lu favorece regras comuns determinísticas que possam ser verificadas localmente, sem fingir que a permissão local virou universal. A primazia do código em execução dá mais valor aos recibos da cadeia, mapa, NACM, RPC e datastore do que ao rótulo “confiável”. As camadas de realidade mantêm validade PKI, identidade, autoridade e efeito em planos distintos. São lentes editoriais declaradas, não novas obrigações da IETF.

Tratar o propósito como parte do desenho da confiança não exige abandonar a PKI corporativa em todos os casos. Exige saber qual população a âncora admite, limitar ou filtrar essa população, preservar a regra que constrói o usuário e nunca deixar o handshake falar em nome do commit ou do dispositivo.

Fontes