Kerberos - Cena III

Projetando um sistema de autenticação, um diálogo em quatro cenas

A manhã seguinte. Athena pega o Eurípedes no canto do café. Ela dá um tapinha no seu ombro enquanto ele enche o seu copo.
Os dois andam em direção da máquina do café.

Athena	Tenho uma nova versão do Caronte para resolver os nossos problemas.
Eurípedes	Sério? Que rápido.
Athena	Bem, você sabe, problemas dessa natureza me fazem perder o sono.
Eurípedes	Deve ser o peso na consciência. Vamos repousar naquela salinha de reuniões?
Athena	Por que não?
	Os dois se movem para a salinha de reuniões.
Athena	Iniciarei expondo os problemas novamente: você só precisará fornecer a sua senha somente uma vez. Eu resolvi esse requisito inventando um novo serviço de rede. Ele se chama "concessionária de tickets", um serviço que edita os tickets do Caronte para o usuário que já tenha comprovado a sua identidade para o Caronte. Você pode utilizar essa concessionária de tickets se você tiver um ticket para ela, um ticket-concessor de ticket. A concessionária de tickets é exatamente de fato uma versão do Caronte, uma vez que ele precisa acessar a base de dados do Caronte. Ele é uma parte do Caronte que permite você se autenticar com um ticket ao invés de uma senha. De qualquer maneira, o sistema autenticador agora trabalha da seguinte maneira: você se loga na sua estação de trabalho e utiliza um programa chamado kinit para contatar o serviço Caronte. Você comprova a sua identidade para o Caronte, e o prgrama kinit pega para você um ticket-concessor de ticket. Agora digamos que você quer pegar a sua correspondência no servidor de correio. Você ainda não tem um ticket do servidor de correio, então você usa o ticket-concessor de ticket para pegar o ticket do servidor de correio para você. Você não precisa usar a sua senha para pegar o novo ticket.
Eurípedes	Eu preciso pegar um novo ticket-concessor de ticket toda vez que eu precisar acessar um outro serviço da rede?
Athena	Não. Lembre-se, nós concordamos da última vez que os tickets podem ser reutilizados. Uma vez que você tenha adquirido um ticket-concessor de ticket, você não precisa pegar outro. Você usa o ticket-concessor de ticket para obter os outros tickets que você necessitar.
Eurípedes	Certo, isso faz sentido. E desde que você possa reusar os tickets, uma vez que a concessionária de tickets te deu um ticket para um serviço específico, você não precisa pegar tickets específicos novamente.
Athena	É isso aí, não ficaria interessante?
Eurípedes	Comprei a idéia faz já tempo... Contanto que você não tenha que enviar a sua senha em texto aberto na rede para pegar o ticket-concessor de ticket.
Athena	Conforme eu disse, já resolvi esse problema também. A questão é, quando eu digo que você precisa contatar o Caronte para pegar o ticket-concessor de ticket, eu quis dizer que você precisa enviar a sua senha em texto aberto sobre a rede para o Servidor do Caronte. Mas isso não precisaria ser assim. A coisa funciona assim. Quando você utiliza o programa kinit para pegar o ticket-concessor de ticket, o kinit não envia a sua senha para o servidor Caronte, o kinit envia somente o seu nome de usuário.
Eurípedes	Legal.
Athena	O Caronte usa o nome de usuário para localizar a sua senha. Depois o Caronte monta um pacote de dados que contém o ticket-concessor de ticket. Antes dele te enviar o pacote, o Caronte usa a sua senha para criptografar o conteúdo do pacote. A sua estação de trabalho recebe o pacote do ticket. Você entra a sua senha, o kinit tenta descriptografar o ticket com a senha que você forneceu. Se o kinit for bem sucedido, você terá se autenticado com sucesso junto ao Caronte. Você agora possui um ticket-concessor de ticket, e esse ticket obterá os outros tickets que você requisitar. Como isso soa mestre?
Eurípedes	Não sei... estou pensando. Sabe, eu acho que as partes do sistema que você descrever agora estão legais. O seu sistema solicita que eu me autentique somente uma vez. Depois disso, o Caronte pode me conceder tickets de serviço sem a minha intervenção. Sem ressalvas em relação a isso. Mas ainda tem alguma coisa no desenho do ticket de serviço que me incomoda. Tem a ver com o fato de os tickets serem reusáveis. Eu ainda concordo que eles têm que ser reusáveis, porém tickets reusáveis são, devido a sua natureza, muito perigosos.
Athena	Como assim?
Eurípedes	Veja o seguinte. Suponha que você esteja utilizando uma estação de trabalho insegura. Durante a sua sessão logada, você adquire um ticket de serviço de correio, um ticket de serviço de impressão e um ticket de serviço de arquivo. Suponha que inadvertidamente, você deixe esses tickets na sua estação de trabalho quando você faça o logout. Agora suponha que eu me logue na sua estação de trabalho e localize aqueles tickets. Eu faço a sua estação de trabalho pensar que eu sou você, e desde que os tickets são confeccionados no seu nome, eu posso utilizar o programa cliente de correio para acessar a sua correspondência, eu posso utilizar o cliente do servidor de arquivos para acessar e remover os seus arquivos e posso utilizar os comandos de impressão deixando as contas para você pagar. Tudo porque esses tickets foram acidentalmente deixados por aí. E nada pode me deter de copiar esses tickets para onde eu quiser. E posso continuar a utilizá-los eternamente.
Athena	Mas é fácil corrigir isso. Só precisamos escrever um programa que destura os tickets dos usuários depois de cada sessão logada. Você não poderá utilizar tickets que tenham sido destruídos.
Eurípedes	Bem, obviamente o seu sistema precisará de um programa destruidor de tickets, mas é besteira deixar os usuários confiarem nisso. Você não pode depender que usuários lembrem-se de destruir os seus tickets todas as vezes que eles terminarem uma sessão na estação de trabalho. E mesmo se você confiar que os seus usuários destruirão os seus tickets, considere o seguinte cenário. Eu tenho um programa que monitora o tráfego de rede e copia os tickets de serviço enquanto eles cruzam a rede. Agora imagine eu judiando de você. Eu espero você iniciar uma sessão na sua estação de trabalho, eu rodo o meu programa e copio uma porção dos seus tickets. Eu espero você finalizar a sua sessão até você se deslogar e sair. Eu dou um balão com o software de rede da minha estação de trabalho e altero o endereço para que ele tenha o mesmo endereço que a estação de trabalho que você estava utilizando quando você adquiriu os tickets que eu copiei. Eu faço a minha estação de trabalho acreditar que eu sou você. Eu tenho os seus tickets, os seu nome de usuário e o endereço correto do endereço da rede. Eu posso REUSAR esses tickets e utilizar serviços no seu nome. Não importa que você distruiu os tickets antes de você finalizar a sessão na sua estação de trabalho. Os tickets que eu roubei serão válidos sempre que eu quiser usá-los, porque atualmente o seu projeto de tickets não coloca uma limitação no número de vezes para o reuso, ou por quanto tempo eles permanecem válidos.
Athena	Entendi o que você quis dizer! Tickets não podem ser válidos para sempre porque eles podem constituir um enorme risco de segurança. Nós temos que restringir a duração do tempo de uso do ticket, talvez dando a cada ticket algum tipo de data de expiração.
Eurípedes	Exatamente. Eu acho que cada ticket precisa ter duas informações adicionais: o tempo de vida que indica a duração do tempo de validade de cada ticket, e um selo cronológico que indica a data e a hora em que o Caronte emitiu o ticket. Estão o ticket ficaria mais ou menos assim: Eurípedes vai até a lousa e rabisca o seguinte: TICKET {nomedeusuario: endereço: serviço: tempodevida: selocronologico} Agora quando um serviço descriptografar os tickets, ele irá checar o usuário e o endereço do ticket contra o nome e o endereço da pessoa que enviou o ticket, e ele irá utilizar as informações de tempo de vida e o selo cronológico para verificar se o ticket expirou.
Athena	Certo. Qual o tempo de vida um serviço de ticket característico deve ter?
Eurípedes	Não sei. Talvez o tamanho de uma sessão típica na estação de trabalho. Digamos oito horas.
Athena	Então se eu fico na minha estação de trabalho por mais de oito horas, todos os tickets expiram. Isso inclui o meu ticket-concessor de ticket. Então eu preciso me reautenticar no Caronte depois de oito horas.
Eurípedes	Não seria demais, não é?
Athena	Acho que não. Então estamos combinados, os tickets expiram depois de oito horas. Agora eu tenho uma questão para você. Suponha que eu tenha copiado os SEUS tickets da rede...
Eurípedes	(Olhos cintilando). Ei Tina! Você não faria uma coisa dessas, faria?
Athena	É só um exemplo. Eu copiei os seus tickets. Agora eu espero você se deslogar. Suponha que você tenha uma consulta médica uma uma aula para ministrar, então você finaliza a sessão na sua estação de trabalho depois de algumas horas. Você é um cara esperto e destruiu as cópias dos seus tickets antes de se deslogar. Mas eu roubei os seus tickets e eles possuem seis horas de vida. O que me dá um grande intervalo de tempo para pilhar os seus arquivos e imprimir milhares de cópias no seu nome. Veja, esse negócio de tempo de vida e selo cronológico funcionam bem no caso de um ladrão tentar reusar o ticket depois que ele tenha expirado. Se o ladrão puder reusar o ticket antes disso...
Eurípedes	Uhn... Claro, você está certa.
Athena	Acho que estamos frente à um grande problema (ela suspira)
	Pause
Eurípedes	Acho que isso significa que você vai ter uma noite daquelas. Quer mais café?
Athena	Porque não?

------------------
Cena IV


---------------------
Revisões
Traduzido em 04/10/2007 14:20 em aprox. 2:30 hr
Editado e publicado em 09/10/2007 19:30 em aproximadamente 1:45 hr