LIMITAÇÕES DO SISTEMA DE AUTENTICAÇÃO KERBEROS

ABSTRACT

O sistema de auten cação Kerberos, parte do Projeto Athena do MIT, foi adotado por outras organizações.
Apesar das muitas vantagens do Kerberos, ele possui algumas limitações e fraquezas. Algumas delas decorrem das
caracterís cas específicas do ambiente do MIT; outras representam deficiências no design do protocolo. Discu mos
vários desses problemas e apresentamos soluções para alguns deles. Também demonstramos como hardware
criptográfico específico pode ser necessário em alguns casos.

INTRODUÇÃO

O sistema de auten cação Kerberos [Stei88, Mill87, Brya88] foi introduzido pelo MIT para atender às
necessidades do Projeto Athena. Desde então, foi adotado por várias outras organizações para seus próprios propósitos
e está sendo discu do como um possível padrão. Em nossa opinião, ambas essas decisões podem ser prematuras. O
Kerberos possui várias limitações e fraquezas; uma decisão de adotá-lo ou rejeitá-lo não pode ser tomada
adequadamente sem considerar essas questões. (Uma limitação é uma caracterís ca que não é tão geral quanto
desejado, enquanto uma fraqueza poderia ser explorada por um atacante para derrotar o mecanismo de auten cação.)
Algumas melhorias podem ser feitas dentro do design atual. O suporte a mecanismos opcionais ampliaria a
aplicabilidade do Kerberos para ambientes radicalmente diferentes do MIT. Esses problemas se enquadram em várias
categorias. Alguns derivam do ambiente do Projeto Athena. O Kerberos foi projetado para esse ambiente; se as
suposições básicas forem diferentes, o sistema de auten cação também pode precisar ser alterado. Outros problemas
são simplesmente deficiências no design do protocolo. Alguns deles são corrigidos na proposta Versão 5 do Kerberos
[Kohl89], mas nem todos. Mesmo os problemas resolvidos merecem discussão, pois o código da Versão 4 foi
amplamente disseminado. Finalmente, alguns problemas com o Kerberos não são solucionáveis sem o uso de
hardware específico, independentemente do design do protocolo. Vamos considerar cada uma dessas áreas em
sequência. Queremos enfa zar que não estamos sugerindo que o Kerberos seja inú l. Pelo contrário, um atacante
capaz de realizar qualquer um dos ataques listados aqui poderia penetrar em uma rede pica de sistemas UNIX com
muito mais facilidade. Adicionar o Kerberos a uma rede aumentará significa vamente sua segurança em pra camente
todas as circunstâncias; nossas crí cas estão focadas na medida em que a segurança é aprimorada. Além disso,
recomendamos alterações nos protocolos que aumentam substancialmente a segurança. Além de sua u lidade
específica em produção, o Kerberos desempenha uma função importante ao focar o interesse em soluções prá cas
para o problema de auten cação de rede. O elegante design do protocolo e a ampla disponibilidade do código
ca varam uma ampla audiência. Longe de ser uma condenação, nossa crí ca tem o obje vo de contribuir para a
compreensão das propriedades do Kerberos e influenciar sua evolução para uma ferramenta de maior poder e
u lidade.

Vários dos problemas que destacamos são mencionados no ar go original do Kerberos ou em outros lugares
[Davi90]. Para alguns desses problemas, apresentamos melhorias no protocolo que resolvem, ou pelo menos mi gam,
o problema; para outros, os colocamos diretamente no contexto do ambiente pretendido do Kerberos.

Versão 5, Rascunho 3

Desde a redação deste ar go, um novo rascunho do Protocolo Versão 5 foi lançado, e uma especificação final
está prome da [Kohl90]. Muitos dos problemas que discu mos aqui foram corrigidos. Outros permanecem, e
encontramos alguns novos. A resolução final dessas questões é incerta enquanto este documento está sendo
elaborado. Consequentemente, uma breve análise do Rascunho 3 é apresentada em um apêndice, em vez de no corpo
principal do documento.
 Foco na Segurança

O Kerberos é um sistema de segurança; assim, embora abordemos questões de funcionalidade e eficiência,

nossa ênfase primária é na segurança do Kerberos em um ambiente geral. Isso significa que as suposições crí cas de
segurança devem ser poucas em número e claramente declaradas. Para a maior u lidade, a rede deve ser considerada
completamente aberta. Especificamente, os protocolos devem ser seguros mesmo se a rede es ver sob completo
controle de um adversário. Isso significa que derrotar o protocolo deve exigir que o adversário inverta o algoritmo de
criptografia ou subverta um principal especificamente considerado confiável. Somente esse obje vo de design robusto
pode jus ficar os custos da criptografia. (Nada de "portas de aço em paredes de papel".) Acreditamos que o Kerberos
pode a ngir esse ambicioso obje vo com apenas pequenas modificações, mantendo seu caráter essencial.

Algumas de nossas sugestões implicam em uma penalidade de desempenho; outras complicam o design das
melhorias sugeridas. À medida que mais organizações u lizam o Kerberos, as pressões para aprimorar ou aumentar
sua funcionalidade e eficiência aumentarão. A segurança tem custos reais, e os bene cios são intangíveis. Deve haver
ênfase con nua e explícita na segurança como o requisito primordial.

Validação

Não é suficiente projetar e implementar um sistema de segurança. Tais sistemas, embora aparentemente
adequados quando projetados, podem ter falhas graves. Portanto, os sistemas devem ser subme dos à maior
escru nio possível. Uma consequência disso é que eles devem ser projetados e implementados de maneira a facilitar
tal escru nio. O Kerberos também enfrenta vários problemas nessa área.

O QUE É UM KERBEROS?

Antes de discu r áreas específicas de problema, é ú l revisar o Kerberos Versão 4. O Kerberos é um sistema
de auten cação; ele fornece evidências da iden dade de um principal. Um principal é geralmente um usuário ou um
serviço específico em alguma máquina. Um principal consiste na tríade <nomeprimário, instância, reino>.

Se o principal for um usuário - uma pessoa real - o nome primário é o iden ficador de login, e a instância é
nula ou representa atributos específicos do usuário, ou seja, root. Para um serviço, o nome do serviço é usado como
nome primário e o nome da máquina é usado como instância, por exemplo, rlogin.myhost. O reino é usado para
dis nguir entre diferentes domínios de auten cação; assim, não é necessário ter um único e universalmente confiável
banco de dados Kerberos servindo uma empresa inteira.

Tabela 1: Nota on

c client principal
s server principal
tgs cket-gran ng server
Kx private key of ‘‘x’’
Kc,s session key for ‘‘c’’ and ‘‘s’’
{in f o }Kx ‘‘in f o’’ encrypted in key K x
{Tc,s }Ks Encrypted cket for ‘‘c’’ to use ‘‘s’’
{Ac }Kc,s Encrypted authen cator for ‘‘c’’ to use ‘‘s’’
addr client’s IP address

Kerberos principals podem obter ckets para serviços de um servidor especial conhecido como o servidor de
concessão de ckets, ou TGS. Um cket contém diversas informações iden ficando o principal, criptografado na chave
privada do serviço. (A notação está resumida na Tabela 1.)

{Tc,s }Ks = {s, c, addr, mestamp, life me, Kc,s }Ks

 Como apenas o Kerberos e o serviço compar lham a chave privada Ks, o cket é reconhecido como autên co.
O cket contém uma nova chave de sessão privada, Kc,s, também conhecida pelo cliente; essa chave pode ser usada
para criptografar transações durante a sessão.

Para se proteger contra ataques de repe ção, todos os ckets apresentados são acompanhados por um
auten cador:

{Ac }Kc,s = {c, addr, mestamp}Kc,s

Isso é uma breve sequência criptografada na chave de sessão e contendo um carimbo de data/hora; se o tempo
não corresponder ao horário atual dentro dos limites de desvio de relógio (predeterminados), a solicitação é
considerada fraudulenta.

Para serviços nos quais o cliente precisa de auten cação bidirecional, o servidor pode responder com:

{ mestamp + 1}Kc,s

Isso demonstra que o servidor foi capaz de ler o carimbo de data/hora do auten cador e, portanto, que
conhecia Kc,s; por sua vez, essa informação só está disponível no cket, que é criptografado na chave privada do
servidor.

Os ckets são ob dos do TGS ao enviar uma solicitação:

s, {Tc,tgs }Ktgs , {Ac }K c,tgs

Em outras palavras, é usado um par comum de cket/auten cador; o cket é conhecido como o cket-gran ng
cket. O TGS responde com um cket para o servidor s e uma cópia de Kc,s, ambos criptografados com uma chave
privada compar lhada pelo TGS e pelo principal:

{ {Tc,s }Ks ,Kc,s }Kc,tgs

A chave de sessão Kc,s é uma chave aleatória recém-escolhida.

A chave Kc,tgs e o cket-gran ng cket em si são ob dos no início da sessão. O cliente envia uma mensagem
para o Kerberos com um nome principal; o Kerberos responde com:

{Kc,tgs ,{Tc,tgs }Ktgs }Kc

A chave do cliente Kc é derivada de uma transformação não inver vel da senha digitada pelo usuário. Assim,
todos os privilégios dependem, em úl ma instância, desta única chave.

Observação: os servidores devem possuir chaves privadas próprias para descriptografar ckets. Essas chaves
são armazenadas em um local seguro na máquina do servidor.

O AMBIENTE DO KERBEROS

O ambiente de computação do Projeto Athena consiste em um grande número de estações de trabalho mais
ou menos anônimas e um número menor de máquinas servidoras autônomas. Os servidores fornecem
armazenamento volá l de arquivos, spool de impressão, caixas de correio e talvez algum poder computacional; as
estações de trabalho são usadas para a maioria das interações e computações. Geralmente, elas possuem discos locais,
mas esses discos são efe vamente de leitura apenas; eles não contêm dados de usuário de longo prazo. Além disso,
eles não são fisicamente seguros; alguém inclinado poderia remover, ler ou alterar qualquer parte do disco sem
impedimentos.

Dentro desse ambiente, a necessidade primária é a auten cação do usuário para o servidor. Ou seja, quando
um usuário se senta em uma estação de trabalho, essa pessoa precisa de acesso a arquivos privados em um servidor.
A estação de trabalho em si não possui esses arquivos e, portanto, não precisa entrar em contato com o servidor ou
mesmo se iden ficar.
 Isso contrasta marcadamente com a visão pica de um sistema UNIX. Tais sistemas têm uma iden dade e
possuem arquivos. Vários daemons de rede transferem arquivos em segundo plano, daemons de relógio realizam
funções de gerenciamento, e-mails e no cias eletrônicas chegam, etc. Se uma máquina dessas dependesse de
servidores para armazenar seus arquivos, ela teria que afirmar e possivelmente provar uma iden dade ao falar com
esses servidores. As estações de trabalho do Projeto Athena não são capazes nem necessitam disso; elas funcionam,
na verdade, como terminais muito inteligentes com considerável capacidade de computação local, em vez de sistemas
de computadores completos.

O que isso significa para o Kerberos? Simplesmente isso: o Kerberos é projetado para auten car o usuário final
- a pessoa sentada no teclado - para um certo número de servidores. Não é um sistema peer-to-peer; não é des nado
a ser usado por um computer´s daemons quando contactando outro computador. Tentar usar o Kerberos nesse modo
pode causar problemas.

Fazemos essa declaração por várias razões. Em primeiro lugar, os sistemas de computadores picos não têm
uma área segura de armazenamento de chaves. No Kerberos, uma chave em texto simples deve ser usada no diálogo
inicial para obter um cket-gran ng cket. Mas armazenar chaves em texto simples em uma máquina geralmente é
considerado uma má ideia;[Morr79] se uma chave Kerberos que uma máquina usa para si mesma for comprome da,
o invasor provavelmente pode se passar por qualquer usuário nesse computador, ao se passar por solicitações
auten cadas por essa máquina (ou seja, montagens de arquivos ou tarefas cron).5 Além disso, as chaves de sessão
retornadas pelo TGS não podem ser armazenadas de forma segura; por necessidade, elas são armazenadas em uma
área acessível ao root. Portanto, se o invasor conseguir quebrar o mecanismo de proteção no computador local — ou,
talvez mais importante, contorná-lo para alguns propósitos limitados — todas as chaves de sessão atuais podem ser
roubadas. Isso é menos sério do que uma violação da chave principal do Kerberos, é claro, uma vez que as chaves de
sessão são limitadas em tempo de vida e escopo; no entanto, não se deseja expor essas chaves.

Isso aponta para uma segunda falha quando computadores mul usuários usam o Kerberos, seja em seu
próprio nome ou para seus usuários: as chaves em cache são acessíveis a invasores conectados ao mesmo tempo. Em
um ambiente de estação de trabalho, apenas o usuário atual tem acesso aos recursos do sistema; não há necessidade
de habilitar login remoto para essa estação de trabalho. Há muitas razões para isso; uma consequência, no entanto, é
que o invasor simplesmente não pode se aproximar da porta segura para tentar abrir sua fechadura.6 Somente quando
o usuário legí mo sair é que o invasor pode tentar encontrar as chaves. Mas as chaves não estão mais disponíveis; o
Kerberos tenta apagar as chaves an gas no momento do logout, deixando o invasor vasculhar os destroços. Com um
computador mul usuário, por outro lado, um invasor tem acesso simultâneo às chaves se houver falhas na segurança
do host.

Há outras duas falhas menores no Kerberos diretamente atribuíveis ao ambiente. Primeiro, há alguma dúvida
sobre onde as chaves devem ser armazenadas em cache. Como todas as máquinas do Projeto Athena têm discos locais,
o código original usava /tmp. Mas isso é altamente inseguro em estações de trabalho sem disco, onde /tmp existe em
um servidor de arquivos; consequentemente, foi feita uma modificação para armazenar chaves na memória
compar lhada. No entanto, não há garan a de que a memória compar lhada não seja paginada; se isso envolver
tráfego de rede, um intruso pode capturar estas chaves.

Finalmente, o protocolo Kerberos vincula ckets a endereços IP. Esse uso é problemá co em hosts com várias
interfaces de rede (ou seja, hosts com mais de um endereço IP). Como as estações de trabalho raramente têm múl plos
endereços, esse recurso — des nado a aprimorar a segurança — não era um problema no MIT. No entanto, hosts
mul usuários frequentemente têm vários endereços e não podem conviver com essa limitação. Esse problema foi
corrigido na Versão 5.

Vulnerabilidades do Protocolo

Ataques de Repe ção

O protocolo Kerberos não é tão resistente à penetração quanto deveria ser. Diversas fraquezas são aparentes,
sendo a mais séria o uso de um auten cador para evitar ataques de repe ção.
 O auten cador depende do uso de um carimbo de data/hora para evitar reu lização. Isso é problemá co por
várias razões. A alegação é de que replays não são prováveis dentro da vida ú l do auten cador (normalmente cinco
minutos). Isso é reforçado pela presença do endereço IP tanto no cket quanto no auten cador. Não somos
convencidos por essa lógica. Um invasor não começaria capturando um cket e auten cador e, em seguida,
desenvolveria o so ware para usá-los; tudo estaria pronto antes da tenta va de captura do cket. Vamos considerar
dois exemplos.

Há alguns anos, Morris descreveu um ataque com base na taxa lenta de incremento do contador de número
de sequência inicial em algumas implementações de TCP.[Morr85] Ele demonstrou que era possível, em certas
circunstâncias, falsificar uma metade de uma conexão TCP preauten cada sem ver nenhuma resposta do host-alvo.
Em um ambiente Kerberos, seu ataque ainda funcionaria se acompanhado por um auten cador ao vivo roubado, mas
não se um protocolo de desafio/resposta fosse usado. Alterna vamente, um invasor pode simplesmente observar uma
sessão de "verificação de e-mail", na qual um usuário faz login brevemente, lê algumas mensagens e faz logout. Uma
série de ckets valiosos seria exposta por tal sessão, especialmente o usado para montar o diretório inicial do usuário.
Note que o tempo de vida dos auten cadores — 5 minutos — contribui consideravelmente para esse ataque.

Além disso, a proposta Versão 5 do Kerberos antecipa protocolos de comunicação alterna vos nos quais tais
repe ções podem ser fáceis de implementar. Se o Kerberos deve ser considerado como uma u lidade de propósito
geral, ele deve fazer poucas suposições crí cas de segurança sobre a rede subjacente, e essas devem ser explícitas.

Sugeriu-se que a defesa adequada seria para o servidor armazenar todos os auten cadores a vos; assim, uma
tenta va de reu lização poderia ser detectada.[Stei88] Na verdade, o design original do Kerberos exigia esse
armazenamento em cache, embora isso nunca tenha sido implementado. (Embora isso seja uma caracterís ca da
implementação e não do protocolo em si, uma caracterís ca de segurança não é muito ú l se for muito di cil de
implementar.)

Por várias razões, não acreditamos que o armazenamento em cache resolva o problema. Primeiro, em sistemas
UNIX, é di cil para servidores baseados em TCP[Post81] armazenar auten cadores. Os servidores geralmente operam
criando um processo separado para lidar com cada solicitação recebida. Os processos filho não compar lham nenhuma
memória com o processo pai e, portanto, não têm uma maneira conveniente de informá-lo — e, portanto, a qualquer
outro servidor filho — do valor do auten cador usado. Existem várias soluções óbvias — pipes, servidores de
auten cadores, segmentos de memória compar lhada e assim por diante — mas todas são complicadas, e algumas
até levantam questões de auten cação. Até o momento, não conhecemos nenhuma implementação de servidor com
várias threads que armazene auten cadores em cache.

Servidores de consulta baseados em UDP[Post80] podem armazenar os auten cadores mais facilmente, já que
geralmente um único processo lida com todas as solicitações recebidas; no entanto, eles podem ter problemas com
retransmissões legí mas da solicitação do cliente se a resposta for perdida. (O UDP não fornece entrega garan da;
assim, todas as retransmissões ocorrem no nível de aplicação e são visíveis para a aplicação.) Solicitações legí mas
podem ser rejeitadas, e um alarme de segurança pode ser acionado inadequadamente. Uma possível solução seria
para a aplicação gerar um novo auten cador ao retransmi r uma solicitação; se não fossem pelas outras fraquezas do
esquema de auten cadores, isso seria aceitável.

Serviços Seguros de Tempo

Como mencionado, os auten cadores dependem de relógios das máquinas estarem aproximadamente
sincronizados. Se um host pode ser enganado sobre o horário correto, um auten cador an go pode ser retransmi do
sem problemas. Como alguns protocolos de sincronização de tempo não são auten cados,[Post83, Mill88] e os hosts
ainda estão usando esses protocolos apesar da existência de melhores,[Mill89] tais ataques não são di ceis.

A filosofia de design de construir um serviço de auten cação em cima de um serviço de tempo seguro é em si
ques onável. Ou seja, pode não fazer sen do construir um sistema de auten cação assumindo um sistema subjacente
já auten cado. Além disso, embora falsificar um serviço de tempo não auten cado possa ser uma tarefa de
programação di cil, não é criptograficamente di cil. Usar protocolos baseados em tempo de maneira segura significa
pensar cuidadosamente em todas essas questões e realizar apropriadamente a sincronização de uma parte explícita
do protocolo. À medida que o Kerberos é proposto para ambientes mais variados, sua dependência de um serviço de
tempo seguro torna-se mais problemá ca e deve ser enfa zada.

Como alterna va, propomos o uso de um mecanismo de auten cação desafio/resposta. Como é feito hoje, o
cliente apresentaria um cket, embora sem um auten cador. O servidor responderia com um iden ficador nonce
criptografado com a chave de sessão Kc,s; o cliente responderia com alguma função desse iden ficador, provando assim
que possui a chave de sessão.

Essa implementação não é isenta de custos, é claro. Um par adicional de mensagens deve ser trocado sempre
que um cket é usado, o que exclui a possibilidade de datagramas auten cados. Mais seriamente, todos os servidores
precisariam reter um estado para concluir o processo de auten cação. Embora não seja um problema para servidores
baseados em TCP, isso pode exigir modificações substanciais nos servidores de consulta baseados em UDP. (A
complexidade de gerenciar desafios pendentes pode ser comparável à necessária para armazenar auten cadores
a vos — o trade-off não é entre um protocolo com estado e um sem estado, mas sim em gerenciar dois pos de
estado.)

No entanto, há uma diferença filosófica significa va entre as duas técnicas. Na implementação atual do
Kerberos, com suas suposições sobre o ambiente de rede, o estado re do é apenas necessário para aprimorar a
segurança. O esquema de desafio/resposta, por outro lado, garante segurança em um ambiente mais geral, mas requer
estado re do para funcionar.

Em vez de subs tuir completamente pelo desafio/resposta, um possível compromisso é estender o protocolo
com uma opção de desafio/resposta. Essa opção poderia ser usada, por exemplo, para auten car o usuário na troca
inicial de cket-gran ng cket e para acessar um serviço de tempo.8 Interações subsequentes cliente-servidor
poderiam usar o protocolo atual baseado em tempo. No entanto, sincronizar os servidores ainda é um problema; não
sincronizá-los levará à negação de serviço, e se eles acessarem o serviço de tempo como cliente, eles devem de alguma
forma obter e armazenar um cket e chave para auten cá-lo. (Veja acima sobre armazenamento de chaves em
servidores.) Dadas essas complexidades e possíveis fraquezas, pareceria razoável permi r que qualquer serviço insista
na opção de desafio/resposta.

Resumindo, enfa zamos que a segurança do Kerberos depende cri camente de relógios sincronizados. Em
essência, os protocolos Kerberos envolvem confiança mútua entre quatro partes: o cliente, o servidor, o servidor de
auten cação e o servidor de tempo.

Ataques de Adivinhação de Senha

Uma segunda grande classe de ataque aos protocolos Kerberos envolve um intruso gravando diálogos de login
para montar um ataque de adivinhação de senha. Quando um usuário solicita Tc,tgs (o cket-gran ng cket), a resposta
é devolvida criptografada com Kc, uma chave derivada por um algoritmo de conhecimento público a par r da senha
do usuário. Um palpite da senha do usuário pode ser confirmado calculando Kc e usando-o para descriptografar a
resposta gravada. Um intruso que gravou muitos desses diálogos de login tem boas chances de encontrar várias senhas
novas; empiricamente, os usuários não escolhem senhas boas a menos que sejam forçados a fazê-lo. [Morr79, Gram84,
Stol88]

Propomos o uso de uma troca de chaves exponenciais[Diff76] para fornecer uma camada adicional de
criptografia. Sem descrever o algoritmo em detalhes, ele envolve as duas partes trocando números que cada uma pode
usar para calcular uma chave secreta. Um outsider, não sabendo como os números foram calculados, não pode derivar
facilmente a chave.

O uso de troca de chaves exponenciais dessa forma impediria que um bisbilhoteiro passivo acumulasse o
equivalente em rede do /etc/passwd. Embora a troca de chaves exponenciais normalmente seja vulnerável a escutas
telefônicas a vas, esses ataques são compara vamente raros, especialmente se roteadores de rede dedicados forem
usados.

Adicionalmente, foram adicionadas mensagens extras ao diálogo de login e imposta a exigência de um

considerável estado adicional no servidor. Dada a tendência de ocultar até mesmo senhas criptografadas em sistemas
UNIX e considerando as es ma vas de que metade de todos os logins no MIT são u lizados dentro de um período de
duas semanas, o inves mento pode ser jus ficável. Talvez a melhor solução seja suportar esse recurso como uma
opção específica de domínio.

Mesmo a troca de chaves exponenciais não impedirá todos os ataques de adivinhação de senha. Dependendo
de quão cuidadosamente os logs do Kerberos são analisados, um intruso pode nem mesmo precisar interceptar. As
solicitações de ckets não são criptografadas por si só; um atacante poderia simplesmente solicitar cket-gran ng
ckets para muitos usuários diferentes. Uma melhoria no servidor para limitar a taxa de solicitações de uma única
fonte pode ser ú l.

Alterna vamente, alguma parte da solicitação inicial de cket pode ser criptografada com Kc, proporcionando
uma auten cação mínima do usuário ao Kerberos, de modo que seria necessário um verdadeiro monitoramento para
montar esse ataque. (Enquanto preparamos este manuscrito, uma sugestão exatamente desse po está sendo
intensamente deba da na lista de discussão do Kerberos. Inicialmente, não consideramos uma alterna va para montar
um ataque de adivinhação de senha.)

Clientes podem ser tratados como serviços, e ckets para o cliente, criptografados por Kc, podem ser ob dos
por qualquer usuário. Essa capacidade tem sido sugerida como base para auten cação de usuário para usuário e
serviços de correio aprimorados. No entanto, qualquer esquema desse po parece exigir a reintrodução repe da da
senha do usuário, uma inconveniência que suspeitamos que não será tolerada. Preferiríamos fornecer a mesma
funcionalidade fazendo com que os clientes registrem instâncias separadas como serviços, com chaves
verdadeiramente aleatórias. (Chaves poderiam ser fornecidas ao cliente pelo keystore, descrito abaixo.)

Uma abordagem alterna va é um protocolo descrito por Lomas, Gong, Saltzer e Needham. Eles apresentam
um diálogo com um servidor que não expõe o usuário a ataques de adivinhação de senha. No entanto, o protocolo
deles depende da criptografia de chave pública, uma abordagem explicitamente rejeitada para o Kerberos.

Spoofing no Login

Em um ambiente de estação de trabalho, é bastante simples para um intruso subs tuir o comando de login
por uma versão que registra as senhas dos usuários antes de usá-las no diálogo do Kerberos. Esse ataque anula uma
das principais vantagens do Kerberos, que é a de que as senhas nunca são transmi das em texto claro por uma rede.
Embora esse problema não seja restrito a ambientes do Kerberos, o protocolo do Kerberos torna di cil empregar a
contramedida padrão: senhas de uso único.

Um esquema pico de senha de uso único envolve uma chave secreta compar lhada entre um servidor e
algum disposi vo de posse do usuário. O servidor escolhe um número aleatório e o transmite para o usuário. Ambos,
o servidor e o usuário (com a ajuda do disposi vo), criptografam esse número usando a chave secreta; o resultado é
transmi do de volta para o servidor. Se os dois valores calculados coincidirem, presume-se que o usuário possui a
chave apropriada.

O Kerberos não prevê tal diálogo de desafio/resposta no momento do login. A resposta do servidor à solicitação
de login é sempre criptografada com Kc, uma chave derivada da senha do usuário. A menos que um 'cartão inteligente'
seja u lizado e compreenda todo o protocolo do Kerberos, isso impede qualquer uso de senhas de uso único.

Uma alterna va (sugerida pela primeira vez por T.H. Foregger) exige que o servidor escolha um número
aleatório R e use Kc para criptografar R. Este valor {R}Kc, em vez de Kc, seria usado para criptografar a resposta do
servidor. R seria transmi do em texto claro para o usuário. Se um auten cador portá l es vesse em uso, o usuário o
u lizaria para calcular {R}Kc; caso contrário, o programa de login o faria automa camente.

Ataques de Texto Escolhido entre Sessões

De acordo com a descrição no rascunho da Versão 5, servidores que u lizam o formato KRB_PRIV são
susce veis a um ataque de texto escolhido. Especificamente, a parte criptografada de mensagens desse po tem a
forma
 X = (DATA, mestamp + direção, endereço do host, PAD).

Como o encadeamento de blocos de cifra tem a propriedade de que prefixos de criptografias são criptografias
de prefixos, se DATA ver a forma

(AUTENTICADOR, CHECAGEM, RESTANTE),

então um prefixo da criptografia de X com a chave de sessão é a criptografia de

(AUTENTICADOR, CHECAGEM)

e pode ser usada para falsificar uma sessão inteira com o servidor.

Pode-se argumentar que a maioria dos servidores não é susce vel a ataques de texto escolhido. Dado que
existem contramedidas fáceis para esse ataque, parece tolo advogar um formato geral para servidores privados que
também não o proteja. Vale notar que o simples ataque acima não funciona contra o Kerberos Versão 4, no qual a
parte criptografada da mensagem KRB_PRIV tem a forma

(comprimento(DATA), DATA, msec me, endereço do host, mestamp + direção, PAD),

pois o campo de comprimento(DADOS) interfere no ataque baseado em prefixo. Deixamos para o leitor descobrir um
ataque mais complicado de cifragem escolhida contra esse formato, mesmo considerando que a Versão 4 u liza o
modo de criptografia não padrão PCBC. (Dica: assuma que o vetor inicial é fixo e público.) No entanto, é interessante
observar que a ordem de concatenação dos campos da mensagem pode ter implicações crí cas de segurança.
Voltaremos a essa questão na seção posterior sobre codificação de mensagens.

Exposição de Chaves de Sessão

O termo "chave de sessão" é um equívoco no protocolo Kerberos. Essa chave está con da no cket de serviço
e é usada nas múl plas sessões entre o cliente e o servidor que u lizam esse cket. Assim, é mais apropriado chamá-
la de "chave de múl plas sessões". Tornar esse ponto explícito leva naturalmente à sugestão de que as verdadeiras
chaves de sessão sejam negociadas como parte do protocolo Kerberos. Isso limita a exposição à criptoanálise da chave
de múl plas sessões con da no cket e impede ataques que subs tuem mensagens de uma sessão em outra. (O
ataque de texto escolhido da seção anterior é um exemplo desse po.) A chave de sessão poderia ser gerada pelo
servidor ou poderia ser calculada como uma função específica da sessão da chave de múl plas sessões.

Escopo dos Tickets

Os ckets do Kerberos são limitados no tempo e no espaço. Ou seja, os ckets só podem ser usados dentro do
reino do servidor de concessão de ckets e apenas por um período limitado de tempo. O primeiro é necessário para o
design do Kerberos; o TGS não teria chaves em comum com servidores em outros reinos. O úl mo é uma medida de
segurança; quanto mais tempo um cket es ver em uso, maior será o risco de ser roubado ou comprome do.

Uma restrição adicional nos ckets, na Versão 4, é que eles não podem ser encaminhados. Um usuário pode
obter ckets no momento do login e usá-los para fazer login em outro host; no entanto, não é possível obter serviços
de rede auten cados desse host a menos que um novo cket de concessão de ckets seja ob do. E isso, por sua vez,
exigiria a transmissão de uma senha pela rede, violando os princípios fundamentais do design do Kerberos.

A Versão 5 incorpora disposições para encaminhamento de ckets; no entanto, isso introduz o problema da
confiança em cascata. Ou seja, um host A pode estar disposto a confiar em credenciais do host B, e B pode estar
disposto a confiar no host C, mas A pode não estar disposto a aceitar ckets criados originalmente no host C, que A
acredita ser inseguro.

Também foi introduzido no Kerberos um bit de sinalização para indicar se um cket foi encaminhado, mas não
inclui a fonte original.
 Um segundo problema com o encaminhamento é que o conceito só faz sen do se os ckets incluírem o
endereço de rede do principal. Se o endereço for omi do, como é permi do na Versão 5, um cket pode ser usado a
par r de qualquer host, sem nenhuma modificação adicional no protocolo. Tudo o que é necessário para u lizar esse
po de cket é um mecanismo seguro para copiar a chave de várias sessões para o novo host. No entanto, isso pode
ser realizado por meio de um mecanismo de transferência de arquivos criptografado sobre as facilidades existentes;
não requer bits de sinalização no cabeçalho do Kerberos.

É ú l incluir o endereço de rede em um cket? Achamos que não. Dada nossa suposição de que a rede está
sob total controle do atacante, nenhuma segurança adicional é ob da ao depender do endereço de rede. Na verdade,
o principal bene cio de incluí-lo parece ser evitar o reuso imediato de auten cadores de um host diferente.

Mesmo com a proteção fornecida pelos endereços de rede, os ataques de repe ção que envolvem endereços
falsos são fáceis; novamente, consulte [Morr85]. Além disso, um atacante sempre pode esperar até que a conexão seja
estabelecida e auten cada e, em seguida, assumi-la, anulando assim qualquer segurança fornecida pela presença do
endereço. Diante desses problemas e da questão de cascata de confiança levantada anteriormente, sugerimos que o
encaminhamento de ckets seja excluído.

Um novo mecanismo de auten cação entre reinos também foi introduzido na Versão 5. Resumidamente, se
um usuário deseja acessar um serviço em outro reino, esse usuário deve primeiro obter um cket-gran ng cket para
aquele reino. Isso é feito tornando o servidor de concessão de ckets em um reino o cliente do TGS de outro reino. Por
sua vez, ele pode ser cliente do TGS de mais um reino. O pedido de cket de um usuário é assinado por cada TGS e
passado adiante; os reinos normalmente serão configurados de maneira hierárquica, embora "links em tandem" sejam
permi dos.

Infelizmente, esse esquema, embora pareça resolver o problema, é deficiente em vários aspectos.
Primeiramente, e mais grave, não há discussão sobre como um TGS pode determinar qual dos seus reinos vizinhos
deve ser o próximo salto. Subindo na árvore, em direção à raiz, é uma resposta óbvia para os nós folha; no entanto,
cada nó pai precisaria de conhecimento completo dos reinos de toda a sua subárvore para determinar como passar o
pedido para baixo. Existem analogias óbvias aqui com questões de roteamento de camada de rede; observe, no
entanto, que qualquer "protocolo de roteamento de reino" deve incluir disposições de auten cação robustas.

Outra resposta é dizer que tabelas está cas devem ser usadas. Isso também tem suas limitações de segurança:
os administradores de reinos devem depender de mensagens de correio eletrônico ou telefonemas para configurar
suas tabelas de roteamento? Se essas chamadas não forem auten cadas, os riscos de segurança são óbvios; se forem
auten cadas, a segurança de um reino Kerberos fica subordinada à segurança de um sistema de auten cação
totalmente diferente. Há também uma ligação evidente entre a auten cação entre reinos e o problema de confiança
em cascata. O Kerberos Versão 5 tenta resolver isso incluindo informações de caminho na solicitação de cket. No
entanto, na ausência de um espaço de nomes global, não fica claro se isso é ú l. Se um reino não é vizinho, seu nome
pode não ter nenhum significado global, seja por malícia ou coincidência. Além disso, para avaliar a validade de uma
solicitação, um servidor precisa de conhecimento global sobre a confiabilidade de todos os reinos de trânsito possíveis.
Em uma grande internet, esse conhecimento provavelmente não é possível.

CRITÉRIOS DE DESIGN DE HARDWARE PARA O KERBEROS

Uma Unidade de Criptografia no Host

Uma das principais razões pelas quais ques onamos a adequação do Kerberos para hosts mul usuários é a
necessidade de armazenamento de chaves em texto simples. E se o host es vesse equipado com uma unidade
criptográfica anexada? Consideramos os parâmetros de design para tal disposi vo.

O obje vo principal é realizar operações criptográficas sem expor chaves a comprome mentos. Essas
operações devem incluir a validação de ckets apresentados por usuários remotos, a criação de solicitações tanto para
ckets de concessão quanto para ckets de aplica vos, e a criptografia e descriptografia de conversas. Portanto, deve
haver armazenamento seguro para um número adequado de chaves, e o sistema operacional deve ser capaz de
selecionar qual chave deve ser usada para qual função.
 A próxima pergunta, é claro, é como as chaves são inseridas na área de armazenamento segura. Se os ckets
forem descriptografados pela caixa de criptografia, mas transferidos para a memória do host para análise, a chave de
sessão incorporada é exposta. Portanto, concluímos que a própria caixa de criptografia deve entender os protocolos
Kerberos; nada menos garan rá a segurança das chaves armazenadas.

A entrada de chaves de usuário é mais problemá ca, pois elas precisam passar pelo host. A menos que os
terminais de usuário estejam conectados diretamente à unidade de criptografia, há pouca escolha. Armazená-las fora
do host, no entanto, é uma ajuda significa va, pois o período de exposição é então minimizado. As chaves de
propriedade do host, como chaves de serviço ou as chaves que o root usaria para montar sistemas de arquivos NFS,
devem ser carregadas por meio de um serviço auten cado pelo Kerberos residente na unidade de criptografia.
Voltaremos a esse ponto abaixo.

Agora devemos garan r que o protocolo em si não forneça um mecanismo para obter chaves. Ao examinar as
definições de mensagem, vemos que apenas as chaves de sessão são enviadas e sempre estão criptografadas. Além
disso, as máquinas de usuário nunca geram tais mensagens; elas apenas as encaminham. Assim, a caixa não precisa
ter a capacidade de transmi r uma chave, proporcionando-nos um nível muito alto de garan a de que não o fará.

Se uma caixa de criptografia for usada para o próprio servidor Kerberos, o problema é um pouco mais
complexo. Há dois lugares onde as chaves são transmi das. Primeiro, quando um cket é concedido, o próprio cket
contém uma chave de sessão, e uma cópia dessa chave de sessão é enviada de volta criptografada na chave de sessão
de concessão de cket do cliente. Em segundo lugar, durante o diálogo inicial com o Kerberos, a chave de sessão de
concessão de cket deve ser enviada, criptografada na chave de senha do cliente. No entanto, chaves permanentes
nunca são enviadas; novamente, isso nos assegura que a caixa de criptografia não fornecerá chaves. Além disso, como
essas chaves de sessão são des nadas a serem aleatórias, podemos obter uma grande segurança incluindo um gerador
de números aleatórios de hardware a bordo.

Não estamos muito preocupados em ter que carregar chaves de cliente e servidor na placa. Essa operação é
feita apenas pelo servidor mestre do Kerberos, para o qual uma segurança sica forte deve ser assumida em qualquer
caso. É possível que uma unidade de criptografia desse po possa ser tornada suficientemente resistente a
adulterações, que até estações de trabalho possam usá-las; certamente, existem disposi vos criptográficos comerciais
que afirmam ter tais resistências.

Uma grande objeção a todo esse esquema é que, em úl ma análise, a caixa de criptografia é controlada pelo
computador host. Portanto, se o root for comprome do, o host pode instruir a caixa a criar ckets falsos. Tais
preocupações são certamente válidas. No entanto, como observado acima, consideramos tais violações temporárias
de segurança muito menos sérias do que o comprome mento de uma chave. Além disso, o uso de uma unidade
separada nos permite criar logs inalteráveis, etc.

Também é desejável evitar o uso indevido de chaves. Por exemplo, não queremos que a chave de login seja
usada para descriptografar o bloco arbitrário de texto que acaba sendo o cket de concessão de cket. Portanto, as
chaves devem ser marcadas com seu propósito. Uma chave de login deve ser usada apenas para descriptografar o
cket de concessão de cket; a chave associada a ela deve ser usada apenas para obter ckets de serviço, etc. Como a
caixa de criptografia está realizando todo o gerenciamento de chaves, isso não é um problema di cil.

A Unidade de Armazenamento de Chaves

Uma variedade de tecnologias pode ser usada para implementar unidades de criptografia, desde placas
especiais até microcomputadores dedicados conectados a hosts de servidor por linhas fisicamente seguras. Se o úl mo
for u lizado, há a tentação de usar seu armazenamento de disco para manter as chaves de serviço associadas ao host
conectado, mas consideramos isso inábil. Qualquer mídia desse po deve ser copiada e os backups devem ser
cuidadosamente guardados. Esse alto nível de segurança pode ser impra cável em alguns ambientes. Em vez disso,
sugerimos que as chaves sejam man das na memória volá l e baixadas de um keystore seguro quando solicitado, por
meio de um canal protegido por criptografia. Assim, apenas uma chave mestra precisa ser armazenada dentro da caixa;
essa chave pode estar armazenada em armazenamento não volá l ou ser fornecida por um operador quando
necessário.
 De maneira mais geral, o keystore é um repositório seguro e confiável para uma quan dade limitada de
informações. Um cliente do keystore pode empacotar dados arbitrários a serem re dos pelo keystore e recuperados
posteriormente. Esses dados, como as chaves e tags de serviço, no caso de uma unidade de criptografia, ou mesmo
um host Kerberos convencional, seriam não interpretados pelo keystore. Solicitações de armazenamento e
recuperação seriam auten cadas por ckets Kerberos, é claro. Deve-se empregar apenas a transferência criptografada
(KRB_PRIV), como seguro contra divulgação desse material sensível.

Como observado, o mesmo protocolo do keystore pode ser usado para fornecer chaves adicionais para novas
instâncias do mesmo cliente. Por exemplo, um usuário "pat" pode ter uma instância separada "pat.email", para receber
emails criptografados. A chave para essa instância seria restrita apenas a esse usuário, é claro.

Geralmente, as transações com o keystore são iniciadas pelo cliente. No entanto, há alguma dúvida sobre como
criar as chaves de usuário adicionais, já que os terminais de usuário não são fontes muito boas de chaves aleatórias. A
melhor alterna va é fornecer um serviço de números aleatórios (seguro) na rede. Quando uma nova instância do
cliente é adicionada, esse serviço seria consultado para gerar a chave; tanto o Kerberos quanto o keystore seriam
informados sobre a chave.

VALIDAÇÃO DE SEGURANÇA

O Kerberos está correto? Com isso, queremos saber se existem bugs (ou backdoors!) no design ou
implementação do Kerberos, bugs que poderiam ser usados para penetrar em um sistema que depende do Kerberos.
Alguns diriam que, ao disponibilizar o código amplamente, os implementadores possibilitaram que invasores em
potencial ganhassem um conhecimento detalhado do sistema, facilitando bastante sua tarefa. Rejeitamos essa noção.

No final do século XIX, Kerckhoffs formulou o princípio básico sob o qual a segurança dos sistemas
criptográficos deve ser avaliada: todos os detalhes do design do sistema devem ser assumidos como conhecidos pelo
adversário. Apenas as chaves criptográficas especificamente consideradas secretas devem estar indisponíveis para um
atacante. Dada essa premissa básica, a segurança de um sistema criptográfico é avaliada com base em esforços
concertados de criptoanálise.

O Kerberos é projetado principalmente como um sistema de auten cação incorporando um criptossistema

tradicional (o Padrão de Criptografia de Dados) como um componente. No entanto, a filosofia que orienta o critério de
avaliação de Kerckhoffs se aplica à avaliação da segurança do Kerberos. Os detalhes do design e implementação do
Kerberos devem ser considerados conhecidos por um potencial atacante, que também pode estar em conluio com
algum subconjunto de servidores, clientes e (no caso de reinos configurados hierarquicamente) alguns servidores de
auten cação. O Kerberos é seguro somente se puder proteger outros clientes e servidores, começando apenas com a
premissa de que essas chaves de cliente e servidor são secretas, e que o sistema de criptografia é seguro.

Além disso, na ausência de uma 'autoridade de validação' central e confiável, cada usuário em potencial do
Kerberos é responsável por julgar sua segurança. Claro, uma discussão pública sobre segurança do sistema e a
publicação de avaliações de segurança facilitarão tais julgamentos.

Ao descrever o design do Kerberos em publicações e tornar o código-fonte publicamente disponível, os

designers e implementadores do Kerberos no Projeto Athena fizeram um esforço louvável para incen var essa
validação pública do sistema. Obviamente, este documento faz parte desse processo. No entanto, o design do sistema
e sua implementação sofreram modificações significa vas, em parte como consequência dessa discussão pública.
Ressaltamos que cada modificação no design e na implementação resulta em um novo sistema cujas propriedades de
segurança devem ser consideradas novamente. (Exemplos de tais modificações são a incorporação de servidores
organizados hierarquicamente e ckets encaminháveis na Versão 5.)

Portanto, a modificação con nua do Kerberos o torna um alvo móvel para tenta vas de validação de segurança.
Uma análise detalhada de segurança seria, portanto, prematura. No entanto, as alterações propostas ao Kerberos nas
próximas seções têm como obje vo, não tanto derrotar ataques específicos, mas facilitar o processo de validação. Em
par cular, essas sugestões têm como obje vo tornar o Kerberos mais modular, em design e implementação. Fazê-lo
deve tornar as consequências de segurança das modificações mais aparentes e facilitar uma abordagem incremental
para a validação de segurança do Kerberos.

Codificação de Mensagens e Ataques de Copiar e Colar

A análise mais simples da segurança dos protocolos Kerberos deve verificar a inexistência de ambiguidade
entre mensagens enviadas em contextos diferentes. Ou seja, um ingresso nunca deve ser interpretável como um
auten cador, ou vice-versa. Tal análise depende da redundância nas codificações binárias pré-cifragem de cada
ingresso e informações do auten cador. Atualmente, essa análise deve ser repe da a cada modificação no protocolo.
Essa análise repe va e muitas vezes intrincada seria desnecessária se codificações padrão (como ASN.1)[ASN1, BER]
fossem u lizadas. Essas codificações devem incluir o po geral de mensagem (como KRB_TGS_REP ou KRB_PRIV).
Juntamente com suposições razoáveis sobre a camada de criptografia (consulte a próxima seção), tal esquema de
codificação simplificaria enormemente o processo de validação do protocolo, especialmente à medida que o protocolo
é modificado ou estendido.

Alguma u lização de codificações ASN.1 foi adotada por outras razões na Versão 5. Reforçamos aqui que
existem princípios de design além da compa bilidade com padrões que mo vam tal mudança.

A Camada de Criptografia

A Versão 4 do Kerberos usa o modo de criptografia não padrão PCBC, propagando o encadeamento de blocos
cifrados, no qual o bloco de texto simples i + 1 é exclusivamente ou-exclusivo com ambos o texto simples e o texto
cifrado do bloco i antes da criptografia. Esse modo foi observado como tendo propriedades de propagação ruins que
permitem a modificação da sequência de mensagens: especificamente, se dois blocos de texto cifrado são trocados,
apenas os blocos correspondentes são corrompidos na descriptografia. A Versão 5 subs tui o modo PCBC pelo modo
CBC padrão, encadeamento de blocos cifrados, que realiza a operação de ou-exclusivo apenas com o texto cifrado do
bloco i com o texto simples do bloco i + 1 antes da criptografia. Um checksum — até o Rascunho 2, a forma exata não
havia sido determinada — é usado para detectar a modificação da mensagem. Para garan r que mensagens duplicadas
tenham criptografias diferentes, inicializadores aleatórios 'confounders' são adicionados a alguns formatos de
mensagem. Além disso, a Versão 5 suporta algoritmos de criptografia alterna vos como opções.

Tanto os mecanismos de 'confounder' quanto de checksum são des nados a aumentar a segurança da
criptografia CBC. Eles pertencem a uma camada de criptografia separada, não no nível dos próprios protocolos
Kerberos. Além disso, o mecanismo 'confounder' deve ser subs tuído pelo uso do mecanismo padrão de vetor inicial
de encadeamento de blocos cifrados.[FIPS81, Davi89] Para evitar a modificação da sequência de mensagens durante
sessões auten cadas ou privadas, a Versão 5 usa um campo de carimbo de data/hora para evitar a reprodução de
mensagens criptografadas inteiras. Essa é outra preocupação mais adequada à camada de criptografia, onde o
encadeamento entre os pacotes de toda a sessão é o mecanismo mais padrão. (Esse encadeamento evita tanto a
dependência de um relógio quanto a necessidade de armazenar em cache carimbos de data/hora recentes.)

Separar os protocolos Kerberos dos detalhes da criptografia facilitaria tanto a validação da segurança dos
protocolos Kerberos quanto implementações e validações envolvendo criptossistemas alterna vos. Muito foco no
mecanismo, embora endêmico ao design de protocolos criptográficos, afasta a necessidade de afirmar as propriedades
básicas exigidas da camada de criptografia. Sugerimos a seguinte análise adversarial como ponto de par da para tal
especificação: permi r a um adversário enviar, um após o outro, qualquer número de mensagens para criptografia sob
uma chave desconhecida K. O adversário também tem a capacidade de pegar prefixos e sufixos de mensagens
conhecidas, realizar ou-exclusivo em mensagens conhecidas e criptografar ou descriptografar com chaves conhecidas.
No final desse processo, o adversário não deve ser capaz de produzir mensagens criptografadas que não aquelas
especificamente enviadas para criptografia. Tal análise impediria esquemas de criptografia susce veis a ataques
simples de texto simples escolhido, como descrito em uma seção anterior.
 Dada a intratabilidade de raciocinar sobre DES, ou provar propriedades de complexidade de qualquer
criptossistema com tamanho de chave limitado, tais análises não garan rão a segurança geral. Mas elas podem ser
usadas para excluir a existência de ataques triviais de copiar e colar.[DeMi83, Moor88].

MUDANÇAS RECOMENDADAS NO PROTOCOLO KERBEROS

Abaixo, listamos nossas mudanças recomendadas para o protocolo Kerberos. Nossa classificação é governada
por nossa es ma va da probabilidade e consequências do ataque, equilibradas contra a dificuldade de implementação
da modificação.

a. Um protocolo de desafio/resposta deve ser oferecido como uma alterna va opcional à auten cação baseada
em tempo.

b. U lizar uma codificação padrão de mensagens, como ASN.1, que inclua a iden ficação do po de mensagem
dentro dos dados criptografados.

c. Alterar o protocolo básico de login para permi r auten cadores portáteis, nos quais {R}KC, para um R
aleatório, é usado para criptografar a resposta do servidor ao usuário, em vez da chave KC ob da da senha do usuário.
Isso permite que o procedimento de login solicite ao usuário o valor de R, que obtém {R}KC do disposi vo portá l e
retorna esse valor em vez da senha em si.

d. Mecanismos como vetores iniciais aleatórios (em vez de 'confounders'), encadeamento de blocos e códigos
de auten cação de mensagem devem ser deixados para uma camada de criptografia separada, cujos requisitos de
ocultação de informações são claramente explicados. Mecanismos específicos baseados em DES devem ser validados
e implementados.

e. O protocolo cliente/servidor deve ser modificado para que a chave de múl plas sessões seja usada para
negociar uma chave de sessão real, que é então usada para proteger o restante da sessão.

f. O suporte para hardware com finalidade especial, como o keystore, deve ser adicionado. Mais importante
ainda, futuros aprimoramentos no protocolo Kerberos devem ser projetados sob a suposição de que um host,
especialmente um host mul usuário, pode estar u lizando hardware de criptografia e armazenamento de chaves.

g. Para proteger contra ataques triviais de adivinhação de senha, o protocolo não deve distribuir ckets para
usuários (criptografados com a chave baseada na senha), e a troca inicial deve auten car o usuário no servidor
Kerberos.

h. Suporte para extensões opcionais deve ser incluído. Em par cular, uma opção para proteger contra ataques
de adivinhação de senha por meio de escuta pode ser uma caracterís ca desejável.

AGRADECIMENTOS

Gostaríamos de agradecer a D. Davis e T.H. Foregger por seus comentários em um rascunho inicial.
Agradecemos especialmente a C. Neuman por suas análises detalhadas de muitas versões do ar go e por discu r os
problemas conosco. W. Griffeth nos ajudou na preparação do apêndice sobre o Rascunho 3. Por fim, gostaríamos de
agradecer à equipe de desenvolvimento do Projeto Athena e do Kerberos por seu design e implementação inicial do
Kerberos, por solicitarem comentários e por serem responsivos às nossas crí cas.

APÊNDICE: RASCUNHO 3 DA VERSÃO 5

O Rascunho 3 avançou significa vamente para aliviar nossas preocupações. Muitos problemas foram
corrigidos, e disposições foram feitas para aprimoramentos compa veis para resolver outras questões pendentes.
Ainda assim, algumas questões permanecem não resolvidas ou não abordadas. Além disso, levantamos novas questões
relacionadas a áreas mais an gas da especificação.
 Em alguns lugares, mencionamos alterações que podem ser feitas em futuras revisões da especificação; o leitor
é adver do de que essas representam nossa compreensão, e apenas nossa compreensão, de um processo con nuo.

Com uma exceção, este resumo omite áreas em que a intenção dos autores era clara ou foi esclarecida em
comunicações privadas. Essa exceção - uma maneira de usar checksums fracos para subverter a auten cação
bidirecional - é incluída para demonstrar a delicadeza inerente ao design e especificação de protocolos de auten cação.

Rascunho 3 e Nossas Mudanças Recomendadas

Começamos revisando nossas mudanças recomendadas à luz do Rascunho 3 e discussões subsequentes com
seus autores.

a. As trocas KRB_AS_REQ/KRB_AS_REP e KRB_TGS_REQ/KRB_TGS_REP agora fornecem auten cação de

desafio/resposta do servidor para o cliente por meio de um campo de nonce, em vez de depender do tempo da estação
de trabalho. Para servidores de aplica vos, o campo e - data na mensagem de erro KRB_AP_ERR_METHOD pode ser
usado pelo servidor para sinalizar ao cliente que deve usar uma alterna va de auten cação de desafio/resposta à
auten cação kerberos baseada em tempo.

b. Todos os dados criptografados são rotulados com o po de mensagem antes da criptografia, por meio da
integração completa do padrão ASN.1. Embora tenha havido muitas razões para essa decisão, aplaudimos seu impacto
benéfico na segurança.

c. Um campo padata opcional provavelmente será adicionado ao KRB_AS_REP para permi r extensões de
protocolo de auten cador portá l.

d. Conforme discu do, mecanismos como vetores iniciais aleatórios (em vez de 'confounders'), encadeamento
de blocos e códigos de auten cação de mensagem agora são deixados para uma camada de criptografia separada, com
uma discussão muito mais clara sobre requisitos e mecanismos específicos baseados em DES.

e. Campos opcionais provavelmente serão adicionados às mensagens AP_REQ e AP_REP para suportar a
negociação de chaves de sessão reais.

f. A adição de campos opcionais (como padata) deve facilitar extensões que explorem hardware com finalidade
especial.

g. A troca inicial ainda não auten ca o usuário no servidor Kerberos. Assim, o equivalente do Kerberos para
/etc/passwd deve ser tratado como público, e senhas devem ser escolhidas e administradas com ataques de
adivinhação de senha em mente. No entanto, o campo padata facilita a implementação opcional de tais mecanismos
de pré-auten cação.

h. Como mencionado acima, vários campos opcionais facilitam extensões como a troca de chaves exponenciais
para proteger contra adivinhação de senha por meio de escuta. As seções a seguir discutem algumas das revisões no
Rascunho 3 com mais detalhes e levantam algumas novas questões.

Diálogo de Login

O diálogo de login foi aprimorado para incluir um campo adicional de dados de auten cação. Isso pode ser
usado para suportar auten cadores portáteis, pré-cifragem da solicitação original e futuras extensões. Este é um
aprimoramento significa vo, mas lamentamos que o suporte a auten cadores portáteis e pré-cifragem ainda não faça
parte do padrão.

Em par cular, o campo opcional na mensagem de solicitação pode suportar algum po de pré-cifragem. Por
exemplo, o campo de nonce pode ser enviado tanto de forma clara quanto criptografado na chave de login do usuário,
demonstrando assim que o cliente é legí mo e impedindo a coleta remota de ckets criptografados com a chave do
usuário. Conforme discu do no corpo principal deste ar go, acreditamos que tal mecanismo deveria ser obrigatório,
não opcional. Programas de quebra de senha requerem exatamente esse po de dado; não há necessidade de fornecer
material para os alimentar.

Atualmente, como lançado, um diálogo de desafio-resposta não pode ser implementado pelo formato de
resposta do Rascunho 3. Embora a mensagem de solicitação possua o campo extra opcional, a resposta não possui e,
portanto, não pode carregar a chave criptografada. Adicionar esse campo também permi ria suporte compa vel à
troca de chaves exponenciais, em que cada parte deve enviar um exponencial aleatório. Entendemos que o campo
opcional provavelmente será adicionado à resposta.

Camadas de Criptografia e Checksum

Agora existe uma camada de criptografia separada e bem definida, com propriedades especificadas. Entre
essas propriedades está que o módulo de criptografia seja capaz de detectar qualquer adulteração na mensagem. O
único método suportado, nesta versão, é um checksum CRC-32 selado dentro da parte criptografada da mensagem.

A camada de criptografia também se beneficia da codificação ASN.1. Como a codificação inclui um campo de
comprimento, não é mais possível para um atacante truncar uma mensagem e apresentar a forma encurtada como
uma mensagem criptografada válida. Se uma decisão fosse tomada para subs tuir ASN.1 (digamos, por algo mais
eficiente), essa propriedade precisaria ser preservada.

O confounder agora foi movido para a camada de criptografia, mas ainda há alguma confusão com a função
do IV usado pela criptografia no modo CBC. Como comumente usado, um IV é um confounder (veja, por exemplo,
[Voyd83]); mantê-lo constante durante uma sessão nega seu propósito e, portanto, exige o confounder adicional.
Sugerimos que o IV seja usado como pretendido, sendo incrementado ou alterado de alguma forma após cada
mensagem. Os valores iniciais para isso devem ser trocados durante (ou derivados) do handshake de auten cação.
Além de simplificar a definição da função de criptografia, esse esquema também permi ria a detecção de exclusões
de mensagem por aplica vos interessados.

Pode-se argumentar que exigir que o IV seja manipulado em uma camada mais alta viola o empilhamento de
camadas que defendemos. No entanto, um IV é tanto um atributo de um criptossistema quanto uma chave. Seria
razoável encapsular a definição do IV na definição do objeto de chave passado para a camada de criptografia.

As propriedades necessárias para checksums não são bem definidas. Três pos são especificados: CRC-32, MD4
e MD4 criptografado com DES.[Rive90] No entanto, não há menção de suas caracterís cas, exceto que algumas são
rotuladas como "criptográficas". Esta é uma omissão crucial, como discu do abaixo. Uma melhor classificação é se um
checksum é à prova de colisões, ou seja, se um atacante pode construir uma nova mensagem com o mesmo checksum.
O checksum CRC-32 não é à prova de colisões, enquanto o MD4 acredita-se ser. Note que criptografar um checksum
fornece pouca proteção; se o checksum não for à prova de colisões e os dados forem públicos, um adversário pode
calcular o valor e subs tuir os dados por outra mensagem com o mesmo valor de checksum. (Vários desses ataques
são indicados abaixo.)

Checksums Fracos e Ataques de Copiar e Colar

Uma das principais mudanças no Rascunho 3 foi a remoção da proteção por criptografia dos bilhetes adicionais
e dos dados de autorização que podem ser incluídos em certas solicitações. Esses campos são protegidos por um
checksum selado no auten cador criptografado enviado com a solicitação. Suponha que o algoritmo de checksum
usado seja o CRC-32. (Isso é permi do por uma leitura literal do Rascunho 3, embora tenhamos aprendido que esse
não era o obje vo dos autores.) Com essa suposição, a existência da opção ENC-TKT-IN-SKEY leva a uma grande violação
de segurança, e em par cular à negação completa da auten cação bidirecional.

Como de costume, o cliente, possuindo um cket de concessão de quete válido, envia uma solicitação de um
novo quete para algum serviço S. O inimigo intercepta essa solicitação e a modifica. Primeiro, o bit ENC-TKT-IN-SKEY
é definido. Isso especifica que o quete, normalmente criptografado na chave de S, deve ser criptografado na chave
de sessão do quete de concessão de quete incluído. Em segundo lugar, o próprio quete de concessão de quete
do atacante é incluído. Obviamente, o atacante conhece sua chave de sessão. Finalmente, o campo de dados de
autorização adicional é preenchido com as informações necessárias para fazer o CRC corresponder à versão original.

Considere o que acontece. O serviço de concessão de quete, ao ver uma solicitação válida, envia de volta um
quete. Este quete, criptografado na chave do inimigo, não será inteligível para o serviço real, mas é claro que não
chegará tão longe. O cliente legí mo não pode perceber que o quete está criptografado incorretamente; os quetes
são, quase por definição, criptografados em uma chave conhecida apenas para o servidor e o Kerberos. Quando o
serviço é solicitado, o inimigo intercepta a solicitação e descriptografa o quete. O cliente pode solicitar auten cação
bidirecional; no entanto, como o atacante descriptografou o quete, a chave de sessão para aquela solicitação de
serviço está disponível. Consequentemente, o diálogo de auten cação bidirecional pode ser falsificado sem problemas.

Vários fatores diferentes interagiram para tornar esse ataque possível. Um é óbvio: a solicitação do quete foi
protegida por um checksum que acabou sendo fraco. Se um checksum à prova de colisões fosse usado, o ataque seria
inviável; o inimigo não poderia ter gerado o campo de dados de autorização adicional necessário para fazer o checksum
da nova solicitação corresponder ao original. Mas há su lezas aqui. Primeiro, se os quetes adicionais usados por ENC-
TKT-IN-SKEY fossem criptografados (novamente), eles teriam sido adequadamente protegidos pelo mesmo checksum
CRC-32 que foi abusado no ataque. No entanto, devido à criptografia, o inimigo seria incapaz de discernir ou
corresponder ao checksum. Em outras palavras, o contexto é crí co; simplesmente se abster de recriptografar alguns
dados criptografados, enquanto usa o mesmo checksum para protegê-los, levou a uma violação de segurança. (Nota:
nos disseram que os designers pretendiam exigir que o cname no quete adicional correspondesse ao nome do
servidor para o qual o novo quete está sendo solicitado. Essa exigência ainda permi ria o uso pretendido da opção,
mas impediria o ataque que descrevemos. Aparentemente, a exigência foi inadver damente omi da do Rascunho 3.)

Um ataque semelhante pode ser possível usando a opção REUSE-SKEY. Esta opção foi projetada para
distribuição de chaves mul cast; com um checksum fraco, um atacante pode abusar dela para gerar um quete de
serviço cuja chave é conhecida. A opção REUSE-SKEY também permite um ataque relacionado, embora menos grave.
Se dois quetes, T1 e T2, compar lharem a mesma chave, o atacante pode interceptar uma solicitação de um serviço
e redirecioná-la para o outro. Como os dois quetes compar lham a mesma chave, o auten cador será aceito. O quão
prejudicial essa possibilidade é depende dos pos de serviços que podem querer compar lhar a mesma chave. Se, por
exemplo, um servidor de arquivos e um servidor de backup fossem invocados dessa maneira, um atacante poderia
redirecionar algumas solicitações para destruir cópias arquivadas de arquivos sendo editados. Uma solução para esse
ataque específico é incluir o nome do serviço, um checksum à prova de colisões do quete ou ambos no auten cador.
Para garan r, o Rascunho 3 adverte explicitamente contra o uso de quetes com DUPLICATE-SKEY definido para
auten cação. Servidores que obedecem a essa restrição não são vulneráveis a esse ataque. Além disso, nos disseram
que a opção REUSE-SKEY provavelmente será omi da em futuras revisões do protocolo.

Um úl mo ataque desse po pode ocorrer se o atacante subs tuir um quete diferente pelo legí mo nas
respostas de distribuição de chaves do Kerberos. A parte criptografada de tal mensagem não contém nenhum
checksum para validar se a mensagem foi ou não adulterada durante a transmissão. Embora isso pareça ser mais um
ataque de negação de serviço do que uma invasão, seria ú l para o cliente saber disso imediatamente.

Dois problemas subjacentes a esta lista de ataques potenciais. Como discu do, checksums fracos
(criptografados, mas não à prova de colisões e sobre dados públicos) permitem que um adversário junte mensagens
com aparência legí ma. A integridade da mensagem por meio de checksums fortes e/ou criptografia deve ser
estendida a tantas mensagens de protocolo (e tantos campos) quanto possível. Em segundo lugar, as opções REUSE-
SKEY e ENC-TKT-IN-SKEY "sobrecarregam" o protocolo básico, pois os quetes agora podem compar lhar chaves de
sessão ou serem criptografados em chaves que não a do serviço. É possível que haja outras maneiras de um ataque
explorar as ambiguidades resultantes. Essas opções são des nadas a usos muito restritos, não à auten cação geral;
elas não deveriam ser tão in mamente integradas ao protocolo básico de auten cação. Os mesmos propósitos seriam
servidos adicionando pos de mensagem separados que não podem ser interpretados erroneamente como quetes e
usando chaves derivadas, mas não idên cas, às usadas no protocolo básico. Mesmo assim, uma análise do padrão final
é necessária para garan r que uma extensão mínima não tenha negado uma suposição crí ca de segurança. (Por
exemplo, o protocolo básico do Kerberos assume que nenhum dois quetes compar lham uma chave de sessão e que
os quetes são sempre criptografados com a chave do servidor.)
 Mensagens KRB_SAFE e KRB_PRIV

As mensagens KRB_SAFE e KRB_PRIV u lizam a chave de sessão distribuída com o quete para verificação de
integridade e privacidade, respec vamente. O Rascunho 3 dita que ambas usem valores de hora do dia para proteger
contra repe ção, o que pode ser problemá co. Atualmente, a resolução do carimbo de data/hora é limitada a 1
milissegundo, o que é muito grosseiro para muitas aplicações. (Este e outros carimbos de data/hora no protocolo
provavelmente serão alterados para resolução de microssegundos.) Uma segunda área problemá ca é a necessidade
de um cache de carimbos de data/hora recentemente u lizados. Obviamente, se essas mensagens forem usadas para
coisas como solicitações de sistema de arquivos, o tamanho do cache pode rapidamente se tornar ingovernável. Além
disso, se duas sessões auten cadas ou criptografadas forem executadas simultaneamente, o cache deve ser
compar lhado entre elas, ou mensagens de uma sessão podem ser reproduzidas na outra.

Ambos os problemas podem ser resolvidos se a ideia de um carimbo de data/hora for abandonada em favor
de números de sequência. Um número de sequência inicial aleatório pode ser transmi do com o auten cador e/ou na
mensagem KRB_AP_REP; após o envio de cada mensagem auten cada, ele, é claro, seria incrementado. O cache é
então um simples contador de úl ma mensagem. Esse mecanismo também fornece a capacidade de detectar
mensagens excluídas, observando lacunas na u lização do número de sequência. E, como cada sessão teria seu próprio
número de sequência inicial, não seria possível para um atacante realizar reproduções entre fluxos e o acesso
simultâneo a um cache comum não é necessário. (Essa vantagem seria ob da mesmo com carimbos de data/hora se
chaves de sessão verdadeiras fossem usadas.) É provável que em uma revisão futura, números de sequência serão
fornecidos como uma alterna va ao uso de mestamps.

Auten cadores

O Rascunho 3 ainda solicita o uso de auten cadores para evitar repe ção de quetes. No entanto, agora há
uma disposição para o servidor especificar que auten cação adicional é necessária, e um campo de dados opcional
para isso foi adicionado à mensagem de resposta KRB_ERROR. Isso pode ser usado para implementar esquemas de
desafio/resposta.

O auten cador deve ter alguns outros campos adicionados a ele, alguns deles opcionais. Como mencionado
anteriormente, deve conter um checksum à prova de colisões vinculando-o ao quete e um número de sequência
inicial opcional. Este úl mo seria usado por quaisquer aplica vos que desejem trocar mensagens criptografadas ou
auten cadas.

O auten cador também é o local adequado para negociar uma chave de sessão real. Propomos adicionar um
novo campo para isso tanto no auten cador quanto na mensagem KRB_AP_REP. A chave de sessão real poderia ser
formada por um ou-exclusivo da chave de múl plas sessões associada ao quete, um campo gerado aleatoriamente
no auten cador e um campo semelhante na mensagem de resposta. Note que isso mantém uma medida de
compa bilidade com o esquema atual: se os dois campos opcionais não es verem presentes, a chave de múl plas
sessões será usada como a chave de sessão real. A negociação de chaves de sessão reais, números de sequência iniciais
e confundidores ou IVs poderia ser combinada em um mecanismo padrão, talvez subsumido como subcampos
específicos de criptografia dos campos de chave de sessão.

Auten cação Interdomínio

A auten cação interdomínio ainda é problemá ca. Concedido que arquivos de configuração está cos podem
informar a um servidor Kerberos quem é seu pai, e até mesmo as iden dades de todos os seus filhos, ainda não há um
mecanismo escalável para aprender sobre netos ou descendentes mais distantes.

Certamente, aparentemente é intenção dos autores que o espaço de nomes de domínio da Internet seja usado
para denotar reinos e, implicitamente, a hierarquia de servidores. Não está claro para nós que as duas hierarquias
coincidem. Além disso, tal uso não é obrigatório. Nenhum mecanismo de roteamento alterna vo foi sugerido.
 Além disso, existem várias partes do protocolo que são pouco claras ou simplesmente não funcionam com
quetes interdomínio. Por exemplo, ENC-TKT-IN-SKEY e REUSE-KEY exigem que o servidor de concessão de quetes
decriptografe um quete. Ele não pode fazer isso se o quete ver sido emi do por outro reino. Presumivelmente, é
claro, a solicitação poderia ser enviada para o servidor de concessão de quetes do outro reino, mas pode não possuir
a chave necessária para gerar o novo quete.

NOVAS ALTERAÇÕES RECOMENDADAS

Abaixo, incluímos uma nova lista de alterações recomendadas, além das que indicamos que provavelmente
serão adotadas. As duas primeiras são repe das de nossa lista anterior e agora (ou serão) implementáveis como
opções; repe mos aqui para enfa zar nossa crença de que devem ser uma parte obrigatória do protocolo.

a. Alterar o protocolo básico de login para permi r auten cadores portáteis de desafio/resposta.

b. A troca inicial deve auten car o usuário no servidor Kerberos para complicar ataques de adivinhação de
senha.

c. Checksums fortes, criptografia e campos adicionais devem ser usados para garan r a integridade das
mensagens básicas do Kerberos. (Por exemplo, os quetes devem ser mais in mamente ligados aos contextos nos
quais são usados, incluindo nomes de serviço no quete, e a parte criptografada de KRB_AS_REP e KRB_TGS_REP deve
conter checksums à prova de colisões dos quetes.)

d. Extensões de protocolo não relacionadas à auten cação básica (as opções ENC-TKT-IN-SKEY e REUSE-SKEY)
devem ser omi das ou usar formatos dis ntos de mensagens e quetes.

REFERÊNCIAS

FIPS81. "DES Modes of Opera on," Federal Informa on Processing Standards Publica on 81 (dezembro de 1980).
Na onal Bureau of Standards, U.S. Department of Commerce.

ASN1. "Informa on Processing Systems — Open Systems Interconnec on — Specifica on of Abstract Syntax Nota on
One (ASN.1)," Interna onal Standard 8824 (1987). Interna onal Organiza on for Standardiza on and
Interna onal Electrotechnical Commi ee.

BER. "Informa on Processing Systems — Open Systems Interconnec on — Specifica on of Basic Encoding Rules for
Abstract Syntax Nota on One (ASN.1)," Interna onal Standard 8825 (1987). Interna onal Organiza on for
Standardiza on and Interna onal Electrotechnical Commi ee.

Beke82. H. Beker and F. Piper, Cipher Systems, John Wiley & Sons (1982).

Brya88. B. Bryant, Designing an Authen ca on System: A Dialogue in Four Scenes, Dra February 8, 1988.

Davi89. D.W. Davies and W.L. Price, Security for Computer Networks, John Wiley & Sons (1989). Second Edi on.

Davi90. D. Davis and R. Swick, Worksta on Services and Kerberos Authen ca on at Project Athena, MIT Laboratory for
Computer Science Technical Memorandum 424 (fevereiro de 1990).

Deav85. C.A. Deavours and L. Kruh, Machine Cryptography and Modern Cryptanalysis, Artech House (1985).

DeMi83. R. DeMillo and M. Merri , "Protocols for Data Security," Computer 16(2) pp. 39-50 (fevereiro de 1983).

Diff76. W. Diffie and M.E. Hellman, "New Direc ons in Cryptography," IEEE Transac ons on Informa on Theory 6 pp.
644-654 (novembro de 1976).

Gram84. F.T. Grampp and R.H. Morris, "Opera ng System Security," AT&T Bell Laboratories Technical Journal 63(8, Part
2) pp. 1649-1672 A&T, (outubro de 1984).

Kahn67. D. Kahn, Codebreakers: The Story of Secret Wri ng, Macmillan (1967).
Kerc83. A. Kerckhoffs, La Cryptographie Militaire, Libraire Militaire de L. Baudoin & Cie., Paris (1883).

Kohl89. J. Kohl, B. Clifford Neuman, and J. Steiner, The Kerberos Network Authen ca on Service, MIT Project Athena
(6 de novembro de 1989). Version 5, Dra 2.

Kohl90. J. Kohl, B. Clifford Neuman, and J. Steiner, The Kerberos Network Authen ca on Service, MIT Project Athena
(8 de outubro de 1990). Version 5, Dra 3.

LaMa. B.A. LaMacchia and A.M. Odlyzko, Computa on of Discrete Logarithms in Prime Fields, (Manuscript in
prepara on).

Loma89. T.M.A. Lomas, L. Gong, J.H. Saltzer, and R.M. Needham, "Reducing Risks from Poorly Chosen Keys," Opera ng
Systems Review 23(5) pp. 14-18 ACM, (dezembro de 1989).

Mill87. S.P. Miller, B.C. Neuman, J.I. Schiller, and J.H. Saltzer, "Kerberos Authen ca on and Authoriza on System," in
Project Athena Technical Plan, (dezembro de 1987). Seção E.2.1.

Mill88. D.L. Mills, "Network Time Protocol," RFC 1059 (julho de 1988).

Mill89. D.L. Mills, "Network Time Protocol," RFC 1119 (setembro de 1989).

Moor88. J.H. Moore, "Protocol Failures in Cryptosystems," Proc. IEEE 76(5) pp. 594-602 (maio de 1988).

Morr79. R. Morris and K. Thompson., "UNIX Password Security," Communica ons of the ACM 22(11) p. 594 (novembro
de 1979).

Morr85. R.T. Morris, "A Weakness in the 4.2BSD TCP/IP So ware," Compu ng Science Technical Report No. 117, AT&T
Bell Laboratories, Murray Hill, New Jersey (fevereiro de 1985).

Post80. J.B. Postel, "User Datagram Protocol," RFC 768 (28 de agosto de 1980).

Post81. J.B. Postel, "Transmission Control Protocol," RFC 793 (setembro de 1981).

Post83. J.B. Postel and K. Harrens en, "Time Protocol," RFC 868 (maio de 1983).

Rive90. R.L. Rivest, "MD4 message digest algorithm," RFC 1186 (outubro de 1990).

Salt90. J.H. Saltzer, comunicação privada em 19 de junho de 1990.

Stei88. J. Steiner, C. Neuman, and J.I. Schiller, "Kerberos: An Authen ca on Service for Open Network Systems," in
Proc. Winter USENIX Conference, , Dallas (1988).

Stol88. C. Stoll, "Stalking the Wiley Hacker," Communica ons of the ACM 31(5) p. 484 (maio de 1988).

Voyd83. V.L. Voydock and S.T. Kent, "Security Mechanisms in High-Level Network Protocols," ACM Computer Surveys
15(2) pp. 135-171 (junho, 1983).

Steven M. Bellovin obteve um diploma de bacharel em Columbia University e um mestrado e doutorado em Ciência da
Computação pela University of North Carolina em Chapel Hill. Enquanto era estudante de pós-graduação, ele escreveu a versão
original do pathalias e ajudou a criar o netnews. No entanto, o primeiro não é uma infração passível de acusação, e o prazo de
prescrição para o úl mo expirou. No entanto, ele ainda está se redimindo por ambas as ações. Ele trabalha nos Laboratórios Bell
da AT&T desde 1982, onde realiza pesquisas em redes, segurança e nas razões pelas quais as duas não se dão bem. Ele pode ser
contatado eletronicamente como smb@ulysses.a .com; aqueles que preferem evitar o desperdício de papel podem enviar
correspondências para a Sala 3C-536B, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, NJ 07974, EUA.

Michael Merri obteve um diploma de bacharel em Yale University, e um mestrado e doutorado em Ciência da Informação
e Computação no Georgia Ins tute of Technology. Sua dissertação, "Protocolos Criptográficos", desenvolveu técnicas para explorar
propriedades de segurança de algoritmos distribuídos. Ele está nos Laboratórios Bell da AT&T desde 1983, onde realiza pesquisas
em sistemas distribuídos e segurança. Seu endereço de e-mail é mischu@research.a .com; correspondências podem ser enviadas
para a Sala 3D-458, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, NJ 07974, EUA.