Resumo

  • A RFC 3129 propôs usar chaves de sessão de tickets Kerberos como base para chaves de associações de segurança IPsec, reduzindo segredos duradouros entre cada par.
  • KINK não seria substituto do IKE: centralização e economia computacional vinham acompanhadas da dependência de um terceiro confiável ativo.
  • A complexidade migrava para disponibilidade do KDC, realms, relógios e nomes, enquanto autorização de túneis e seletores continuava em cada par.

O número mais esclarecedor da RFC 3129 não media tamanho de chave. Media relações. Num conjunto em que cada dupla de pares IPsec recebe um segredo pré-compartilhado distinto, a distribuição foi descrita como O(n²). Num realm Kerberos, cada principal mantém uma relação de longo prazo com o Centro de Distribuição de Chaves, e o KDC entrega tickets com chaves de sessão para serviços. Na comparação simplificada do documento, o conjunto de segredos duradouros torna-se O(n).

Essa conta não inclui todo o custo de operar Kerberos. Ela serve para mostrar que uma arquitetura pode fracassar por excesso de vínculos administrativos sem que nenhum algoritmo seja quebrado. Chaves precisam ser cadastradas, entregues, rotacionadas, revogadas e explicadas depois de um incidente.

O IPsec já separava proteção e negociação. A RFC 2401 tratava de associações de segurança, AH e ESP. A RFC 2409 definia IKE, no qual dois pares se autenticavam, negociavam parâmetros e derivavam material criptográfico. Sua autonomia tinha valor: os pares podiam agir sem uma autoridade central participando naquele momento.

Essa autonomia espalhava o trabalho. Certificados X.509 exigiam cadeia de confiança, assinatura e verificação. Diffie–Hellman impunha cálculo e podia aumentar a superfície de negação de serviço do respondente. Segredos pré-compartilhados fugiam desses mecanismos, mas restauravam a malha de distribuição. A política da organização também precisava chegar a equipamentos cuja configuração e confiabilidade podiam divergir.

Kerberos oferecia outra topologia. Conforme a RFC 1510, o cliente autenticava-se perante o KDC, obtinha um ticket de serviço e recebia uma chave de sessão. O serviço abria o ticket e obtinha a mesma chave. KINK, Kerberized Internet Negotiation of Keys, deveria usar essa chave como base do material das SAs IPsec.

Não era apenas um handshake diferente. O segredo permanente podia ligar principal e KDC, não todos os pares entre si. Quando PKINIT fosse usado, o custo da autenticação pública inicial poderia ser amortizado por tickets destinados a vários serviços. Parte da política poderia ser administrada numa autoridade controlada pelo realm, em vez de depender apenas de cada ponta interpretar e obedecer à intenção do site.

A RFC 3129 recusou chamar isso de substituição. Ela registrou que KINK não substituía IKE. IKE conseguia autenticar dois pares e trocar chaves sem a participação ativa de um terceiro. KINK não preservava essa propriedade. O modelo só fazia sentido onde já existisse um terceiro confiável e sua intervenção fosse desejável.

Portanto, centralizar era escolher uma área de falha. O KDC diminuía a provisão par a par e certas operações de chave pública nos servidores. Ao mesmo tempo, emissão de tickets, nomes de principals, confiança entre realms, tempo e início de novas relações passavam a depender de uma instituição comum.

Os requisitos tentavam impedir que o centro participasse de tudo. Qualquer par IPsec precisava iniciar a negociação, fosse ele um cliente Kerberos com TGT ou um serviço com keytab. O modo user-to-user atenderia ao respondente incapaz de abrir um ticket de serviço convencional. Havia requisitos para múltiplos realms, autenticação inicial simétrica ou pública e tratamento de diferença absoluta de relógio.

O rekey expõe melhor essa limitação consciente. Enquanto o ticket de sessão permanecesse válido, as pontas deveriam renovar chaves sem ajuda do KDC. O centro não ficaria no caminho dos pacotes e não aprovaria cada atualização. Ele emitia material compartilhado com prazo definido; durante esse prazo, os pares podiam continuar.

Ainda sobrava muito para eles. KINK deveria criar, modificar, renovar e apagar SAs, negociar cifras e seletores, atender transporte e túnel, AH e ESP, IPv4 e IPv6. A identidade confirmada pelo Kerberos não concedia automaticamente o direito de representar um prefixo. A política IPsec local continuava decidindo a autorização.

Confundir autenticação com autorização é um risco estrutural. Um ticket válido diz quem apresentou a credencial e fornece uma chave compartilhada. Não diz sozinho que esse principal pode abrir um túnel para determinada rede. Se a regra local ligar uma identidade verdadeira a um seletor amplo demais, a autoridade central apenas torna o erro mais convincente.

Também é essencial não tratar a RFC 3129 como protocolo pronto. Ela era Informational e apresentava requisitos. A RFC 4430, de 2006, especificou KINK como Proposed Standard e citou 3129 como base. A primeira publicação definiu o problema; a segunda descreveu interoperabilidade. Nenhuma demonstra adoção ampla ou substituição de IKE.

Outros padrões avançaram. A RFC 4120 atualizou Kerberos V5; a RFC 3961 organizou sua estrutura de criptografia e checksums; a RFC 4556 padronizou PKINIT; a RFC 6113 generalizou pré-autenticação. IKE tornou-se IKEv2 na RFC 4306 e depois foi consolidado na RFC 7296. A Internet manteve arquiteturas concorrentes porque cada uma aceitava falhas diferentes.

O contraste O(n) e O(n²) deve ficar dentro de sua hipótese. KDC reduz segredos bilaterais de longo prazo, mas não elimina proteção de chaves mestras, rotação de keytabs, backup, confiança cruzada, sincronização, auditoria e capacidade. Troca muitas obrigações pequenas por poucas obrigações sistêmicas.

Uma pane mostra a gradação. SAs instaladas podem continuar, e tickets válidos podem permitir rekey local. Novas credenciais, tickets vencidos e relações ainda não iniciadas podem falhar. O limite não é “KDC fora, IPsec fora”; depende da duração de ticket e SA, do cache e do próximo ponto de contato.

Uma invasão altera a escala. Logs centrais ajudam a ligar principal, ticket e instante. Um KDC comprometido, porém, pode emitir confiança plausível para muitos serviços. A mesma centralização que melhora a governança amplia a consequência de um erro na autoridade.

As considerações de segurança da RFC 3129 foram diretas: as SAs criadas herdariam a união das fragilidades de IPsec e Kerberos. Compor protocolos maduros não cancela seus defeitos e pode criar uma fraqueza na fronteira entre eles.

O documento pertence à história da Internet por reconhecer que administração faz parte da criptografia. A pergunta não era somente se duas máquinas chegavam à mesma chave. Era quem conhecia quem, onde a política vivia, quais cálculos se repetiam e que instituição tornava a rede governável.

O KDC não eliminou confiança; tornou-a reutilizável, auditável e concentrada. Isso podia ser uma grande vantagem operacional e um risco compartilhado por muitos pares. RFC 3129 registrou os dois lados antes de declarar o protocolo concluído.

Fontes