Propostas de Autenticao para o Protocolo de Gerncia de Redes SNMP

Mauro Tapajs Santos e Rafael Timteo de Sousa Jnior

Departamento de Engenharia Eltrica - Universidade de Braslia - UnB Caixa Postal 4386, CEP: 70919-970, Braslia DF Brasil Tel: 061-2735977, Fax: 061-2746651, tapajos@abordo.com.br, desousa@unb.br Sumrio - este trabalho apresenta propostas implementadas de servios de autenticao no protocolo SNMP, provendo um mecanismo bsico de segurana para sua verso 1 e mantendo flexibilidade suficiente para permitir uma integrao ao modelo de segurana das novas verses do protocolo. Tais propostas tm base na utilizao de senhas descartveis na autenticao das mensagens SNMP, com os necessrios protocolos criptogrficos para gerao e troca de chaves de criptografia entre as entidades usurias do protocolo. 1. INTRODUO O protocolo de gerncia de redes mais usado atualmente o SNMP (Simple Network Management Protocol). Juntamente com outros padres relacionados, SNMP oferece um denominador comum na construo de arquiteturas de gerncia de redes distribudas. Como est hoje, o SNMP ainda no responde a requisitos importantes de segurana. A efetiva gerncia de redes demanda tanto facilidades de monitorao, como de controle dos diversos componentes das redes. SNMP usado basicamente para monitorao, devido aos seus mecanismos fracos de segurana que inibem a execuo de aes distncia, necessrias s diversas tarefas de controle das redes. Em conseqncia, as operaes de configurao possveis via SNMP so subutilizadas por causa da desconfiana dos operadores e gerentes de redes com relao segurana do processo. Contudo, o projeto inicial de SNMP previra a necessidade de atualizaes. A forma modular como foi definido o protocolo visou facilitar futuras modificaes para as solues das falhas, mantendo a filosofia da simplicidade do protocolo. O problema-chave na verso mais utilizada (SNMPv1) do protocolo o emprego de um mecanismo de segurana trivial que visava oferecer autenticao para as mensagens e controle bsico de autorizaes de acesso para operaes sobre objetos gerenciados [1]. De fato, o mecanismo de autenticao em SNMPv1 consiste em preencher o campo comunidade (communityString) das mensagens do protocolo com uma senha no criptografada e virtualmente imutvel. Com freqncia, na prtica da gerncia de redes, usado o termo public como nome de comunidade. Tal senha pode ser obtida por simples anlise do trfego, permitindo a um atacante ter acesso aos elementos gerenciados para executar operaes de gerncia de rede. Assim, o acesso no-autorizado pode possibilitar a um atacante, no somente descobrir parmetros crticos dos sistemas e da rede, como tambm alter-los e prejudicar os servios que deles dependem. A segunda verso do protocolo [2], denominada SNMPv2 clssica ou SNMPv2p, tenta solucionar o problema da segurana, apresentando um modelo de segurana que integra autenticao e criptografia ao protocolo, para proteg-lo de ameaas como interrupo, interceptao, modificao e mascaramento de informaes. Isso permitiria que troca de mensagens SNMP fosse ou totalmente aberta, ou autenticada mas no privada, ou privada mas no autenticada, ou ainda autenticada e simultaneamente privada. O novo conceito de party era muito importante nesta proposta. Uma party definida como um contexto de execuo virtual nas entidades SNMP, onde a operao do protocolo restringe-se a um subconjunto de possveis operaes. A estrutura da party substitua as comunidades da verso 1, acrescentando informaes de tempo (clocks), chaves de criptografia e polticas de acesso s entidades SNMP. Foi difcil a aceitao deste novo protocolo principalmente por causa de sua incompatibilidade com a verso 1, j que as novas mensagens criptografadas no eram compreendidas pelas entidades SNMPv1. E, alm de ter problemas de overhead nas mensagens, o modelo administrativo baseado em parties implica numa pr-configurao destas parties, o que pode se tornar um processo excessivamente complexo, j que aspectos como protocolos de transporte, clocks, chaves para os algoritmos de segurana e direitos de acesso devem ser previamente definidos na etapa de configurao das entidades do protocolo, ou seja, os agentes de gerncia e gerentes de rede. Em conseqncia, foram empreendidos novos esforos de reviso do protocolo em resposta baixa aceitao da verso SNMPv2 clssica. Tal reviso se deu principalmente no que diz respeito ao contexto baseado em parties, configurao dos agentes SNMP, dificuldade de mapeamento da rede e implementao do modelo administrativo e de segurana. Decidiu-se voltar o contexto de operao do protocolo antiga forma de comunidades, sem o modelo de segurana proposto em SNMPv2 clssico, e, consequentemente, voltando ao antigo formato das mensagens. Assim, foi apresentada mais uma verso SNMP, chamada de SNMPv2c, baseada em comunidades, o que recolocou o problema de segurana original.

A partir da, dentre as tentativas de definio do modelo administrativo e de segurana, duas linhas de desenvolvimento se destacaram: a SNMP USEC (User-based Security Model) e a SNMPv2* (SNMPv2 star). Estas duas propostas, que representaram caminhos independentes percorridos por integrantes das equipes originadoras do protocolo, terminaram por convergir nos trabalhos de definio da verso 3 do protocolo, denominada SNMPv3, cujos trabalhos ainda esto sendo concludos com a elaborao de documentos que sero submetidos ao processo da padronizao definitiva [3]. Alguns detalhes da nova proposta ainda esto em discusso, e, at o momento da redao deste artigo, as especificaes geradas ainda no possuam status de padronizao completa. Na proposta SNMPv3, existe, at o momento da redao deste trabalho, um nico modelo de segurana sendo adotado. Ele se chama USM - User-Based Security Model [4] e sua implementao obrigatria em todas as entidades SNMPv3. O modelo de segurana USM identifica as ameaas levadas em considerao na operao do protocolo SNMP e define as protees a serem usadas e as regras que o tornaro operacional dentro da arquitetura proposta para SNMPv3. USM basicamente derivado do modelo SNMP USEC de segurana baseado em usurio [5], com algumas alteraes. Nele, existe um conceito de usurio ao qual esto associadas informaes de segurana usadas em um ambiente de gerncia SNMP. A definio de SNMPv3 reconhece que um erro querer definir um nico modelo de segurana definitivo e imutvel, pois, com o tempo, novos requisitos de segurana aparecero e outros podem cair em desuso. Assim, admite-se que SNMP poder suportar vrios modelos de segurana, sendo porm obrigatria a implementao do USM para garantir compatibilidade com o modelo inicial de SNMPv3 As principais ameaas levadas em considerao na definio de SNMPv3 so a modificao da informao gerada por um usurio vlido e o mascaramento de um usurio, efetivado pelo uso de uma identificao falsa por parte de uma entidade no autorizada. Tambm foram consideradas, ainda como secundrias, as seguintes ameaas de replay, ou seja reordenamento e atraso das mensagens de forma estranha operao normal da rede, e falta de privacidade nas trocas de mensagens entre entidades SNMP. Estas ameaas so evitadas com a utilizao de criptografia e de uma poltica de acesso s informaes, o que subentende a utilizao de algoritmos criptogrficos e de chaves de criptografia. Os servios de segurana para defesa contra as ameaas consideradas acima so: integridade dos dados da mensagem, autenticao da origem das mensagens, confidencialidade dos dados das mensagens e proteo temporizada contra replays. Todos eles so servios comuns de segurana nas mensagens do protocolo. Cabe notar que o servio de autenticao da origem dos dados proposto s pode garantir que se saiba qual usurio dentro do modelo USM est enviando a

mensagem. Assim, qualquer um, de posse das informaes daquele usurio, pode agir sob seu nome. Por outro lado, o modelo USM oferece capacidade de autenticao e confidencialidade da comunicao. Como no possvel oferecer confidencialidade sem ter autenticao da origem e garantia da integridade dos dados, existem 3 nveis de segurana possveis dentro do modelo: 1. Comunicao sem autenticao ou confidencialidade (nvel de segurana denominado noAuthNoPriv); 2. Comunicao com autenticao, mas sem confidencialidade (denominado authNoPriv); 3. Comunicao com autenticao e confidencialidade (denominado authPriv). Dentre os campos componentes dos dados globais da mensagem SNMPv3, est a informao de qual ser o nvel de segurana que dever ser aplicado mensagem. Para implementar os mecanismos de segurana descritos acima, so definidos 3 mdulos dentro do modelo de segurana: mdulo de autenticao (que lida com a integridade dos dados e autenticao da origem), mdulo de temporizao (que lida com atrasos e replays de mensagens) e mdulo de confidencialidade (que lida com a privacidade da mensagem). Visando a implementao desses mdulos, preconizada a utilizao de protocolos criptogrficos de autenticao, de integridade dos dados e autenticao da origem, com base nos algoritmos MD5 [6] e SHA-1 [7], alm do mtodo HMAC (Keyed-Hashing for Message Authentication) [8]. Diante dessa evoluo, e considerando que, apesar do desenvolvimento j avanado, o trabalho em SNMPv3 ainda no est concludo e algumas questes ainda esto em aberto, o trabalho apresentado neste artigo procura desenvolver alternativas de mecanismos de autenticao para SNMP compatveis com as verses anteriores do protocolo, ainda largamente utilizadas e bastante eficazes. Nesse sentido, as propostas descritas nesta artigo visam apresentar um mecanismo autenticador de mensagens SNMP para as verses v1 e v2c do protocolo, mecanismo este capaz de substituir o esquema trivial de autenticao dessas verses. Por outro lado, foi tambm preocupao no desenvolvimento manter coerncia com os trabalhos em SNMPv3, de forma a tornar possvel a utilizao das propostas aqui descritas dentro da arquitetura da verso 3. Assim, so apresentados a seguir dois protocolos de autenticao, denominados auth-N e auth-P, ambos com base no emprego de chaves de autenticao que mudam constantemente, reduzindo o risco da quebra de qualquer uma das chaves a um comprometimento de somente uma mensagem SNMP e isso apenas no momento em que tal mensagem est sendo trocada entre duas entidades de gerncia de rede. 2. PROTOCOLOS DE AUTENTICAO PROPOSTOS

Os protocolos de autenticao aqui propostos se preocupam basicamente com as ameaas de modificao da informao e mascaramento. Para oferecer proteo contra estes ataques, enviada juntamente com a mensagem, a informao de autenticao. Esta informao ser usada pelo receptor no processo de verificao da autenticidade da mensagem, implicando na necessidade de um mtodo de gerao desta informao, em funo pelo menos dos dados da prpria mensagem e de um segredo compartilhado pelas duas partes, ou seja, uma chave de autenticao. A soluo do problema deve estar integrada totalmente com a operao normal dos protocolos SNMPv1 e SNMPv2c. Isto significa que, alm de a mensagem permanecer a mesma, o novo mdulo de autenticao no deve alterar outros aspectos como o controle de acesso s informaes de gerncia ou a execuo normal de cada tipo de operao SNMP. Um cliente SNMP (gerente) deve construir e enviar o seu pedido ao servidor (agente), usando a chave de autenticao correta. Devido ao fato de o protocolo UDP (ou outro protocolo de transporte que no seja confivel) no garantir a entrega dos pacotes, o cliente deve implementar estratgias para timeout e retransmisso das mensagens. Nessa situao, vale mais uma vez lembrar que a comunicao autenticada se d ento pelo procedimento que consiste em calcular o campo de autenticao para a mensagem que se quer enviar e enviar tal campo juntamente com a mensagem. Na recepo, feito novamente o mesmo clculo e a comparao entre os dois valores determina se a mensagem autntica. Para no alterar o formato das mensagens, o prprio campo comunidade (communityString) de SNMPv1 e SNMPv2c usado para enviar as informaes de autenticao entre as entidades participantes. A idia bsica das solues aqui propostas fazer com que o segredo compartilhado entre gerente e agente mude a cada solicitao SNMP. Esta mudana contnua permite evitar que o segredo, mesmo conhecido, no tenha maior utilidade j que sua validade cobre to somente uma nica transao SNMP. Para no alterar o formato da mensagem SNMP v1 ou v2c, o campo a ser usado para transporte da informao de autenticao unicamente o campo comunidade (communityString), que passa a ter uma nova interpretao. Desta forma, toda a informao pertinente de autenticao ser processada conforme descrito a seguir e ser ento inserida no campo communityString, mais especificamente na forma de uma sequncia de bits. A informao de autenticao a ser gerada e inserida na mensagem dever ser uma funo da chave de autenticao definida, das caractersticas de controle de acesso desejadas e da prpria mensagem. Mais especificamente, neste trabalho, as duas propostas de protocolo de autenticao para SNMP implementam um esquema onde ocorre uma transformao contnua das chaves de autenticao. O comprometimento de uma delas no coloca em perigo mensagens ou chaves que venham a ser geradas posteriormente. A RFC 1905 [9] sugere que cada nova

mensagem tenha um novo valor para o campo requestId, o mesmo pode ser dito aqui em relao chave de autenticao a ser usada: ela deve mudar a cada mensagem, mesmo no caso de retransmisso. No processo de autenticao, as respostas utilizam a mesma chave de autenticao usada nas solicitaes. Respostas sem correspondncia com solicitaes so descartadas. Ou seja, a autenticao obrigatria para as respostas tambm. Estes mecanismos dependem da inicializao prvia de dados de autenticao nos elementos da rede, sendo este procedimento uma deciso de implementao e podendo ser usados quaisquer mtodos, tanto automticos (certificados, canais seguros), como manuais. Esta a mesma posio do grupo de trabalho SNMPv3. A chave de autenticao proposta tem 128 bits. Este valor foi considerado suficiente para a aplicao de autenticao em questo, pois as operaes de gerncia de rede tm um tempo de vida normalmente curto. 2.1 Protocolo Auth-P Este protocolo cria uma chave de autenticao aleatria a cada mensagem. Esta chave cifrada e enviada juntamente com a mensagem, atravs de um subcampo do communityString, denominado informao de chave. Na recepo, a chave decifrada e a autenticao testada. O P aqui indica que a chave passa pela rede juntamente com a mensagem. Para realizar o protocolo, uma funo cifradora C chaveada dever ser usada. Ela dever consistir de um cifrador de blocos que ter o papel de cifrar sempre uma mensagem de tamanho 128 bits: a chave de autenticao. O tamanho de sua chave tambm ser 128 bits. Em sntese, o procedimento auth-P pode ser descrito da seguinte maneira, conforme ilustra a Figura 1: 1. inicializada uma mesma chave, chamada chave mestre de autenticao (Kmestre), em cada um dos elementos de rede que compartilharem esta chave. 2. Quando o gerente for enviar um request, uma chave de autenticao da transaao (Ktransao) ser gerada aleatoriamente e usada no clculo do digest. 3. Ktransao ser criptografada pela funo C, chaveada por Kmestre, gerando sua cifrao Kcipher; 4. Kcipher inserida na mensagem a ser enviada, no subcampo informao de chave do campo communityString redefinido. 5. Na recepo, a chave Ktransao recuperada pela transformao inversa de C utilizando Kmestre em Kcipher 6. A chave Ktransao obtida usada no teste da autenticao. Cabe notar que no far diferena se o protocolo de transporte abaixo do SNMP for no-confivel, pois cada solicitao espera uma resposta especificada pelo valor de requestId da mensagem. Logo, se uma

mensagem ou sua resposta se perderem, cabe ao gerente estabelecer estratgias de retransmisso para aquele determinado request, cuidando para que a nova operao empregue uma nova chave de autenticao aleatria. No caso de mensagens duplicadas, a que vale a primeira a chegar corretamente autenticada. Como definido anteriormente, mensagens recebidas sem correspondncia devem ser descartadas. 2.1 Protocolo Auth-N Este protocolo cria uma chave de autenticao pela aplicao de uma funo de hash Hn vrias vezes sobre uma chave inicial, chamada chave geradora (Kgeradora). A cada mensagem, o nmero (n) destas aplicaes decrementado pelo gerente e a mensagem carregar o n para o agente poder chegar na mesma chave. Na recepo, a mesma funo de hash Hn aplicada n vezes sobre a chave inicial para se chegar mesma chave usada para autenticar a mensagem. O caracter N no nome Auth-N indica a dependncia da chave com relao ao nmero de vezes n em que a funo de hash deve ser aplicada. Este protocolo obedece s seguintes regras (Figura 2): 1. So inicializadas duas chaves idnticas no gerente e agente, K--matriz e Kgeradora. 2. Chama-se o intervalo 0 n w de janela. O valor de n inicialmente w. A cada nova transao, n decresce at chegar a 1. A constante alterao do valor de n de responsabilidade do gerente e deve ser feita a cada mansagem enviada. 3. A chave de autenticao da transao corrente, Ktransao = Kauth n corresponder Kgeradora transformada n vezes por uma funo de hash h (K), sendo n um inteiro maior que 0 e menor ou igual a w. Logo Kauth n= hn(Kgeradora). 4. Quando n chegar a 1, deve ser gerada uma nova chave Kgeradora, usando uma funo H one-way e a chave Kmatriz previamente inicializada. Logo, Kgeradora nova = H(Kgeradora velha, Kmatriz). Note-se que para cada Kgeradora, a janela ser completamente atravessada de w a 1. 5. O gerente s deve efetuar a transformao da chave aps receber a resposta da mensagem com n = 1. O agente muda sua chave geradora quando receber a primeira mensagem da nova janela. Uma mensagem considerada da nova janela quando seu valor for maior que w/2. 6. Assim que transformar sua chave geradora, o agente deve comear a us-la imediantamente na prpria mensagem que disparou a mudana. 7. A mensagem a ser transmitida, ento, dever carregar n para que o agente (que supostamente possui tambm Kmatriz e Kgeradora sincronizadas) transforme Kgeradora tantas vezes quanto necessrio para chegar mesma chave de autenticao usada no envio. 8. Com a chave da transao correta, o agente procede o teste de auteticao da mensagem recebida.

Supondo um protocolo de transporte no confivel, deve-se prever as excees possveis na transmisso destas mensagens. Duas situaes so mais importantes: a perda de mensagem e a troca de ordem na travessia pela rede. Se uma mensagem de request no obtiver resposta, o timeout de espera do gerente vai expirar. Depender da implementao o que ser feito se, durante o tempo de timeout, forem recebidas mensagens com mesmo RequestId, mas com autenticao falha. De qualquer forma, a sincronizao das chaves geradoras no perturbada. Deve-se observar que a retransmisso do request dever usar uma nova chave. Se a mensagem com n=1 no obtiver resposta, uma exceo regra imposta: n dever permanecer em 1 at que se receba a resposta para este request e a troca da chave do gerente possa ser efetuada. Para o manter o sincronismo de chaves, necessrio que o gerente nunca envie chaves da nova janela (depois da transformao H) enquanto no receber a resposta da mensagem autenticada com Kauth 1 da janela anterior. Quando a mensagem com Kauth 1 no receber resposta, a prxima mensagem deve ser autenticada com a mesma Kauth 1 at que uma resposta seja recebida. Esta a nica situao onde o gerente reutiliza a chave de autenticao. Em todos os outros casos, a chave deve ser constantemente mudada. Quanto ao agente, este responder s mensagens reenviadas autenticadas com Kauth 1 tantas vezes quantas forem necessrias e far sua transformao somente quando receber a primeira mensagem da nova janela, indicando que o gerente realizou sua troca da chave geradora. A mensagem ser considerada de uma nova janela quando apresentar n > w/2. No percurso pela rede, mensagens enviadas podem sofrer troca de ordem ao chegar ao seu destino. Esta possibilidade s prejudicaria a operao do protocolo auth-N se a resposta da mensagem com n=1 trocar de ordem com uma anterior, caso em que uma mensagem corretamente autenticada poderia ser rejeitada pelo gerente. Se a resposta da mensagem com n=2 chegar depois da resposta de n=1, para o gerente, ela estar na nova janela e este tentar autentic-la com a nova chave geradora, implicando em falha. A soluo para este problema estaria unicamente no gerente. Uma cpia da chave geradora anterior sempre estaria disponvel e, no caso da falha na autenticao de valores de n prximos de 1, essa cpia seria usada. Com esta abordagem, o agente no onerado com mais procedimentos de controle.

2.3 Caractersticas dos Protocolos Propostos Os protocolos propostos e descritos aqui identificam a origem de uma mensagem como sendo um endereo de rede de uma entidade SNMP. Um endereo de rede, tal como entendido aqui, s poder ser na realidade um nico endereo efetivo de rede atribudo e alcanvel. As chaves empregadas nos mecanismos autenticadores apresentados s fazem sentido quando usadas entre dois elementos distintos, um gerente e um agente. Em SNMPv1/v2c, estes so identificados por seus endereos de rede. Isto associa um endereo de rede a uma entidade SNMPv1/v2c agente ou gerente. Desta forma, uma entidade SNMP (agente ou gerente) dever possuir uma tabela que armazenar chaves de autenticao para cada outra entidade SNMP com quem puder se comunicar. Esta tabela, de forma semelhante tabela de usurios de uma entidade SNMPv3, conter informaes sobre as possibilidades de comunicao daquela entidade com outras entidades SNMPv1/v2c. Uma vantagem direta das abordagens usadas nos protocolos auth-P e auth-N o fato de que no h necessidade de se esperar a resposta da mensagem anterior para poder disparar a prxima. Em operaes SNMP como get-Next-Request, que normalmente so disparadas seguidamente, este aspecto de seqenciao importante. Outro detalhe que, nem no protocolo auth-P nem no protocolo auth-N, preciso que o agente armazene chaves anteriores chave corrente. Conforme se sabe, um requisito interessante que o agente necessite do mnimo de processamento e memria, de modo que o protocolo possa ser largamente adotado em todo tipo de equipamento. O mecanismo de autenticao auth-N exige que a comunicao entre agente e gerente seja do tipo de pedido/resposta, ou seja, uma mensagem do gerente dever sempre esperar uma resposta. Dentro da arquitetura SNMP, a maior parte das operaes so deste tipo. A exceo so as traps que so mensagens espntaneas do agente. No caso de necessidade da autenticao de traps, esta s seria possvel se for utilizado o protocolo auth-P, j que ele no depende de respostas para sincronizar as alteraes dos segredos de autenticao. Para este esquema funcionar, basta que agente e gerente possuam a mesma chave mestre, como requer o protocolo auth-P. Por outro lado, o protocolo auth-P baseia-se numa nica chave: a chave mestre. Se esta for descoberta pode-se gerar mensagens autenticadas quaisquer. Outra desvantagem deste protocolo o fato da mensagem SNMP carregar a chave de autenticao usada (chave da transao). Mesmo criptografada, esta chave estar disponvel para criptoanlise. E se uma criptoanlise tiver sucesso, a chave usada na cifrao (chave mestre) ainda poder ser descoberta. A passagem de chaves de autenticao cifradas pela rede oferece ao atacante vrias amostras de cifrao com a chave mestre. Auth-N, por sua vez, no apresenta essa caracterstica. O que passa pela rede somente um nmero com significado apenas para quem possui as

duas chaves usadas na autenticaao: a chave matriz e a chave geradora. O que estar disponvel para o atacante na rede ser apenas o digest gerado pela chave da transao, chave esta que muda a cada mensagem. Tanto a chave matriz como a geradora no atravessam a rede e, portanto, suas caractersticas no esto disponveis em qualquer informao carregada pela mensagem SNMP. Alm disso, em Auth-N, a chave geradora muda a cada n = 1, evitando que a descoberta de uma chave geradora signifique perda da segurana. Isto possvel por que a nova chave geradora alterada em funo da chave matriz por uma funo one-way, portanto sem retorno. Para um atacante, s seria possvel acompanhar as alteraes das chaves do protocolo se conseguisse ambas as chaves e observasse os valores de n para saber quando obter a nova chave geradora. Contudo, para auth-N funcionar sincronizadamente necessrio que a mensagem com n=1 receba sua resposta e, enquanto isso no acontecer, o gerente s deve usar n=1 nas mensagens posteriores. A mensagem de resposta com n=1 a confirmao do agente para a mudana da atual chave geradora. interessante notar que esta uma preocupao somente do gerente j que o agente s mudar sua chave geradora quando receber valores de n da nova janela. Assim, colocando-se esta responsabilidade sobre o gerente, mantm-se a caraterstica simples do agente SNMP. Desse modo, se o agente no responder mensagem com n =1 apesar das retransmisses, considera-se que houve um problema com a rede, ou com o dispositivo gerenciado, ou ainda um ataque de negao de servio. Por este motivo, necessrio limitar estas retransmisses no gerente. Um nmero mximo de 50 retransmisses parece razovel para operaes de gerncia de rede. Aps atingido este limiar, interrompida a comunicao com o elemento de rede em questo e considera-se uma nova inicializao ou interveno manual, mas isto uma caracterstica particular de implementao. 2.3 Implementao dos Protocolos Propostos As propostas apresentadas acima foram implementadas, para averiguao das condies dos protocolos e obteno de dados para uma anlise da utilidade e operacionalidade destes mtodos de autenticao dentro do protocolo SNMP. O protocolo auth-N exige uma funo de hash h para poder gerar a chave de autenticao especfica da mensagem em operao. A escolha do MD5 neste trabalho levou em conta o nvel de segurana aceitvel do algoritmo contra ataques de fora bruta e sua facilidade de implementao em mquinas de 32 bits (PC Pentium), alm da disponibilidade de cdigo j pronto na Internet. Tanto auth-P como auth-N precisam de uma funo criptogrfica que gere o digest da mensagem, em funo da mensagem e de uma chave. Como SNMP opta sempre pela simplicidade e os agentes a serem implementados devem ser facilmente desenvolvidos, constitui-se uma boa escolha utilizar um mtodo que

utiliza o mesmo algoritmo usado na funo h. Assim, MD5, com o mtodo de chaveamento HMAC, foi a escolha para a funo de hash a ser usada em H. Para o protocolo auth-P, um cifrador de blocos chaveado necessrio para fazer a cifrao da chave de autenticao a ser usada na mensagem. O algoritmo Blowfish [10] escolhido um cifrador de blocos de 64 bits desenvolvido por Bruce Schneier em 1993, no patenteado e livre para utilizao. No que diz respeito ao ambiente de desenvolvimento, foi utilizado um sistema Linux Red Hat 5.1 para microcomputar PC. Os testes foram feitos numa rede local composta de 3 mquinas semelhantes. A linguagem C++ foi escolhida para o desenvolvimento e a interface de protocolo de rede foi a biblioteca sockets que acompanha o sistema Linux usado. Para a implementao, partiu-se de um pacote de software CMU verso 3.5, contendo cdigo-fonte em linguagem C de um agente SNMPv1/v2c acompanhado de algumas pequenas aplicaes SNMP. Este cdigo-fonte foi alterado para a linguagem C++, resultando em um agente SNMPv1/v2c e algumas pequenas aplicaes SNMP, todos integrando os protocolos auth-P e auth-N aqui propostos. O procedimento de teste das implementaes preocupou-se em checar os itens crticos da execuo de ambos os protocolos, apontados no item anterior. Verificou-se que em ambiente de laboratrio os protocolos funcionam conforme previsto nas especificaes iniciais. 3. CONCLUSO Tanto o modelo de segurana baseado em usurio de SNMPv3, como as propostas deste trabalho, dependem da prvia inicializao de chaves nos elementos da rede sendo gerenciados. O modo de realizar tal operao deixado a cargo do fabricante e dos administradores de redes, podendo ser usados certificados, canais seguros, algoritmos assimtricos, ou at mesmo procedimentos manuais, da maneira mais conveniente na inicializao dos segredos. Este trabalho procurou mostrar que ainda possvel implementar autenticao segura nas verses v1 e v2c do protocolo SNMP. Mais ainda, foram propostos e implementados dois protocolos de autenticao, aproveitando elementos que existem e so empregados atualmente nos protocolos SNMPv1 e SNMPv2c, no interferindo de maneira nenhuma nos outros aspectos operacionais do SNMP, tais como o processamento da mensagem ou o controle de acesso. O formato da mensagem SNMP no foi alterado nas propostas. As implementaes demostraram a robustez dos servios de autenticao dos protocolos auth-P e authN. O preo pago pelo melhor servio traduziu-se basicamente em pequeno atraso no processamento de uma mensagem, j que o tamanho das implementaes no aumentou de forma a inviabilizar a sua utilizao. O agente SNMPv1/v2c bsico foi pouco onerado, atendendo assim a uma das premissas do trabalho. 4. BIBLIOGRAFIA

[1] IETF, RFC 1157 - Simple Network Management Protocol (SNMP), (Status: standard), 1990. [2] IETF, RFC 1351 - SNMP Administrative Model, (Status: proposed standard), 1992. [3] IETF, RFC 2026 - The Internet Standards Process - Revision 3, 1996. [4] IETF, draft - The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3), 1999. [5] IETF, RFC 1909 - An Administrative Infrastructure for SNMPv2, (Status: experimental), 1996. [6] IETF, RFC 1321 - The MD5 Message-Digest Algorithm, (Status: informational), 1992. [7] NIST, FIPS Publication 180-1 Secure Hash Algorithm, 1995. [8] IETF, RFC 2104 HMAC: Keyed-Hashing for Message Authentication, (Status: informational), 1997. [9] IETF, RFC 1905 - Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), (Status: draft standard), 1996. [10] SCHNEIER, Bruce. The Blowfish Encryption Algorithm, 1998. http://www.counterpane.com/ blowfish.html.

Gerador Aleatrio

Gerente SNMP

Kmestre

Ktransao C Kcipher

Gerao do digest

Agente SNMP comunidade

Kcipher

digest (Ktransao)

Kmestre C Ktransao

Teste da Autenicao

Figura 1: Protocolo Auth-P

Gerente SNMP

Kgeradora hn Ktransao
Gerao do digest

Agente SNMP comunidade

n

digest (Ktransao)

Kgeradora hn Ktransao

Teste da Autenicao

Figura 2: Protocolo Auth-N