Resumo

  • RFC 3961 separou a chave-base do material específico de cada operação e exigiu que um número de uso não nulo contextualizasse criptografia e checksum.
  • No perfil simplificado, uso e constantes diferentes produziam Kc, Ke e Ki; o sucesso validava essa relação técnica, não a autorização nem a entrega do serviço.

Uma linha de auditoria diz que o texto foi descriptografado. Outra diz que a integridade passou. Falta a pergunta que RFC 3961 transformou em parte do cálculo: para qual operação aquela chave estava sendo usada?

O documento de 2005 criou um contrato entre Kerberos e mecanismos criptográficos. O perfil precisava definir formato de chave, conversão de senha e aleatoriedade, derivação, estado, cifragem, integridade e função pseudoaleatória. Um número etype identificava o perfil completo; não demonstrava suporte local, configuração, seleção ou resultado.

Essa separação retirou material do antigo RFC 1510. O posterior RFC 4120 substituiu aquela especificação do protocolo e tratou as operações criptográficas por meio do novo framework. Assim, aplicações não precisavam presumir que todo algoritmo tinha o mesmo IV, padding ou estrutura de chave.

Uma chave-base não era uma permissão genérica

O número de uso era um inteiro público de 32 bits, diferente de zero e atribuído pela especificação consumidora. A chave-base alimentava uma derivação; a chave específica executava a operação. No perfil simplificado, usage | 0x99 criava Kc para checksum, usage | 0xAA criava Ke para cifrar e usage | 0x55 criava Ki para integridade.

Esse desenho respondia a um problema real de composição. O RFC observou que programas podiam compartilhar chaves entre Kerberos v4 e v5, permitindo que uma função da versão antiga servisse de oráculo contra a nova. Confounders aleatórios reduziam a previsibilidade do texto; derivação por finalidade impedia que uma capacidade atravessasse contextos sem mudança. A fonte descreve a superfície de ataque, não um incidente medido.

Passar no HMAC era apenas uma etapa

A decifragem precisava verificar o HMAC e descartar dados inválidos. Quando passava, provava compatibilidade entre ciphertext, chave derivada, uso e etiqueta. Não provava sozinha o dono legítimo da chave-base, o uso normativo correto, a validade temporal do ticket, ausência de replay, autorização da aplicação ou serviço concluído.

RFC 6113 levou o framework à pré-autenticação geral, sem transformar pré-autenticação em autorização de negócio. A trilha completa precisa registrar tipo de mensagem, oferta e escolha de etype, referência não secreta da versão da chave, uso e cláusula que o atribui, hash do objeto, implementação, integridade, frescor, replay, ticket, autorização e resultado. A chave secreta não deve aparecer.

O vocabulário permaneceu enquanto os algoritmos mudaram

RFC 3962 definiu tipos AES no framework. RFC 4537 mostrou que tipos registrados, oferecidos e selecionados são estados diferentes. O registro IANA comprova atribuições, não adoção.

RFC 6649 desaconselhou DES simples e RFC 8429 atualizou RFC 3961 ao retirar outros algoritmos antigos. RFC 8009 manteve o framework, mas abandonou o perfil simplificado para autenticar o ciphertext antes da decifragem. A abstração sobreviveu à construção inicial.

A página do RFC Editor e o registro no Datatracker estabelecem a história documental. As erratas distinguem uma correção Unicode verificada, uma questão DES retida e uma proposta rejeitada. Esses estados não são prova de falha operacional.

RFC 3961 ensinou que “a chave funcionou” é uma frase incompleta. A evidência só ganha significado quando inclui o uso, o perfil e a mensagem. A autoridade para agir continua fora desse recibo criptográfico.

Fontes