Resumo

  • RFC 9645 define agrupamentos YANG reutilizáveis para identidade de cliente e servidor, autenticação do par, parâmetros Hello e keepalives. O escopo é uma configuração genérica mínima, não um registro completo por sessão.
  • Certificado, chave pública bruta ou PSK configurado prova uma possibilidade autorizada. Não prova o que o par solicitou, qual material apareceu, se houve retomada, como a validação terminou ou qual principal a aplicação reconheceu.
  • Uma afirmação operacional defensável exige ligar versão do modelo e configuração à rota real do handshake, identidade apresentada, resultado de validação, autenticação opcional do cliente e resultado da operação.

A conformidade parou antes do fato decisivo

O caso parece simples. O servidor tem identidade X.509. O cliente possui referências de confiança válidas. A política permite versões e cifras aprovadas. Um PSK externo existe para contingência. O inventário confirma que tudo está disponível.

Essa evidência sustenta a frase “o sistema estava configurado para aceitar estas rotas”. Não sustenta “a conexão que executou esta mudança usou aquela rota”.

RFC 9645 define ietf-tls-common, ietf-tls-client e ietf-tls-server, além do módulo de enumeração de suites mantido pela IANA. Os agrupamentos de cliente e servidor tratam do TLS e deixam endereço, porta e modo de estabelecimento da conexão para os modelos consumidores. O texto classifica o modelo genérico como “menor denominador comum”, não como descrição completa de toda função TLS.

A fronteira é intencional. O padrão oferece uma linguagem compartilhada para expressar intenção sem reivindicar autoridade sobre cada implementação ou aplicação. O erro operacional surge quando o dashboard transforma essa linguagem em testemunho de uma sessão que ele não observou.

Quatro ramos carregam quatro significados

Os ramos principais de identidade são certificado, chave pública bruta, PSK de TLS 1.2 e PSK externo de TLS 1.3. Não são apenas formatos diferentes para a mesma prova.

O certificado envolve cadeia, identidade de referência, relógio, uso de chave, algoritmos de assinatura, âncora e política local. A chave pública bruta elimina a semântica da cadeia e costuma depender de correspondência exata com material confiável. O PSK de TLS 1.2 segue convenções anteriores de segredo e identidade. O PSK externo de TLS 1.3 inclui identidade externa, hash e parâmetros opcionais de contexto e destino.

RFC 9257 mostra que identificadores PSK podem ser visíveis e correlacionáveis e que participantes com um segredo de grupo podem se passar uns pelos outros. RFC 9258 distingue PSKs importados com contexto dos context-free. Logo, “PSK aceito” pode provar posse por um conjunto, sem atribuir a ação a um único dispositivo.

O recibo deve nomear o ramo, a classe do PSK e o estado do contexto, preservando apenas identificadores ou impressões protegidas do material efetivamente carregado. Guardar o segredo seria um novo risco; apagar a distinção seria perder a atribuição.

Identidade do servidor e identidade do cliente não formam uma única chave booleana

No agrupamento do cliente, client-identity é separado de server-authentication. A identidade do cliente é opcional porque uma camada acima do TLS pode autenticar o usuário. Mesmo configurada, ela só é apresentada no TLS quando o servidor a solicita.

No agrupamento do servidor, server-identity também é separado do contêiner opcional client-authentication. Sem esse contêiner, o servidor não deveria pedir credenciais ao cliente. Com ele, CA, certificados finais exatos, chaves brutas e PSKs compõem caminhos permitidos e aditivos.

Por isso “mTLS habilitado” é insuficiente. Pode descrever capacidade, não pedido real. O pedido pode existir sem resposta. A resposta pode chegar e falhar na validação. A validação pode passar e a aplicação recusar o mapeamento. O principal pode existir e não ter permissão para a operação.

O recibo precisa registrar pedido, apresentação, validação, mapeamento e autorização separadamente. Só então uma falha deixa de ser um genérico “problema de certificado” e ganha uma localização verificável.

Uma sessão retomada não repete necessariamente o certificado

RFC 9846, a especificação atual de TLS 1.3 no momento desta pesquisa, mantém versões, algoritmos de assinatura, grupos, key shares e identidades PSK como insumos diferentes. O servidor seleciona um PSK compatível e valida um binder que o vincula ao transcript atual.

Esse vínculo protege o handshake presente, mas não prova que o certificado do handshake original foi reapresentado. A retomada pode carregar contexto estabelecido antes. Um relatório que lê “TLS concluído” e injeta o certificado encontrado na configuração cria uma narrativa mais forte que o evento observado.

Também é preciso separar PSK externo de PSK de retomada. Um nasce fora do TLS; o outro deriva de sessão anterior. Em um caminho com early data, bytes de aplicação podem ser enviados antes da confirmação comum de 1-RTT. O sucesso final não revela sozinho o limite de replay e autorização sob o qual a ação ocorreu.

O registro operacional deve marcar full, resumed ou early data e indicar a origem e o contexto do PSK sem expor a chave. Caso contrário, a organização não saberá se provou a identidade nesta conexão ou se herdou uma decisão anterior.

Versão e cifra descrevem o canal, não o ator

hello-params-grouping permite configurar versões mínima e máxima e uma lista ordenada de suites. A lista opcional de algoritmos suportados descreve capacidade de implementação. São elementos importantes, mas não resolvem a identidade do par.

O registro TLS da IANA alerta que algoritmos se enfraquecem e que registro não equivale a endosso. Suites de TLS 1.3 têm semântica diferente das anteriores. RFC 9325 oferece recomendações de implantação; RFC 9852 exige suporte a TLS 1.3 para novos protocolos no seu escopo. Um identificador pode continuar representável enquanto a decisão local muda.

Por isso versão e suite negociadas devem aparecer no recibo em campos distintos do modo de identidade, do material apresentado e do resultado de validação. “TLS 1.3 com cifra aprovada” não diz se o par foi autenticado por certificado, chave crua, PSK externo ou retomada.

A configuração concede mandato para tentar

RFC 8342 separa configuração pretendida de estado operacional. RFC 8341 limita quem pode escrever dados sensíveis. RFC 9641 e RFC 9642 oferecem truststore e keystore reutilizados por RFC 9645. Cada camada produz um fato próprio.

Uma referência de keystore pode resolver e não ser selecionada. O truststore pode estar disponível sem receber certificado. A configuração pode ser aplicada a um listener não alcançado pela conexão. O TLS pode validar uma chave que a aplicação não transforma em conta. Uma conta autorizada ainda pode falhar na operação.

A separação de Heng Lu entre autoridade simbólica e realidade executada traz disciplina: o modelo controla vocabulário; a mudança aprovada controla intenção; a pilha TLS executa um ramo; a aplicação atribui significado e consequência.

O recibo mínimo deve reunir:

  • revisão RFC/YANG, features, deviations e modelo consumidor;
  • revisão aplicada, origem no datastore, aprovador e horário de ativação;
  • ramo de identidade e referências de keystore/truststore realmente resolvidas;
  • impressões ou versões protegidas da credencial e confiança carregadas;
  • identificador correlacionável e timestamps confiáveis;
  • versão e suite negociadas, separadas do modo de identidade;
  • caminho full, resumed ou early data e origem/contexto do PSK;
  • identidade apresentada, método, entradas e resultado de validação;
  • pedido, resposta, validação e principal da autenticação do cliente;
  • conclusão, alertas, novas tentativas e fallback;
  • autorização, operação, critério de aceitação e resultado aplicativo;
  • campos desconhecidos e responsável pela afirmação final.

Nenhum RFC citado exige esse formato unificado. Ele é um controle operacional derivado das fronteiras. Sua frase mínima é estreita: para esta sessão e operação, sob esta configuração aplicada, este ramo autenticou esta identidade, gerou este principal e terminou com este resultado.

Fontes

  1. Especificação inicial mínima
  2. Camadas da realidade e poder simbólico
  3. Primazia do código em execução
  4. Histórico do RFC 9645
  5. Página informativa do RFC 9645
  6. RFC 9645 em HTML
  7. RFC 9645 em texto
  8. RFC 9645 em XML
  9. Errata incorporada do RFC 9645
  10. Parâmetros TLS da IANA
  11. Módulo YANG IANA de suites TLS
  12. RFC 9641: modelo de truststore
  13. RFC 9642: modelo de keystore
  14. RFC 9846: TLS 1.3 atual
  15. RFC 9852: TLS 1.3 para novos protocolos
  16. RFC 9325: implantação segura de TLS
  17. RFC 9257: orientação para PSK externo
  18. RFC 9258: importação de PSKs externos
  19. RFC 8341: controle de acesso à configuração
  20. RFC 8342: arquitetura de datastores de rede