Resumo

  • A revisão 07 do Internet-Draft individual draft-howard-virp foi enviada em 6 de setembro de 2026 e tem data de 7 de setembro. Não é padrão, documento adotado por grupo de trabalho nem projeto endossado pela IETF.
  • O novo perfil External Authorization Binding restringe a identidade permanente do portão a comandos de observação e entrega a autorização de escrita a um serviço que o portão não controla.
  • O modelo confronta intenção e execução declaradas pelo portão com a decisão externa e a contabilidade produzida pelo equipamento. Falta ou divergência de registros recebe estado próprio em vez de virar automaticamente êxito ou recusa.
  • O texto afirma que política estática por comando e reconciliação com a contabilidade do dispositivo foram implementadas e exercitadas em Cisco IOS e IOS-XE. É relato do autor, não reprodução independente nem prova de uso amplo.
  • A peça mais exigente continua ausente: permissões de escrita limitadas pela aprovação, pelo prazo e por um único consumo não estão implementadas, e as decisões do autorizador externo ainda não entram na cadeia como registros nativos.

O segredo privilegiado não pode morar com quem pede a ação

O histórico do Datatracker registra a revisão 07 como carregada, aceita e disponibilizada em 6 de setembro. O texto datado do dia seguinte acrescenta um perfil que faz uma pergunta verificável: se o componente que recebe pedidos de um agente autônomo for comprometido, o invasor também obtém a credencial capaz de alterar o equipamento?

No novo arranjo, a identidade estável do portão só pode observar. O próprio dispositivo consulta um serviço separado para autorizar cada comando que ultrapasse essa classe. Uma identidade com poder de escrita não pode permanecer armazenada no portão de forma utilizável sem uma decisão específica, tomada por outra parte.

Esse deslocamento muda a resistência do controle. Um classificador dentro do mesmo processo que guarda a credencial privilegiada deixa de conter qualquer coisa quando o processo cai. Já uma regra aplicada pelo dispositivo, a partir de um serviço independente, obriga o atacante a vencer outro ponto de autoridade. Pedidos de autorização e registros contábeis também devem seguir um caminho que o portão não consiga suprimir ou falsificar sozinho.

As peças são antigas, como a própria revisão reconhece. A RFC 8907 define autorização TACACS+ por comando e contabilidade; identidades administrativas de leitura são comuns. A contribuição reivindicada pelo VIRP é a composição dessas peças ao redor de um solicitante automatizado, com separação entre leitura e escrita e uma camada para comparar versões do mesmo ato produzidas em lugares diferentes.

O alcance institucional é menor que a ambição técnica. A página do Datatracker classifica o documento como Internet-Draft individual, sem fluxo RFC nem AD responsável. Ela afirma que qualquer pessoa pode submeter um rascunho, que este não é endossado pela IETF e que não tem posição formal no processo de padronização. O mérito precisa vir da arquitetura e das provas, não do cabeçalho.

Três origens não formam uma só verdade automaticamente

gate_intent/1 registra antes do contato o que o portão pretende fazer; gate_execution/1 registra depois o que ele afirma ter feito. Os dois estão marcados como implementados. device_accounting/1 contém o evento de comando originado no equipamento, recebido por um coletor alcançável sem depender do portão e encadeado ao chegar. Também é indicado como implementado.

authorization_decision/1 tem outro estado. Esse registro deveria carregar o permit ou deny do serviço externo, com equipamento, identidade, comando canônico ou resumo e horário. A semântica está especificada, mas a implementação ainda não o emite na cadeia. A decisão permanece no log local do serviço e pode ser anexada ao conjunto de verificação como artefato de outra fonte.

Daí surgem duas recusas. O classificador VIRP pode barrar uma intenção dentro do limite de coleta e gerar um registro encadeado. O serviço externo pode negar um comando que o portão chegou a enviar, mas essa decisão ainda não tem a mesma custódia. Unificar ambas como uma simples palavra “negado” apaga qual autoridade decidiu.

A reconciliação usa identificador do dispositivo, identidade do principal, resumo exato do comando canônico e uma janela de tempo declarada. Relógio não confiável exige UNRESOLVED. Registros qualificados que concordam produzem MATCHED; execução alegada apenas pelo portão é GATE-ONLY; ação contabilizada sem execução correspondente do portão é DEVICE-ONLY; DENIED depende da decisão do autorizador, não da ausência de contabilidade.

Preservar a incerteza é parte da proteção. Se o sistema aproximar horários ou textos até conseguir uma correspondência, o painel fica completo justamente quando a evidência deixou de ser confiável.

O significado da contabilidade depende do equipamento

Segundo a RFC 8907, accounting registra o que um usuário está fazendo ou fez. Para administração de equipamentos, entretanto, a norma manda enviar um registro de início para todo comando inserido, independentemente de como foi autorizado. Em alguns dispositivos, o evento prova entrada, não autorização ou execução.

Por isso o VIRP exige uma declaração por classe de equipamento: a contabilidade significa comando inserido, autorizado, executado ou evento com semântica de execução desconhecida. Somente registros demonstrados como prova de execução podem sustentar uma classificação de execução.

O rascunho relata um resultado limitado em Cisco IOS e IOS-XE: nos exercícios descritos, o registro correspondia ao comando executado e uma negativa não produzia o mesmo evento. Também proíbe supor que isso vale em outras plataformas. O repositório de referência é mantido pelo próprio projeto e documenta o que o autor declara ter construído; não funciona como validação independente.

O transporte AAA participa da confiança. A revisão cita a RFC 9887 para proteger TACACS+ com TLS 1.3 quando houver suporte nas duas pontas. Um serviço desenhado fora do portão não é fonte independente se o portão puder interceptar, alterar ou silenciar o tráfego que leva autorização e contabilidade.

A permissão efêmera está desenhada em detalhe

O emissor futuro, que deve ser distinto do portão, verificaria a assinatura Ed25519 de um aprovador cadastrado e seu vínculo com comando, alvo e expiração. Uma aprovação de uso único teria identificador próprio. O emissor precisaria registrar o consumo de forma durável antes de liberar a autoridade e recusar a reutilização. Expiração não basta, pois uma aprovação ainda válida poderia ser repetida diversas vezes.

Também seria necessário demonstrar que o comando aprovado é a invocação efetivamente entregue. Se o driver transforma a forma canônica, a correspondência deve ser estabelecida. Políticas textuais precisam ancorar as duas extremidades para impedir correspondência por prefixo com comando maior ou composto. A expiração efetiva inclui a latência do serviço ao aplicar revogação; o retorno de uma recarga assíncrona não prova que a permissão antiga já morreu.

O próprio texto marca esse caminho como não implementado. O que existe, segundo a revisão, é política estática: identidade de leitura, identidade de operador e recusa do restante, acompanhada de reconciliação. Isso pode reduzir o raio de dano. Não equivale à capacidade temporária derivada de uma aprovação e extinta depois de um consumo.

As novas assinaturas Ed25519 por entrada e por cabeça da cadeia também são opcionais, desativadas por padrão e configuráveis por nó. Elas acompanham o HMAC obrigatório. Acrescentam uma forma de verificação pública onde habilitadas, sem certificar a verdade do dispositivo nem preencher a ausência da decisão externa encadeada.

Um recibo para a custódia do direito de escrever

Cada ação de escrita deveria produzir um recibo que prove a restrição da identidade permanente, identifique o autorizador independente, vincule aprovação, comando, alvo, expiração e identificador único, e mostre que o consumo foi gravado antes da liberação. O recibo deve declarar quando a revogação realmente passou a valer e qual invocação chegou ao dispositivo.

Depois, deve reunir intenção do portão, execução declarada, decisão externa e contabilidade. A janela de comparação, a saúde dos relógios e o significado contábil da família de equipamentos acompanham o veredicto. Quando faltarem dados, UNRESOLVED é a conclusão correta.

Esse recibo é uma recomendação de Daniel Kade, não uma regra do VIRP, da RFC 8907, da RFC 9887 ou da IETF. Seu objetivo é impedir que uma interface central tome emprestados ao mesmo tempo o poder do autorizador e a força probatória do equipamento.

Fontes