O Kerberos é um protocolo de autenticação de rede de computadores, que funciona com base em bilhetes (tickets) para permitir que nós se comunicando em uma rede insegura provem sua identidade uns aos outros de maneira segura. Seus projetistas o direcionaram principalmente para um modelo cliente-servidor e ele fornece autenticação mútua — tanto o usuário quanto o servidor verificam a identidade um do outro. As mensagens do protocolo Kerberos são protegidas contra escutas (eavesdropping) e ataques de repetição.

O Kerberos baseia-se em criptografia de chave simétrica e requer uma terceira parte confiável, podendo, opcionalmente, utilizar criptografia de chave pública durante certas fases da autenticação.RFC 4556, abstract. O Kerberos utiliza a porta UDP 88 por padrão.

O protocolo recebeu o nome do personagem Cérbero (do grego Kerberos), da mitologia grega, o feroz cão de guarda de três cabeças de Hades.

História e desenvolvimento O Instituto de Tecnologia de Massachusetts (MIT) desenvolveu o Kerberos em 1988 para proteger os serviços de rede fornecidos pelo Projeto Athena. Sua primeira versão foi projetada principalmente por Steve Miller e Clifford Neuman, baseando-se no anterior protocolo de chave simétrica Needham-Schroeder. As versões 1 a 3 do Kerberos foram experimentais e não foram lançadas fora do MIT.

A versão 4 do Kerberos, a primeira versão pública, foi lançada em 24 de janeiro de 1989. Como o Kerberos 4 foi desenvolvido nos Estados Unidos e utilizava o algoritmo de encriptação Data Encryption Standard (DES), as restrições de controle de exportação dos EUA impediram que ele fosse exportado para outros países. O MIT criou uma versão exportável do Kerberos 4 com todo o código de encriptação removido, chamada "Bones". Eric Young, da Universidade Bond na Austrália, reimplementou o DES no Bones, criando uma versão chamada "eBones", que podia ser usada livremente em qualquer país. O Instituto Real de Tecnologia da Suécia lançou outra reimplementação chamada KTH-KRB.

Neuman e John Kohl publicaram a versão 5 em 1993 com a intenção de superar as limitações e problemas de segurança existentes. A versão 5 apareceu como RFC 1510, que foi posteriormente tornada obsoleta pela RFC 4120 em 2005.

Em 2005, o grupo de trabalho de Kerberos da Internet Engineering Task Force (IETF) atualizou as especificações. As atualizações incluíram: Especificações de Encriptação e Checksum (RFC 3961). Encriptação Advanced Encryption Standard (AES) para Kerberos 5 (RFC 3962). Uma nova edição da especificação do Kerberos V5 "The Kerberos Network Authentication Service (V5)" (RFC 4120). Esta versão torna obsoleta a RFC 1510, esclarece aspectos do protocolo e o uso pretendido em uma explicação mais detalhada e clara. Uma nova edição da especificação da Interface de Programação de Aplicativo para Serviços de Segurança Genérica (GSS-API) "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).

O MIT disponibiliza uma implementação do Kerberos gratuitamente, sob permissões de direitos autorais semelhantes às usadas nas licenças BSD. Em 2007, o MIT formou o Consórcio Kerberos para promover o desenvolvimento contínuo. Os patrocinadores fundadores incluem empresas como Oracle, Apple Inc., Google, Microsoft, Centrify Corporation e TeamF1 Inc., além de instituições acadêmicas como o Instituto Real de Tecnologia na Suécia, a Universidade Stanford e o MIT. Empresas como a CyberSafe também oferecem versões com suporte comercial.

Protocolo

Descrição O cliente se autentica no Servidor de Autenticação (AS - Authentication Server), que faz parte do centro de distribuição de chaves (KDC - Key Distribution Center). O KDC emite um ticket de concessão de ticket (TGT - Ticket-Granting Ticket), que possui um carimbo de data/hora (timestamp), criptografa-o usando a chave secreta do serviço de concessão de ticket (TGS - Ticket-Granting Service) e retorna o resultado criptografado para a estação de trabalho do usuário. Isso é feito de forma infrequente, normalmente no logon do usuário; o TGT expira em algum momento, embora possa ser renovado de forma transparente pelo gerenciador de sessão do usuário enquanto ele estiver logado.

Quando o cliente precisa se comunicar com um serviço em outro nó (um "principal", no jargão do Kerberos), o cliente envia o TGT para o TGS, que é outro componente do KDC e geralmente compartilha o mesmo hospedeiro (host) que o servidor de autenticação. O serviço já deve ter sido registrado no TGS com um Nome Principal de Serviço (SPN - Service Principal Name). O cliente usa o SPN para solicitar acesso a esse serviço. Após verificar que o TGT é válido e que o usuário tem permissão para acessar o serviço solicitado, o TGS emite um ticket de serviço (ST - Service Ticket) e chaves de sessão para o cliente. O cliente então envia o ticket para o servidor de serviço (SS - Service Server) junto com sua solicitação de serviço.

class=skin-invert-image|thumb|upright=1.5|Negociações do protocolo Kerberos O protocolo é descrito em detalhes abaixo. Logon do Usuário e Pré-autenticação O usuário insere um nome de usuário e senha na máquina cliente. Outros mecanismos de credenciais, como o PKINIT (RFC 4556), permitem o uso de chaves públicas ou cartões inteligentes (smart cards) em vez de uma senha. O cliente transforma a senha em uma chave simétrica usando uma função de hash unidirecional ou derivação de chave, dependendo do conjunto de cifras utilizado. No Kerberos moderno (v5), o cliente geralmente usa essa chave para criptografar um carimbo de data/hora (timestamp) atual. Esse timestamp criptografado é enviado ao AS junto com o nome de usuário como uma "pré-autenticação", provando que o usuário conhece a senha antes que o AS emita qualquer bilhete, o que previne ataques de força bruta offline.

Autenticação do cliente O cliente envia uma mensagem em texto claro com o ID do usuário para o AS (Servidor de Autenticação) solicitando serviços em nome do usuário. (Nota: Nem a chave secreta nem a senha são enviadas ao AS.) O AS verifica se o cliente está em seu banco de dados. Se estiver, o AS gera a chave secreta calculando o hash da senha do usuário encontrada no banco de dados (por exemplo, Active Directory no Windows Server) e envia de volta as seguintes duas mensagens para o cliente: Mensagem A: Chave de Sessão Cliente/TGS criptografada usando a chave secreta do cliente/usuário. Mensagem B: Ticket de Concessão de Ticket (TGT, que inclui o ID do cliente, o endereço de rede do cliente, o período de validade do ticket e a Chave de Sessão Cliente/TGS) criptografado usando a chave secreta do TGS. Assim que o cliente recebe as mensagens A e B, ele tenta decifrar a mensagem A com a chave secreta gerada a partir da senha inserida pelo usuário. Se a senha inserida pelo usuário não corresponder à senha no banco de dados do AS, a chave secreta do cliente será diferente e, portanto, incapaz de decifrar a mensagem A. Com uma senha e chave secreta válidas, o cliente decifra a mensagem A para obter a Chave de Sessão Cliente/TGS. Esta chave de sessão é usada para comunicações posteriores com o TGS. (Nota: O cliente não pode decifrar a Mensagem B, pois ela está criptografada com a chave secreta do TGS.) Neste ponto, o cliente possui informações suficientes para se autenticar no TGS.

Autorização de serviço do cliente Ao solicitar serviços, o cliente envia as seguintes mensagens para o TGS: Mensagem C: Composta pela mensagem B (o TGT criptografado com a chave secreta do TGS) e o ID do serviço solicitado. Mensagem D: Autenticador (composto pelo ID do cliente e o carimbo de data/hora), criptografado usando a Chave de Sessão Cliente/TGS (encontrada pelo cliente na Mensagem A). Ao receber as mensagens C e D, o TGS extrai a mensagem B da mensagem C. Ele decifra a mensagem B usando a chave secreta do TGS. Isso lhe fornece a Chave de Sessão Cliente/TGS e o ID do cliente (ambos estão no TGT). Usando esta Chave de Sessão Cliente/TGS, o TGS decifra a mensagem D (Autenticador) e compara os IDs de cliente das mensagens B e D; se eles corresponderem, o servidor envia as seguintes duas mensagens para o cliente: Mensagem E: Ticket cliente-servidor (que inclui o ID do cliente, o endereço de rede do cliente, o período de validade e a Chave de Sessão Cliente/Servidor) criptografado usando a chave secreta do serviço. Mensagem F: Chave de Sessão Cliente/Servidor criptografada com a Chave de Sessão Cliente/TGS.

Solicitação de serviço do cliente Ao receber as mensagens E e F do TGS, o cliente possui informações suficientes para se autenticar no Servidor de Serviço (SS). O cliente se conecta ao SS e envia as seguintes duas mensagens: Mensagem E: Do passo anterior (o Ticket cliente-servidor, criptografado usando a chave secreta do serviço pelo TGS). Mensagem G: Um novo Autenticador, que inclui o ID do cliente, carimbo de data/hora e é criptografado usando a Chave de Sessão Cliente/Servidor. O SS decifra o ticket (mensagem E) usando sua própria chave secreta para recuperar a Chave de Sessão Cliente/Servidor. Usando a chave de sessão, o SS decifra o Autenticador e compara o ID do cliente das mensagens E e G; se eles corresponderem, o servidor envia a seguinte mensagem ao cliente para confirmar sua identidade real e disposição para atender o cliente: Mensagem H: O carimbo de data/hora encontrado no Autenticador do cliente (mais 1 na versão 4, mas não necessário na versão 5), criptografado usando a Chave de Sessão Cliente/Servidor. O cliente decifra a confirmação (mensagem H) usando a Chave de Sessão Cliente/Servidor e verifica se o carimbo de data/hora está correto. Em caso afirmativo, o cliente pode confiar no servidor e começar a emitir solicitações de serviço para o servidor. O servidor fornece os serviços solicitados ao cliente.

Suporte por sistemas operacionais

Microsoft Windows O Windows 2000 e versões posteriores utilizam o Kerberos como seu método de autenticação padrão. Algumas adições da Microsoft ao conjunto de protocolos Kerberos estão documentadas na RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". A RFC 4757 documenta o uso da cifra RC4 pela Microsoft. Embora a Microsoft utilize e estenda o protocolo Kerberos, ela não usa o software do MIT.

O Kerberos é usado como o método de autenticação preferido: em geral, ingressar um cliente em um domínio Windows significa ativar o Kerberos como o protocolo padrão para autenticações desse cliente para serviços no domínio Windows e em todos os domínios com relações de confiança com esse domínio.

Em contrapartida, quando o cliente, o servidor ou ambos não estão integrados a um domínio (ou não fazem parte do mesmo ambiente de domínio confiável), o Windows utilizará o NTLM para autenticação entre cliente e servidor.

Aplicações web da Internet podem impor o Kerberos como método de autenticação para clientes integrados ao domínio usando APIs fornecidas sob o SSPI.

O Microsoft Windows e o Windows Server incluem o , utilitário de linha de comando que pode ser usado para ler, modificar ou excluir os Nomes Principais de Serviço (SPN) de uma conta de serviço do Active Directory.Setspn - Windows CMD - SS64.comSetspn | Microsoft Docs

Unix e outros sistemas operacionais Muitos sistemas operacionais semelhantes ao Unix, incluindo FreeBSD, macOS da Apple, Red Hat Enterprise Linux, Solaris da Oracle, AIX da IBM, HP-UX e outros, incluem software para autenticação Kerberos de usuários ou serviços. Uma variedade de sistemas operacionais não baseados em Unix, como z/OS, IBM i e OpenVMS, também apresentam suporte ao Kerberos. Implementações embarcadas do protocolo de autenticação Kerberos V para agentes clientes e serviços de rede em execução em plataformas embarcadas também estão disponíveis por meio de empresas do setor.

Desvantagens e limitações