IPsec - IPsec

Na computação , o Internet Protocol Security ( IPsec ) é um conjunto de protocolos de rede seguro que autentica e criptografa os pacotes de dados para fornecer comunicação criptografada segura entre dois computadores em uma rede de protocolo da Internet . É usado em redes privadas virtuais (VPNs).

O IPsec inclui protocolos para estabelecer autenticação mútua entre agentes no início de uma sessão e negociação de chaves criptográficas a serem usadas durante a sessão. O IPsec pode proteger fluxos de dados entre um par de hosts ( host a host ), entre um par de gateways de segurança ( rede a rede ) ou entre um gateway de segurança e um host ( rede a host ). O IPsec usa serviços de segurança criptográfica para proteger as comunicações em redes de protocolo da Internet (IP). Ele oferece suporte à autenticação de mesmo nível em nível de rede, autenticação de origem de dados, integridade de dados, confidencialidade de dados (criptografia) e proteção contra reprodução.

O pacote IPv4 inicial foi desenvolvido com poucas provisões de segurança. Como parte do aprimoramento do IPv4, o IPsec é um modelo OSI de camada 3 ou esquema de segurança ponta a ponta da camada da Internet . Em contraste, enquanto alguns outros sistemas de segurança da Internet em uso generalizado operam acima da camada 3, como Transport Layer Security (TLS) que opera acima da Camada de Transporte e Secure Shell (SSH) que opera na camada de aplicativo, o IPsec pode proteger automaticamente os aplicativos em a camada IP.

História

Começando no início dos anos 1970, a Advanced Research Projects Agency patrocinou uma série de dispositivos experimentais de criptografia ARPANET , primeiro para criptografia de pacotes ARPANET nativa e, posteriormente, para criptografia de pacotes TCP / IP; alguns deles foram certificados e colocados em campo. De 1986 a 1991, a NSA patrocinou o desenvolvimento de protocolos de segurança para a Internet sob seu programa Secure Data Network Systems (SDNS). Isso reuniu vários fornecedores, incluindo a Motorola, que produziu um dispositivo de criptografia de rede em 1988. O trabalho foi publicado abertamente por volta de 1988 pelo NIST e, desses, o Protocolo de Segurança na Camada 3 (SP3) acabaria se transformando no protocolo de Segurança de Camada de Rede padrão ISO (NLSP).

De 1992 a 1995, vários grupos conduziram pesquisas sobre criptografia de camada IP.

  • 1. Em 1992, o US Naval Research Laboratory (NRL) iniciou o projeto Simple Internet Protocol Plus (SIPP) para pesquisar e implementar criptografia IP.
  • 2. Em 1993, na Columbia University e na AT&T Bell Labs , John Ioannidis e outros pesquisaram o software experimental Software IP Encryption Protocol (swIPe) no SunOS .
  • 3. Em 1993, patrocinado pelo projeto de serviço de Internet Whitehouse, Wei Xu da Trusted Information Systems (TIS) pesquisou ainda mais os protocolos de segurança IP de software e desenvolveu o suporte de hardware para o triplo DES Data Encryption Standard , que foi codificado no kernel BSD 4.1 e suportava as arquiteturas x86 e SUNOS. Em dezembro de 1994, a TIS lançou seu produto Gauntlet Firewall de código aberto patrocinado pela DARPA com criptografia de hardware 3DES integrada em velocidades acima de T1 . Foi a primeira vez usando conexões VPN IPSec entre as costas leste e oeste dos Estados Unidos, conhecido como o primeiro produto VPN IPSec comercial.
  • 4. Sob o esforço de pesquisa financiado pela DARPA da NRL, a NRL desenvolveu as especificações de faixa de padrões IETF (RFC 1825 a RFC 1827) para IPsec, que foi codificado no kernel BSD 4.4 e suportou as arquiteturas de CPU x86 e SPARC. A implementação do IPsec do NRL foi descrita em seu artigo nos procedimentos da conferência USENIX de 1996. A implementação de IPsec de código aberto da NRL foi disponibilizada online pelo MIT e se tornou a base para a maioria das implementações comerciais iniciais.

A Internet Engineering Task Force (IETF) formou o IP Security Working Group em 1992 para padronizar extensões de segurança especificadas abertamente para IP, chamadas IPsec . Em 1995, o grupo de trabalho organizou alguns dos workshops com membros das cinco empresas (TIS, CISCO, FTP, Checkpoint, etc.). Durante os workshops IPSec, os padrões do NRL e o software Cisco e TIS são padronizados como referências públicas, publicados como RFC-1825 até RFC-1827.

Arquitetura de segurança

O IPsec é um padrão aberto como parte do pacote IPv4. O IPsec usa os seguintes protocolos para executar várias funções:

Cabeçalho de Autenticação

Uso do formato de cabeçalho de autenticação IPsec nos modos de túnel e transporte

O Security Authentication Header ( AH ) foi desenvolvido no US Naval Research Laboratory no início de 1990 e é derivado em parte do trabalho de padrões IETF anteriores para autenticação do Simple Network Management Protocol (SNMP) versão 2. O Authentication Header (AH) é um membro do conjunto de protocolos IPsec. O AH garante integridade sem conexão usando uma função hash e uma chave secreta compartilhada no algoritmo AH. O AH também garante a origem dos dados autenticando pacotes IP . Opcionalmente, um número de sequência pode proteger o conteúdo do pacote IPsec contra ataques de repetição , usando a técnica de janela deslizante e descartando pacotes antigos.

  • No IPv4 , o AH evita ataques de inserção de opção. No IPv6 , o AH protege contra ataques de inserção de cabeçalho e ataques de inserção de opção.
  • No IPv4 , o AH protege a carga de IP e todos os campos de cabeçalho de um datagrama IP, exceto os campos mutáveis ​​(ou seja, aqueles que podem ser alterados em trânsito), e também as opções de IP, como a opção de segurança IP (RFC 1108). Os campos de cabeçalho IPv4 mutáveis ​​(e, portanto, não autenticados) são DSCP / ToS , ECN , Sinalizadores, Deslocamento de fragmento , TTL e Soma de verificação de cabeçalho .
  • No IPv6 , o AH protege a maior parte do cabeçalho base do IPv6, o próprio AH, os cabeçalhos de extensão não mutáveis ​​após o AH e a carga de IP. A proteção para o cabeçalho IPv6 exclui os campos mutáveis: DSCP , ECN , Flow Label e Hop Limit.

O AH opera diretamente sobre o IP, usando o protocolo IP número 51 .

O seguinte diagrama de pacote AH mostra como um pacote AH é construído e interpretado:

Formato do cabeçalho de autenticação
Offsets Octeto 16 0 1 2 3
Octeto 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Próximo Cabeçalho Payload Len Reservado
4 32 Índice de parâmetros de segurança (SPI)
8 64 Número sequencial
C 96 Valor de verificação de integridade (ICV)
...
... ...
Próximo cabeçalho (8 bits)
Tipo do próximo cabeçalho, indicando qual protocolo da camada superior foi protegido. O valor é obtido da lista de números de protocolo IP .
Payload Len (8 bits)
O comprimento deste cabeçalho de autenticação em unidades de 4 octetos, menos 2. Por exemplo, um valor AH de 4 é igual a 3 × (campos AH de comprimento fixo de 32 bits) + 3 × (campos ICV de 32 bits) - 2 e assim um valor AH de 4 significa 24 octetos. Embora o tamanho seja medido em unidades de 4 octetos, o comprimento desse cabeçalho precisa ser um múltiplo de 8 octetos se transportado em um pacote IPv6. Essa restrição não se aplica a um cabeçalho de autenticação transportado em um pacote IPv4.
Reservado (16 bits)
Reservado para uso futuro (todos zeros até então).
Índice de parâmetros de segurança (32 bits)
Valor arbitrário que é usado (junto com o endereço IP de destino) para identificar a associação de segurança da parte receptora.
Número de sequência (32 bits)
Um número de sequência monotônico estritamente crescente (incrementado em 1 para cada pacote enviado) para evitar ataques de repetição . Quando a detecção de reprodução está ativada, os números de sequência nunca são reutilizados, porque uma nova associação de segurança deve ser renegociada antes de uma tentativa de incrementar o número de sequência além de seu valor máximo.
Valor de verificação de integridade (múltiplo de 32 bits)
Valor de verificação de comprimento variável. Ele pode conter preenchimento para alinhar o campo a um limite de 8 octetos para IPv6 ou a um limite de 4 octetos para IPv4 .

Encapsulando a carga útil de segurança

Uso de IPsec Encapsulating Security Payload (ESP) nos modos de túnel e transporte

O IP Encapsulating Security Payload (ESP) foi desenvolvido no Naval Research Laboratory começando em 1992 como parte de um projeto de pesquisa patrocinado pela DARPA e foi publicado abertamente pelo IETF SIPP Working Group elaborado em dezembro de 1993 como uma extensão de segurança para SIPP. Este ESP foi originalmente derivado do protocolo SP3D do Departamento de Defesa dos EUA , em vez de ser derivado do Protocolo de Segurança de Camada de Rede ISO (NLSP). A especificação do protocolo SP3D foi publicada pelo NIST no final dos anos 1980, mas projetada pelo projeto Secure Data Network System do Departamento de Defesa dos Estados Unidos. Encapsulating Security Payload (ESP) é um membro do conjunto de protocolos IPsec. Ele fornece origem autenticidade através de fonte de autenticação , integridade dos dados através de funções hash e confidencialidade através de criptografia de proteção para IP pacotes . O ESP também oferece suporte a configurações somente de criptografia e autenticação , mas o uso de criptografia sem autenticação é fortemente desencorajado porque é inseguro.

Ao contrário do Authentication Header (AH) , o ESP no modo de transporte não fornece integridade e autenticação para todo o pacote IP . No entanto, no modo de túnel , onde todo o pacote IP original é encapsulado com um novo cabeçalho de pacote adicionado, a proteção ESP é concedida a todo o pacote IP interno (incluindo o cabeçalho interno) enquanto o cabeçalho externo (incluindo quaisquer opções IPv4 externas ou extensão IPv6 cabeçalhos) permanece desprotegido. O ESP opera diretamente sobre o IP, usando o protocolo IP número 50.

O seguinte diagrama de pacote ESP mostra como um pacote ESP é construído e interpretado:

Encapsulando formato de carga útil de segurança
Offsets Octeto 16 0 1 2 3
Octeto 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Índice de parâmetros de segurança (SPI)
4 32 Número sequencial
8 64 Dados de carga útil
... ...
... ...    
... ...   Preenchimento (0-255 octetos)  
... ...   Comprimento da almofada Próximo Cabeçalho
... ... Valor de verificação de integridade (ICV)
...
... ...
Índice de parâmetros de segurança (32 bits)
Valor arbitrário usado (junto com o endereço IP de destino) para identificar a associação de segurança da parte receptora.
Número de sequência (32 bits)
Um número de sequência monotonicamente crescente (incrementado em 1 para cada pacote enviado) para proteção contra ataques de repetição . Há um contador separado mantido para cada associação de segurança.
Dados de carga útil (variável)
O conteúdo protegido do pacote IP original, incluindo quaisquer dados usados ​​para proteger o conteúdo (por exemplo, um vetor de inicialização para o algoritmo criptográfico). O tipo de conteúdo protegido é indicado pelo campo Próximo cabeçalho .
Preenchimento (0-255 octetos)
Preenchimento para criptografia, para estender os dados de carga útil a um tamanho que se ajuste ao tamanho do bloco de criptografia da criptografia e para alinhar o próximo campo.
Comprimento da almofada (8 bits)
Tamanho do preenchimento (em octetos).
Próximo cabeçalho (8 bits)
Tipo do próximo cabeçalho. O valor é obtido da lista de números de protocolo IP .
Valor de verificação de integridade (múltiplo de 32 bits)
Valor de verificação de comprimento variável. Ele pode conter preenchimento para alinhar o campo a um limite de 8 octetos para IPv6 ou a um limite de 4 octetos para IPv4 .

Associação de segurança

Os protocolos IPsec usam uma associação de segurança , onde as partes em comunicação estabelecem atributos de segurança compartilhados, como algoritmos e chaves. Como tal, o IPsec fornece uma gama de opções, uma vez que tenha sido determinado se AH ou ESP é usado. Antes de trocar dados, os dois hosts concordam sobre qual algoritmo é usado para criptografar o pacote IP, por exemplo DES ou IDEA , e qual função hash é usada para garantir a integridade dos dados, como MD5 ou SHA . Esses parâmetros são acordados para a sessão específica, para a qual deve ser acordado um tempo de vida e uma chave de sessão .

O algoritmo de autenticação também é acordado antes de ocorrer a transferência de dados e o IPsec oferece suporte a uma variedade de métodos. A autenticação é possível por meio de chave pré-compartilhada , onde uma chave simétrica já está em posse de ambos os hosts, e os hosts enviam hashes da chave compartilhada um para o outro para provar que possuem a mesma chave. O IPsec também suporta criptografia de chave pública , onde cada host tem uma chave pública e uma privada, eles trocam suas chaves públicas e cada host envia ao outro um nonce criptografado com a chave pública do outro host. Como alternativa, se ambos os hosts possuírem um certificado de chave pública de uma autoridade de certificação , isso pode ser usado para autenticação IPsec.

As associações de segurança do IPsec são estabelecidas usando a Internet Security Association e o Key Management Protocol (ISAKMP). ISAKMP é implementado por configuração manual com segredos pré-compartilhados, Internet Key Exchange (IKE e IKEv2), Negociação de Chaves por Internet Kerberizada (KINK) e o uso de registros IPSECKEY DNS . O RFC 5386 define a segurança Better-Than-Nothing (BTNS) como um modo não autenticado de IPsec usando um protocolo IKE estendido. C. Meadows, C. Cremers e outros usaram métodos formais para identificar várias anomalias que existem no IKEv1 e também no IKEv2.

Para decidir qual proteção deve ser fornecida para um pacote de saída, o IPsec usa o Índice de Parâmetros de Segurança (SPI), um índice para o banco de dados de associação de segurança (SADB), junto com o endereço de destino em um cabeçalho de pacote, que juntos identifica de forma exclusiva uma associação de segurança para esse pacote. Um procedimento semelhante é executado para um pacote de entrada, onde o IPsec coleta chaves de descriptografia e verificação do banco de dados de associação de segurança.

Para multicast IP, uma associação de segurança é fornecida para o grupo e é duplicada em todos os receptores autorizados do grupo. Pode haver mais de uma associação de segurança para um grupo, usando diferentes SPIs, permitindo vários níveis e conjuntos de segurança dentro de um grupo. Na verdade, cada remetente pode ter várias associações de segurança, permitindo a autenticação, uma vez que um destinatário só pode saber que alguém que conhece as chaves enviou os dados. Observe que o padrão relevante não descreve como a associação é escolhida e duplicada no grupo; presume-se que uma parte responsável terá feito a escolha.

Modos de operação

Os protocolos IPsec AH e ESP podem ser implementados em um modo de transporte host a host, bem como em um modo de túnel de rede.

Modos IPsec

Modo de transporte

No modo de transporte, apenas a carga útil do pacote IP é geralmente criptografada ou autenticada. O roteamento está intacto, pois o cabeçalho IP não é modificado nem criptografado; entretanto, quando o cabeçalho de autenticação é usado, os endereços IP não podem ser modificados pela tradução do endereço de rede , pois isso sempre invalida o valor de hash . As camadas de transporte e de aplicativo são sempre protegidas por um hash, portanto, não podem ser modificadas de nenhuma forma, por exemplo, traduzindo os números de porta .

Um meio de encapsular mensagens IPsec para passagem NAT foi definido por documentos RFC que descrevem o mecanismo NAT-T .

Modo túnel

No modo de túnel, todo o pacote IP é criptografado e autenticado. Ele é então encapsulado em um novo pacote IP com um novo cabeçalho IP. O modo túnel é usado para criar redes privadas virtuais para comunicações rede a rede (por exemplo, entre roteadores para sites de link), comunicações host a rede (por exemplo, acesso de usuário remoto) e comunicações host a host (por exemplo, chat privado).

O modo de túnel é compatível com NAT traversal.

Algoritmos

Algoritmos de criptografia simétrica

Os algoritmos criptográficos definidos para uso com IPsec incluem:

Consulte RFC 8221 para obter detalhes.

Algoritmos de troca de chave

Algoritmos de autenticação

Implementações

O IPsec pode ser implementado na pilha de IP de um sistema operacional , o que requer modificação do código-fonte. Este método de implementação é feito para hosts e gateways de segurança. Várias pilhas de IP compatíveis com IPsec estão disponíveis em empresas, como HP ou IBM. Uma alternativa é a chamada implementação bump-in-the-stack (BITS), em que o código-fonte do sistema operacional não precisa ser modificado. Aqui, o IPsec é instalado entre a pilha IP e os drivers de rede . Desta forma, os sistemas operacionais podem ser adaptados com IPsec. Este método de implementação também é usado para hosts e gateways. No entanto, ao adaptar o IPsec, o encapsulamento de pacotes IP pode causar problemas para a descoberta automática de MTU do caminho , onde o tamanho máximo da unidade de transmissão (MTU) no caminho de rede entre dois hosts IP é estabelecido. Se um host ou gateway tiver um criptoprocessador separado , o que é comum nas forças armadas e também pode ser encontrado em sistemas comerciais, é possível uma implementação chamada bump-in-the-wire (BITW) de IPsec.

Quando o IPsec é implementado no kernel , o gerenciamento de chaves e a negociação ISAKMP / IKE são realizados a partir do espaço do usuário. A "API de gerenciamento de chave PF_KEY, versão 2" desenvolvida por NRL e especificada abertamente é freqüentemente usada para permitir que o aplicativo de gerenciamento de chave de espaço de aplicativo atualize as associações de segurança IPsec armazenadas na implementação IPsec de espaço kernel. As implementações de IPsec existentes geralmente incluem ESP, AH e IKE versão 2. As implementações de IPsec existentes em sistemas operacionais semelhantes a UNIX, por exemplo, Solaris ou Linux, geralmente incluem PF_KEY versão 2.

O IPsec incorporado pode ser usado para garantir a comunicação segura entre aplicativos executados em sistemas de recursos restritos com uma pequena sobrecarga.

Status de padrões

O IPsec foi desenvolvido em conjunto com o IPv6 e originalmente precisava ser compatível com todas as implementações de IPv6 em conformidade com os padrões antes que o RFC 6434 o tornasse apenas uma recomendação. O IPsec também é opcional para implementações IPv4 . O IPsec é mais comumente usado para proteger o tráfego IPv4.

Os protocolos IPsec foram originalmente definidos no RFC 1825 até o RFC 1829, que foram publicados em 1995. Em 1998, esses documentos foram substituídos pelo RFC 2401 e pelo RFC 2412 com alguns detalhes de engenharia incompatíveis, embora fossem conceitualmente idênticos. Além disso, uma autenticação mútua e protocolo de troca de chaves Internet Key Exchange (IKE) foi definido para criar e gerenciar associações de segurança. Em dezembro de 2005, novos padrões foram definidos no RFC 4301 e no RFC 4309, que são em grande parte um superconjunto das edições anteriores com uma segunda versão do padrão IKEv2 do Internet Key Exchange . Esses documentos de terceira geração padronizaram a abreviatura de IPsec para “IP” maiúsculo e “sec” minúsculo. “ESP” geralmente se refere ao RFC 4303, que é a versão mais recente da especificação.

Desde meados de 2008, um grupo de trabalho de manutenção e extensões de IPsec (ipsecme) está ativo na IETF.

Suposta interferência NSA

Em 2013, como parte dos vazamentos de Snowden , foi revelado que a Agência de Segurança Nacional dos EUA estava trabalhando ativamente para "Inserir vulnerabilidades em sistemas comerciais de criptografia, sistemas de TI, redes e dispositivos de comunicação de endpoint usados ​​por alvos" como parte do programa Bullrun . Há alegações de que o IPsec era um sistema de criptografia direcionado.

A pilha OpenBSD IPsec veio mais tarde e também foi amplamente copiada. Em uma carta que o desenvolvedor líder do OpenBSD Theo de Raadt recebeu em 11 de dezembro de 2010 de Gregory Perry, é alegado que Jason Wright e outros, trabalhando para o FBI, inseriram "uma série de backdoors e mecanismos de vazamento de chave de canal lateral " na criptografia do OpenBSD código. No e-mail encaminhado de 2010, Theo de Raadt não expressou, a princípio, uma posição oficial sobre a validade das reivindicações, além do endosso implícito do encaminhamento do e-mail. Resposta de Jason Wright às alegações: "Todas as lendas urbanas se tornam mais reais com a inclusão de nomes, datas e horários reais. O e-mail de Gregory Perry se enquadra nesta categoria. ... Declararei claramente que não adicionei backdoors ao OpenBSD operacional sistema ou a estrutura de criptografia do OpenBSD (OCF). " Alguns dias depois, de Raadt comentou que "acredito que a NETSEC provavelmente foi contratada para escrever backdoors, conforme alegado. ... Se foram escritos, não acredito que tenham entrado em nossa árvore". Isso foi publicado antes dos vazamentos de Snowden.

Uma explicação alternativa apresentada pelos autores do ataque Logjam sugere que a NSA comprometeu VPNs IPsec ao minar o algoritmo Diffie-Hellman usado na troca de chaves. Em seu artigo, eles alegam que a NSA construiu especialmente um cluster de computação para pré-calcular subgrupos multiplicativos para primos e geradores específicos, como para o segundo grupo Oakley definido na RFC 2409. Em maio de 2015, 90% das VPNs IPsec endereçáveis ​​suportavam o segundo grupo Oakley como parte do IKE. Se uma organização fosse pré-computar esse grupo, ela poderia derivar as chaves que estão sendo trocadas e descriptografar o tráfego sem inserir backdoors de software.

Uma segunda explicação alternativa apresentada foi que o Equation Group usou exploits de dia zero contra equipamentos VPN de vários fabricantes que foram validados pela Kaspersky Lab como sendo vinculados ao Equation Group e validados por esses fabricantes como sendo exploits reais, alguns dos quais eram exploits de dia zero no momento de sua exposição. Os firewalls Cisco PIX e ASA tinham vulnerabilidades que eram usadas para escuta telefônica pela NSA.

Além disso, as VPNs IPsec que usam as configurações do "Modo agressivo" enviam um hash do PSK em claro. Isso pode ser e aparentemente é alvejado pela NSA usando ataques de dicionário offline.

Documentação IETF

Trilha de padrões

  • RFC  1829 : A transformação ESP DES-CBC
  • RFC  2403 : O uso de HMAC-MD5-96 no ESP e AH
  • RFC  2404 : O uso de HMAC-SHA-1-96 no ESP e AH
  • RFC  2405 : O algoritmo de cifra ESP DES-CBC com IV explícito
  • RFC  2410 : O algoritmo de criptografia NULL e seu uso com IPsec
  • RFC  2451 : Os Algoritmos de Cifra ESP CBC-Mode
  • RFC  2857 : O uso de HMAC-RIPEMD-160-96 no ESP e AH
  • RFC  3526 : Grupos Diffie-Hellman mais modulares exponenciais (MODP) para Internet Key Exchange (IKE)
  • RFC  3602 : O algoritmo de cifra AES-CBC e seu uso com IPsec
  • RFC  3686 : Usando o modo de contador do Advanced Encryption Standard (AES) com IPsec Encapsulating Security Payload (ESP)
  • RFC  3947 : Negociação de NAT-Traversal no IKE
  • RFC  3948 : Encapsulamento UDP de pacotes IPsec ESP
  • RFC  4106 : O uso de Galois / modo de contador (GCM) em IPsec Encapsulating Security Payload (ESP)
  • RFC  4301 : Arquitetura de segurança para o protocolo da Internet
  • RFC  4302 : Cabeçalho de autenticação de IP
  • RFC  4303 : Carga útil de segurança de encapsulamento de IP
  • RFC  4304 : Adendo do Número de Sequência Estendido (ESN) ao Domínio de Interpretação (DOI) de IPsec para Associação de Segurança da Internet e Protocolo de Gerenciamento de Chaves (ISAKMP)
  • RFC  4307 : Algoritmos criptográficos para uso na versão 2 do Internet Key Exchange ( IKEv2 )
  • RFC  4308 : Cryptographic Suites for IPsec
  • RFC  4309 : Usando o modo CCM de padrão de criptografia avançado (AES) com carga útil de segurança de encapsulamento IPsec (ESP)
  • RFC  4543 : O uso do código de autenticação de mensagem Galois (GMAC) em IPsec ESP e AH
  • RFC  4555 : Protocolo de Mobilidade e Multihoming IKEv2 (MOBIKE)
  • RFC  4806 : Extensões de protocolo de status de certificado online (OCSP) para IKEv2
  • RFC  4868 : Usando HMAC-SHA-256, HMAC-SHA-384 e HMAC-SHA-512 com IPsec
  • RFC  4945 : O perfil de PKI de segurança de IP da Internet de IKEv1 / ISAKMP, IKEv2 e PKIX
  • RFC  5280 : Certificado de infraestrutura de chave pública da Internet X.509 e perfil de lista de revogação de certificado (CRL)
  • RFC  5282 : Usando algoritmos de criptografia autenticados com a carga criptografada do protocolo Internet Key Exchange versão 2 (IKEv2)
  • RFC  5386 : Segurança melhor que nada: um modo não autenticado de IPsec
  • RFC  5529 : Modos de operação para camélia para uso com IPsec
  • RFC  5685 : mecanismo de redirecionamento para o Internet Key Exchange Protocol versão 2 (IKEv2)
  • RFC  5723 : retomada da sessão do Internet Key Exchange Protocol versão 2 (IKEv2)
  • RFC  5857 : Extensões IKEv2 para oferecer suporte à compactação robusta de cabeçalho sobre IPsec
  • RFC  5858 : Extensões IPsec para oferecer suporte à compactação robusta de cabeçalho sobre IPsec
  • RFC  7296 : Internet Key Exchange Protocol versão 2 (IKEv2)
  • RFC  7321 : Requisitos de implementação de algoritmo criptográfico e orientação de uso para carga útil de segurança de encapsulamento (ESP) e cabeçalho de autenticação (AH)
  • RFC  7383 : Fragmentação de Mensagem do Internet Key Exchange Protocol versão 2 (IKEv2)
  • RFC  7427 : Autenticação de assinatura na versão 2 do Internet Key Exchange (IKEv2)
  • RFC  7634 : ChaCha20, Poly1305 e seu uso no Internet Key Exchange Protocol (IKE) e IPsec

RFCs experimentais

  • RFC  4478 : Autenticação repetida no protocolo Internet Key Exchange (IKEv2)

RFCs informativos

  • RFC  2367 : Interface PF_KEY
  • RFC  2412 : O Protocolo de Determinação da Chave OAKLEY
  • RFC  3706 : um método baseado em tráfego de detecção de pares mortos do Internet Key Exchange (IKE)
  • RFC  3715 : Requisitos de compatibilidade IPsec-Network Address Translation (NAT)
  • RFC  4621 : Projeto do protocolo IKEv2 Mobility and Multihoming (MOBIKE)
  • RFC  4809 : Requisitos para um Perfil de Gerenciamento de Certificado IPsec
  • RFC  5387 : Declaração de problema e aplicabilidade para segurança melhor que nada (BTNS)
  • RFC  5856 : Integração de compactação robusta de cabeçalho sobre associações de segurança IPsec
  • RFC  5930 : Usando o modo de contador padrão de criptografia avançada (AES-CTR) com o protocolo Internet Key Exchange versão 02 (IKEv2)
  • RFC  6027 : Declaração de problema de cluster IPsec
  • RFC  6071 : Roteiro de documentos IPsec e IKE
  • RFC  6379 : Suite B Cryptographic Suites para IPsec
  • RFC  6380 : Perfil Suite B para Internet Protocol Security (IPsec)
  • RFC  6467 : Estrutura de senha segura para Internet Key Exchange versão 2 (IKEv2)

RFCs de melhores práticas atuais

  • RFC  5406 : Diretrizes para especificar o uso de IPsec versão 2

RFCs obsoletos / históricos

  • RFC  1825 : Arquitetura de segurança para o protocolo da Internet (obsoleto pelo RFC 2401)
  • RFC  1826 : Cabeçalho de autenticação IP (obsoleto pelo RFC 2402)
  • RFC  1827 : IP Encapsulating Security Payload (ESP) (obsoleto pelo RFC 2406)
  • RFC  1828 : Autenticação IP usando MD5 com chave (histórico)
  • RFC  2401 : Arquitetura de segurança para o protocolo da Internet (visão geral do IPsec) (obsoleto pelo RFC 4301)
  • RFC  2406 : IP Encapsulating Security Payload (ESP) (obsoleto pelo RFC 4303 e RFC 4305)
  • RFC  2407 : O domínio de interpretação de segurança de IP da Internet para ISAKMP (obsoleto pelo RFC 4306)
  • RFC  2409 : O Internet Key Exchange (obsoleto pelo RFC 4306)
  • RFC  4305 : Requisitos de implementação de algoritmo criptográfico para encapsulamento de carga útil de segurança (ESP) e cabeçalho de autenticação (AH) (obsoleto pelo RFC 4835)
  • RFC  4306 : Protocolo Internet Key Exchange (IKEv2) (obsoleto pelo RFC 5996)
  • RFC  4718 : IKEv2 Esclarecimentos e Diretrizes de Implementação (obsoleto pelo RFC 7296)
  • RFC  4835 : Requisitos de implementação de algoritmo criptográfico para encapsulamento de carga útil de segurança (ESP) e cabeçalho de autenticação (AH) (obsoleto pelo RFC 7321)
  • RFC  5996 : Internet Key Exchange Protocol versão 2 (IKEv2) (obsoleto pelo RFC 7296)

Veja também

Referências

links externos