Resumo

  • draft-ietf-kitten-sasl-ht-02 define uma família SASL de duas mensagens para reautenticação rápida com tokens compartilhados, curtos e exclusivamente efêmeros.
  • A revisão 02 é um Internet-Draft ativo do grupo KITTEN, em Working Group Last Call, destinado a Proposed Standard e com expiração em 24 de dezembro de 2026. Não é RFC nem relato de implementação.
  • Um HMAC válido prova posse sob o mecanismo, o token e o dado de channel binding usados. Não prova que o privilégio existente na emissão ainda vale, que a revogação convergiu, que a sessão correta voltou ou que uma ação foi autorizada.
  • A operação precisa separar emissão, mecanismo fixado, vínculo TLS, prova iniciadora, prova respondente, reserva contra repetição, consumo, política atual, geração de sessão e resultado observado.

Validade criptográfica e validade institucional usam relógios diferentes

SASL-HT parte de uma sequência razoável. O cliente realiza antes uma autenticação forte, pede um token, perde a conexão e usa esse segredo para se reautenticar em um único round trip. O serviço evita repetir uma cerimônia cara sem transformar o token em senha permanente.

O token pode continuar dentro do prazo enquanto a organização muda. A conta pode ser suspensa, um papel pode ser removido, um projeto pode fechar ou uma sessão privilegiada pode ser encerrada. Nenhuma dessas decisões altera retroativamente o HMAC. Se o verificador tratar validade do token como autorização atual, uma otimização de continuidade vira uma cópia atrasada da política.

O recibo de emissão deve, portanto, guardar a autenticação anterior, sujeito, serviço, mecanismo pretendido, época, prazo, limite de uso e linhagem da sessão. No uso, a plataforma verifica posse e depois consulta a autoridade de autorização atual. O segundo passo pode dizer não sem contradizer o primeiro.

Essa separação também protege a análise de incidentes. “Token válido, acesso negado” pode ser comportamento correto após mudança de papel. “Token expirado” pode ser um relógio divergente. “Token já usado” pode indicar repetição, retry ambíguo ou replicação tardia. Um único erro genérico não explica a causa.

Curta duração exige uma definição operacional

O rascunho exige token recém-gerado por fonte criptograficamente segura e pelo menos 128 bits de entropia. Recomenda vida limitada por tempo ou contagem de usos, além de retorno periódico a uma autenticação forte sem HT.

Entropia reduz a chance de adivinhação. Não define qual relógio marca nascimento e expiração, onde vive o contador ou como regiões discordantes resolvem consumo. Uma política de dez minutos não é uma propriedade do segredo; é uma decisão aplicada por nós que precisam compartilhar tempo e estado.

O exemplo do documento mostra o serviço revogando o token depois de uso bem-sucedido. A extensão é recomendada a oferecer rotação ou revogação. Ainda assim, o sucesso do HMAC não contém a confirmação dessa escrita. Para afirmar uso único, o operador deve demonstrar reserva, commit e alcance de convergência.

Reservar antes da resposta evita duas aceitações, mas pode inutilizar o token se a resposta se perder. Consumir depois cria uma janela em que outro nó pode aceitar. O desenho deve declarar o comportamento de retry e o custo da operação posterior. Não existe semântica universal escondida na palavra “efêmero”.

Dois HMACs não formam uma decisão de acesso

A mensagem iniciadora inclui authcid, valores opcionais e um HMAC sobre a cadeia Initiator, o dado de channel binding e esses valores. O respondedor recalcula e compara. Correspondência autentica o iniciador; diferença exige falha.

Depois, a resposta de sucesso inclui valores do servidor e um HMAC separado com a cadeia Responder. O cliente deve verificar essa mensagem para alcançar autenticação mútua. Um log do servidor que registra apenas a primeira comparação não prova que o cliente autenticou o par.

Mesmo quando as duas direções terminam, o rascunho declara que HT não carrega uma identidade de autorização e não protege uma. Também não oferece uma camada de segurança SASL; oferece channel binding. O mapeamento de authcid para direitos e operação permitida pertence à aplicação.

Isso significa que a operação precisa de eventos distintos: prova do iniciador, prova do respondedor, autorização atual e resultado. A palavra success sem um proprietário e uma etapa é inadequada.

O tipo de channel binding não pode desaparecer

Os nomes HT combinam hash com ENDP, UNIQ, EXPR ou NONE. Os três primeiros selecionam entradas TLS específicas. NONE usa dado vazio. Um HMAC correto com NONE não prova exporter binding ou qualquer vínculo que não entrou no cálculo.

Uma política que exige EXPR deve rejeitar ou classificar separadamente NONE. Guardar apenas “HT aprovado” impede a auditoria. O recibo precisa do nome completo do mecanismo, identidade TLS, tipo de vínculo, digest seguro do dado ou ausência explícita.

O rascunho recomenda ainda que a extensão permita fixar o mecanismo no momento da emissão. Uso com mecanismo diferente deve falhar. Esse controle só existe se a fixação estiver armazenada e replicada junto do token. Um nó que conhece apenas o segredo consegue verificar matemática sem conhecer a política de downgrade.

Valores protegidos ainda passam por política

As duas mensagens aceitam pares chave/valor autenticados pelo HMAC. A integridade é útil para contexto, negociação e hashes de proteção contra downgrade. Mas ela não cria esquema, significado nem autoridade.

Um cliente pode enviar autenticamente uma geração de sessão antiga ou pedir uma opção que não lhe é permitida. O servidor deve validar chave, tipo, versão, conflito, tamanho e permissão. A resposta também não ganha autoridade ilimitada só porque seu valor foi autenticado pelo servidor.

O registro necessário contém o digest dos octetos, a versão de esquema, a regra de admissão, a decisão e a alteração resultante. Assim, “foi dito pelo portador do token” não vira “era verdade” ou “deveria ser executado”.

Early data separa autenticação de ação

O iniciador pode enviar sua mensagem em TLS 1.3 0-RTT. Nesse caso, não pode incluir payload de aplicação além do framing necessário; o respondedor deve abortar SASL se houver carga extra. O motivo é o risco de replay.

A regra protege a fronteira: reavaliar uma prova idempotente não autoriza repetir uma compra, remoção ou mudança de configuração. Antes de aceitar trabalho não idempotente, o servidor precisa resolver replay, reservar o uso, aplicar autorização atual e sair da zona de early data.

O caminho de meio round trip melhora ordem e latência. Não prova execução exatamente uma vez. O cliente ainda verifica o HMAC respondente; a aplicação ainda interpreta valores; o estado ainda precisa ser retomado.

Retomar identidade não é restaurar memória

O token não contém por padrão cursor, fila, versão de documento, lock ou transação. A aplicação decide o que significa “sessão anterior” e precisa nomear ID, geração predecessora, conflito e estado resultante.

Um token válido pode encontrar uma sessão apagada, uma geração substituída ou um estado em outra região. O serviço pode criar nova sessão, negar ou pedir autenticação completa. Nenhuma opção invalida a prova de posse; elas respondem a uma pergunta posterior.

O recibo final liga token record não secreto, emissão, mecanismo, TLS, ambas as mensagens, uso e revogação, policy version, geração escolhida, operação e observação. Não se deve registrar token bruto, exporter reutilizável ou autenticador que aumente o risco.

O vocabulário precisa permanecer estreito: “posse comprovada”, “autenticação mútua concluída”, “uso consumido neste escopo”, “política atual autorizou”, “sessão geração X restaurada”, “resultado Y observado”. Cada frase exige sua própria prova.

Fontes