Segurança e VPN : Kerberos

Vista geral do Kerberos um serviço de autenticação para sistemas de rede aberta

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Em um ambiente de computação de rede aberta, uma estação de trabalho não é confiável para identificar corretamente seus usuários para os serviços de rede. O Kerberos oferece uma abordagem alternativa em que um serviço confiável de autenticação de terceiros é usado para verificar a identidade dos usuários. Este artigo oferece uma visão geral do modelo de autenticação Kerberos como implantado para o projeto Athena do MIT. Descreve os protocolos usados por clientes, servidores e o Kerberos para conseguir a autenticação. Também descreve o gerenciamento e a duplicação da base de dados necessária. As exibições do Kerberos, como visualizadas pelo usuário, pelo programador e pelo administrador são descritas. Finalmente, o papel do Kerberos, no escopo mais amplo do projeto Athena, é apresentado, juntamente com uma lista de aplicações que atualmente usam o Kerberos para autenticação de usuários. Nós descrevemos a integração da ferramenta de autenticação Kerberos ao Sistema de Arquivo de Rede Sun como um estudo de caso para integração do Kerberos a um aplicativo existente.

Autores de Kerberos

  • Jennifer G. Steiner, projeto Athena, Massachusetts Institute of Technology, Cambridge, MA 02139, steiner@ATHENA.MIT.EDU

  • Clifford Neuman, departamento de ciência da computação, FR-35, universidade de washington, Seattle, WA 98195, bcn@CS.WASHINGTON.EDU. Clifford Neuman era um membro do grupo de trabalho do projeto Athena durante o projeto e a fase de implementação inicial de Kerberos.

  • Jeffrey I. Schiller, projeto Athena, Massachusetts Institute of Technology, Cambridge, MA 02139, jis@ATHENA.MIT.EDU

Introdução ao Kerberos

Este papel dá uma vista geral do Kerberos, um sistema de autenticação projetado por Miller e Neuman. para ambientes da computação de rede aberta, e descreve nossa experiência usando a no projeto Athena do MIT. Na seção na motivação, nós explicamos porque um modelo de autenticação novo é precisado para redes aberta, e quais suas exigências são. O que é Kerberos? secione lista os componentes do Kerberos Software e descreva como interagem em proporcionar o serviço de autenticação. No Kerberos nomeia a seção, nós descrevem o esquema de nomeação do Kerberos.

Como o Kerberos trabalha presentes os montagens de bloco da autenticação de Kerberos - o bilhete e o autenticador. Isto conduz a um exame dos dois Protocolos de autenticação: a autenticação inicial de um usuário ao Kerberos (análogo à abertura), e o protocolo para a autenticação mútua de um consumidor potencial e de um produtor potencial de um serviço de rede.

O Kerberos exige uma informação de base de dados sobre seus clientes; a seção do base de dados de Kerberos descreve o base de dados, seu Gerenciamento, e o protocolo para sua alteração. O Kerberos da parte externa que olha na seção descreve o Kerberos conecta a seus usuários, programadores de aplicativos, e administradores. Na seção da análise mais ampla, nós descrevemos como os ajustes dos kerberos do projeto athena no resto do ambiente Athena. Nós igualmente descrevemos a interação de domínios de autenticação de Kerberos diferentes, ou de reinos; em nosso caso, na relação entre os kerberos do projeto athena e o Kerberos que são executado no laboratório do MIT para a ciência da computação.

Nas questões e problema aberto seção, nós mencionamos edições abertas e problemas até agora não-resolvidos. A última seção dá o status atual de kerbero no projeto Athena. No apêndice, nós descrevemos em detalhe como o Kerberos é aplicado a um serviço do arquivo de rede para autenticar os usuários que desejam aceder aos sistemas de arquivo remotos.

Conceitos de Kerberos

Durante todo este papel nós usamos os termos que podem ser ambíguos, novo ao leitor, ou usado diferentemente em outra parte. Abaixo dos nós indicamos nosso uso daqueles termos.

Usuário, cliente, server — Pelo usuário, nós significamos ser humano que usa um programa ou um serviço. Um cliente igualmente usa algo, mas não é necessariamente uma pessoa; pode ser um programa. Frequentemente os aplicativos de rede consistem em duas porções; um programa que é executado em uma máquina e pede um serviço remoto, e um outro programa que corridas na máquina remota e executam esse serviço. Nós chamamos aqueles o lado do cliente e o lado de servidor do aplicativo, respectivamente. Frequentemente, um cliente contactará um server em nome de um usuário.

Cada entidade que usa o sistema Kerberos, seja ele um usuário ou um servidor de rede, é em um sentido um cliente, desde que usa o serviço de kerberos. Para distinguir assim clientes Kerberos dos clientes de outro serviço, nós usamos o principal do termo para indicar tal entidade. Note que um Kerberos principal pode ser um usuário ou um server. (Nós descrevemos a nomeação dos Kerberos principal em uma seção mais recente.)

Preste serviços de manutenção contra o server — Nós usamos o serviço como uma especificação abstrata de algumas ações a ser executadas. Um processo que execute aquelas ações é chamado um server. Em um dado momento, pode haver diversos server (que são executado geralmente em máquinas diferentes) que executam um dado serviço. Por exemplo, em Athena há um servidor rlogin do BSD UNIX que é executado em cada um de nossas máquinas da partilha de tempo.

Chave, chave privada, senha — Criptografia chave privada dos usos do Kerberos. Cada Kerberos principal é atribuído um número grande, sua chave privada, conhecida somente àquele principal e ao Kerberos. No caso de um usuário, a chave privada é o resultado de uma função unidirecional aplicada à senha de usuário. Nós usamos a chave como a estenografia para a chave privada.

Credenciais — Infelizmente, esta palavra tem um significado especial para o Sistema de Arquivo de Rede Sun e o sistema Kerberos. Nós indicamos explicitamente se nós significamos credenciais de NFS ou credenciais kerberizadas, se não o termo é usado no sentido de língua inglesa normal.

Mestre e escravo — É possível executar o software da autenticação de Kerberos em mais de uma máquina. Contudo, há sempre somente uma cópia definitiva do base de dados de Kerberos. A máquina que abriga este base de dados é chamada a máquina mestre, ou apenas o mestre. Outras máquinas podem possuir cópias de somente leitura do base de dados de Kerberos, e estes são chamados escravos.

Motivação além de kerberos

Em um ambiente NON-conectado da computação pessoal, os recursos e a informação podem ser protegidos fisicamente fixando o computador pessoal. Em um ambiente de computação da partilha de tempo, o sistema operacional protege usuários de um outro e controla recursos. A fim determinar o que cada usuário pode ler ou alterar, é necessário que o sistema de associação de tempo identifique cada usuário. Isto é realizado quando o usuário entra.

Em uma rede de usuários que exige serviços de muitos computadores separados, há três aproximações uma pode tomar ao controle de acesso: Um pode não fazer nada, confiando na máquina a que o usuário é entrado para impedir o acesso não autorizado; um pode exigir o host provar sua identidade, mas confia a palavra do host a respeito de quem o usuário é; ou um pode exigir o usuário provar a identidade (dele/dela) para cada serviço requerido.

Em um ambiente fechado onde todas as máquinas estejam sob o controle estrito, um pode usar a primeira aproximação. Quando os controles organizacionais todos os anfitriões que se comunicam sobre a rede, isto forem uma aproximação razoável.

Em um mais o ambiente aberto, um pôde seletivamente confiar somente aqueles anfitriões sob o controle organizational. Neste caso, cada host deve ser exigido provar sua identidade. Os programas de rlogin e rsh usam esta aproximação. Naqueles protocolos, a autenticação é feita verificando o endereço do Internet de que uma conexão foi estabelecida.

No ambiente Athena, nós devemos poder honrar pedidos dos anfitriões que não estão sob o controle organizational. Os usuários têm o controle completo de suas estações de trabalho: podem recarregá-los, trazê-los acima de autônomo, ou mesmo carreg fora do seus próprias fitas. Como tal, a terceira aproximação deve ser tomada; o usuário deve provar a identidade (dele/dela) para cada serviço desejado. O server deve igualmente provar sua identidade. Não é suficiente fixar fisicamente o host que executa um servidor de rede; alguém em outra parte na rede pode masquerading como o dado servidor.

Nosso ambiente coloca várias requisições em um mecanismo de identificação. Primeiramente, deve ser seguro. Contorná-lo deve ser difícil bastante que um atacante potencial não encontra o mecanismo da autenticação para ser o elo mais fraco. Alguém que olha a rede não deve poder obter a informação necessária encarnar um outro usuário. Em segundo, deve ser segura. O acesso a muitos serviços dependerá do serviço de autenticação. Se não é seguro, o sistema de serviços no conjunto não será. Em terceiro lugar, deve ser transparente. Idealmente, o usuário não deve estar ciente da autenticação que ocorre. Finalmente, deve ser escalável. Muitos sistemas podem comunicar-se com os anfitriões de Athena. Não toda a estes apoiará nosso mecanismo, mas o software não deve quebrar se fizeram.

O Kerberos é o resultado de nosso trabalho para satisfazer as exigências acima. Quando um usuário anda acima a uma estação de trabalho entram. Tanto quanto o usuário pode dizer, esta identificação inicial é suficiente para provar sua identidade a todos os server de rede obrigatória para a duração da sessão de login. A Segurança do Kerberos confia nas seguranças dos diversos servidores de autentificação, mas não no sistema de que os usuários entram, nem na Segurança dos servidores finais que serão usados. O Authentication Server fornece corretamente um usuário autenticado uma maneira de provar a identidade (dele/dela) aos server dispersados através da rede.

A autenticação é um bloco de construção fundamental para um ambiente com rede seguro. Se, por exemplo, um server conhece com certeza a identidade de um cliente, pode decidir se proporcionar e assim por diante o serviço, se o usuário deve ser dado os privilégios especiais, que devem receber a conta para o serviço. Ou seja os esquemas da autorização e da contabilidade podem ser construídos sobre a autenticação que o Kerberos fornece, tendo por resultado a segurança equivalente ao computador pessoal solitário ou ao sistema de associação de tempo.

O que é Kerberos?

O Kerberos é um serviço de autenticação confiável de terceira parte baseado no modelo apresentado por Needham e por Schroeder. Confia-se no sentido esse cada um do julgamento do seu Kerberos das crenças dos clientes a respeito da identidade de cada um de seus outros clientes ser exato. Os Timestamps (números grandes que representam a data atual e hora) foram adicionados ao modelo original para ajudar na detecção de repetição. A repetição ocorre quando uma mensagem é roubada fora da rede e enviada novamente mais tarde. Para mais descrição completa da repetição, e outras introduções da autenticação, veja Voydock e Kent.

O que faz o Kerberos?

O Kerberos mantém um base de dados de seus clientes e de suas chaves privadas. A chave privada é um número grande conhecido somente ao Kerberos e ao cliente que pertença a. No caso em que o cliente for um usuário, é uma senha criptografada. Os serviços de rede que exigem a autenticação registram-se com Kerberos, como faça os clientes que desejam usar aqueles serviços. As chaves privadas são negociadas no registro.

Porque o Kerberos conhece estas chaves privadas, pode criar as mensagens que convencem um cliente que outros são realmente quem reivindicam ser. O Kerberos igualmente gerencie as chaves privadas provisórias, chamadas as chaves de sessão, que são dadas a dois clientes e a ninguém mais. Uma chave de sessão pode ser usada para cifrar mensagens entre dois partidos.

O Kerberos fornece três níveis distintos de proteção. O programador de aplicativo determina qual é apropriado, de acordo com as exigências do aplicativo. Por exemplo, alguns aplicativos exigem somente que a autenticidade esteja estabelecida na iniciação de uma conexão de rede, e podem supor que os mensagens futura de um dado endereço de rede originam do partido autenticado. Nosso Network File System autenticado usa este nível de segurança.

Outros aplicativos exigem a autenticação de cada mensagem, mas não se importam se o índice da mensagem está divulgado ou não. Para estes, o Kerberos fornece mensagens segura. Contudo um de mais alto nível da Segurança é fornecido pelos mensagens privada, onde cada mensagem é autenticada não somente, mas igualmente cifrado. Os mensagens privada são usados, por exemplo, pelo servidor Kerberos próprio enviando senhas sobre a rede.

Componentes de software kerberos

A implementação de Athena compreende diversos módulos:

  • Biblioteca dos aplicativos Kerberos

  • biblioteca de criptografia

  • biblioteca de base de dados

  • programas da administração da base de dados

  • servidor de administração

  • Authentication Server

  • software de propagação DB

  • programas de usuário

  • aplicativos

A biblioteca dos aplicativos Kerberos fornece uma relação para clientes de aplicativo e serveres de aplicativo. Contém, entre outros, rotinas para pedidos de autenticação criadores ou de leituras, e as rotinas para criar o cofre forte ou os mensagens privada.

A criptografia no Kerberos é baseada no DES, a criptografia padrão de dados. A biblioteca de criptografia executa aquelas rotinas. Diversos métodos de criptografia são fornecidos, com as trocas entre a velocidade e a Segurança. Uma extensão ao modo do DES Cypher Block Chaining (CBC), chamado o modo de CBC da propagação, é fornecida igualmente. No CBC, um erro é propagado somente através do bloco atual da cifra, visto que no PCBC, o erro é propagado durante todo a mensagem. Isto torna o mensagem completa inútil se um erro ocorre, um pouco do que apenas uma parcela dele. A biblioteca de criptografia é um módulo independente, e pode ser substituída com outras implementações DES ou uma biblioteca de criptografia diferente.

Um outro módulo substituível é o sistema de gerenciamento de base de dados. A implementação de athena atual da biblioteca de base de dados usa o ndbm, embora Ingres seja usado originalmente. Outras bibliotecas do gerenciamento de base de dados podiam ser usadas também.

As necessidades do base de dados de Kerberos são diretas; um registro é guardado para cada principal, contendo o nome, a chave privada, e a data de expiração do principal, junto com alguma informação administrativa. (A data de expiração é a data depois do qual uma entrada é já não válida. É ajustada geralmente a alguns anos no futuro no registro.)

A outra informação sobre o usuário, tal como o nome real, número de telefone, é mantida e assim por diante por um outro server, o servidor de nome de Hesiod. Esta maneira, informação sensível, a saber senhas, pode ser segurada pelo Kerberos, usando razoavelmente medidas de segurança elevada; quando a informação NON-sensível mantida por Hesiod for tratada diferentemente; pode, por exemplo, ser enviada unencrypted sobre a rede.

Os servidores Kerberos usam a biblioteca de base de dados, como fazem as ferramentas para administrar o base de dados.

O servidor de administração (ou o servidor KDBM) fornecem uma interface de rede de leitura/gravação ao base de dados. O lado do cliente do programa pode ser executado em toda a máquina na rede. O lado de servidor, contudo, deve ser executado na máquina que abriga o base de dados de Kerberos a fim fazer mudanças ao base de dados.

O Authentication Server (ou o servidor Kerberos), por outro lado, executam operações de somente leitura no base de dados de Kerberos, a saber, na autenticação de gerentes, e na geração de chaves de sessão. Desde que este server não altera o base de dados de Kerberos, pode ser executado em uma máquina que abriga uma cópia de somente leitura do base de dados kerberos mestre.

O software de propagação do base de dados controla a replicação do base de dados de Kerberos. É possível ter cópias do base de dados em diversas máquinas diferentes, com uma cópia do Authentication Server que é executado em cada máquina. Cada um destas máquinas do escravo recebe uma atualização do base de dados de Kerberos da máquina mestre em dados intervalo.

Finalmente, há uns programas do utilizador final para entrar ao Kerberos, mudar uma senha de kerberos, e indicar ou bilhetes destrui-los do Kerberos (os bilhetes são explicados mais tarde).

Nomes de Kerberos

Parte de autenticar uma entidade está nomeando-a. O processo de autenticação é a verificação que o cliente é esse nomeado em um pedido. Que um nome consiste? No Kerberos, os usuários e os server são nomeados. Tanto quanto o Authentication Server, são equivalentes. Um nome consiste em um nome principal, em um exemplo, e em um reino, expressado como name.instance@realm.

O nome principal é o nome do usuário ou do serviço. O exemplo é usado para distinguir entre variações no nome principal. Para usuários, um exemplo pode envolver privilégios especiais, tais como os exemplos da “raiz” ou “admin”. Para serviços no ambiente Athena, o exemplo é geralmente o nome da máquina em que o server é executado. Por exemplo, o serviço de rlogin tem exemplos diferentes em anfitriões diferentes: rlogin.priam é o servidor rlogin no host nomeado priam. Um bilhete do Kerberos é somente bom para um único servidor nomeado. Como tal, um bilhete separado é exigido aceder aos exemplos diferentes do mesmo serviço. O reino é o nome de uma entidade administrativa que mantenha dados de autenticação. Por exemplo, as instituições diferentes podem cada um ter sua própria máquina do Kerberos, abrigando um base de dados diferente. Têm esferas de kerberos diferentes. (Os reinos são discutidos mais em Interactionwith o outro Kerberi.)

Como o Kerberos funciona

Esta seção descreve os protocolos de autenticação de Kerberos. Como mencionado acima, o modelo de autenticação de kerberos é baseado protocolo na distribuição chave de Needham e de Schroeder. Quando as requisições de usuário um serviço, identidade (dele/dela) deverem ser estabelecidas. Para fazer isto, um bilhete é apresentado ao server, junto com a prova que o bilhete originalmente esteve emitido ao usuário, não roubado. Há três fases à autenticação com o Kerberos. Na primeira fase, o usuário obtém as credenciais a ser usadas para pedir o acesso aos outros serviços. Na segunda fase, a autenticação das requisições de usuário para um serviço específico. Na fase final, o usuário apresenta aquelas credenciais ao servidor final.

Credenciais do Kerberos

Há dois tipos de credenciais usadas no modelo de autenticação de kerberos: bilhetes e autenticadores. Ambos são baseados na criptografia chave privada, mas são cifradas usando chaves diferentes. Um bilhete é usado para passar firmemente a identidade da pessoa a quem o bilhete foi emitido entre o Authentication Server e o servidor final. Um bilhete igualmente passa a informação que pode ser usada para se certificar de que a pessoa que usa o bilhete é a mesma pessoa a que foi emitido. O autenticador contém a informação adicional que, quando comparada contra aquela no bilhete mostra que o cliente que apresenta o bilhete é mesmo a que o bilhete foi emitido.

Um bilhete é bom para um servidor único e um único cliente. Contém o nome do server, o nome do cliente, o endereço do Internet do cliente, um timestamp, uma vida, e uma chave de sessão aleatória. Esta informação é cifrada usando a chave do server para que o bilhete será usado. Uma vez que o bilhete foi emitido, pode ser usado épocas múltiplas pelo cliente Nomeado aceder ao servidor nomeado, até que o bilhete expire. Note que porque o bilhete é cifrado na chave do server, é seguro permitir que o usuário passe o bilhete sobre ao server sem ter que se preocupar sobre o usuário que altera o bilhete.

Ao contrário do bilhete, o autenticador pode somente ser usado uma vez. Um novo deve ser gerado cada vez que um cliente quer usar um serviço. Isto não apresenta um problema porque o cliente pode construir o autenticador próprio. Um autenticador contém o nome do cliente, do endereço IP de Um ou Mais Servidores Cisco ICM NT da estação de trabalho, e do tempo atual de estação de trabalho. O autenticador é cifrado na chave de sessão que é parte do bilhete.

Obtenha o ticket de kerberos inicial

Quando o usuário andar acima a uma estação de trabalho, simplesmente uma parte de informação pode provar a identidade (dele/dela): a senha de usuário. A troca inicial com o Authentication Server é projetada minimizar a possibilidade que a senha estará comprometida, ao ao mesmo tempo não permitir que um usuário autentique corretamente a/ele mesmo sem conhecimento dessa senha. O processo de fazer login parece ao usuário ser o mesmo que entrando a um sistema de associação de tempo. Atrás das cenas, embora, é bastante diferente.

O usuário é alertado para ela/seu username. Uma vez que foi entrado, um pedido está enviado ao Authentication Server que contém o nome de usuário e o nome de um serviço especial conhecido como o serviço de consessão de licensa.

O Authentication Server certifica-se de saiba sobre o cliente. Em caso afirmativo, gerencie uma chave de sessão aleatória que seja usada mais tarde entre o cliente e o servidor de consessão de licensa. Cria então um bilhete para o servidor de consessão de licensa que contém o nome do cliente, o nome do servidor de consessão de licensa, as horas atual, uma vida para o bilhete, o endereço IP de Um ou Mais Servidores Cisco ICM NT do cliente, e a chave de sessão aleatória apenas criada. Isto é cifrado toda em uma chave conhecida somente ao servidor de consessão de licensa e ao Authentication Server.

O Authentication Server envia então o bilhete, junto com uma cópia da chave de sessão aleatória e de alguma informação adicional, de volta ao cliente. Esta resposta é cifrada na chave privada do cliente, conhecida somente ao Kerberos e ao cliente, que é derivado da senha de usuário.

Uma vez que a resposta foi recebida pelo cliente, o usuário está pedido ela/sua senha. A senha é convertida a uma chave DES e usada para decifrar a resposta do Authentication Server. O bilhete e a chave de sessão, junto com alguma da outra informação, são armazenados para uso futuro, e a senha de usuário e a chave DES são apagadas da memória.

A troca foi terminada uma vez, a estação de trabalho possui a informação que pode usar para provar a identidade de seu usuário para a vida do ticket-granting ticket (ingresso que concede ingresso). Enquanto o software na estação de trabalho não tinha sido alterado previamente, nenhuma informação existe que permitirá que alguma outra pessoa encarne o usuário além da vida do bilhete.

Peça um serviço de kerberos

No momento, deixe-nos fingem que o usuário já tem um bilhete para o servidor desejado. A fim aceder ao server, o aplicativo constrói um autenticador que contêm o nome e o endereço IP de Um ou Mais Servidores Cisco ICM NT do cliente, e as horas atual. O autenticador é cifrado então na chave de sessão que foi recebida com o bilhete para o server. O cliente envia então o autenticador junto com o bilhete ao server de um modo definido pelo aplicativo individual.

Uma vez que o autenticador e o bilhete foram recebidos pelo server, o server decifra o bilhete, usa a chave de sessão incluída no bilhete para decifrar o autenticador, compara a informação no bilhete com a aquela no autenticador, no endereço IP de Um ou Mais Servidores Cisco ICM NT de que o pedido foi recebido, e no tempo atual. Se tudo combina, permite o pedido continuar.

Supõe-se que os pulsos de disparo estão sincronizados dentro de diversos minutos. Se o tempo no pedido é demasiado distante no futuro ou o passado, o server trata o pedido como uma tentativa à repetição uma requisição precedente. O server é permitido igualmente manter-se a par de tudo pedidos do passado com timestamps que são ainda válidos. A fim foil mais os ataques de replay, um pedido recebido com o mesmo bilhete e o timestamp como um já recebido pode ser rejeitado.

Finalmente, se o cliente especifica que quer o server provar também sua identidade, o server adiciona um ao timestamp o cliente enviado no autenticador, cifra o resultado na chave de sessão, e envia o resultado de volta ao cliente.

No fim desta troca, é certo que o server que, de acordo com o Kerberos, o cliente é quem diz que é. Se a autenticação mútua ocorre, o cliente está convencido igualmente que o server é autêntico. Além disso, a parte do cliente e servidor uma chave que ninguém mais conheça, e pode com segurança supor que razoavelmente um mensagem recente cifrado nessa chave originou com o outro partido.

Obtenha ticket de servidor kerberos

Recorde que um bilhete é somente bom para um servidor único. Como tal, é necessário obter um bilhete separado para cada serviço que o cliente quer se usar. Os bilhetes para servidores individuais podem ser obtidos do serviço de consessão de licensa. Desde que o serviço de consessão de licensa é próprio um serviço, utiliza o protocolo de acesso do serviço descrito na seção anterior.

Quando um programa exige um bilhete que não esteja pedido já, envia um pedido ao servidor de consessão de licensa. O pedido contém o nome do server para que um bilhete é pedido, junto com o ticket-granting ticket (ingresso que concede ingresso) e de um autenticador construídos como descrito na seção anterior.

O servidor de consessão de licensa verifica então o autenticador e o ticket-granting ticket (ingresso que concede ingresso) como descrito acima. Se válido, o servidor de consessão de licensa gerencie uma chave de sessão aleatória nova a ser usada entre o cliente e o server novo. Constrói então um bilhete para o server novo que contém o nome do cliente, o nome do servidor, as horas atual, o endereço IP de Um ou Mais Servidores Cisco ICM NT do cliente e a chave de sessão que nova apenas gerou. A vida do bilhete novo é o mínimo da vida restante para o ticket-granting ticket (ingresso que concede ingresso) e do padrão para o serviço.

O servidor de consessão de licensa envia então o bilhete, junto com a chave de sessão e a outra informação, de volta ao cliente. Esta vez, contudo, a resposta é cifrada na chave de sessão que era parte do ticket-granting ticket (ingresso que concede ingresso). Esta maneira, lá não é nenhuma necessidade para que o usuário incorpore a/sua senha outra vez.

O banco de dados Kerberos

Até este ponto, nós discutimos as operações que exigem o acesso somente leitura ao base de dados de Kerberos. Estas operações são executadas pelo serviço de autenticação, que pode ser executado em máquinas do mestre e do escravo.

Nesta seção, nós discutimos as operações que exigem o acesso de gravação ao base de dados. Estas operações são executadas pelo serviço da administração, chamado o Kerberos Database Management Service (KDBM). A implementação atual estipula que as mudanças podem somente ser feitas ao base de dados kerberos mestre; as cópias do escravo são de leitura apenas. Consequentemente, o servidor KDBM pode somente ser executado na máquina kerberos mestre.

Note que, quando a autenticação puder ainda ocorrer (em escravos), as requisições de administração não podem ser prestadas serviços de manutenção se a máquina mestre está para baixo. Em nossa experiência, isto não apresentou um problema, porque as requisições de administração são raras.

O KDBM segura pedidos dos usuários mudar suas senhas. O lado do cliente deste programa, que envia pedidos ao KDBM sobre a rede, é o programa de kpasswd. O KDBM igualmente aceita pedidos dos administradores de kerberos, que podem adicionar principais ao base de dados, assim como muda senhas para gerentes existentes. O lado do cliente do programa da administração, que igualmente envia pedidos ao KDBM sobre a rede, é o programa kadmin.

O servidor KDBM

O servidor KDBM aceita pedidos adicionar principais ao base de dados ou mudar as senhas para gerentes existentes. Este serviço é original que o serviço de consessão de licensa não emitirá bilhetes para ele. Em lugar de, o serviço de autenticação próprio deve ser usado (o mesmo serviço que é usado para obter um ticket-granting ticket (ingresso que concede ingresso)). A finalidade desta é exigir o usuário incorporar uma senha. Se isto não era assim, a seguir se um usuário saiu dela/sua estação de trabalho desacompanhadas, um transeunte poderia andar acima e mudar a/sua senha para elas, algo que deve ser impedido. Igualmente, se um administrador saiu dela/sua estação de trabalho descuidados, um transeunte poderia mudar toda a senha no sistema.

Quando o servidor KDBM recebe um pedido, autoriza-o comparando o nome principal autenticado do solicitador da mudança ao nome principal do alvo do pedido. Se são os mesmos, o pedido está permitido. Se não são os mesmos, o servidor KDBM consulta um Access Control List (armazenado em um arquivo no sistema Kerberos mestre). Se o nome principal do solicitador é encontrado neste arquivo, o pedido está permitido, se não nega-se.

Por convenção, os nomes com um exemplo NULO (o exemplo do padrão) não aparecem no arquivo do Access Control List; em lugar de, uma instância de administração é usada. Consequentemente, para que um usuário transforme-se um administrador do Kerberos um a instância de administração para esse username deve ser criado, e adicionado ao Access Control List. Esta convenção permite que um administrador use uma senha de autenticação Kerberos diferente então que se usaria para o início de uma sessão normal.

Todos os pedidos ao programa KDBM, se permitido ou negado, são registrados.

Os programas kadmin e kpasswd

Os administradores do Kerberos usam o programa kadmin para adicionar principais ao base de dados, ou mudam as senhas das gerentes existentes. Um administrador está exigido incorporar a senha para seu nome da instância de administração quando invocam o programa kadmin. Esta senha é usada para buscar um bilhete para o servidor KDBM.

Os usuários podem mudar suas senhas de kerberos usando o programa de kpasswd. Estão exigidos incorporar sua senha antiga quando invocam o programa. Esta senha é usada para buscar um bilhete para o servidor KDBM.

Replicação de banco de dados kerberos

Cada esfera de kerberos tem uma máquina kerberos mestre, que abrigue a cópia mestre da base de dados de autenticação. É possível (embora não necessário) ter adicional, cópias de somente leitura do base de dados em máquinas do escravo em outra parte no sistema. As vantagens de ter cópias múltiplas do base de dados são aquelas mencionado geralmente para a replicação: disponibilidade mais alta e melhor desempenho. Se a máquina mestre está para baixo, a autenticação pode ainda ser conseguida em uma das máquinas do escravo. A capacidade para executar a autenticação em qualquer de diversas máquinas reduz a probabilidade de um gargalo na máquina mestre.

Manter cópias múltiplas do base de dados introduz o problema da consistência de dados. Nós encontramos que muito os métodos simples bastam tratando a inconsistência. O base de dados mestre é despejado cada hora. O base de dados é enviado, em sua totalidade, às máquinas do escravo, que atualizam então seus próprios bases de dados. Um programa no host mestre, chamado kprop, envia a atualização a um programa do par, chamado kpropd, sendo executado em cada um das máquinas do escravo. O primeiro kprop envia uma soma de verificação do base de dados que novo esteja a ponto de enviar. A soma de verificação é cifrada na chave de base de dados mestre do Kerberos, que as máquinas do Kerberos do mestre e do escravo possuem. Os dados são transferidos então sobre a rede ao kpropd na máquina do escravo. O server da propagação do escravo calcula uma soma de verificação dos dados que receba, e se combina a soma de verificação enviada pelo mestre, a informação nova é usada para atualizar o base de dados do escravo.

Todas as senhas no base de dados de Kerberos são cifradas na chave de base de dados mestre consequentemente, a informação passada do mestre para slave sobre a rede não são úteis a um eavesdropper. Contudo, é essencial que somente a informação do host mestre esteja aceitada pelos escravos, e que a alteração dos dados esteja detectada, assim a soma de verificação.

Visão externa do Kerberos

Esta seção descreve o Kerberos do ponto de vista prático, primeiramente como considerado pelo usuário, então do ponto de vista do programador de aplicativo, e finalmente, com as tarefas do administrador de kerberos.

Ponto de vista do usuário do Kerberos

Se tudo vai bem, o usuário observará mal que o Kerberos esta presente. Em nossa implementação Unix, o ticket-granting ticket (ingresso que concede ingresso) é obtido do Kerberos como parte do processo de login. A mudança da senha de kerberos de um usuário é parte do programa da senha. E os bilhetes do Kerberos forem destruídos automaticamente quando log de usuário para fora.

Se a sessão de login do usuário dura mais por muito tempo do que a vida do ticket-granting ticket (ingresso que concede ingresso) (atualmente 8 horas), o usuário observará a presença do Kerberos porque a próxima vez que um aplicativo Kerberos-autenticado é executado, falhará. O bilhete do Kerberos para ele terá expirado. Nesse ponto, o usuário pode executar o programa do kinit para obter um bilhete novo para o servidor de consessão de licensa. Como ao entrar, uma senha deve ser fornecida a fim obtê-lo. Um usuário que executa o comando klist fora da curiosidade pode ser surpreendido em todos os bilhetes quais foram obtidos silenciosamente em ela/seu nome para serviços quais exigem a autenticação de Kerberos.

Kerberos do ponto de vista do programador

Um programador que escreve um aplicativo Kerberos frequentemente estará adicionando a autenticação já a um aplicativo da rede existente que consiste em um lado do cliente e servidor. Nós chamamos este processo “Kerberizing” um programa. Kerberizing envolve geralmente fazer um atendimento à biblioteca de kerberos a fim executar a autenticação na solicitação inicial para o serviço. Pode igualmente envolver atendimentos à biblioteca de DES para cifrar as mensagens e os dados que são enviados subseqüentemente entre o cliente de aplicativo e o server de aplicativo.

As funções de biblioteca as mais de uso geral são krb_mk_req no lado do cliente, e krb_rd_req no lado de servidor. A rotina do krb_mk_req toma como parâmetros o nome, o exemplo, e o reino do servidor de destino, que será pedido, e uma soma de verificação dos dados a ser enviados possivelmente. O cliente envia então a mensagem retornada pelo atendimento do krb_mk_req sobre a rede ao lado de servidor do aplicativo. Quando o server recebe esta mensagem, faz um atendimento ao krb_rd_req da rotina de biblioteca. A rotina retorna um julgamento sobre a autenticidade da identidade alegada do remetente.

Se o aplicativo exige que as mensagens enviadas entre o cliente e servidor sejam secretas, a seguir os atendimentos da biblioteca podem ser feitos ao krb_mk_priv (krb_rd_priv) para cifrar mensagens (do decrypt) na chave de sessão de que os ambos os lados compartilham agora.

O trabalho do administrador do Kerberos

O trabalho do administrador de kerberos começa com executar um programa para inicializar o base de dados. Um outro programa deve ser executado para registrar princípios essenciais no base de dados, tal como o nome do administrador de kerberos com uma instância de administração. O server da autenticação de Kerberos e o servidor de administração devem ser postos em andamento. Se há uns bases de dados do escravo, o administrador deve arranjar que os programas para propagar atualizações da base de dados do mestre aos escravos estejam retrocedidos fora periodicamente.

Depois que estas etapas inicial foram tomadas, o administrador manipula o base de dados sobre a rede, usando o programa kadmin. Com esse programa, os principais novos podem ser adicionados, e as senhas podem ser mudadas.

Em particular, quando um aplicativo Kerberos novo é adicionado ao sistema, o administrador de kerberos deve tomar algumas etapas para obtê-lo que trabalha. O server deve ser registrado no base de dados, e atribuiu uma chave privada (geralmente esta é uma chave aleatória automaticamente gerada). Então, alguns dados (que incluem a chave do server) devem ser extraídos do base de dados e ser instalados em um arquivo na máquina do server. O arquivo padrão é /etc/srvtab. A rotina de biblioteca do krb_rd_req chamada pelo server (veja a seção anterior) usa a informação nesse arquivo para decifrar as mensagens enviadas cifradas na chave privada do server. O arquivo de /etc/srvtab autentica o server enquanto uma senha datilografada em um terminal autentica o usuário.

O administrador de kerberos deve igualmente assegurar-se de que as máquinas do Kerberos sejam fisicamente seguras, e igualmente seria sábio manter backup do base de dados mestre.

Análise mais ampla do banco de dados Kerberos

Nesta seção, nós descrevemos como ajustes do Kerberos no ambiente Athena, incluindo seu uso por outros serviços de rede e aplicativos, e como interage com as esferas de kerberos remotas. Para mais descrição completa do ambiente Athena, veja por favor G.W. Treese.

Uso de Kerberos por outros serviços de rede

Diversos aplicativos de rede foram alterados usar o Kerberos. Os comandos rlogin and rsh tentam primeiramente autenticar usando o Kerberos. Um usuário com os bilhetes válidos do Kerberos enlata rlogin a uma outra máquina de Athena sem ter que estabelecer arquivos do .rhosts. Se a autenticação de Kerberos falha, os programas voltam seus métodos usuais de autorização, neste caso, os arquivos do .rhosts.

Nós alteramos o protocolo Post Office Protocol para usar o Kerberos para os usuários de autenticação que desejam recuperar seu correio eletrônico da “correspondência.” Um programa da entrega de mensagem, chamado Zéfiro, tem sido desenvolvido recentemente em Athena, e usa o Kerberos para a autenticação também.

O programa para assinar acima novos usuários, chamado registro, usa o Service Management System (SMS) e o Kerberos. De SMS, determina se a informação incorporada pelo usuário novo em potência de Athena, tal como o nome e o número de identificação MIT, é válida. Verifica então com o Kerberos para ver se o username pedido é original. Se tudo vai bem, uma entrada nova está feita ao base de dados de Kerberos, contendo o nome de usuário e senha.

Para uma discussão detalhada do uso do Kerberos fixar o Network File System de Sun, refira por favor o apêndice.

Interação com outros Kerberi

Espera-se que as organizações administrativas diferentes quererão usar o Kerberos para a autenticação de usuário. Igualmente espera-se que em muitos casos, os usuários em uma organização quererão usar serviços em outra. Campos administrativos do Kerberos suporta vários. A especificação dos nomes no Kerberos inclui um campo chamado o reino. Este campo contém o nome do campo administrativo dentro de que o usuário deve ser autenticada.

Os serviços são registrados geralmente em um único reino e aceitarão somente as credenciais emitidas por um Authentication Server para esse reino. Um usuário é registrado geralmente em um único reino (a esfera local), mas é possível para que ela/obtenha as credenciais emitidas por um outro reino (o domínio remoto), na força da autenticação fornecida pela esfera local. As credenciais válidas em um domínio remoto indicam o reino em que o usuário foi autenticado originalmente. Os serviços no domínio remoto podem escolher se honrar aquelas credenciais, segundo o grau de segurança exigido e o nível de confiança no reino que autenticou inicialmente o usuário.

A fim executar a autenticação do cruz-reino, é necessário que os administradores de cada par de reinos selecionam uma chave para ser compartilhados entre seus reinos. Um usuário na esfera local pode então pedir um ticket-granting ticket (ingresso que concede ingresso) do servidor de autenticação local para o servidor de consessão de licensa no domínio remoto. Quando esse bilhete é usado, o servidor de consessão de licensa remoto reconhece que o pedido não é de seu próprio reino, e usa a chave previamente trocada para decifrar o ticket-granting ticket (ingresso que concede ingresso). Emite então um bilhete como normalmente, salvo que o campo do reino para o cliente contém o nome do reino em que o cliente foi autenticado originalmente.

Esta aproximação podia ser estendida para permitir que se autentique-se oneself com uma série de realms até o alcance do reino com o serviço desejado. A fim fazer isto, embora, seria necessário gravar o trajeto inteiro que foi tomado, e não apenas o nome do reino inicial em que o usuário foi autenticado. Em tal situação, tudo que é sabido pelo server é que A diz que B diz que o C diz que o usuário é fulano. Esta indicação pode somente ser confiada se todos ao longo do trajeto é confiado igualmente.

Questões e problemas abertos do Kerberos

Há um número de questões e problema aberto associadas com o mecanismo de autenticação de Kerberos. Entre as edições seja como decidir a vida correta para um bilhete, como permitir proxys, e como garantir a integridade de estação de trabalho.

O problema da vida do bilhete é uma matéria de escolher a transação apropriada entre a Segurança e a conveniência. Se a vida de um bilhete é longa, a seguir se um bilhete e sua chave de sessão associada são roubados ou colocados mal, podem ser usados por um período de tempo mais longo. Tal informação pode ser roubada se um usuário esquece logout de uma estação de trabalho pública. Alternativamente, se um usuário foi autenticado em um sistema que permitisse usuários múltiplos, um outro usuário com o acesso a enraizar pôde poder encontrar a informação necessária usar bilhetes roubados. O problema com doação um bilhete de uma vida curto, contudo, é que quando expira, o usuário terá que obter um novo que exija o usuário incorporar outra vez a senha.

Um problema aberto é o problema com o proxy. Como pode um usuário autenticado permitir que um server adquira outros serviços de rede em ela/seu nome? Um exemplo onde este seja importante é o uso de um serviço que aceda aos arquivos protegidos diretamente de um fileserver. Um outro exemplo deste problema é o que nós chamamos encaminhamento de autenticação. Se um usuário é registrado em uma estação de trabalho e entra a um host remoto, seria agradável se o usuário teve o acesso aos mesmos serviços disponíveis localmente, ao executar um programa no host remoto. O que faz este difícil é que o usuário não pôde confiar o host remoto, assim o encaminhamento de autenticação não é desejável em todos os casos. Nós não temos presentemente uma solução a este problema.

Um outro problema, e um que é importante no ambiente Athena, são como garantir a integridade do software que é executado em uma estação de trabalho. Isto não é tanto de um problema em estações de trabalho privadas desde que o usuário que o estará usando tem o controle sobre ele. Em estações de trabalho pública, contudo, alguém pôde ter vindo avante e ter alterado o programa do início de uma sessão para salvar a senha de usuário. A única solução presentemente disponível em nosso ambiente é fazê-la difícil para que os povos alterem o software que é executado nas estações de trabalho pública. Uma solução melhor exigiria que a chave do usuário nunca deixa um sistema que o usuário conhecesse pudesse ser confiado. Uma maneira que esta poderia ser feita seria se o usuário possuiu uma carta inteligente capaz de fazer as criptografias exigidas no protocolo de autenticação.

Status do Kerberos

Uma versão protótipo do Kerberos entrou na produção em setembro de 1986. Desde janeiro de 1987, o Kerberos foi os únicos meios do projeto Athena de autenticar seus 5,000 usuários, 650 estações de trabalho, e 65 server. Além, o Kerberos está sendo usado agora no lugar dos arquivos do .rhosts para o acesso de controlo em diversos dos sistemas de associação de tempo de Athena.

Reconhecimentos de Kerberos

O Kerberos foi projetado inicialmente por Steve Miller e por Clifford Neuman com sugestões do jeff schiller e do Jerry Saltzer. Desde então, numeroso outros povos foram envolvidos com o projeto. Entre eles são Jim Aspnes, Bob Baldwin, John Barba, Richard Basch, Jim Bloom, Bill Bryant, Mark Colan, Rob French, Dan Geer, John Kohl, John Kubiatowicz, Bob McKie, Brian Murphy, John Ostlund Ken Raeburn, Chris Reed, Jon Rochlis, Mike Shanzer, Bill Sommerfeld, Ted T'so, Win Treese, e Stan Zanarotti.

Nós somos gratos a Dan Geer, a Kathy Lieben, a Josh Lubarr, a Ken Raeburn, a Jerry Saltzer, a ED steiner, a Robbert van Renesse, e a Win Treese cujas as sugestões melhoraram muito uns esboços mais adiantados deste papel.

Jedlinsky, J.T. Kohl, e W.E. Sommerfeld, “o sistema de notificação zephyr,” em eventos de conferência de Usenix (inverno, 1988).

M.A. Rosenstein, D.E. Geer, e P.J. Levine, em eventos de conferência de Usenix (inverno, 1988).

R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, e B. Lyon, “projeto e aplicação do Sistema de Arquivo de Rede Sun,” em eventos de conferência de Usenix (verão, 1985).

Anexo: Aplicação do Kerberos ao Network File System (NFS) da SUN

Um componente-chave do sistema de estação de trabalho do projeto Athena é a intervenção da rede entre a estação de trabalho do usuário e ela/seu armazenamento de arquivo privado (diretório home). Todo o armazenamento privado reside em um grupo de computadores (atualmente VAX 11/750s) que são dedicados a esta finalidade. Isto permite que nós ofereçam a serviços sobre publicamente - estações de trabalho Unix disponíveis. Quando um usuário entra a um destes publicamente - as estações de trabalho disponíveis, validam um pouco então a/seu nome e senha contra localmente um arquivo de senha do residente, nós usamos o Kerberos para determinar a/sua autenticidade. O programa do início de uma sessão alerta para um username (como em algum sistema Unix). Este username é usado para buscar um ticket-granting ticket (ingresso que concede ingresso) do Kerberos. O programa do início de uma sessão usa a senha para gerar uma chave DES para decifrar o bilhete. Se a descriptografia é bem sucedida, o diretório home do usuário está ficado situado consultando o serviço de nomeação de Hesiod e montado com o NFS. O programa do início de uma sessão vira então o controle para o shell do usuário, que então pode executar os arquivos tradicionais da personalização por usuário porque o diretório home “é anexado agora” à estação de trabalho. O serviço de Hesiod é usado igualmente para construir uma entrada no arquivo da senha local. (Isto é em favor dos programas que olham acima a informação em /etc/passwd.)

De diversas opções de entrega do serviço do arquivo remoto, nós escolhemos o Network File System de Sun. Contudo este sistema não engrena com nossas necessidades em uma forma crucial. O NFS supõe que todas as estações de trabalho caem em duas categorias (como visto do ponto de vista de um servidor de arquivo): confiado e não-confiável. Os Sistemas não confiável não podem alcançar nenhuns arquivos de todo, confiado podem. Os sistemas confiável são confiados completamente. Supõe-se que um sistema confiável está controlado pelo gerenciamento amigável. Especificamente, é possível de uma estação de trabalho confiada masquerade porque todo o usuário válido do sistema do serviço de arquivo e acede assim a apenas sobre cada arquivo no sistema. (Somente os arquivos possuídos pela “raiz” são isentados.)

Em nosso ambiente, o Gerenciamento de uma estação de trabalho (no sentido tradicional do Gerenciamento de sistema Unix) está nas mãos do usuário que usa atualmente o. Nós não fazemos nenhum segredo da senha root em nossas estações de trabalho, porque nós realizamos que um usuário verdadeiramente hostil pode adaptar pelo fato mesmo de que se está sentando no mesmo local físico que a máquina e tem o acesso a todas as funções de console. Consequentemente nós não podemos verdadeiramente confiar nossas estações de trabalho na interpretação NFS da confiança. Para permitir a controles de acesso apropriados em nosso ambiente nós tivemos que fazer algumas alterações ao software da base NFS, e integramos o Kerberos no esquema.

NFS de Kerberos não modificado

Na aplicação do NFS que nós começamos com (da universidade de wisconsin), a autenticação foi fornecida sob a forma de uma parte de dados incluídos em cada pedido NFS (chamado umas “credenciais” na terminologia NFS). Estas credenciais contêm a informação sobre o identificador de usuário original (UID) do solicitador e uma lista dos identificadores do grupo (GIDs) da sociedade do solicitador. Esta informação é usada então pelo servidor de NFS para a verificação de acesso. A diferença entre uma estação de trabalho confiada e não-confiável é mesmo se suas credenciais estão aceitadas pelo servidor de NFS.

NFS modificado de Kerberos

Em nosso ambiente, os servidores de NFS devem aceitar credenciais de uma estação de trabalho se e somente se as credenciais indicam o UID do usuário da estação de trabalho, e de não outro.

Uma solução óbvia seria mudar a natureza de credenciais dos meros indicadores do UID e do GIDs ao Kerberos desenvolvido autenticou dados. Contudo uma penalidade de desempenho significativa seria paga se esta solução foi adotada. As credenciais são trocadas em cada operação NFS que inclui todo o disco lido e escrevem atividades. Incluindo uma autenticação de Kerberos em cada transação do disco adicionaria um número justo de criptografias desenvolvidas (feitas no software) pela transação e, de acordo com nossos cálculos de envelope, entregaria o desempenho inaceitável. (Igualmente exigiria a colocação das rotinas de biblioteca de kerberos no espaço de endereços do núcleo.)

Nós precisamos uma aproximação híbrida, descrita abaixo. A ideia básica é ter as credenciais do mapa do servidor de NFS recebidas das estações de trabalho cliente, a umas credenciais válidas (e possivelmente diferentes) no sistema de servidor. Este mapeamento é executado no núcleo do server em cada transação NFS e setup no tempo da “montagem” por um processo do nível de usuário que contrate na autenticação moderada do Kerberos antes de estabelecer um mapeamento de credencial do kernel válido.

Para executar isto nós adicionamos uma chamada de sistema nova ao núcleo (exigido somente em sistemas de servidor, não em sistemas de cliente) que fornece para o controle da função de mapeamento que credenciais entrantes dos mapas das estações de trabalho cliente às credenciais válidas para o uso no server (eventualmente). A função de mapeamento básica traça a tupla:

<CLIENT-IP-ADDRESS, UID-ON-CLIENT>

a umas credenciais NFS válidas no sistema de servidor. O CLIENT-IP-ADDRESS é extraído do pacote de requisição NFS fornecido pelo sistema de cliente. Nota: toda a informação nas credenciais cliente-geradas exceto o UID-ON-CLIENT é rejeitada.

Se nenhum mapeamento existe, o server reage em uma de duas maneiras, dependendo ele está configurado. Em nossa configuração adequada nós optamos pelos pedidos unmappable nas credenciais para o usuário “ninguém” quem não tem nenhum acesso de privilegiado e tem um UID original. Os server hostis retornam um erro de acesso NFS quando nenhum mapeamento válido pode ser encontrado para umas credenciais NFS recebidas.

Nossa chamada de sistema nova é usada para adicionar e suprimir de entradas do mapa residente de kernel. Igualmente fornece a capacidade para nivelar todas as entradas que traçam a um UID específico no sistema de servidor, ou nivela todas as entradas de um CLIENT-IP-ADDRESS dado.

Nós alteramos o demônio da montagem (que segura requisições de instalação NFS em sistemas de servidor) para aceitar um tipo de transação novo, o pedido do mapeamento da autenticação de Kerberos. Basicamente, como parte do processo da montagem, o sistema de cliente fornece uma autenticação de kerberos junto com uma indicação dela/seu UID-ON-CLIENT (cifrados na autenticação de kerberos) na estação de trabalho. O demônio da montagem do server converte o nome de Kerberos principal em um nome de usuário local. Este username é olhado então acima em um arquivo especial para render a lista UID e GIDs do usuário. Para a eficiência, este arquivo é um arquivo da base de dados do ndbm com o username como a chave. Desta informação, umas credenciais de NFS são construídas e entregadas ao núcleo como o mapeamento válido do <CLIENT-IP-ADDRESS, tupla CLIENT-UID> para este pedido.

No tempo do unmount um pedido é enviado ao demônio da montagem remover o mapeamento previamente adicionado do núcleo. É igualmente possível enviar um pedido no tempo da saída invalidar todo o mapeamento para o usuário atual no server na pergunta, assim limpando todos os mapeamentos restantes que existirem (embora não devem) antes que a estação de trabalho esteja feita disponível para o usuário seguinte.

Implicações de segurança do Kerberos do NFS modificado

Esta aplicação não é completamente segura. Para começar, os dados do usuário são enviados ainda através da rede em um unencrypted, e consequentemente interceptable, formulário. O de baixo nível, autenticação da por-transação é baseado em um <CLIENT-IP-ADDRESS, pares CLIENT-UID> fornecidos unencrypted no pacote de requisição. Esta informação poderia ser forjada e assim a Segurança comprometeu. Contudo, deve-se notar que somente quando um usuário usar ativamente a/seus arquivos (isto é, quando entrados) são os mapeamentos válidos no lugar e consequentemente este formulário do ataque estão limitados a quando o usuário na pergunta é entrado. Quando um usuário não é entrado, nenhuma quantidade de falsificação do endereço IP de Um ou Mais Servidores Cisco ICM NT permitirá o acesso não autorizado a ela/seus arquivos.

Referências de Kerberos

  1. S.P. Miller, B.C. Neuman, J.I. Schiller, e J.H. Saltzer, seção E.2.1: Autenticação de Kerberos e sistema de autorização, M.I.T. Projeto Athena, Cambridge, Massachusetts (dezembro 21, 1987).

  2. E. Balkovich, S.R. Lerman, e R.P. Parmelee, “computando na educação superior: A experiência de Athena,” comunicações do ACM, Vol. 28(11), pp. 1214-1224, ACM (novembro, 1985).

  3. R.M. Needham e M.D. Schroeder, “usando a criptografia para autenticação nas redes grandes dos computadores,” comunicações do ACM, Vol. 21(12), pp. 993-999 (dezembro, 1978).

  4. V.L. Voydock e S.T. Kent, “mecanismos de segurança nos protocolos de rede de alto nível,” análises de computação, Vol. 15(2), ACM (junho 1983).

  5. Instituto nacional de padrões, “criptografia padrão de dados,” publicação 46 dos padrões de processamento de informação federal, escritório de impressão do governo, Washington, DC (1977).

  6. Tintureiro SP, “Hesiod,” em eventos de conferência de Usenix (inverno, 1988).

  7. W.J. Bryant, o curso do programador de Kerberos, mit project athena (na preparação).

  8. W.J. Bryant, o manual do administrador de kerberos, mit project athena (na preparação).

  9. G.W. Treese, “Berkeley Unix em 1000 estações de trabalho: Mudanças de Athena a 4.3BSD," em eventos de conferência de Usenix (inverno, 1988).

  10. C.A. DellaFera, M.W. Eichin, R.S. Francês, C.C. Jedlinsky, J.T. Kohl, e W.E. Sommerfeld, “o sistema de notificação zephyr,” em eventos de conferência de Usenix (inverno, 1988).

  11. M.A. Rosenstein, D.E. Geer, e P.J. Levine, em eventos de conferência de Usenix (inverno, 1988).

  12. R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, e B. Lyon, “projeto e aplicação do Sistema de Arquivo de Rede Sun,” em eventos de conferência de Usenix (verão, 1985).


Informações Relacionadas


Document ID: 16087