Kerberos - Cena II
Projetando um sistema de autenticação, um diálogo em quatro cenas
------------------
Cena III
Cena IV
Epílogo
Athena | Bem, descobri como tornar seguro um ambiente de rede aberto de modo que um colega inescrupuloso como você não possa utilizar os serviços de rede em nome de outras pessoas. |
Eurípedes | É mesmo? Sente-se. |
Ela se senta. | |
Athena | Antes de eu descrevê-lo, vamos estabelecer as regras básicas do que estamos discutindo? |
Eurípedes | Quais são as regras? |
Athena | Bem, suponha que eu diga algo como: "Eu quero o meu correio eletrônico, portanto eu contato o servidor de correio e solicito que ele envie a correspondência para a minha estação de trabalho.". Na realidade, não sou eu a entidade que contata o servidor de correio. Eu estou utilizando um programa que contata o servidor de correio e resgata a minha correspondência, um programa que é um CLIENTE do programa servidor de correio. Mas não estou querendo dizer que o cliente faz "coisa e tal" todas as vezes que me refiro a uma transação entre o usuário e o servidor de rede. Eu poderia dizer de uma maneira melhor que eu faço "coisa e tal", tendo em mente, claro, que o programa cliente está fazendo as coisas em meu nome. Comprendeu? |
Eurípedes | Claro, sem problema. |
Athena | Certo. Tudo bem, eu vou iniciar expressando o problema que acabei dveteranoe resolver. Em um ambiente de rede aberto, máquinas que fornecem serviços precisam estar aptas à confirmar a identidade das pessoas que solicitam serviços. Se eu contato o servidor de correio e solicito a minha correspondência, o programa que provê o serviço precisa estar apto à verificar que eu seja quem eu digo ser, certo? |
Eurípedes | Certo. |
Athena | Você pode resolver o problema de maneira inconveniente, requerindo que o servidor de correio solicite a senha antes de eu poder utilizá-lo. Eu provo para o servidor que eu sou fornecendo a minha senha. |
Eurípedes | É certamente inconveniente. Em um sistema desses, todos os servidores precisam saber a sua senha. Se a rede tiver mil usuários, cada servidor precisa saber mil senhas. Se você quiser alterar a sua senha, você precisa contatar todos os servidores e notificá-los da mudança. Entendi que o seu sistema não é bobo assim. |
Athena | O meu sistema não é bobo. Ele trabalha assim: Não somente as pessoas possuem senhas, serviços têm senha também. Cada usuário sabe a sua senha, cada serviço sabe a sua senha e existe um SERVIÇO DE AUTENTICAÇÃO que sabe TODAS as senhas, cada senha de usuário e cada senha de serviço. O serviço de autenticação armazena as senhas em uma base de dados simples e centralizada. |
Eurípedes | Você tem um nome para esse sistema de autenticação? |
Athena | Ainda não pensei em um. Você tem alguma idéia? |
Eurípedes | Qual o nome do camarada que transporta os mortos através do Rio Styx? |
Athena | Caronte? |
Eurípedes | Isso, é ele. Ele não te leva a cruzar o rio ao menos que você possa provar a sua identidade. |
Athena | Vem você de novo Rip, querendo rescrever a mitologia grega novamente. Caronte não está nem aí com a sua identidade. Ele só quer saber se você está morto. |
Eurípedes | Você tem um nome melhor? |
Pausa | |
Athena | Não, não tenho. |
Eurípedes | Então vamos chamar o serviço de autenticação "Caronte". |
Athena | Tudo bem. Posso descrever o sistema então? Digamos que você que utilizar um serviço, o serviço de correio. No meu sistema você não pode utilizar um serviço ao menos que, ahn, Caronte diga ao serviço que você é quem você diz ser. E voc não pode obter a permissão para utilizar o serviço ao menos que você tenha se autenticado para o Caronte. Quando você solicita autenticação do Caronte, você precisa dizer ao Caronte o serviço para o qual você quer a permissão. Se você quiser utilizar o serviço de correio, você precisa dizer ao Caronte. Caronte solicita que você prove a sua identidade. Que você realiza fornecendo a sua senha secreta. Caronte pega a sua senha e compara com a que está registrada para você no base de dados do Caronte. Se as duas senhas coincidem, Caronte considera que a sua identidade foi verificada. Caronte precisa convencer o servidor de correio que você é quem você diz que é. Desde que Caronte sabe a senha de todos os serviços, ele sabe a senha do serviço de correio. É concebível que Caronte possa passar a senha para você, à qual você poderá enviar para o serviço de correio como prova de que você se autenticou com o Caronte. O problema é, Caronte não pode te dar a senha diretamente, porque senão você teria acesso a ela. A próxima vez que você quizesse a correspondência, você evitava o Caronte e utilizaria o servidor de correio sem a sua correta identificação. Você poderia inclusive fingir ser alguém e utilizar o servidor de correio no nome de outra pessoa. Então ao invés de dar a senha do servidor de correio, Caronte te dá um TICKET de serviço de correio. Esse ticket contém uma versão do seu nome de usuário que foi CRIPTOGRAFADA UTILIZANDO a SENHA DO SERVIÇO DE CORREIO. Ticket em mãos, você pode agora solicitar o serviço de correio para a sua correspondência. Você faz a sua solicitação dizendo ao servidor de correio quem você é e fornecendo o ticket que prova que você é quem você diz que você é. O servidor utilizar a senha dele para descriptografar o ticket, e se o ticket descriptografar corretamente, o servidor se depara com o nome de usuário que o Caronte colocou no ticket. O serviço compara esse nome com o nome que você enviou com o ticket. Se os nomes coincidirem, o servidor de correio considera a sua identidade comprovada e prossegue para te entregar a sua correspondência. Que tal? |
Eurípedes | Eu tenho algumas perguntas. |
Athena | Como sempre. Vá em frente. |
Eurípedes | Quando o programa de um serviço descriptografa um ticket, como ele sabe que ele descriptografou o ticket corretamente? |
Athena | Não sei. |
Eurípedes | Talvez você possa incluir o nome do serviço no ticket. Dessa maneira, quando um serviço descriptografar um ticket, ele pode avaliar o seu sucesso ao encontrar ou não o seu nome no ticket descriptografado. |
Athena | Me parece bom. Então o ticket ficará meio assim: Ela rabisca o seguinte em um rascunho de papel: TICKET {nomedousuario:nomedoserviço} |
Eurípedes | Então o ticket de serviço contém somente o seu nome de usuário e o nome do serviço? |
Athena | Criptografado com a senha do serviço. |
Eurípedes | Eu não acho que essas informações sejam suficientes para que o ticket seja seguro. |
Athena | Como assim? |
Eurípedes | Vamos supor que você solicite ao Caronte um ticket para o servidor de correio. Caronte irá preparar o ticket que terá o nome de usuário "tina" contido nele. Suponha que eu copie aquele ticket enquanto ele trafega na rede do Caronte para você. Eu convença a minha estação de trabalho insegura de que o meu nome de usuário é "tina". O programa cliente de correio na minha estação de trabalho pensa que eu sou você. Sob o seu nome, o programa envia o ticket roubado para o servidor de correio. O servidor descriptografa o ticket e veririca que ele é válido. O nome de usuário no ticket bate com o nome de usuario que enviou o ticket. O servidor de correio me entrega a sua correspondência... |
Athena | Oh-ou! Isso não é nada bom. |
Eurípedes | Mas eu acho que sei uma maneira de resolver esse problema. Ou ao menos providenciar um solução parcial. Creio que o Caronte poderia incluir mais informações nos tickets de serviço que ele irá produzir. Adicionalmente ao nome de usuário, o ticket poderia incluir também o ENDEREÇO DE REDE de onde o usuário solicitou o ticket para o Caronte. O que fornecerá um nível adicional de segurança para você |
Athena | Bravo, bravo! Como não pensei nisso antes. |
Eurípedes | Ah se não sou eu. |
Athena | Então o formato do ticket revisado ficaria mais ou menos assim Ela rabisca o seguinte na lousa: TICKET {nomedeusuário: estaçãodettrabalho_endereço: nomedoserviço} |
Athena | Agora estou excitada. Vamos construir o sistema Caronte e ver se ele funciona! |
Eurípedes | Ainda não. Eu tenho algumas outras questões sobre o seu sistema. |
Athena | Certo. (Athena se desloca para frente na sua cadeira) Manda ver. |
Eurípedes | Tipo, eu tenho que pegar um novo ticket a cada vez que eu quiser utilizar um serviço. Se eu estou em um dia lotado de trabalho, provavelmente eu pegarei a minha correspondência mais de uma vez. Eu precisarei de um novo ticket a cada vez que eu quiser pegar a minha correspondência? Se for verdade, eu não gostei do seu sistema. |
Athena | Ahn... Bem, eu não acho que os tickets não possam ser reutilizados. Se você tiver um ticket para o servidor de correio, você poderia utilizá-lo novamente. Por exemplo, quando o programa cliente de correio faz uma solicitação para um serviço em seu nome, ele envia uma CÓPIA do ticket para o servidor de correio. |
Eurípedes | Assim está melhor, mas ainda vejo problemas. Me parece que você está dizendo que eu tenho que enviar a minha senha para o Caronte toda vez que eu quiser utilizar um serviço para o qual eu não tenha um ticket. Eu me logo e quero acessar os meus arquivos. Eu mando uma requisição para o Caronte para o ticket apropriado e isso significa que eu tenho que usar a minha senha. Então eu quero ler a minha correspondência. Outra requisição para o Caronte, eu preciso entrar a minha senha novamente. Agora suponha que eu queria enviar uma das minhas mensagens para o servidor de impressão. Outra requisição para o Caronte e, bem acho que você captou. |
Athena | Ahn, sim, peguei. |
Eurípedes | Como se isso não bastasse, considere o seguinte: Tipo, quando você se autentica para o Caronte, você envia a sua senha secreta na rede em texto aberto. Pessoas expertas como você podem monitorar a rede e roubar cópias das senhas das pessoas. Se eu tenho a sua senha, eu posso utilizar qualquer serviço em seu nome. |
Athena suspira. | |
Athena | Esses problemas são complicados. Acho que eu preciso voltar pra prancheta. |
------------------
Cena III
Cena IV
Epílogo
---------------------
Revisões
Traduzido em 29/09/2007 14:20 em aprox. 1:30 hr
Editado e publicado em 01/10/2007 03:50 em aproximadamente 2:45 hr