Resumo

  • No RFC 9813, a identidade PSK substitui o endereço IP como chave de consulta da relação cliente-servidor RADIUS/TLS, mas chega em texto claro antes da autenticação e só aponta para um registro candidato.
  • Uma implantação verificável separa admissão por faixa, validação do identificador, versão da tabela, prova do PSK, segredo e integridade RADIUS, política por cliente, contexto de retomada, ação do NAS e serviço observado.

O RADIUS tradicional indexava a tabela de clientes pelo endereço de origem. A linha escolhida continha um segredo compartilhado e frequentemente carregava permissões do equipamento. Assim, localização, relacionamento e política pareciam uma coisa só.

NAT permite vários clientes sob um endereço; mobilidade permite um cliente em vários endereços. Ampliar faixas recupera conectividade, não precisão. Duplicar linhas por endereço possível cria estado administrativo que envelhece rapidamente.

Publicado em julho de 2025 como BCP 243, o RFC 9813 fornece a orientação operacional de TLS-PSK que faltava a RADIUS sobre TLS e DTLS. Sua mudança é usar PSK Identity para escolher o cliente. O endereço continua como restrição independente; a prova da chave ocorre depois; a política RADIUS e o efeito no acesso continuam depois disso.

O nome chega antes da prova

O servidor precisa saber qual PSK testar. Por isso recebe primeiro a identidade, em claro, de um par ainda não autenticado. Qualquer origem que alcance o serviço pode inventar uma cadeia plausível. Um nome significativo ainda revela organização ou local; um identificador opaco, possivelmente em forma de Network Access Identifier, reduz a exposição, mas não vira segredo.

Encontrar uma linha prova apenas correspondência com configuração armazenada. Não prova posse da chave, origem permitida, autorização da mensagem nem identidade física do aparelho. Um painel que registra “cliente autenticado” no lookup transporta o antigo erro do IP para uma coluna nova.

A consulta começa com entrada hostil

A identidade pode conter UTF-8 inválido, NUL, metacaracteres para SQL, LDAP, REST ou shell, e até 65.535 octetos. Concatená-la em uma consulta transforma seleção de protocolo em injeção. O caminho seguro limita tamanho, classifica o namespace, valida a representação, aplica normalização versionada, escapa para a interface concreta e fecha a conexão em caso de falha.

Normalização não pode fundir duas identidades silenciosamente. O recibo deve guardar hash limitado da entrada bruta, resultado, forma canônica, versão da regra e ID da linha escolhida. Motivos de rejeição e geração do parser dão evidência sem espalhar conteúdo controlado pelo atacante pelos logs.

A unidade é a relação, não o equipamento

A tabela TLS-PSK pode associar faixas permitidas, identidade, PSK, credenciais alternativas e exigência de certificado. Depois do TLS, as regras do cliente RADIUS continuam ativas. A linha é um contrato bilateral entre cliente e servidor.

O mesmo aparelho pode manter relações diferentes com primário e contingência. O RFC 9813 exige suporte a identidade e PSK únicos por relação possível. Reutilizar continua sendo escolha local, mas amplia a autoridade simétrica: qualquer portador de uma chave compartilhada pode produzir a mesma prova, e revogar um cliente afeta os demais. O vazamento no lado cliente também pode permitir personificação do servidor, motivo para evitar PSK entre organizações sem relação.

O padrão exige a capacidade mínima de isolamento e deixa topologia e custo de rotação ao operador, uma divisão coerente com Minimum Initial Specification.

O endereço vira coordenada independente

Antes de examinar a identidade, o servidor rejeita conexões fora das faixas globais permitidas. Depois de escolher a relação, verifica a faixa específica daquele cliente. A primeira regra reduz exposição; a segunda pergunta se a relação pode surgir do local observado.

Dentro desses limites, várias identidades podem compartilhar um endereço NAT e uma identidade pode circular entre endereços. Aprovação da faixa prova localização observada. Aprovação do PSK prova posse de uma credencial simétrica. Juntas, estreitam a conclusão sem inventar certeza sobre pessoa ou hardware.

PSK TLS não é segredo compartilhado RADIUS

O PSK autentica o canal TLS. O segredo RADIUS participa das verificações do protocolo encapsulado. O RFC 9813 proíbe o mesmo valor nos dois papéis e requer que a configuração seja rejeitada. A mesma chave também não deve atravessar TLS 1.3 e versões anteriores. O RFC 9258 oferece importação vinculada a versão, KDF e contexto.

Interfaces precisam mostrar papéis e gerações separadamente, impedir igualdade sem registrar a chave e enumerar dependências. Um handshake verde não substitui a integridade RADIUS nem a autorização da solicitação.

Rotação termina quando a autoridade antiga termina

Como a identidade localiza o PSK, ambos mudam juntos. Uma rotação controlada cria nova geração, registra primeiro uso, limita a sobreposição, acompanha último uso da antiga e a desativa. Tentativas tardias tornam-se sinal de ação. Distribuição concluída não é encerramento; aposentadoria do identificador anterior é.

“Última vez visto” ajuda com clientes dormentes, mas silêncio pode significar retirada, falha, sazonalidade ou roubo. Invalidação automática precisa de proprietário, limiar, exceção e recuperação.

Retomada abre outro namespace

TLS 1.3 também usa PSKs e identidades de retomada criadas pela pilha TLS. Elas não são nomes estáticos. O RFC 9813 desaconselha retomada aqui. Quando necessária, tickets opacos e identidades administrativas ficam em tabelas distintas; valores desconhecidos fecham a conexão e colisões nunca atravessam namespaces.

Retomar não congela autorização. O servidor recupera identidade e política da negociação original, reavalia regras afetadas por nova origem e faz handshake completo se o cache não for confiável. Ticket e cache não devem exceder sete dias.

A sequência é o objeto de auditoria

Uma conexão aceita deve revelar faixa global, validação e normalização, geração exata da tabela, faixa da relação, versão TLS e KDF, prova do PSK, estado de retomada, verificações RADIUS, política local, ação do NAS e serviço observado. Cada etapa pode passar enquanto a seguinte falha.

Running-Code Primacy exige prova do parser, lookup e motor de política em execução, não apenas uma tela de configuração. On Reality Layers impede que o símbolo “identidade conhecida” fale pela criptografia e pelo resultado.

O RFC 9813 não coroou outro nome. Ele separou localização, seleção, prova, permissão e efeito. A governança deve conservar essas divisões no inventário e nos recibos.

Fontes