Kerberos (protocolo)

Protocolo

Kerberos usa como base o protocolo Needham-Schroeder. Ele faz uso de uma autenticação de terceiros confiável conhecida como "centro de distribuição de chaves (KDC)", que consiste de duas partes logicamente separadas: um Servidor de Autenticação (AS) e um Servidor de Concessão de Bilhetes (TGS). O Kerberos trabalha com base em "tickets" (chamados tickets Kerberos) que servem para provar a identidade dos usuários.

Banco de dados Kerberos: O centro de distribuição de chaves (KDC) mantém um banco de dados de chaves secretas; cada entidade na rede - seja um cliente ou um servidor - compartilha uma chave secreta conhecida apenas para si e para o KDC. O conhecimento desta chave serve para provar a identidade de cada entidade. Para a comunicação entre duas entidades, o KDC gera uma chave de sessão que elas podem utilizar para assegurar suas comunicações.

O termo "servidor Kerberos" geralmente se refere ao KDC. Para fins de confiabilidade, é possível ter KDCs de reserva. Estes são chamados de "servidores escravos Kerberos". Todos os escravos sincronizam seus bancos de dados a partir do servidor Kerberos mestre.

O termo "Kerberized application server" geralmente refere-se a programas Kerberized com os quais os clientes se comunicam usando bilhetes Kerberos para autenticação. Por exemplo, o servidor Kerberos telnet é um exemplo de um servidor de aplicação Kerberized . Enquanto o termo "Kerberized applications" é usado para se referir ao lado cliente do servidor de aplicações Kerberized , por exemplo, o cliente Kerberos telnet é um exemplo de uma aplicação Kerberized.

A segurança do protocolo depende muito da segurança:

1. Participantes mantendo o tempo vagamente sincronizado.
2. Uma declaração de autenticidade de curta duração: os bilhetes dos Kerberos.

Descrição simplificada do protocolo

Serão utilizadas as seguintes abreviações:

·         AS = Servidor de Autenticação

·         TGS = Ticket Granting Server

·         SS ou Servidor = Servidor de serviço (usuário do servidor que solicita seu serviço, como um servidor de impressão, um servidor de arquivos, etc...)

·         TGT = Ticket Granting Ticket (bilhete Kerberos para o TGS. Preparado pelo AS, depois usado para conversar com o TGS).

Em resumo, o cliente se autentica ao AS usando um segredo compartilhado de longo prazo e recebe um bilhete do AS. Mais tarde, o cliente pode usar este bilhete para obter bilhetes adicionais para o SS usando o mesmo segredo compartilhado. Estes bilhetes podem ser usados para provar a autenticação ao SS.

O protocolo em mais detalhes

Passos de Logon baseados no cliente do usuário:

1. Um usuário digita um nome de usuário e uma senha na máquina do cliente.
2. O cliente executa uma função unidirecional (principalmente uma função Hash) na senha digitada, e esta se torna a chave secreta do cliente/usuário.

Passos de Autenticação do Cliente:

1. O cliente envia uma mensagem de texto claro para o AS solicitando serviços em nome do usuário.
   Mensagem de amostra: "Usuário XYZ gostaria de solicitar serviços".
   Nota: Nem a chave secreta nem a senha são enviadas para o AS.
2. O AS verifica se o cliente está em seu banco de dados. Se estiver, o AS envia de volta as duas mensagens a seguir ao cliente:
• Mensagem A: Chave de sessão cliente/TGS criptografada usando a chave secreta do cliente/usuário.
• Mensagem B: TGT (que inclui a identificação do cliente, endereço da rede do cliente, período de validade do bilhete e a chave de sessão Cliente/TGS) criptografada usando a chave secreta do TGS.
3. Uma vez que o cliente recebe as mensagens A e B, descriptografa a mensagem A para obter a chave de sessão Cliente/TGS. Esta chave de sessão é usada para futuras comunicações com a TGS. Neste ponto, o cliente tem informações suficientes para se autenticar com o TGS.
   Nota: O cliente não pode decifrar a mensagem B, pois ela é criptografada usando a chave secreta da TGS.

Etapas de Autorização do Atendimento ao Cliente:

1. Ao solicitar serviços, o cliente envia as duas mensagens a seguir para o TGS:
• Mensagem C: Composta pelo TGT da mensagem B e a identificação do serviço solicitado.
• Mensagem D: Autenticador (que é composto da identificação do cliente e do carimbo de tempo), criptografado usando a chave de sessão Cliente/TGS.
2. Ao receber as mensagens C e D, o TGS recupera a mensagem B da mensagem C. Ele descriptografa a mensagem B usando a chave secreta do TGS. Isto lhe dá a chave de sessão Cliente/TGS. Usando esta chave, o TGS decripta a mensagem D (Authenticator) e envia as duas mensagens seguintes ao cliente:
• Mensagem E: Ticket cliente-servidor (que inclui o ID do cliente, endereço de rede do cliente, período de validade e chave de sessão cliente/servidor) criptografado usando a chave secreta SS.
• Mensagem F: Chave de sessão cliente/servidor criptografada com a Chave de sessão cliente/TGS.

Etapas de solicitação de serviço ao cliente:

1. Ao receber as mensagens E e F da TGS, o cliente tem informações suficientes para se autenticar junto à SS. O cliente se conecta à SS e envia as duas mensagens a seguir:
• Mensagem E: da etapa anterior (o ticket Cliente-Servidor, criptografado usando a chave secreta SS).
• Mensagem G: um novo Autenticador, que inclui o ID do cliente, carimbo de data e hora e é criptografado usando a Chave de Sessão Cliente/Servidor.
2. A SS descriptografa o bilhete usando sua própria chave secreta para recuperar a chave da sessão Cliente/Servidor. Usando a chave de sessão, a SS descriptografa o Autenticador e envia a seguinte mensagem ao cliente para confirmar sua verdadeira identidade e vontade de servir o cliente:
• Mensagem H: o carimbo da hora encontrado no Autenticador mais 1 do cliente, criptografado usando a Chave de Sessão Cliente/Servidor.
3. O cliente descriptografa a confirmação usando a Chave de Sessão Cliente/Servidor e verifica se o carimbo de data/hora está corretamente atualizado. Se assim for, o cliente pode confiar no servidor e pode começar a emitir solicitações de serviço ao servidor.
4. O servidor fornece os serviços solicitados para o cliente.

Drawbacks

• Ponto único de falha: Exige a disponibilidade contínua de um servidor central. Quando o servidor Kerberos está desligado, ninguém pode entrar no sistema. Isto pode ser resolvido usando múltiplos servidores Kerberos e mecanismos de autenticação de emergência.
• Kerberos exige que os relógios de todos os anfitriões envolvidos sejam sincronizados. Os bilhetes têm um período de disponibilidade de tempo e se o relógio do host não estiver sincronizado com o relógio do servidor Kerberos, a autenticação falhará. A configuração padrão exige que os horários dos relógios não sejam separados por mais de 10 minutos. Na prática, o Network Time Protocol (NTP) é normalmente usado para manter todos os hosts sincronizados.
• O protocolo de administração não é padronizado e difere entre as implementações de servidores. As mudanças de senha são descritas no RFC 3244.
• Como as chaves secretas para todos os usuários são armazenadas no servidor central, um comprometimento desse servidor comprometerá as chaves secretas de todos os usuários.
• Um cliente comprometido irá comprometer a senha do usuário.

Páginas relacionadas

• Gestão da identidade
• Protocolo de senha remota segura (SRP)
• Interface do Programa de Aplicação de Serviços Genéricos de Segurança (GSS-API)