explique como eu tenho 5 anos de idade: Kerberos – o que é Kerberos, e por que eu deveria me importar?embora este tópico provavelmente não possa ser explicado a uma criança de 5 anos e ser compreendido, esta é a minha tentativa de desfragmentar a documentação com algumas ajudas visuais e linguagem digerível.,
Em poucas palavras
Basicamente, o Kerberos se resume a apenas isso:
- um protocolo para autenticação
- usa bilhetes para autenticar
- evita o armazenamento de senhas localmente ou enviá-los através da internet
- envolve um confiáveis de terceiros 3
- construído em simétrica, criptografia de chave
Você tem um ingresso – prova de identidade criptografados com uma chave secreta para, a determinado serviço solicitado em sua máquina local (criação de um bilhete é descrito abaixo); enquanto for válida, você pode acessar o serviço solicitado que está dentro de um realm de Kerberos.,normalmente, isto é usado dentro de ambientes corporativos / internos. Talvez queira aceder ao seu site interno de pagamentos para rever o pequeno bónus que o seu chefe lhe deu. Em vez de voltar a introduzir as suas credenciais de utilizador/senha, o seu bilhete (em cache no seu sistema) é usado para autenticar permitindo um único sinal.
o seu bilhete é actualizado quando você assina no seu computador, ou quando você kinit USER dentro do seu terminal.para as pessoas amantes da trivialidade, o nome de Kerberos vem da mitologia grega, o cão de guarda de três cabeças de Hades., É muito apropriado, uma vez que é necessário um terceiro (um centro de distribuição de chaves) para autenticar entre um cliente e uma máquina de serviço ou host.
Kerberos Realm
Admins criar reinos – territórios Kerberos – que vai abranger tudo o que está disponível para acesso. Concedido, você pode não ter acesso a determinados Serviços ou máquinas host que é definido dentro da gestão política – desenvolvedores não devem acessar qualquer financiamento relacionado, coisas como essas. Mas um reino define o que Kerberos gerencia em termos de quem pode acessar o quê.,
Sua máquina, o cliente, vive neste reino, bem como o serviço ou hospedeiro que você quer solicitar e o centro de distribuição de chaves, KDC (Não, Não a KGB, embora eu sempre penso nisso, também). No exemplo a seguir, eu separo o servidor de autenticação e o servidor de concessão de ingressos, mas ambos estão dentro do KDC.
, Para manter na parte de trás de sua mente
Você pode querer voltar aqui depois de ler os detalhes sobre como o exemplo que funciona.,ao solicitar acesso a um serviço ou host, três interações ocorrem entre si e:
- O servidor de autenticação
- o serviço ou máquina a que pretende aceder.
O servidor de concessão de bilhetes
outros pontos importantes:
- Com cada interacção, receberá duas mensagens. Cada mensagem é uma que você pode decifrar, e uma que você não pode.
- o serviço ou máquina a que está a pedir acesso nunca se comunica directamente com o KDC.,
- o KDC guarda todas as chaves secretas para máquinas e serviços de utilizador na sua base de dados.
- chaves secretas são senhas mais um sal que são hashed – o algoritmo de hash é escolhido durante a implementação da configuração de Kerberos. Para os Serviços ou máquinas hospedeiras, não existem senhas (quem as introduziria). Uma chave é realmente gerada por um administrador durante a configuração inicial e memorizada na máquina de serviço/host.
- Mais uma vez, estas chaves secretas são todas armazenadas na base de dados do KDC; lembre-se da confiança dos Kerberos na criptografia de chave simétrica.,
- o KDC em si é encriptado com uma chave-mestra para adicionar uma camada de dificuldade de roubar chaves da base de dados.
- Existem configurações e implementações de Kerberos que usam criptografia de chave pública em vez de criptografia de chave simétrica.
an aside: the order of the messages and their contents discussed here does not reflect the order in which they are sent over TCP or UDP.
O exemplo abaixo descreve o que acontece quando você pede algo de um serviço interno HTTP – como informações sobre folha de pagamento dentro da sua intranet corporativa.,
você e o servidor de autenticação
deseja aceder a um serviço HTTP, mas primeiro tem de se apresentar ao servidor de autenticação. Login into your computer, or kinit USERNAME, initiates that introduction via a plaintext request for a Ticket Granting Ticket (TGT)., A mensagem de texto sem formatação contém:
- o seu nome/ID
- nome/ID do pedido de serviço (neste caso, o serviço é o Servidor de Concessão de Tíquete),
- o seu endereço de rede (pode ser uma lista de endereços IP para várias máquinas, ou pode ser null se querendo usar em qualquer máquina), e
- pedido de tempo de vida para a validade da TGT,
e é enviada para o Servidor de Autenticação.
o servidor de autenticação irá verificar se você está na base de dados do KDC. Esta verificação é apenas para ver se existe; não são verificadas quaisquer credenciais.,
Se não há erros (e.g. usuário não for encontrado), ele irá gerar aleatoriamente uma chave chamada uma chave de sessão para uso entre você e o Servidor de Concessão de Tíquete (TGS).
O servidor de autenticação irá então enviar duas mensagens de volta para você., Uma mensagem é o TGT que contém:
- o seu nome/ID
- o TGS nome/ID
- carimbo de data / hora
- o seu endereço de rede (pode ser uma lista de endereços IP para várias máquinas, ou pode ser null se querendo usar em qualquer máquina)
- tempo de vida do TGT (poderia ser o que você solicitou inicialmente, menor se você ou o TGS do chaves secretas estão prestes a expirar, ou outro limite que foi implementado durante a configuração Kerberos), e
- TGS Chave de Sessão,
e é encriptada com a TGS Chave Secreta ., A outra mensagem contém:
- The TGS name / ID,
- timestamp,
- lifetime (same as above), and
- TGS Session Key
e está encriptada com a chave secreta do seu cliente. Note que a chave de sessão TGS é a chave compartilhada entre você e o TGS.
a chave secreta do seu cliente é determinada pedindo-lhe a sua senha, adicionando um sal (composto por ) e esmagando tudo. Agora você pode usá-lo para descriptografar a segunda mensagem, a fim de obter a chave de sessão TGS., Se a senha estiver incorreta, então você não será capaz de descriptografar a mensagem. Por favor, note que este é o passo em que a senha que você digita é implicitamente validada.
não pode, contudo, descodificar a TGT, uma vez que não conhece a chave secreta do TGS. O TGT encriptado é armazenado dentro da sua ‘cache’ credencial.
você e o servidor de concessão de bilhetes
neste ponto, você tem a TGT que você não pode ler porque você não tem a chave secreta TGS para decifrá-la. Você, no entanto, tem a chave de sessão TGS.,agora é a sua vez de enviar duas mensagens. Você primeiro prepara o autenticador, criptografado com a chave de sessão TGS, contendo:
- seu nome/ID, e
- timestamp.
você envia uma mensagem não cifrada que contém:
- o nome/ID do Serviço HTTP solicitado a que deseja aceder, e
- vida útil do bilhete para o serviço HTTP,
, juntamente com o autenticador encriptado e TGT para o servidor que concede o bilhete.
o servidor de atribuição de bilhetes irá primeiro verificar a base de dados do KDC para ver se o serviço HTTP existe.,
Se sim, o TGS descriptografa a TGT com a sua chave secreta . Uma vez que a TGT agora não encriptada contém a chave de sessão TGS, o TGS pode descodificar o autenticador que enviou.,devido:
- comparar o seu ID de cliente do Autenticador para que a TGT
- comparar o carimbo de data / hora do Autenticador para que a TGT (típico Kerberos-sistema de tolerância a diferença é de 2 minutos, mas pode ser configurado de outra forma)
- verifique se o TGT é expirada (o tempo de vida do elemento),
- verifique se o Autenticador não é já na TGS cache (para evitar ataques de repetição), e
- se o endereço de rede do pedido original não é nulo, compara a origem do endereço IP para o endereço de rede (ou na lista de pedido) dentro da TGT.,
O Servidor de Concessão de Tíquete, em seguida, gera aleatoriamente o Serviço HTTP Chave de Sessão, e prepara o Serviço HTTP bilhete para você que contém:
- o seu nome/ID
- HTTP nome do Serviço/ID
- o seu endereço de rede (pode ser uma lista de endereços IP para várias máquinas, ou pode ser null se querendo usar em qualquer máquina),
- carimbo de data / hora
- tempo de vida da validade do bilhete, e
- HTTP Chave de Sessão do Serviço,
e encripta-a com o Serviço HTTP Chave Secreta.
então o TGS envia-lhe duas mensagens., Um é o bilhete de serviço HTTP encriptado; o outro contém:
- http Service name/ID,
- timestamp,
- lifetime of the validity of the ticket, and
- HTTP Service Session Key,
que está encriptado com a chave de sessão do TGS.
Sua Máquina descriptografa a última mensagem com a chave de sessão TGS que ele Cache mais cedo para obter a chave de sessão de serviço HTTP.
a sua máquina não pode, no entanto, descodificar o Bilhete do Serviço HTTP, uma vez que está encriptado com a chave secreta do serviço HTTP.,
Você e o Serviço HTTP
Para acessar o Serviço HTTP, sua máquina prepara outro Autenticador de mensagem que contém:
- o seu nome/ID
- carimbo de data / hora
e é encriptada com o Serviço HTTP Chave de Sessão. A sua máquina envia então o autenticador e o bilhete de Serviço HTTP ainda encriptado recebido do TGS.
o serviço HTTP descriptografa então o bilhete com a sua chave secreta para obter a chave de sessão do serviço HTTP., Ele então usa essa chave de sessão para descriptografar a mensagem Autenticadora que Você enviou.,es o seu ID de cliente do Autenticador para que de passagem,
o serviço HTTP envia então uma mensagem de Autenticador contendo o seu ID e a data-limite, a fim de confirmar a sua identidade para si e é encriptado com a chave de sessão do serviço HTTP.
a sua máquina lê a mensagem do Autenticador descodificando com a chave de sessão de HTTP em cache, e sabe que tem de receber uma mensagem com o ID e a hora do Serviço HTTP.
E agora você foi autenticado para usar o serviço HTTP., Solicitações futuras usam o ticket de serviço HTTP Cache, desde que não tenha expirado como definido dentro do atributo lifetime.
enquanto eu vou escrever sobre isso mais tarde, o serviço HTTP em si deve ser capaz de suportar Kerberos. Além disso, você também deve ter um navegador que suporta SPNEGO/negoceie.,
Talvez, re-leia os pontos anteriormente descritos; confira este ou esta implementação atual, especialmente no que eu sou pago para o trabalho que se comunica com esta implementação popular; ou de revisão de um tutorial, guia de recursos, o vídeo que foi enviado para mim quando eu comecei a aprender sobre o Kerberos, ou a RFC si.
As imagens acima foram renderizadas com a introdução de ícones usados a partir de font awesome e glyphicons, e estão disponíveis no slideshare.