Internet Key Exchange - Internet Key Exchange

Na computação, o Internet Key Exchange ( IKE , às vezes IKEv1 ou IKEv2 , dependendo da versão) é o protocolo usado para configurar uma associação de segurança (SA) no conjunto de protocolos IPsec . O IKE baseia-se no protocolo Oakley e ISAKMP . O IKE usa certificados X.509 para autenticação - pré-compartilhados ou distribuídos usando DNS (de preferência com DNSSEC ) - e uma troca de chave Diffie-Hellman para configurar um segredo de sessão compartilhada a partir do qual as chaves criptográficas são derivadas. Além disso, uma política de segurança para cada par que se conectará deve ser mantida manualmente.

História

A Internet Engineering Task Force (IETF) definiu originalmente o IKE em novembro de 1998 em uma série de publicações ( Request for Comments ) conhecidas como RFC 2407, RFC 2408 e RFC 2409:

  • A RFC 2407 definiu o Domínio de Interpretação de Segurança de IP da Internet para ISAKMP.
  • A RFC 2408 definiu a Associação de Segurança da Internet e o Protocolo de Gerenciamento de Chaves (ISAKMP).
  • A RFC 2409 definiu o Internet Key Exchange (IKE).

O RFC 4306 atualizou o IKE para a versão dois (IKEv2) em dezembro de 2005. O RFC 4718 esclareceu alguns detalhes em aberto em outubro de 2006. O RFC 5996 combinou esses dois documentos mais esclarecimentos adicionais no IKEv2 atualizado, publicado em setembro de 2010. Uma atualização posterior atualizou o documento de Padrão proposto para o padrão da Internet , publicado como RFC 7296 em outubro de 2014.

A organização controladora da IETF, The Internet Society (ISOC), manteve os direitos autorais desses padrões disponíveis gratuitamente para a comunidade da Internet.

Arquitetura

A maioria das implementações IPsec consiste em um daemon IKE que é executado no espaço do usuário e uma pilha IPsec no kernel que processa os pacotes IP reais .

Os daemons do espaço do usuário têm fácil acesso ao armazenamento em massa contendo informações de configuração, como endereços de endpoint IPsec, chaves e certificados, conforme necessário. Os módulos do kernel, por outro lado, podem processar pacotes com eficiência e com sobrecarga mínima - o que é importante por motivos de desempenho.

O protocolo IKE usa pacotes UDP , geralmente na porta 500, e geralmente requer 4-6 pacotes com 2-3 viagens de ida e volta para criar uma SA (associação de segurança) em ambos os lados. O material da chave negociada é então fornecido à pilha IPsec. Por exemplo, pode ser uma chave AES , informações que identificam os pontos de extremidade IP e portas que devem ser protegidas, bem como o tipo de túnel IPsec que foi criado. A pilha IPsec, por sua vez, intercepta os pacotes IP relevantes se e onde apropriado e executa a criptografia / descriptografia conforme necessário. As implementações variam em como a interceptação dos pacotes é feita - por exemplo, alguns usam dispositivos virtuais, outros tiram uma fatia do firewall, etc.

IKEv1 consiste em duas fases: fase 1 e fase 2.

Fases IKEv1

O objetivo da primeira fase do IKE é estabelecer um canal de comunicação autenticado seguro usando o algoritmo de troca de chaves Diffie-Hellman para gerar uma chave secreta compartilhada para criptografar outras comunicações IKE. Essa negociação resulta em uma única ISAKMP Security Association (SA) bidirecional . A autenticação pode ser executada usando uma chave pré-compartilhada (segredo compartilhado), assinaturas ou criptografia de chave pública. A fase 1 opera no modo principal ou no modo agressivo. O Modo Principal protege a identidade dos pares e o hash da chave compartilhada criptografando-os; O modo agressivo não.

Durante a fase dois do IKE, os pares IKE usam o canal seguro estabelecido na Fase 1 para negociar associações de segurança em nome de outros serviços como o IPsec . A negociação resulta em um mínimo de duas associações de segurança unidirecionais (uma de entrada e uma de saída). A Fase 2 opera apenas no Modo Rápido.

Problemas com IKE

Originalmente, o IKE tinha várias opções de configuração, mas carecia de um recurso geral para negociação automática de um caso padrão conhecido que é implementado universalmente. Consequentemente, ambos os lados de um IKE tinham que concordar exatamente sobre o tipo de associação de segurança que desejavam criar - opção por opção - ou uma conexão não poderia ser estabelecida. Outras complicações surgiram do fato de que em muitas implementações a saída de depuração era difícil de interpretar, se é que havia algum recurso para produzir saída de diagnóstico.

As especificações IKE estavam abertas a um grau significativo de interpretação, beirando as falhas de projeto ( Dead-Peer-Detection sendo um caso em questão), dando origem a diferentes implementações de IKE, não sendo capazes de criar uma associação de segurança acordada para muitos combinações de opções, embora configuradas corretamente, elas podem aparecer em qualquer uma das extremidades.

Melhorias com IKEv2

O protocolo IKEv2 foi descrito no Apêndice A do RFC 4306 em 2005. Os seguintes problemas foram abordados:

  • Menos solicitações de comentários (RFCs): As especificações para IKE foram abordadas em pelo menos três RFCs, mais se levarmos em consideração o NAT traversal e outras extensões de uso comum. O IKEv2 os combina em um RFC, além de fazer melhorias no suporte para traversal de NAT ( Network Address Translation (NAT)) e traversal de firewall em geral.
  • Suporte de mobilidade padrão: há uma extensão padrão para IKEv2 chamada [rfc: 4555 Mobility and Multihoming Protocol] (MOBIKE) (consulte também, IPsec ) usada para oferecer suporte a mobilidade e multihoming para ele e Encapsulating Security Payload (ESP). Com o uso desta extensão, IKEv2 e IPsec podem ser usados ​​por usuários móveis e com hospedagem múltipla.
  • NAT traversal : O encapsulamento de IKE e ESP no User Datagram Protocol (porta UDP 4500) permite que esses protocolos passem por um dispositivo ou firewall executando NAT .
  • Suporte ao protocolo de transmissão de controle de fluxo (SCTP): IKEv2 permite o protocolo SCTP conforme usado no protocolo de telefonia da Internet, voz sobre IP (VoIP).
  • Troca de mensagens simples: o IKEv2 tem um mecanismo de troca inicial de quatro mensagens, em que o IKE fornece oito mecanismos de troca inicial distintos, cada um com pequenas vantagens e desvantagens.
  • Menos mecanismos criptográficos: o IKEv2 usa mecanismos criptográficos para proteger seus pacotes que são muito semelhantes aos usados ​​pelo ESP IPsec para proteger os pacotes IPsec. Isso levou a implementações e certificações mais simples para Common Criteria e FIPS 140-2 ( Federal Information Processing Standard (FIPS), que exigem que cada implementação criptográfica seja validada separadamente.
  • Confiabilidade e gerenciamento de estado: IKEv2 usa números de sequência e confirmações para fornecer confiabilidade e exige alguma logística de processamento de erros e gerenciamento de estado compartilhado. O IKE poderia terminar em um estado morto devido à falta de tais medidas de confiabilidade, onde ambas as partes esperavam que a outra iniciasse uma ação - que nunca ocorreu. Soluções alternativas (como Dead-Peer-Detection ) foram desenvolvidas, mas não padronizadas. Isso significava que diferentes implementações de soluções alternativas nem sempre eram compatíveis.
  • Resiliência a ataques de negação de serviço (DoS): o IKEv2 não executa muito processamento até determinar se o solicitante realmente existe. Isso resolveu alguns dos problemas de DoS sofridos pelo IKE, que realizaria muito processamento criptográfico caro a partir de locais falsificados .
Supondo que o HostA tenha um Índice de Parâmetro de Segurança (SPI) de Ae o HostB tenha um SPI de B, o cenário seria assim:
HostA -------------------------------------------------- HostB
     |HDR(A,0),sai1,kei,Ni-------------------------->   |
     |   <----------------------------HDR(A,0),N(cookie)|
     |HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |
     |   <--------------------------HDR(A,B),SAr1,ker,Nr|
Se o HostB (o respondente) estiver enfrentando grandes quantidades de conexões IKE semiabertas, ele enviará uma mensagem de resposta não criptografada IKE_SA_INITpara o HostA (o iniciador) com uma mensagem de notificação do tipo COOKIEe esperará que o HostA envie uma IKE_SA_INITsolicitação com esse valor de cookie em uma carga útil de notificação para o HostB . Isso é para garantir que o iniciador seja realmente capaz de lidar com uma resposta IKE do respondente.

Extensões de protocolo

O grupo de trabalho IETF ipsecme padronizou uma série de extensões, com o objetivo de modernizar o protocolo IKEv2 e adaptá-lo melhor a ambientes de produção de alto volume. Essas extensões incluem:

  • Retomada da sessão IKE : a capacidade de retomar uma "sessão" IKE / IPsec com falha após uma falha, sem a necessidade de passar por todo o processo de configuração do IKE ( RFC  5723 ).
  • Redirecionamento IKE : redirecionamento de solicitações IKE de entrada, permitindo o balanceamento de carga simples entre vários pontos de extremidade IKE (RFC  5685 ).
  • Visibilidade do tráfego IPsec : marcação especial de pacotes ESP que são autenticados, mas não criptografados, com o objetivo de tornar mais fácil para middleboxes (como sistemas de detecção de intrusão ) analisar o fluxo (RFC  5840 ).
  • Autenticação EAP mútua : suporte para autenticação somente EAP (ou seja, sem certificado) de ambos os pontos IKE; o objetivo é permitir o uso de métodos modernos de autenticação com base em senha (RFC  5998 ).
  • Detecção rápida de travamento : minimizando o tempo até que um par IKE detecte que seu par oposto travou (RFC  6290 ).
  • Extensões de alta disponibilidade : melhorando a sincronização de protocolo de nível IKE / IPsec entre um cluster de terminais IPsec e um par, para reduzir a probabilidade de conexões perdidas após um evento de failover (RFC  6311 ).

Implementações

O IKE é suportado como parte da implementação do IPsec no Windows 2000 , Windows XP , Windows Server 2003 , Windows Vista e Windows Server 2008 . A implementação ISAKMP / IKE foi desenvolvida em conjunto pela Cisco e pela Microsoft.

O Microsoft Windows 7 e o Windows Server 2008 R2 oferecem suporte parcial a IKEv2 (RFC  7296 ) e também a MOBIKE (RFC  4555 ) por meio do recurso VPN Reconnect (também conhecido como Agile VPN ).

Existem várias implementações de código aberto de IPsec com recursos de IKE associados. Em implementações Linux , Libreswan , Openswan e strongSwan fornecem um daemon IKE que pode configurar (isto é, estabelecer SAs) para as pilhas IPsec baseadas em kernel KLIPS ou XFRM / NETKEY. XFRM / NETKEY é a implementação de IPsec nativa do Linux disponível a partir da versão 2.6.

As Distribuições de Software de Berkeley também possuem uma implementação IPsec e daemon IKE, e o mais importante, uma estrutura criptográfica ( OpenBSD Cryptographic Framework , OCF), que torna o suporte a aceleradores criptográficos muito mais fácil. OCF foi recentemente portado para Linux.

Um número significativo de fornecedores de equipamentos de rede criaram seus próprios daemons IKE (e implementações IPsec) ou licenciam uma pilha de outro.

Existem várias implementações de IKEv2 e algumas das empresas que lidam com certificação IPsec e testes de interoperabilidade estão começando a realizar workshops para testes, bem como requisitos de certificação atualizados para lidar com os testes IKEv2.

As seguintes implementações de código aberto de IKEv2 estão disponíveis atualmente:

Vulnerabilidades

Apresentações NSA vazadas lançadas pela Der Spiegel indicam que o IKE está sendo explorado de uma maneira desconhecida para descriptografar o tráfego IPsec, assim como o ISAKMP . Os pesquisadores que descobriram o ataque Logjam afirmam que quebrar um grupo Diffie – Hellman de 1024 bits quebraria 66% dos servidores VPN, 18% dos milhões de domínios HTTPS e 26% dos servidores SSH, o que os pesquisadores afirmam ser consistente com o vazamentos. Esta afirmação foi refutada por Eyal Ronen e Adi Shamir em seu artigo "Revisão Crítica do Sigilo Futuro Imperfeito" e por Paul Wouters de Libreswan em um artigo "66% das VPNs não estão de fato quebradas"

As configurações de VPN IPsec que permitem a negociação de várias configurações estão sujeitas a ataques de downgrade baseados em MITM entre as configurações oferecidas, com IKEv1 e IKEv2. Isso pode ser evitado pela segregação cuidadosa dos sistemas cliente em vários pontos de acesso de serviço com configurações mais rígidas.

Ambas as versões do padrão IKE são suscetíveis a um ataque de dicionário offline quando uma senha de baixa entropia é usada. Para o IKEv1, isso é verdadeiro para o modo principal e o modo agressivo.

Veja também

Referências

links externos