_rascunho/rede/protocolos/kerberos.txt

@@ -33,6 +33,16 @@ Em outras palavras, se um usuário tenta acessar um serviço de e-mail, por exem
 * Uma vez que o processo de autenticação é concluído, o usuário e o serviço podem estabelecer uma comunicação criptografada, se desejado. Para isto, o protocolo suporta o uso de uma chave criptográfica compartilhada entre usuário e serviço para a troca de informações.
 * Aplicações que fizerem uso do Kerberos devem ser adaptadas para isso (tanto no software cliente quanto no software servidor). Nem todas as aplicações são integradas ao Kerberos.
 
+## Implementações do Kerberos
+
+Um protocolo apenas define características que o serviço deve oferecer, entretanto não é o serviço em si. Este dependerá das suas implementações, isto é, o software que apresentará as características do protocolo. Algumas das implementações do Kerberos, de código-fonte livre são:
+
+* **MIT Kerberos[^2]:** a primeira implementação, criada no MIT, onde foi criado também o protocolo.
+* **Heimdal Kerberos[^3]:** o Heimdal Kerberos foi criado na Suécia, quando o MIT Kerberos ainda era restrito por leis de exportação. O Heimdal não impunha tais restrições (que em 2000 deixaram de existir também para a implementação do MIT).
+* **GNU Shishi[^4]:** implementação GNU do protocolo Kerberos V5.
+* **Apache Directory[^5]:** além de serviço de LDAP, o Apache Directory também oferece um KDC.
+* **Apache Kerby[^6]:** outra implementação do Kerberos mantido pela fundação Apache.
+
 ## Por que usar o Kerberos
 
 Identificar pessoas é um hábito comum. Cada pessoa tem características únicas, como a aparência física, a voz ou até mesmo o cheiro, que dão aos nossos sentidos a capacidade de distinguir as pessoas umas das outras. E nos damos ao trabalho de identificar pessoas antes de conversar ou interagir com elas porque nossas palavras e ações serão medidas de acordo com os nossos interlocutores. O que diremos a uma pessoa não necessariamente diremos a outra. Em outras palavras, saber com quem nos comunicamos importa para a comunicação.
@@ -63,7 +73,7 @@ O protocolo Kerberos trabalha com o conceito de *Realm* (entenda como domínio,
 
 Usuários e serviços fora de um realm não podem ser autenticados pelo Kerberos deste realm, mas podem fazer parte de um outro realm. Isto significa que eles podem ser autenticados pelo serviço Kerberos deste outro realm. Também é possível estabelecer uma relação de confiança entre diferentes realms, de forma que o usuário de um realm consiga acessar o serviço de outro realm.
 
-Para fazer parte de um realm, o usuário deve compartilhar um segredo (sua senha) com o Kerberos daquele realm. O nome de um realm é *case-sensitive*, isto é, o realm GNULINUX.NET.BR é diferente do realm gnulinux.net.br. Por convenção, usa-se caixa alta para nomes de realms. Também é comum que tenham nome igual ao do domínio DNS do qual fazem parte (embora em caixa alta).
+Para fazer parte de um realm, o usuário deve compartilhar um segredo (sua senha) com o Kerberos daquele realm. O nome de um realm é *case-sensitive*, isto é, o realm *GNULINUX.NET.BR* é diferente do realm *gnulinux.net.br*. Por convenção, usa-se caixa alta para nomes de realms. Também é comum que tenham nome igual ao do domínio DNS do qual fazem parte (embora em caixa alta).
 
 ### Principal
 
@@ -73,24 +83,24 @@ Porém serviços também são principals e estes não se autenticam digitando um
 
 O padrão de nomenclatura para principals que são usuários é formado por uma sequência de componentes e pelo realm, conforme observado a seguir:
 
-componente1/componente2/componente3/.../componenteN@REALM
+`componente1/componente2/componente3/.../componenteN@REALM`
 
 Na prática, porém, o uso convencional inclui no máximo dois componentes (nome e opcionalmente uma instância), como a seguir:
 
-nome[/instância]@REALM
+`nome[/instância]@REALM`
 
 A instância é útil para contextualizar o usuário. Por exemplo, eu poderia criar um usuário normal para mim, e outro também para mim, mas com capacidades administrativas, pois assim não misturaria as funções de usuário normal com as de administrador. Esses usuários seriam:
 
-hrcerq@GNULINUX.NET.BR
-hrcerq/admin@GNULINUX.NET.BR
+`hrcerq@GNULINUX.NET.BR`
+`hrcerq/admin@GNULINUX.NET.BR`
 
 O padrão de nomenclatura para principals que correspondem a serviços é composto pelo nome do serviço e pelo servidor onde opera, conforme observado a seguir:
 
-serviço/servidor@REALM
+`serviço/servidor@REALM`
 
 Por exemplo:
 
-imap/mail.gnulinux.net.br@GNULINUX.NET.BR
+`imap/mail.gnulinux.net.br@GNULINUX.NET.BR`
 
 É importante que o nome do servidor (no exemplo acima, *mail.gnulinux.net.br*) corresponda exatamente ao nome qualificado, definido para este servidor no DNS.
 
@@ -115,7 +125,7 @@ O tíquete é criptografado com a senha do serviço para quem ele é destinado.
 
 Pense no Kerberos como uma autoridade central, que fiscaliza as tentativas de acesso a serviços, impedindo que impostores sejam considerados legítimos. Então, o usuário deve primeiramente se reportar a essa autoridade, solicitando seu primeiro tíquete, que é conhecido como *Ticket Granting Ticket* (tíquete de concessão de tíquetes) - TGT. O TGT é um tíquete especial, pois servirá para que o usuário obtenha todos os demais tíquetes que precisar.
 
-Cada serviço requer um tíquete diferente. Assim, quando o usuário precisa acessar um serviço, ele vai precisar solicitar um tíquete de acesso daquele serviço. Para fazer esta solicitação, o usuário deverá apresentar o TGT ao Kerberos. Caso o usuário já disponha do tíquete de um determinado serviço, não terá que solicitar novamente. Tíquetes são reutilizáveis, mas só até certo ponto. Eles tem um prazo para expirar (em geral 10 horas), o que garante que não possam ter muita utilidade caso sejam interceptados.
+Cada serviço requer um tíquete diferente. Assim, quando o usuário precisa acessar um serviço, ele vai precisar solicitar um tíquete de acesso daquele serviço. Para fazer esta solicitação, o usuário deverá apresentar o TGT ao Kerberos. Caso o usuário já disponha do tíquete de um determinado serviço, não terá que solicitar novamente. Tíquetes são reutilizáveis, mas só até certo ponto. Eles tem um prazo para expirar (em geral 10 horas, mas isto é configurável), o que garante que não possam ter muita utilidade caso sejam interceptados.
 
 ### Criptografia
 
@@ -131,7 +141,7 @@ A cada vez que o usuário substitui sua senha, a função string2key é acionada
 
 Outra novidade do Kerberos V5 foi a inclusão de um mecanismo conhecido como **salt** na função string2key. O salt nada mais é que um texto (o nome do principal) concatenado com a senha antes da aplicação da função hash, conforme a seguinte fórmula:
 
-Chave = string2key(<senha> + <nome do principal>)
+Chave = string2key(*senha* + *nome do principal*)
 
 Esse mecanismo permite que usuários de mesmo nome, mas instâncias diferentes (ou realms diferentes) tenham chaves diferentes. Como se pode supor, não basta então que diferentes implementações tenham um algoritmo criptográfico em comum para serem compatíveis. Além disso, devem usar ao menos um algoritmo de hash em comum para a função string2key, e devem aplicar o salt da mesma maneira.
 
@@ -183,29 +193,124 @@ De modo simplificado, podemos separar a comunicação neste protocolo em três e
 
 Perceba, portanto, que o protagonista de todo o processo é o usuário. O KDC nunca faz comunicação direta com os serviços. Em vez disso, ele entrega mensagens ao usuário, que as repassa ao serviço que vai acessar. Isso será melhor compreendido nas seções a seguir.
 
+Na nomenclatura da especificação do protocolo, as mensagens que serão detalhadas a seguir são chamadas pelos seguintes nomes:
+
+* **KRB_AS_REQ**: mensagem enviada pelo usuário ao serviço de autenticação (AS);
+* **KRB_AS_REP**: mensagem devolvida pelo AS ao usuário;
+* **KRB_TGS_REQ**: mensagem enviada pelo usuário ao serviço de concessão de tíquetes (TGS);
+* **KRB_TGS_REP**: mensagem devolvida pelo TGS ao usuário;
+* **KRB_AP_REQ**: mensagem enviada pelo usuário à aplicação;
+* **KRB_AP_REP**: mensagem devolvida pela aplicação ao usuário (somente quando a autenticação mútua é requerida).
+
 ### Autenticação
 
+**KRB_AS_REQ:**
+
 Em uma rede *kerberizada*, o primeiro passo do usuário é se autenticar com o KDC por meio do serviço de autenticação (AS). O usuário, com seu software cliente do Kerberos conecta-se ao AS para se identificar. Esse primeiro passo é necessário para que ele possa ter acesso a qualquer serviço da rede que faça parte do realm daquele KDC.
 
-Nesse primeiro contato, o usuário envia uma requisição ao AS, informando seu nome de usuário. O AS vai varrer a base de dados do KDC à procura do principal correspondente a este nome. Convém lembrar: a base de dados do KDC contempla todos os principals e suas chaves criptográficas. Isso faz do KDC um serviço que requer medidas de segurança bastante rigorosas. Pois bem, o AS verifica se o usuário informado consta nessa base de dados, e caso o encontre, prosseguirá com a geração de um TGT.
+Nesse primeiro contato, o usuário envia uma mensagem ao AS. Essa mensagem não contém dados sensíveis, portanto não é criptografada. Ela contempla as informações a seguir:
+
+`( Pu + Ps + IP + V )`
+
+Onde **Pu** é o principal do usuário, **Ps** é o principal do serviço a ser acessado, **IP** é uma lista de endereços a partir dos quais o serviço será acessado. Este parâmetro é opcional, e caso omitido significa que os tíquetes recebidos podem ser usados a partir de qualquer endereço. **V** é o tempo de validade máximo desejado para os tíquetes recebidos.
+
+**KRB_AS_REP:**
+
+Ao receber a requisição do usuário, o AS vai varrer a base de dados do KDC à procura dos principals correspondentes ao usuário e ao serviço. Convém lembrar: a base de dados do KDC contempla todos os principals do seu realm, e suas chaves criptográficas. 
+
+Pois bem, o AS verifica se o usuário e o serviço informados constam nessa base de dados, e caso os encontre, prosseguirá com a geração de uma chave de sessão, que será o segredo compartilhado entre o usuário e o serviço de concessão de tíquetes (TGS).
+
+A necessidade deste segredo compartilhado está no fato de que a comunicação seguinte será feita entre o usuário e o TGS. Assim, a chave de sessão é gerada, e em seguida o AS vai gerar também o TGT, que terá as informações a seguir:
+
+`( Pu + Ptgs + IP + T + V + CStgs )`
+
+**Pu** é o principal do usuário, **Ptgs** é o principal do serviço de concessão de tíquetes (TGS), **IP** é a lista de endereços de rede que podem usar esse TGT, **T** é o horário (*timestamp*) em que o TGT foi criado, **V** é o prazo de validade desse TGT, e **CStgs** é a chave de sessão que será conhecida apenas entre o usuário e o TGS. 
+
+Como todo tíquete, o TGT é criptografado com a chave do serviço ao qual ele é destinado (neste caso, o TGS). Já que as informações do TGT não devem ser acessíveis ao usuário que fez a requisição, então algumas delas precisam ser transmitidas fora do TGT, de forma que o usuário possa ter acesso. Assim, a resposta do AS para o usuário será:
+
+`{( Ptgs + T + V + CStgs )}Cpu + {TGT}Ctgs`
+
+Perceba que a chave de sessão (CStgs) é transmitida ao usuário, em um pacote criptografado com a chave deste usuário (**Cpu**) e será posteriormente transmitida ao TGS por meio do TGT, criptografado com a chave do TGS (**Ctgs**). Isto garante que a chave de sessão não trafegue desprotegida e assim somente o usuário e o TGS conhecerão esta chave.
+
+Ao receber este pacote, o cliente Kerberos do usuário solicitará a senha. Ao digitar a senha, o usuário atesta que é ele mesmo. Essa senha será concatenada ao *salt* e transformada pela função *string2key*. O resultado dessa transformação será a chave do usuário, que vai ser capaz de descriptografar este pacote. O TGT, por sua vez, não será descriptografado pelo usuário (lembre-se: ele é destinado ao TGS). Portanto, o usuário vai apenas transmití-lo ao TGS na etapa de obtenção do tíquete do serviço.
+
+#### Pré-autenticação
+
+Observe que na etapa de requisição (*KRB_AS_REQ*), o usuário envia o principal do usuário, o principal do serviço, uma lista (opcional) de endereços IPs e o tempo máximo de validade desejado para os tíquetes obtidos. Com essas informações, ele consegue obter um pacote criptografado com a senha do usuário e o TGT. Perceba que essas informações enviadas pelo usuário podem ser facilmente obtidas por um impostor.
+
+Se um impostor obtiver um pacote criptografado com a senha do usuário autêntico, poderá usar esse pacote para descobrir a senha do usuário por meio de testes de força bruta. Para evitar que isso ocorra, o protocolo prevê um recurso extra de segurança, chamado de pré-autenticação. Este recurso não é obrigatório, e fica a critério da implementação do protocolo se ele será usado ou não.
+
+Quando este recurso está ativado, um procedimento adicional ocorre entre a requisição do usuário e a resposta do AS. Quando o AS recebe a requisição do usuário, em vez de retornar de imediato a chave de sessão e o TGT, ele envia uma mensagem de volta informando que uma pré-autenticação é necessária.
+
+Feito isso, o cliente Kerberos do usuário que enviou a requisição vai capturar o horário atual e criptografá-lo com a chave do usuário. Portanto o usuário deverá digitar sua senha, que será transformada pela função *string2key*, aplicando o *salt*. Ele vai enviar esse pacote ao AS, que também possui acesso à chave do usuário e portanto deverá ser capaz de descriptografá-lo. Caso esse processo ocorra sem erros, a requisição será considerada legítima e então o AS vai retornar a resposta necessária para que o usuário consiga prosseguir com a obtenção do tíquete.
 
 ### Obtenção do tíquete
 
-Como já foi explicado, o TGT é o tíquete que permite a obtenção de outros tíquetes. O TGT, é obtido por meio do AS. Porém todos os demais tíquetes são fornecidos pelo TGS (que pode ser entendido como apenas mais um entre os demais serviços da rede). Ocorre que todo serviço também tem uma chave (armazenada na base do KDC, como a de qualquer usuário normal). Dessa forma, o TGS também tem a sua chave. E talvez você se pergunte o porquê disso.
+**KRB_TGS_REQ:**
+
+Nesta etapa, o usuário já possui o TGT. Como já foi explicado, o TGT é o tíquete que permite a obtenção de outros tíquetes. O TGT é obtido por meio do AS. Porém todos os demais tíquetes são fornecidos pelo TGS (que pode ser entendido como apenas mais um entre os demais serviços da rede). O usuário ainda precisa de um tíquete para a aplicação que deseja acessar, e o TGS é o serviço que fornecerá esse tíquete.
 
-Pois bem, um tíquete é composto por um conjunto de informações que, se interceptadas, permitirão que um impostor forje seus tíquetes. Por este motivo, o AS gera o TGT e o criptografa com a chave do TGS. Dessa forma, nem mesmo o usuário que solicitou o tíquete terá acesso a este conteúdo. Porém ele poderá entregar este tíquete ao TGS, que vai ser capaz de descriptografá-lo e verificar se a requisição é legítima ou não.
+Convém lembrar que apenas possuir o TGT não basta para que o usuário seja considerado autêntico. Se assim fosse, quando o usuário transmitisse o TGT ao TGS, esse TGT poderia ser interceptado na rede e retransmitido por um impostor. Entretanto, o usuário possui mais uma informação importante: a chave de sessão. Portanto, o usuário constrói um pacote de informações chamado *autenticador*, contemplando seu principal e o horário atual, criptografados com essa chave de sessão:
+
+`{( Pu + T )}CStgs`
+
+O TGT deve ser transmitido juntamente com o autenticador ao TGS. Diferentemente do TGT, o autenticador só pode ser usado uma vez. Portanto, se ele for interceptado na rede, não será de nenhuma utilidade.
+
+Dessa forma, a requisição do usuário ao TGS será:
+
+`( Ps + V + A ) + {TGT}Ctgs`
+
+Onde **Ps** é o nome do principal do serviço que o usuário deseja acessar (para a qual o TGS vai emitir um tíquete), **V** é o tempo de validade do tíquete gerado e **A** é o autenticador (criptografado com a chave de sessão).
+
+**KRB_TGS_REP:**
+
+Ao receber a requisição do usuário, o TGS vai verificar se o principal da aplicação informado na requisição existe no banco de dados do KDC. Em caso afirmativo, ele vai descriptografar o TGT com sua chave (*Ctgs*) e obter a chave de sessão. Com a chave de sessão, ele vai descriptografar o autenticador. Feito isso, as seguintes condições serão validadas:
+
+* O TGT não está expirado;
+* O principal do usuário que enviou a requisição corresponde com o nome de principal de usuário presente no TGT;
+* O autenticador enviado não foi utilizado ainda (não está presente no *Replay Cache*) e não expirou;
+* Se a lista de IPs informada no TGT não for nula, então o endereço IP do usuário deve corresponder a algum IP dessa lista.
+
+Se todas as condições forem atendidas, o usuário será considerado autêntico pelo TGS, que prosseguirá com a geração de uma resposta. Para isso, ele vai gerar uma nova chave de sessão, que será o segredo compartilhado entre o usuário e o serviço que ele irá acessar. Em seguida, ele vai gerar o tíquete de acesso ao serviço, contemplando as seguintes informações:
+
+`( Pu + Ps + IP + T + V + CSs )`
+
+Onde **IP** é a lista (se não nula) de endereços IP que poderão acessar o serviço com esse tíquete, **T** é o instante em que esse tíquete foi gerado, **V** é o tempo de validade do tíquete e **CSs** é a chave de sessão compartilhada entre o usuário e o serviço. Criado o tíquete, o TGS vai formular a resposta para o usuário, contemplando as seguintes informações:
+
+`{( Ps + T + V + CSs )}CStgs + {Ts}Cs`
+
+Onde **Ts** é o tíquete destinado ao serviço e **Cs** é a chave criptográfica do serviço. Observe que o primeiro conjunto de informações desta resposta pode ser obtida pelo usuário, pois está criptografada com a chave de sessão usada entre ele e o TGS. Já o tíquete do serviço só poderá ser lido pelo próprio serviço. Portanto, o usuário vai apenas transmití-lo ao serviço na etapa de acesso à aplicação.
 
 ### Acesso à aplicação
 
-## Implementações do Kerberos
+**KRB_AP_REQ:**
 
-Um protocolo apenas define características que o serviço deve oferecer, entretanto não é o serviço em si. Este dependerá das suas implementações, isto é, o software que apresentará as características do protocolo. Algumas das implementações do Kerberos, de código-fonte livre são:
+Nesta etapa, o usuário já possui em sua *credential cache* (relembrando: esta é a área em que o usuário guarda os tíquetes obtidos e chaves de sessão) o tíquete do serviço que deseja acessar e a chave de sessão que será compartilhada entre ele e o serviço, ele vai gerar um autenticador para esta nova comunicação com a aplicação. O autenticador será composto pelo principal do usuário e pelo seu horário de criação, criptografados com a nova chave de sessão, gerada para esta comunicação:
 
-* **MIT Kerberos[^2]:** a primeira implementação, criada no MIT, onde foi criado também o protocolo.
-* **Heimdal Kerberos[^3]:** o Heimdal Kerberos foi criado na Suécia, quando o MIT Kerberos ainda era restrito por leis de exportação. O Heimdal não impunha tais restrições (que em 2000 deixaram de existir também para a implementação do MIT).
-* **GNU Shishi[^4]:** implementação GNU do protocolo Kerberos V5.
-* **Apache Directory[^5]:** além de serviço de LDAP, o Apache Directory também oferece um KDC.
-* **Apache Kerby[^6]:** implementação Java focada na interoperabilidade e intergração com outras aplicações.
+`{( Pu + T)}CSs`
+
+Em seguida, ele vai gerar a requisição que será enviada para a aplicação:
+
+`A + {Ts}Cs`
+
+**A** é o Autenticador, e **Ts** é o tíquete destinado à aplicação, criptografado com a chave desta aplicação (**Cs**). Portanto, a aplicação terá recebido o autenticador e o tíquete. Com isso, ela vai descriptografar o tíquete e dentro dele obter a chave de sessão. Com a chave de sessão, vai descriptografar o autenticador. Tendo feito isso, fará as seguintes verificações:
+
+* O tíquete não está expirado;
+* O principal do usuário que enviou a requisição corresponde com o nome de principal de usuário presente no tíquete (Ts);
+* O autenticador enviado não foi utilizado ainda (não está presente no *Replay Cache*) e não expirou;
+* Se a lista de IPs informada no tíquete não for nula, então o endereço IP do usuário deve corresponder a algum IP dessa lista.
+
+Para os casos em que a autenticação do serviço não é necessária, o protocolo é encerrado com a requisição do usuário para a aplicação. Caso contrário, prosseguirá para a resposta da aplicação, descrita a seguir.
+
+**KRB_AP_REP:**
+
+Em alguns casos, não basta que o usuário seja autenticado para ter acesso ao serviço, mas também que o serviço seja autenticado antes que o usuário faça qualquer requisição. Essa medida pode ser necessário quando se considera o risco de um serviço impostor tentar roubar informações do usuário. Um exemplo disso seria um serviço de impressão que pode ser usado para obter do usuário o documento que este deseja imprimir.
+
+Assim, portanto, nestes casos o usuário informa à aplicação que requer autenticação mútua quando faz a requisição (*KRB_AP_REQ*), e esta deverá oferecer uma resposta que ateste seu conhecimento da chave de sessão (o segredo compartilhado entre o usuário e a aplicação). Portanto, essa resposta será:
+
+`{( T )}CSs`
+
+Onde **T** é o mesmo horário presente no autenticador enviado na requisição (*KRB_AP_REQ*). Essa informação é criptografada com a chave de sessão estabelecida para comunicação entre o usuário e aplicação. Se o usuário conseguir descriptografar esse pacote com a chave de sessão estabelecida, o serviço será considerado autêntico.
 
 ## Referências
 
@@ -226,4 +331,4 @@ Editor: hrcerq
 email: hrcerq@gnulinux.net.br
 
 Revisor: hrcerq
-email: hrcerq@gnulinux.net.br
+email: hrcerq@gnulinux.net.br