Kerberos - Cena II

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

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


Popular posts from this blog

Atom - Jupyter / Hydrogen

Design Patterns

Robson Koji Moriya disambiguation name