Internet Key Exchange (IKE)
Introdução ao IKE
O Internet Key Exchange (IKE) é um protocolo de gerenciamento seguro de chave que é usado para configurar um canal de comunicações seguro e autenticado entre dois dispositivos.
A IKE faz o seguinte:
Negocia e gerencia parâmetros IKE e IPsec
Autentica a troca segura de chaves
Fornece autenticação mútua por pares por meio de segredos compartilhados (não senhas) e chaves públicas
Oferece proteção contra identidade (no modo principal)
Emprega métodos Diffie-Hellman e é opcional em IPsec (as chaves compartilhadas podem ser inseridas manualmente nos endpoints).
Versões IKE
Duas versões dos padrões IKE estão disponíveis:
IKE versão 1 — protocolo IKE definido em RFC 2409.
IKE versão 2 — IKE versão 2 (IKEv2) é a versão mais recente do protocolo IKE definida no RFC 7296.
Internet Key Exchange versão 2 (IKEv2) é a versão mais recente do protocolo Internet Key Exchange (IKE) definida na RFC 7296. Um peer VPN está configurado como IKEv1 ou IKEv2. Quando um peer é configurado como IKEv2, ele não pode voltar ao IKEv1 se seu peer remoto iniciar a negociação IKEv1.
As vantagens de usar o IKEv2 no IKEv1 são as seguintes:
Substitui oito trocas iniciais por uma única troca de quatro mensagens.
Reduz a latência para a configuração de SA IPsec e aumenta a velocidade do estabelecimento da conexão.
Aumenta a robustez contra ataques DOS.
Melhora a confiabilidade com o uso de números de sequência, reconhecimentos e correção de erros.
Melhora a confiabilidade, pois todas as mensagens são solicitações ou respostas. O iniciador é responsável por retransmitir se não receber uma resposta.
Interação entre IKE e IPSec
O IPsec pode estabelecer uma VPN da seguinte maneira:
Protocolo internet key exchange (IKE) — O IPsec oferece suporte a geração e negociação automatizadas de chaves e associações de segurança usando o protocolo IKE. Usar o IKE para negociar VPNs entre dois endpoints oferece mais segurança do que a troca manual de chave.
Troca manual de chaves — o IPsec oferece suporte ao uso e troca manual de chaves (exemplo: telefone ou e-mail) de ambos os lados para estabelecer VPN.
Troca de mensagens IKEv1
A negociação do IKE inclui duas fases:
Fase 1 — Negocie a troca de propostas sobre como autenticar e proteger o canal.
Fase 2 — Negocie associações de segurança (SAs) para proteger os dados que atravessam o túnel IPsec.
Fase 1 da negociação de túneis IKE
A fase 1 de uma negociação de túnel da AutoKey Internet Key Exchange (IKE) consiste na troca de propostas de como autenticar e proteger o canal. Os participantes trocam propostas por serviços de segurança aceitáveis, como:
Algoritmos de criptografia — Data Encryption Standard (DES), Triple Data Encryption Standard (3DES) e Advanced Encryption Standard (AES). (Veja Visão geral do IPsec.)
Algoritmos de autenticação — Message Digest 5 (MD5) e Secure Hash Algorithm (SHA). (Veja Visão geral do IPsec.)
Grupo Diffie-Hellman (DH). (Veja Visão geral do IPsec.)
Certificados de chave ou RSA/DSA pré-compartilhados. (Veja Visão geral do IPsec.)
Uma negociação bem-sucedida da Fase 1 termina quando ambas as extremidades do túnel concordam em aceitar pelo menos um conjunto dos parâmetros de segurança da Fase 1 propostos e depois processá-los. Os dispositivos da Juniper Networks oferecem suporte a até quatro propostas para negociações da Fase 1, permitindo que você defina o quão restritivos uma gama de parâmetros de segurança para negociação chave você aceitará. O Junos OS fornece conjuntos de propostas de Fase 1 predefinidos, compatíveis e básicos. Você também pode definir propostas personalizadas da Fase 1.
As trocas de fase 1 podem ocorrer no modo principal ou no modo agressivo. Você pode escolher o seu modo durante a configuração da política de IKE.
Este tópico inclui as seguintes seções:
Modo principal
No modo principal, o iniciador e o destinatário enviam três trocas bidirecionais (seis mensagens no total) para realizar os seguintes serviços:
Primeira troca (mensagens 1 e 2)— Propõe e aceita os algoritmos de criptografia e autenticação.
Segunda troca (mensagens 3 e 4)— Executa uma troca de DH, e o iniciador e o destinatário fornecem cada um número pseudorandom.
Terceira troca (mensagens 5 e 6)— Envia e verifica as identidades do iniciador e destinatário.
As informações transmitidas na terceira troca de mensagens são protegidas pelo algoritmo de criptografia estabelecido nas duas primeiras trocas. Assim, as identidades dos participantes são criptografadas e, portanto, não são transmitidas "de forma clara".
Modo agressivo
No modo agressivo, o iniciador e o destinatário cumprem os mesmos objetivos do modo principal, mas em apenas duas trocas, com um total de três mensagens:
Primeira mensagem — o iniciador propõe a associação de segurança (SA), inicia uma troca de DH e envia um número de pseudorandom e sua identidade IKE.
Ao configurar o modo agressivo com várias propostas para negociações da Fase 1, use o mesmo grupo DH em todas as propostas porque o grupo DH não pode ser negociado. Até quatro propostas podem ser configuradas.
Segunda mensagem — o destinatário aceita o SA; autentica o iniciador; e envia um número de pseudorandom, sua identidade IKE e, se estiver usando certificados, o certificado do destinatário.
Terceira mensagem — o iniciador autentica o destinatário, confirma a troca e, se estiver usando certificados, envia o certificado do iniciador.
Como as identidades dos participantes são trocadas de forma clara (nas duas primeiras mensagens), o modo agressivo não oferece proteção de identidade.
Os modos principal e agressivo se aplicam apenas ao protocolo IKEv1. O protocolo IKEv2 não negocia usando modos principais e agressivos.
Consulte também
Fase 2 da negociação de túneis IKE
Depois que os participantes estabelecerem um canal seguro e autenticado, eles passam pela Fase 2, na qual negociam associações de segurança (SAs) para proteger os dados a serem transmitidos pelo túnel IPsec.
Semelhante ao processo da Fase 1, os participantes trocam propostas para determinar quais parâmetros de segurança empregar na SA. Uma proposta de Fase 2 também inclui um protocolo de segurança — encapsulando o Security Payload (ESP) ou o Authentication Header (AH) — e algoritmos selecionados de criptografia e autenticação. A proposta também pode especificar um grupo Diffie-Hellman (DH), se o sigilo perfeito para o encaminhamento (PFS) for desejado.
Independentemente do modo usado na Fase 1, a Fase 2 sempre opera em modo rápido e envolve a troca de três mensagens.
Este tópico inclui as seguintes seções:
Proxy IDs
Na Fase 2, os pares trocam IDs proxy. Um ID proxy consiste em um prefixo de endereço IP local e remoto. O ID por proxy para ambos os pares deve ser compatível, o que significa que o endereço IP local especificado para um peer deve ser o mesmo que o endereço IP remoto especificado para o outro peer.
Sigilo perfeito para o futuro
PFS é um método para obter chaves da Fase 2 independentes e não relacionadas às chaves anteriores. Como alternativa, a proposta da Fase 1 cria a chave (a chave SKEYID_d) da qual todas as chaves da Fase 2 são derivadas. A chave SKEYID_d pode gerar chaves de Fase 2 com um mínimo de processamento de CPU. Infelizmente, se uma parte não autorizada tiver acesso à chave SKEYID_d, todas as suas chaves de criptografia estarão comprometidas.
O PFS lida com esse risco de segurança forçando uma nova troca de chave DH a ocorrer para cada túnel de Fase 2. O uso de PFS é, portanto, mais seguro, embora o procedimento de reexame na Fase 2 possa demorar um pouco mais com o PFS habilitado.
Proteção de repetição
Um ataque de repetição ocorre quando uma pessoa não autorizada intercepta uma série de pacotes e os usa mais tarde para inundar o sistema, causando uma negação de serviço (DoS) ou para obter a entrada na rede confiável. O Junos OS oferece um recurso de proteção de repetição que permite que os dispositivos verifiquem todos os pacotes IPsec para ver se ele foi recebido anteriormente. Se os pacotes chegarem fora de um intervalo de sequência especificado, o Junos OS os rejeitará. O uso desse recurso não requer negociação, pois os pacotes são sempre enviados com números de sequência. Você simplesmente tem a opção de verificar ou não verificar os números da sequência.
Consulte também
Troca de mensagens IKEv2
A versão 2 do IKE é a sucessora do método IKEv1. Ele oferece um canal de comunicação VPN seguro entre dispositivos VPN peer e define negociação e autenticação para associações de segurança IPsec (SAs) de maneira protegida.
O IKEv2 não inclui a fase 1 e a fase 2 semelhantes ao IKEv1, mas ocorrem quatro trocas de mensagens para negociar um túnel IPsec com o IKEv2. A troca de mensagens no IKEv2 é:
Negocia os atributos de segurança para estabelecer o túnel IPsec. Isso inclui a troca dos protocolos/parâmetros usados e dos grupos Diffie-Hellman.
Cada peer estabelece ou autentica suas identidades enquanto o túnel IPsec é estabelecido.
Pares para criar associações de segurança adicionais entre si.
Os peers realizam a detecção de linhas de vida, removendo relacionamentos SA e relatando mensagens de erro.
- Carga útil da configuração do IKEv2
- Rekeying e Reauthentication IKEv2
- Fragmentação do IKEv2
- Seletores de tráfego para IKEv2
Carga útil da configuração do IKEv2
A carga de configuração é uma opção IKEv2 oferecida para propagar informações de provisionamento de um respondente para um iniciador. A carga de configuração IKEv2 é suportada apenas com VPNs baseadas em rota.
RFC 5996, Internet Key Exchange Protocol Versão 2 (IKEv2), define 15 atributos de configuração diferentes que podem ser devolvidos ao iniciador pelo respondente.
Rekeying e Reauthentication IKEv2
Com o IKEv2, rekeying e reauthenticação são processos separados.
A reproteção estabelece novas chaves para a associação de segurança IKE (SA) e reinicia os contadores de ID de mensagens, mas não reauthentica os pares.
A reauthenticação verifica se os pares de VPN mantêm seu acesso às credenciais de autenticação. A reauthenticação estabelece novas chaves para a SA IKE e as SAs infantis; re-chaves de qualquer SA IKE pendente ou SA infantil não são mais necessários. Após a criação do novo IKE e dos SAs infantis, o antigo IKE e as SAs infantis são excluídos.
A reauthentação do IKEv2 é desativada por padrão. Você permite a reauthenticação configurando um valor de frequência de reauthentação entre 1 e 100. A frequência de reauthenticação é o número de rekeys IKE que ocorre antes que a reauthenticação ocorra. Por exemplo, se a frequência de reauthenticação configurada for 1, a reauthenticação ocorre toda vez que há uma rekey IKE. Se a frequência de reauthenticação configurada for 2, a reauthenticação ocorre em todas as outras chaves de IKE. Se a frequência de reauthenticação configurada for 3, a reauthenticação ocorre em cada terceiro IKE rekey, e assim por diante.
Fragmentação do IKEv2
Quando a autenticação baseada em certificados é usada, os pacotes IKEv2 podem exceder o caminho MTU se vários certificados forem transmitidos. Se o tamanho da mensagem IKE exceder o CAMINHO MTU, as mensagens serão fragmentadas no nível de IP. Alguns equipamentos de rede, como dispositivos NAT, não permitem a passagem de fragmentos de IP, o que impede o estabelecimento de túneis IPsec.
A fragmentação de mensagens IKEv2, conforme descrito no RFC 7383, fragmentação de mensagens do Protocolo de Troca de Chaves da Internet Versão 2 (IKEv2), permite que o IKEv2 opere em ambientes onde fragmentos de IP podem ser bloqueados e os pares não seriam capazes de estabelecer uma associação de segurança IPsec (SA). A fragmentação do IKEv2 divide uma grande mensagem IKEv2 em um conjunto de menores para que não haja fragmentação no nível de IP. A fragmentação ocorre antes que a mensagem original seja criptografada e autenticada, de modo que cada fragmento seja criptografado e autenticado separadamente. No receptor, os fragmentos são coletados, verificados, descriptografados e mesclados na mensagem original.
Seletores de tráfego para IKEv2
Você pode configurar seletores de tráfego no IKEv2 usado durante a negociação do IKE. Um seletor de tráfego é um acordo entre os pares do IKE para permitir o tráfego através de um túnel VPN se o tráfego combinar com um par especificado de endereços locais e remotos. Somente o tráfego que estiver em conformidade com um seletor de tráfego é permitido por meio da associação de segurança associada (SA). Os seletores de tráfego são usados durante a criação do túnel para configurar o túnel e determinar qual tráfego é permitido através do túnel.
Proxy ID
Um proxy-ID é usado durante a fase 2 das negociações da Internet Key Exchange (IKE) Virtual Private Network (VPN). Ambas as extremidades de um túnel VPN têm um ID por proxy configurado manualmente (VPN baseada em rota) ou apenas usam uma combinação de IP de origem, IP de destino e serviço em uma política de túnel. Quando a fase 2 do IKE é negociada, cada extremidade compara o ID de proxy local e remoto configurado com o que é realmente recebido.
Seletores de tráfego
O ID proxy é suportado tanto para VPNs baseadas em rota quanto para VPNs baseadas em políticas. No entanto, o ID multi-proxy é suportado apenas para VPNs baseadas em rota. O ID multi-proxy também é conhecido como seletor de tráfego. Um seletor de tráfego é um acordo entre os pares da IKE para permitir o tráfego através de um túnel, se o tráfego combinar com um par especificado de endereços locais e remotos. Você define um seletor de tráfego em uma VPN baseada em rota específica, o que pode resultar em vários SAs IPsec da Fase 2. Somente o tráfego em conformidade com um seletor de tráfego é permitido por meio de um SA. O seletor de tráfego é comumente necessário quando dispositivos de gateway remotos não são dispositivos da Juniper Networks.
Transversal de endereço de rede (NAT-T)
Network Address Translation-Traversal (NAT-T) é um método para contornar problemas de tradução de endereço IP encontrados quando dados protegidos por IPsec passam por um dispositivo NAT para tradução de endereços.
Qualquer alteração no endereçamento ip, que é a função do NAT, faz com que o IKE descarte pacotes. Depois de detectar um ou mais dispositivos NAT ao longo do caminho de dados durante as trocas de Fase 1, o NAT-T adiciona uma camada de encapsulamento do Protocolo de Datagram do Usuário (UDP) aos pacotes IPsec para que eles não sejam descartados após a tradução do endereço. O NAT-T encapsula o tráfego IKE e ESP dentro do UDP com a porta 4500 usada como porta de origem e destino. Como os dispositivos NAT envelhecem as tradução de UDP obsoletas, são necessárias mensagens keepalive entre os pares.
A localização de um dispositivo NAT pode ser tal que:
Apenas o iniciador IKEv1 ou IKEv2 está por trás de um dispositivo NAT. Vários iniciadores podem estar por trás de dispositivos NAT separados. Os iniciadores também podem se conectar ao respondente por meio de vários dispositivos NAT.
Apenas o IKEv1 ou iKEv2 estão por trás de um dispositivo NAT.
Tanto o IKEv1 quanto o iniciador IKEv2 e o respondente estão por trás de um dispositivo NAT.
Suíte B e suítes criptográficas PRIME
A Suíte B é um conjunto de algoritmos criptográficos designados pela Agência de Segurança Nacional dos EUA para permitir que produtos comerciais protejam o tráfego classificado em níveis secretos ou ultra secretos. Os protocolos de suíte B são definidos em RFC 6379, Suite B Cryptographic Suites para IPsec. Os pacotes criptográficos do Suite B oferecem integridade e confidencialidade do Encapsulating Security Payload (ESP) e devem ser usados quando a proteção da integridade e a criptografia esp são necessárias. Os requisitos de protocolo para criptografia modular de IP (PRIME), um perfil IPsec definido para redes do setor público no Reino Unido, é baseado no pacote criptográfico suite B, mas usa AES-GCM em vez de AES-CBC para negociações IKEv2.
Os seguintes pacotes criptográficos são suportados:
Suite-B-GCM-128
ESP: Criptografia avançada de padrão de criptografia (AES) com chaves de 128 bits e valor de verificação de integridade (ICV) de 16 octets no Modo Contador galois (GCM).
IKE: Criptografia AES com chaves de 128 bits no modo de encadeamento de blocos (CBC), integridade usando autenticação SHA-256, estabelecimento chave usando Diffie-Hellman (DH) grupo 19, e autenticação usando algoritmo de assinatura digital de curva elíptica (ECDSA) assinaturas de curva elíptica de 256 bits.
Suite-B-GCM-256
ESP: Criptografia AES com chaves de 256 bits e ICV de 16 octets na GCM para ESP.
IKE: Criptografia AES com chaves de 256 bits no modo CBC, integridade usando autenticação SHA-384, estabelecimento chave usando grupo DH 20 e autenticação usando assinaturas de curva elíptica ECDSA 384 bit.
PRIME-128
ESP: Criptografia AES com chaves de 128 bits e ICV de 16 octets na GCM.
IKE: Criptografia AES com chaves de 128 bits na GCM, estabelecimento chave usando o grupo DH 19 e autenticação usando assinaturas de curva elíptica de ECDSA de 256 bits.
PRIME-256
ESP: Criptografia AES com chaves de 256 bits e ICV de 16 octets na GCM para ESP.
IKE: Criptografia AES com chaves de 256 bits na GCM, estabelecimento chave usando o grupo DH 20 e autenticação usando assinaturas de curva elíptica ECDSA de 384 bits.
As suítes criptográficas suite-B oferecem suporte a IKEv1 e IKEv2. As suítes criptográficas PRIME oferecem suporte apenas ao IKEv2.