Resumo

  • O RFC 5349 permite que um KDC rejeite os parâmetros ECDH do cliente e devolva TD-DH-PARAMETERS em ordem de preferência. Como o erro Kerberos que carrega a lista não tem proteção de integridade, a resposta pode orientar uma nova tentativa, mas não ampliar a política local.
  • O requisito de suporte a P-256 e P-384 é um piso de capacidade do documento, não prova de que uma curva esteja habilitada, permitida, selecionada, validada ou executada numa implantação.
  • Certificado válido, ponto público válido, segredo compartilhado derivado, tíquete Kerberos emitido e ação de aplicação autorizada são recibos distintos. A reutilização de uma chave ECDH de longo prazo torna a validação de cada ponto ainda mais crítica.

O quadro de equivalência não é uma planilha de custo total

O texto compara tamanhos de chaves com base na orientação histórica citada e usa P-256 como exemplo para uma meta de segurança simétrica de 128 bits. A comparação ajuda a entender a escolha de projeto em 2008.

Ela não inclui emissão e renovação de certificados, módulos criptográficos, suporte de bibliotecas, testes de curvas, resistência a canais laterais, inventário de chaves, telemetria, treinamento ou tempo de substituição. Esses custos aparecem no sistema implantado, não no comprimento da chave.

Uma representação menor pode economizar tráfego, armazenamento e algum processamento. Ao mesmo tempo, a adoção pode introduzir novos identificadores de algoritmo, analisadores, políticas de curva, caminhos de negociação e modos de falha.

Por isso, a liderança não deve converter uma tabela histórica de força em uma decisão contemporânea de aquisição. A política atual precisa de padrões atuais, medições da plataforma e uma avaliação atual da ameaça.

A lista do KDC é entrada, não política

Quando o cliente envia parâmetros que o KDC não aceita, a resposta pode trazer KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED e uma lista ordenada de alternativas. O cliente escolhe e tenta novamente.

O problema de autoridade está no transporte: a mensagem de erro não é protegida por integridade. Um intermediário pode remover ou reordenar opções. Se o cliente simplesmente adotar o primeiro item que sua biblioteca entende, a mensagem remota passa a escrever política local.

O cliente precisa começar com seu próprio conjunto autorizado e calcular a interseção com a lista recebida. A lista pode reduzir candidatos; não pode criar uma permissão. Interseção vazia deve encerrar a tentativa.

O KDC enfrenta a mesma distinção. Uma curva presente no código não está automaticamente aprovada para uso. Capacidade, configuração, permissão e execução têm provas diferentes.

Sucesso posterior não autentica a mensagem anterior

Um atacante pode excluir a opção mutuamente preferida e deixar uma segunda curva ainda aceita pela política do cliente. A nova tentativa pode terminar com uma troca criptográfica válida e um tíquete.

Esse resultado mostra que houve uma opção aceitável na interseção restante. Não mostra que a lista era autêntica nem que a ordem representava a preferência real do KDC.

Há, portanto, duas perguntas de auditoria. O parâmetro final era permitido e foi executado corretamente? O caminho de negociação preservou a origem e a prioridade declarada pelo KDC? A primeira resposta pode ser positiva enquanto a segunda permanece desconhecida.

Guardar apenas a curva final apaga essa diferença. É preciso reter proposta original, erro, ordem recebida, política vigente, interseção, seleção e resultado da repetição.

Ordem também é dado de controle

Uma coleção sem ordem não representa TD-DH-PARAMETERS. Duas listas com os mesmos membros podem expressar preferências diferentes e produzir resultados diferentes.

A trilha deve preservar a lista bruta separadamente da lista filtrada pela política. Se o sistema substitui a entrada pelo resultado do filtro, deixa de mostrar o que tentou influenciar a decisão.

Também é necessário fixar a versão da política. Ler a configuração atual depois de uma mudança não reconstrói o conjunto que existia durante a tentativa.

Com esses elementos, a investigação consegue diferenciar uma alteração de preferência que permaneceu dentro do limite seguro de uma execução que atravessou o limite autorizado.

O certificado não valida o objeto matemático sozinho

O RFC 5349 coloca certificados ECC e assinaturas nas estruturas PKINIT e CMS existentes. A validação X.509 examina cadeia, emissores, nomes, restrições, validade e assinaturas.

O ponto público usado no ECDH ainda precisa ser verificado como ponto válido na curva correta. Um contêiner assinado não transforma qualquer sequência de bits analisável em entrada segura para multiplicação escalar.

São perguntas diferentes: quem emitiu o certificado e para que ele vale; qual algoritmo foi codificado; se a assinatura confere; e se o ponto pertence ao grupo matemático esperado.

Um único indicador “certificado válido” torna invisível a última verificação. Registros operacionais devem mostrar cada etapa e se uma entrada rejeitada alcançou ou não a operação com a chave privada.

Chave duradoura muda a escala do defeito

O RFC 5349 alerta que, diante de uma chave privada ECDH de longo prazo, aceitar um ponto que não seja válido na curva correta pode revelar informações sobre essa chave. Ataques repetidos podem acabar expondo-a por inteiro.

A gravidade depende da vida da chave, do número de entradas hostis que conseguem alcançá-la e da observabilidade das respostas. Uma única linha de autenticação bem-sucedida não descreve essa superfície acumulada.

Limitação de taxa pode reduzir tentativas, mas não substitui validação. Rotação frequente reduz a janela, mas não torna seguro usar pontos inválidos. A rejeição precisa ocorrer antes do cálculo privado.

Cada tentativa deve vincular origem, curva, resultado da validação, identidade e idade da chave, motivo de rejeição, contagem de reutilizações e comportamento de resposta.

Os nonces delimitam a reutilização

O mecanismo de RFC 4556, mantido por RFC 5349, usa clientDHNonce e serverDHNonce para que cliente e KDC autorizem reutilização de chaves. Isso não é uma licença geral para manter o mesmo valor privado por conveniência.

Os nonces fazem parte do contexto de consentimento. Se a operação guarda apenas o segredo derivado ou o tíquete, perde a evidência de qual lado permitiu a reutilização e sob quais condições.

Reutilizar pode economizar cálculo e latência. Também aumenta o número de entradas que interagem com uma única chave privada e amplia o efeito de qualquer desvio na validação de pontos.

O registro deve ligar nonces, decisão de política, par de chaves, período de uso, contagem de operações, rejeições e descarte final. “ECDH concluído” não responde a essas questões.

Suporte obrigatório é só o primeiro estado

P-256 e P-384 são exigências de suporte do RFC 5349 para implementações conformes. O documento cria uma base comum de interoperabilidade.

Não prova que as curvas estejam habilitadas em determinada instalação, que apareçam na proposta, passem pela política, sejam devolvidas pelo KDC, selecionadas na nova tentativa, validadas ou efetivamente usadas. O mesmo limite vale para o suporte histórico a ecdsa-with-Sha256.

Um inventário sério separa implementado, configurado, oferecido, recebido, permitido, selecionado, validado e executado. A documentação do produto só sustenta o primeiro estado.

Misturar os estados produz confiança sem observação: uma organização acredita conhecer seu uso de criptografia quando conhece apenas a lista de recursos possíveis.

Curva comum troca atrito por concentração

Curvas nomeadas usam um identificador comum, tornam a codificação compacta e facilitam que implementações concordem sobre os parâmetros. As estruturas de RFC 4556 também comportam parâmetros explícitos para curvas personalizadas.

Uma curva amplamente compartilhada simplifica certificados, testes e hardware. Em contrapartida, muitas chaves passam a depender da mesma hipótese e do mesmo caminho de implementação. Uma fraqueza futura pode atingir um conjunto grande de uma vez.

Diversidade não é automaticamente segura. Mais curvas significam mais código, combinações, configurações e superfícies de rebaixamento. A decisão precisa comparar risco de concentração com complexidade real.

Número de chaves, diversidade de bibliotecas, cobertura de validação, dependências de hardware, tempo de substituição e negociações observadas são melhores indicadores que a quantidade de nomes suportados.

Parâmetros no certificado transferem a custódia

Certificados ECC podem fornecer os parâmetros ECDH e evitar uma configuração separada. Isso reduz um ponto de preparação, mas não elimina a autoridade sobre a escolha.

Ela passa para emissão do certificado, validação do caminho, restrições de algoritmo, análise da chave e política local. Um parâmetro não se autoriza sozinho por estar dentro de um certificado assinado.

O sistema deve registrar a proveniência: configuração explícita, certificado atual, erro do KDC ou outro mecanismo. Sem isso, menos arquivos podem parecer menos governança quando apenas mudaram o local da governança.

A pergunta operacional é quem pode mudar o parâmetro agora, que revisão essa mudança exige e quanto tempo leva para revogá-la ou substituí-la.

O segredo compartilhado é um recibo limitado

Depois da aceitação, as partes calculam um ponto elíptico; a coordenada x é convertida em cadeia de octetos e usada como DHSharedSecret no fluxo de RFC 4556.

O cálculo comprova que surgiu o insumo criptográfico da fase seguinte. Não prova sozinho identidade organizacional completa, emissão de tíquete, obtenção de tíquete de serviço, autorização de aplicação nem conclusão da ação.

Cada estágio pode recusar o resultado do anterior. Promover acordo criptográfico a autoridade de negócio elimina decisões que pertencem ao Kerberos, ao serviço e à aplicação.

O RFC 5349 foi publicado como Informational em setembro de 2008 e afirma não alterar sintaxe ou semântica das mensagens de RFC 4556. A pesquisa de erratas capturada não exibiu registros para o documento; isso é uma observação datada, não garantia de implementação.