Mostrar código-fonte de Kerberos

{{mais fontes|data=abril de 2014}}
[[Ficheiro:Kerberos sch en1.png|miniaturadaimagem|Interações da rede Kerberos]]
'''Kerberos'''<ref name=":0">{{citar web|título=Portal do MIT, O que é Kerberos?|url=http://web.mit.edu/kerberos/#what_is|publicado=Massachusetts Institute of Technology|acessodata=}}{{en}}</ref> é um [[Protocolo de rede]], que permite comunicações individuais seguras e identificadas, em uma rede insegura. Para isso o [[Massachusetts Institute of Technology]] (MIT) disponibiliza um pacote de aplicativos que implementam esse protocolo. O protocolo Kerberos previne [[Eavesdropping]] e Replay attack, e ainda garante a integridade dos dados. Seus projetistas inicialmente o modelaram na arquitetura [[Modelo cliente–servidor|cliente-servidor]], e é possível a [[autenticação]] mutua entre o cliente e o servidor, permitindo assim que ambos se autentiquem.

Kerberos utiliza [[Criptografia simétrica]] e necessita de um [[sistema de confiança tripla]].

== História e Desenvolvimento ==
<ref name=":1">{{citar web|título=Portal do MIT, Documento do Projeto Athena|url=ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.txt|publicado=Massachusetts Institute of Technology|acessodata=}}{{en}}</ref> Kerberos é um protocolo de autenticação do Projeto Athena. Tem esse nome em alusão ao Cão guarda de três cabeças ([[Cérbero]]) do deus [[Hades]] da [[Mitologia grega]]. Diversas versões do protocolo já existiram, as versões 1 até a 3 foram utilizadas somente dentro da MIT.
Steve Miller e Clifford Neuman, foram os principais projetistas da versão 4 do Kerberos, publicada nos anos 80, ainda com foco no Projeto Athena.

A versão 5 foi projetada por John Kohl e Clifford Neuman e publicada em 1993 no RFC 1510 (Ficou obsoleto ao RFC 4120 de 2005), e teve como intenção melhorar a segurança e as limitações relativas a versão 4.

A [[Massachusetts Institute of Technology|MIT]] disponibilizou uma implementação livre sob [[licença BSD]].

Autoridades [[Estados Unidos|Norte-americanas/Estadundenses]] proibiram o uso do Kerberos, pois esse utiliza um [[algoritmo]] de criptografia com uma chave de 56-bit, chamado [[DES]]. Eles consideraram que o protocolo prejudica a segurança nacional, porque impede que mensagens interceptadas sejam entendidas (Assim como qualquer aplicativo que utilize criptografia com chave maior que 40-bit). Uma implementação não americana do Kerberos, [https://web.archive.org/web/20060218171004/http://www.pdc.kth.se/kth-krb/ KTH-KRB] foi desenvolvida pela Royal Institute of Technology na [[Suécia]], tornando assim o sistema disponível fora dos EUA, até a mudança da regulamentação de exportação de criptografias. A implementação Sueca é baseada em uma versão chamada eBones. eBones é baseado em um release da versão eBones da MIT (Retirado a criptografia e as chamadas a mesma) que por sua vez foi baseado na versão 4 do Kerberos atualização 9. Esse Kerberos limitado é chamado hoje como eBones. Uma implementação chamada [https://web.archive.org/web/20060314022451/http://www.pdc.kth.se/heimdal/ Heimdal], foi feita basicamente, pelo mesmo grupo de pessoas e é baseada na versão 5 do Kerberos.

[[Windows 2000]], [[Windows XP]] e o [[Windows Server 2003]] utilizam uma variante do Kerberos, como seu método de autenticação padrão. As adições feitas no conjunto de protocolos do Kerberos pela [[Microsoft]] são documentadas no RFC 3244 chamado “Microsoft Windows 2000 Kerberos change Password and Set Password Protocols”. O [[Mac OS X]] da Apple também usa o Kerberos, tanto o cliente como o servidor.

Em [[2005]], o grupo chamado [[IETF]] “IETF Kerberos Workgroup” atualizou as especificações [https://web.archive.org/web/20040707075602/http://www.ietf.org/html.charters/krb-wg-charter.html Kerberos]. As atualizações incluem:
* "Encryption and [[Soma de verificação|Checksum]] Specifications" (RFC 3961),
* "[[AES|Advanced Encryption Standard]] (AES) Encryption for Kerberos 5" (RFC 3962),
* Uma nova edição da especificação do Kerberos versão 5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Essa versão substitui o RFC 1510, tornando a especificação do protocolo mais transparente e o explicando de modo mais detalhado e limpo.
* Uma nova edição de especificação do [[:en:Generic Security Services Application Program Interface|GSS-API]] "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

== Descrição ==
<ref name=":1" /> O Kerberos utiliza basicamente o protocolo [[:en:Needham-Schroeder|Needham-Schroeder]]. O [[:en:trusted third party|sistema de confiança tripla]] é chamado de ''Centro de Distribuição de Chaves'' (CDC), que é composta por duas partes separadas: um Servidor de Autenticação (SA) e Servidor de Concessão de Ticket (SCT). O Kerberos trabalha baseado em Tickets, que identificam os usuários.

O CDC mantém um banco de dados de chaves secretas; toda entidade de rede – tanto clientes como servidores – compartilham uma chave secreta	que é apenas conhecido por eles mesmos e pelo CDC. O conhecimento da chave secreta pelo CDC é necessário para a identificação das entidades de rede. Para a comunicação entre as entidades o CDC gera uma [[:en:session key|chave de sessão]] temporária, que serve para garantir a privacidade das informações.

== Utilizadores ==
Os seguintes softwares podem utilizar Kerberos para a autenticação:
* [[AFS]]
* [[Apache HTTP Server|Apache]] (com o módulo [http://modauthkerb.sourceforge.net/index.html mod_auth_kerb])
* [[Apache HTTP Server|Apache 2]] (usando libapache-mod-auth-kerb)
* [[Postfix]] (usando GSSAPI)
* Roteadores e Switches Cisco utilizando [[:en:Cisco IOS|IOS]]
* [http://en.wikipedia.org/wiki/Coda_(file_system) Coda File System]
* [[Eudora]]
* [[Mac OS X]]
* [[Microsoft Windows]] (2000 e posteriores) utiliza como protocolo de autenticação padrão
* Mulberry, um [[cliente de e-mail]] desenvolvido por Cyrusoft, Inc.
*[[Network File System|NFS]] (Desde NFSv3)
* [[OpenSSH]] (com Kerberos v5 ou maior)
* [[Pluggable Authentication Modules|PAM]] (com o módulo pam_krb5)
* [[Samba (servidor)|Samba]] Desde v3.x
* [[SOCKS]] (Desde SOCKS5)
* [http://en.wikipedia.org/wiki/Netatalk Netatalk]
* FreeIPA
* As implementações [[X Window System]]
* Indire(c)tamente, qualquer software que possa utilizar o [http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer SASL] para autenticação, como o [[OpenLDAP]], [[Dovecot (software)|Dovecot]] [[IMAP4]] e servidores [[POP3]], Servidor de e-mail [[Postfix (software)|Postfix]]
* O suíte de aplicativos Kerberos já vem com os clientes e servidores habilitados para [http://en.wikipedia.org/wiki/Remote_Shell rsh], [[File Transfer Protocol|FTP]], e [[Telnet]]
* Qualquer software baseado em Java (Desde 1.4.2) utilizando JAAS/JGSS pode utilizar o Kerberos para a sua segurança, veja http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/single-signon.html

== O Protocolo ==
Qualquer um pode especificar o protocolo utilizando a [[:en:security protocol notation|notação de protocolo de segurança]], onde [[:en:characters in cryptography|''Alice'']] (''A'') se autentica com [[:en:characters in cryptography|''Bob'']] (''B'') utilizando um servidor ''S''. Onde:
* K<sub>AS</sub> é uma chave pré-estabelecida somente conhecida por A e S;
* Como também K<sub>BS</sub> é somente conhecido por B e S;
* K<sub>AB</sub> é uma [[:en:session key|chave de sessão]] entre A e B, gerada a cada vez que o protocolo é utilizado;
* T<sub>S</sub> e T<sub>A</sub> são [[Marca temporal|marcas temporais]] geradas por S e por A, respectivamente;
* L é um 'lifespan' definindo o tempo de vida da marca temporal.

<math>A \rightarrow S: A,B</math>
:A pede para S iniciar um conexão com B.
<math>S \rightarrow A: \{T_S, L, K_{AB}, B, \{T_S, L, K_{AB}, A\}_{K_{BS}}\}_{K_{AS}}</math>
:S gera uma chave K<sub>AB</sub> e envia para A junto com a marca temporal e com os dados encriptados por B.
<math>A \rightarrow B: \{T_S, L, K_{AB}, A\}_{K_{BS}}, \{A, T_A\}_{K_{AB}}</math>
:A passa a mensagem para o B, obtém um novo TA e passa utilizando a chave de sessão.
<math>B \rightarrow A: \{T_A + 1\}_{K_{AB}}</math>
:B confirma a recepção da chave de sessão retornando uma versão modificada da marca temporal do A.

Percebemos que a [[segurança]] do protocolo se baseia em marcas temporais T e “lifespans” L como indicadores de quão recente é a comunicação.
E em relação à operação do Kerberos, é importante salientar que o servidor S é utilizado por ambos como o Servidor de Autenticação (SA), e como Servidor de Concessão de Ticket (SCT). Sendo <math>\{T_S, L, K_{AB}, B, \{T_S, L, K_{AB}, A\}_{K_{BS}}\}_{K_{AS}}</math>, <math>\{T_S, L, K_{AB}, A\}_{K_{BS}}</math> é o Ticket do cliente para o servidor, <math>\{A, T_A\}_{K_{AB}}</math> é o autenticador, e <math>\{T_A + 1\}_{K_{AB}}</math> confirma a veracidade da identificação de B e se o mesmo é reconhecido por A. Isso é necessário para uma autenticação mutua.

== Funcionamento do Kerberos ==
A seguir, é descrito fluxo simplificado do funcionamento do protocolo.

As seguintes nomenclaturas serão usadas:
* SA = Servidor de Autenticação
* SCT = Servidor de Concessão de Ticket
* SS = Servidor de Serviço
* cliente = Aplicação cliente do kerberos no sistema

Em uma sentença: o cliente se autentica no SA, então demonstra para o SCT que está autorizado a receber um Ticket para utilizar em um serviço (e o recebe), então demonstra ao SS que ele está aprovado para receber um serviço.

Em mais detalhes:
# O usuário coloca o nome de usuário e a senha no cliente.
# O cliente aplica uma criptografia de via única (ou hash) na senha digitada, e isso se torna a chave secreta do cliente.
# O cliente envia uma solicitação de serviço, através de uma mensagem em texto-plano, ao SA. Exemplo de mensagem: “O usuário XYZ gostaria de receber um serviço”. Nota: Nem a chave secreta, nem a senha são enviadas ao SA.
# O SA verifica se o cliente está em sua base de dados. Se estiver, ele manda as seguintes duas mensagens ao cliente:
## Mensagem A: ''Chave de sessão Cliente/SCT'' criptografada usando a chave secreta do usuário.
## Mensagem B: ''Ticket de Concessão'' (Que inclui a ID do cliente, endereço de rede do cliente, validade do ticket e a ''Chave de sessão Cliente/SCT'') criptografado utilizando a chave secreta do SCT.
# Somente após o cliente receber a mensagem A e B, ele descriptografa a mensagem A e obtém a ''Chave de sessão Cliente/SCT''. Essa chave de sessão será utilizada em comunicações futuras com o SCT. (Nota: O cliente não consegue descriptografar a mensagem B, pois essa é criptografada utilizando a chave secreta do SCT). A partir desse momento, o cliente tem informações o suficiente para se autenticar no SCT.
# Após requisitar o serviço, o cliente envia as seguintes duas mensagens ao SCT:
## Mensagem C: Mensagem B e o ID do serviço requisitado.
## Mensagem D: O Autenticador (que é composto do ID do cliente e a marca temporal), criptografado utilizando a ''Chave de sessão Cliente/SCT''.
# Após receber as mensagens C e D, o SCT descriptografa a mensagem B com sua chave secreta e a mensagem D (O Autenticador) utilizando a ''Chave de sessão Cliente/SCT'' da mensagem B, verifica se os dados das mensagens conferem com os dados de quem enviou os pacotes e, caso esteja tudo certo, envia as seguintes duas mensagens ao cliente:
## Mensagem E: ''Ticket Cliente-para-Servidor'' (que inclui o ID do cliente, endereço de rede do cliente, período válido, e uma ''chave de sessão Cliente/Servidor'') criptografado utilizando a chave secreta do serviço.
## Mensagem F: ''Chave de sessão Cliente/Servidor'' criptografado utilizando a ''chave de sessão Cliente/SCT''.
# Após receber as mensagens E e F do SCT, o cliente tem informações suficiente para se autenticar no SS (Nota: O cliente não consegue descriptografar a mensagem E, pois essa é criptografada utilizando a chave secreta do SS). Assim, o cliente se conecta no SS e envia as seguintes mensagens:
## Mensagem E do passo anterior (o ''Ticket Cliente-para-servidor'', criptografado utilizando a chave secreta do serviço) .
## Mensagem G: Um novo Autenticador, que inclui o ID do cliente, uma marca temporal, criptografados com ''chave de sessão Cliente/Servidor''
# Após receber as mensagens, SS descriptografa a mensagem E e, com o ''Ticket Cliente-para-Servidor'' que estava nesta, descriptografa a mensagem G. Novamente os dados das mensagens são comparados com os dados de quem as envia e, caso esteja tudo certo, uma mensagem de confirmação, codificada com a ''Chave de sessão Cliente/Servidor'', é enviada ao cliente contendo a marca temporal recebida na mensagem G incrementada em uma unidade.
# O cliente descriptografa a confirmação utilizando a chave compartilhada com o servidor e verifica se a marca temporal está atualizado corretamente. Se tiver, o cliente pode confiar no servidor e começa a pedir serviços ao mesmo.
# O Servidor retorna os serviços solicitados pelo cliente.

== Limitações do Kerberos ==
Ponto de falha único: É necessária uma disponibilidade contínua do servidor central. Quando o servidor do Kerberos está indisponível, ninguém pode mais se autenticar na rede. Isso pode ser resolvido utilizando diversos servidores Kerberos.

O Kerberos necessita que os relógios internos dos clientes estejam sincronizados com o dele. Os Tickets têm um tempo de vida, e se o relógio do cliente não estiver sincronizado com o do servidor, a autenticação irá falhar. Na configuração padrão, é necessário que os relógios dos clientes não tenham uma diferença maior do que 10 minutos. Na prática, servidores [[Network Time Protocol|NTP]] são utilizados para manter os relógios do servidor e dos clientes sincronizados.

== Referências ==
<references />

[[Categoria:Protocolos de controle de acesso a computador]]
[[Categoria:Protocolos de criptografia]]
[[Categoria:Criptografia]]
[[Categoria:Protocolos da Internet]]