Resumo

  • O RFC 1004 propôs um servidor Cookie Jar para conferir quais pares podiam se associar e emitir uma chave de sessão de uso único. A publicação de abril de 1987 era uma proposta para discussão.
  • Repetir a terceira mensagem da abertura poderia levar o destinatário a presumir uma associação nova; o iniciador rejeitaria a resposta, e repetições rápidas poderiam produzir sucessivos tempos de espera.

Dois gateways querem trocar informações de roteamento. O endereço de origem no pacote diz quem se apresenta, mas não identifica a mão que escreveu o envelope. O Exterior Gateway Protocol já exigia que vizinhos estabelecessem uma associação antes de conversar. Mills colocou um porteiro nessa hora. Chamou-o de Cookie Jar. O nome parece de cozinha; a função era decidir quem podia conversar e entregar a cada par um segredo temporário.

No RFC 1004, o cenário incluía EGP, o Dissimilar Gateway Protocol então proposto e protocolos distribuídos semelhantes. Mensagens podiam se perder, duplicar ou ser interceptadas, alteradas e reenviadas por um adversário. Cada usuário possuía endereço público e chave privada duradoura. Um diretório público listava os pares permitidos; o pote tinha uma tabela das chaves privadas e conferia essa lista. Se j constasse entre os parceiros autorizados de i, o servidor sorteava K(i,j), uma chave nova para aquela associação. Duas porções embaladas de modo diferente permitiam a i levar a parte de j durante a abertura, mantendo as chaves duradouras fora das mensagens trocadas entre gateways.

Quem segurava o pote segurava a lista de convidados e o molho de chaves. Ter conexão física com outro gateway ainda não bastava para entrar na associação. Depois da abertura, a chave compartilhada protegia a soma de verificação e o número de sequência das mensagens. Mills queria tornar falsificações e repetições reconhecíveis, enquanto os dados comuns continuavam visíveis no caminho. Ele examinou as ferramentas sem entusiasmo cerimonial. A soma de verificação de Internet tinha só 16 bits e fraquezas diante de trocas na ordem de palavras e bytes; DES aparecia como escolha natural da época, também sujeita a revisão.

Um pote de vidro bonito não torna o cadeado mais forte.

O problema mais divertido começava com um ato trivial: recomeçar. Um novo Request apagava o estado da associação anterior. Mills perguntou o que aconteceria se alguém repetisse a terceira mensagem, a que iniciava a relação do lado de j. O destinatário poderia achar que uma associação nova estava começando e responder. O iniciador i rejeitaria a resposta porque o número de sequência não batia. Uma repetição isolada dificilmente criaria uma conversa não autorizada; uma rajada de pedidos antigos poderia forçar j a reiniciar, esperar e chegar ao tempo limite repetidas vezes. O intruso nem precisava entrar.

Bastava tocar a campainha até todos se atrasarem.

Havia a opção de acrescentar uma pergunta e resposta extras, formando um cumprimento em três passos. Mills calculou o custo e a deixou de lado: um atacante insistente ainda poderia obrigar os pares a gastar recursos nesse trabalho. O texto descreve também uma corrida sem atacante. Se os dois vizinhos pedissem autenticação ao mesmo tempo, os Requests cruzados poderiam redefinir chaves até que tempos de espera desencontrados rompessem o impasse. A renovação periódica de chaves e o comportamento das esperas eram parte da mecânica diária.

Esse RFC convidava a comunidade a discutir uma proposta. Sua imagem histórica é poderosa porque mostra, na mesma porta, a autoridade para admitir alguém e a chance de paralisar a entrada. O pote distribuía chaves frescas. O velho biscoito, servido outra vez, podia consumir a tarde dos gateways.