Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Internet Key Exchange

IKE(Internet Key Exchange) 소개

IKE(Internet Key Exchange)는 두 디바이스 간에 인증된 안전한 통신 채널을 설정하는 데 사용되는 보안 키 관리 프로토콜입니다.

IKE(Internet Key Exchange)는 다음을 수행합니다.

  • IKE 및 IPsec 매개 변수 협상 및 관리

  • 보안 키 교환 인증

  • 비밀번호가 아닌 공유 비밀번호 및 공용 키를 사용하여 상호 피어 인증 제공

  • ID 보호 제공(기본 모드)

  • Diffie-Hellman 메서드를 사용하며 IPsec에서 선택 사항(공유 키는 엔드포인트에서 수동으로 입력할 수 있음)

IKE(Internet Key Exchange) 버전

두 가지 버전의 IKE(Internet Key Exchange) 표준을 사용할 수 있습니다.

  • IKE 버전 1 - RFC 2409에 정의된 IKE 프로토콜

  • IKE 버전 2 - IKE 버전 2(IKEv2)는 RFC 7296에 정의된 IKE 프로토콜의 최신 버전

IKEv2(Internet Key Exchange version 2)는 RFC 7296에 정의된 IKE(Internet Key Exchange) 프로토콜의 최신 버전입니다. VPN 피어가 IKEv1 또는 IKEv2 중 하나로 구성되어 있습니다. 피어가 IKEv2로 구성된 경우 해당 원격 피어가 IKEv1 협상을 시작하면 피어가 IKEv1로 다시 이동할 수 없습니다.

IKEv1에 비해 IKEv2를 사용하면 다음과 같은 이점이 있습니다.

  • 8개의 초기 교환을 단일 4개의 메시지 교환으로 대체합니다.

  • IPsec SA 설정의 지연 시간을 줄이고 연결 설정 속도를 높입니다.

  • DOS 공격에 대한 견고성을 향상합니다.

  • 시퀀스 번호 사용, 승인 및 오류 수정을 통해 안정성이 향상됩니다.

  • 모든 메시지가 요청 또는 응답이므로 신뢰성이 향상됩니다. 이니시에이터는 응답을 수신하지 않을 경우 재전송할 책임이 있습니다.

IKE와 IPSec 간의 상호 작용

IPsec은 다음과 같은 방법으로 VPN을 설정할 수 있습니다.

  • IKE(Internet Key Exchange) 프로토콜 - IPsec은 IKE 프로토콜을 사용하여 키 및 보안 연결의 자동 생성 및 협상을 지원합니다. IKE를 사용하여 두 엔드포인트 간에 VPN을 협상하면 수동 키 교환보다 더 많은 보안이 제공됩니다.

  • 수동 키 교환—IPsec은 수동으로 키 사용 및 교환을 지원합니다(예: 전화 또는 이메일)을 사용하여 VPN을 설정할 수 있습니다.

IKEv1 메시지 교환

IKE(Internet Key Exchange) 협상에는 두 가지 단계가 포함됩니다.

  • 1단계: 채널을 인증하고 안전하게 보호하는 방법에 대해 제안 교환을 협상합니다.

  • 2단계: 보안 연결(SA)을 협상하여 IPsec 터널을 통과하는 데이터를 보호합니다.

IKE(Internet Key Exchange) 터널 협상 1단계

자동 키 IKE(Internet Key Exchange) 협상의 1단계는 채널의 인증 및 보안 방법에 대한 제안 교환으로 구성됩니다. 참가자는 다음과 같은 허용되는 보안 서비스에 대한 제안을 교환합니다.

  • 암호화 알고리즘 - 데이터 암호화 표준(DES), 트리플 데이터 암호화 표준(3DES) 및 고급 암호화 표준(AES). (IPsec 개요을(를) 참조하십시오.)

  • 인증 알고리즘 - 메시지 다이제스트 5(MD5) 및 보안 해시 알고리즘(SHA). (IPsec 개요을(를) 참조하십시오.)

  • Difie-Hellman(DH) 그룹. (IPsec 개요을(를) 참조하십시오.)

  • 사전 공유 키 또는 RSA/DSA 인증서. (IPsec 개요을(를) 참조하십시오.)

성공적인 1단계 협상은 터널의 양 끝이 한 개 이상의 제안된 1단계 보안 매개 변수 세트를 수락하고 처리하기로 동의할 때 끝납니다. 주니퍼 네트웍스 디바이스는 1단계 협상에 최대 4개의 제안을 지원하여, 허용할 핵심 협상에 대한 보안 매개 변수 범위를 얼마나 제한할지 정의할 수 있습니다. Junos OS는 사정 정의된 표준의 호환 가능한 기본 1단계 제안 세트를 제공합니다. 또한 사용자 정의 1단계 제안을 정의할 수 있습니다.

1단계 교환은 메인 모드 또는 적극적인 모드에서 발생할 수 있습니다. IKE(Internet Key Exchange) 정책 구성 중 모드를 선택할 수 있습니다.

이 주제는 다음 섹션을 포함합니다.

메인 모드

메인 모드에서 개시자 및 응답자는 세 가지 양방향 교환(총 6개의 메시지)으로 다음 서비스를 수행합니다.

  • 첫 번째 교환(메시지 1 및 2) - 암호화 및 인증 알고리즘을 제안하고 수락합니다.

  • 두 번째 교환(메시지 3 및 4) - DH 교환을 실행하고, 개시자 및 응답자는 각각의 의사 난수 번호를 제공합니다.

  • 세 번째 교환(메시지 5 및 6) - 개시자 및 응답자의 ID을 전송하고 확인합니다.

세 번째 메시지 교환에서 전송되는 정보는 앞선 두 교환에서 설정된 암호화 알고리즘에 의해 보호됩니다. 따라서 참가자의 ID는 암호화되어 "명확하게" 전송되지 않습니다.

적극적인 모드

적극적인 모드에서 개시자 및 응답자는 메인 모드와 함께 동일한 목표를 달성하지만, 총 세 개의 메시지 중 두 번의 교환에서만 해당됩니다.

  • 첫 번째 메시지 - 개시자는 보안 연결(SA)을 제안하고, DH 교환을 시작하며, 의사 난수 번호와 해당 IKE(Internet Key Exchange) ID를 전송합니다.

    1단계 협상에 대한 여러 제안으로 적극적인 모드를 구성할 때, DH 그룹이 협상될 수 없으므로 모든 제안에서 동일한 DH 그룹을 사용합니다. 최대 4개의 제안을 구성할 수 있습니다.

  • 두 번째 메시지 - 응답자는 SA를 허용하고, 개시자를 인증합니다. 그리고 의사 난수 번호, 해당 IKE ID 및 인증서(수신자의 인증서를 사용하면)를 전송합니다.

  • 세 번째 메시지 - 개시자는 응답자를 인증하고, 교환을 확인하고, 인증서를 사용하는 경우 개시자의 인증서를 전송합니다.

참가자의 ID가 명확하게 교환되기 때문에(처음 두 메시지에서), 적극적인 모드는 ID 보호를 제공하지 않습니다.

메인 및 적극적인 모드는 IKEv1 프로토콜에만 적용됩니다. IKEv2 프로토콜은 메인 및 적극적인 모드를 사용하여 협상하지 않습니다.

IKE(Internet Key Exchange) 터널 협상 2단계

참가자가 안전하고 인증된 채널을 설립한 후 참가자는 IPsec 터널을 통해 전송할 데이터를 확보하기 위한 보안 연결(SA)를 협상하는 2단계를 통해 진행됩니다.

1단계의 프로세스와 마찬가지로 참가자는 SA에 사용할 보안 매개 변수 중 어느 하나를 결정하기 위해 제안을 교환합니다. 또한 2단계 제안은 암호화된 보안 페이로드(ESP) 또는 인증 헤더(AH) 중 하나인 보안 프로토콜과 선택된 암호화와 인증 알고리즘을 포함합니다. 또한 제안은 PFS(Perfect Forward Secrecy)이 원하는 경우 DH(Diffie-Hellman)그룹을 지정할 수 있습니다.

1단계에서 사용되는 모드에 관계없이 2단계는 항상 빠른 모드로 동작하며 세 개의 메시지를 교환하는 것과 연관됩니다.

이 주제는 다음 섹션을 포함합니다.

프록시 ID

2단계에서 피어들은 프록시 ID를 교환합니다. 프록시 ID는 로컬 및 원격 IP 주소 접두사로 구성됩니다. 두 피어의 프록시 ID는 반드시 일치되어야 하며 이는 하나의 피어에 지정된 로컬 IP 주소가 다른 피어에 지정된 원격 IP 주소와 동일해야 한다는 것을 의미합니다.

PFS(Perfect Forward Secrecy)

PFS는 이전 키와 관련없고 독립적인 2단계 키를 유도하는 방법입니다. 또는 1단계 제안은 모든 2단계 키가 유도되는 키(SKEYID_d 키)를 만듭니다. SKEYID_d 키는 최소한의 CPU 처리를 통해 2단계 키를 생성할 수 있습니다. 불행하게도, 무단으로 SKEYID_d 키에 대한 액세스를 얻는 경우 모든 암호화 키는 손상됩니다.

PFS는 각 2단계 터널에 대해 새로운 DH 키 교환을 강요함으로써 보안 위험을 다룹니다. 따라서 PFS를 사용하는 것은 더 안전하지만, 2단계에서 재구성하는 절차는 PFS가 활성화된 경우 약간 더 오래 걸릴 수 있습니다.

재생 보호

재생 공격은 허가 받지 않은 사람이 일련의 패킷을 가로채고 나중에 시스템을 홍수로 사용할 때 발생하며, 서비스 거부(DoS)를 유발하거나 또는 신뢰할 수 있는 네트워크 진입을 얻게 됩니다. Junos OS는 장치가 이전에 받은 지 확인하기 위해 모든 IPSec 패킷 체크를 할 수 있는 재생 보호 기능을 제공합니다. 지정된 시퀀스 범위 밖에 패킷이 도착하면 Junos OS는 패킷을 거부합니다. 이 기능을 사용하는 것은 협상이 필요하지 않습니다. 왜냐하면 패킷은 항상 시퀀스 번호로 보내졌기 때문입니다. 단순히 시퀀스 번호를 확인하거나 확인하지 않을 옵션이 있습니다.

IKEv2 메시지 교환

IKE 버전 2는 IKEv1 메서드의 후속 버전입니다. 피어 VPN 디바이스 간에 보안 VPN 통신 채널을 제공하고 보호된 방식으로 IPsec SA(Security Association)에 대한 협상 및 인증을 정의합니다.

IKEv2는 IKEv1과 유사한 1단계 및 2단계를 포함하지 않지만, IPsec 터널을 IKEv2와 협상하기 위해 4개의 메시지 교환이 발생합니다. IKEv2의 메시지 교환은 다음과 같습니다.

  • IPsec 터널을 설정하기 위해 보안 특성을 협상합니다. 여기에는 사용된 프로토콜/파라미터와 Diffie-Hellman 그룹의 교환이 포함됩니다.

  • 각 피어는 IPsec 터널이 설정되는 동안 자신의 ID를 설정하거나 인증합니다.

  • 피어 - 서로 간에 추가 보안 연결을 만듭니다.

  • 피어는 활성도 탐지, SA 관계 제거 및 오류 메시지 보고를 수행합니다.

IKEv2 구성 페이로드

구성 페이로드는 응답기에서 이니시에이터로 프로비저닝 정보를 전파하기 위해 제공되는 IKEv2 옵션입니다. IKEv2 구성 페이로드는 루트 기반 VPN에서만 지원됩니다.

RFC 5996, 인터넷 키 교환 프로토콜 버전 2(IKEv2)는 응답자가 이니시에이터에 반환할 수 있는 15가지 다른 구성 속성을 정의합니다.

IKEv2 키 재생성 및 재인증

IKEv2에서는 키 재생성과 재인증이 별개의 프로세스입니다.

키 재생성은 IKE SA(보안 연결)에 대한 새 키를 설정하고 메시지 ID 카운터를 재설정하지만 피어를 재인증하지는 않습니다.

재인증은 VPN 피어가 인증 자격 증명에 대한 액세스 권한을 유지하는지 확인합니다. 재인증은 IKE SA 및 하위 SA에 대한 새 키를 설정합니다. 보류 중인 IKE SA 또는 하위 SA의 키 재생성은 더 이상 필요하지 않습니다. 새 IKE 및 하위 SA가 생성되면 이전 IKE 및 하위 SA가 삭제됩니다.

IKEv2 재인증은 기본적으로 비활성화되어 있습니다. 재인증 빈도 값을 1에서 100 사이로 구성하여 재인증을 사용하도록 설정합니다. 재인증 빈도는 재인증이 발생하기 전에 발생하는 IKE 키 재생성 횟수입니다. 예를 들어, 구성된 재인증 빈도가 1인 경우 IKE 키 재생성이 있을 때마다 재인증이 발생합니다. 구성된 재인증 빈도가 2이면 다른 모든 IKE 키 재생성에서 재인증이 발생합니다. 구성된 재인증 빈도가 3이면 세 번째 IKE 키 재생성 시마다 재인증이 발생합니다.

IKEv2 단편화

인증서 기반 인증을 사용하는 경우 여러 인증서가 전송되는 경우 IKEv2 패킷이 경로 MTU를 초과할 수 있습니다. IKE 메시지 크기가 경로 MTU를 초과하면 메시지가 IP 수준에서 조각화됩니다. NAT 디바이스와 같은 일부 네트워크 장비는 IP 조각의 통과를 허용하지 않으므로 IPsec 터널을 설정할 수 없습니다.

RFC 7383, IKEv2(Internet Key Exchange 프로토콜 버전 2) 메시지 단편화에 설명된 바와 같이, IKEv2는 IP 조각이 차단되고 피어가 SA(IPsec Security Association)를 설정할 수 없는 환경에서 작동할 수 있습니다. IKEv2 단편화는 큰 IKEv2 메시지를 일련의 작은 메시지로 분할하여 IP 수준에서 단편화가 발생하지 않도록 합니다. 단편화는 원래 메시지가 암호화되고 인증되기 전에 수행되므로 각 조각이 별도로 암호화되고 인증됩니다. 수신기에서 조각은 수집, 확인, 해독 및 원본 메시지로 병합됩니다.

IKEv2의 트래픽 선택기

IKE 협상 중에 사용되는 IKEv2에서 트래픽 선택기를 구성할 수 있습니다. 트래픽 셀렉터는 트래픽이 로컬 및 원격 주소의 특정 한 쌍과 일치하는 경우 VPN 터널을 통과하는 트래픽을 허용하는 IKE(Internet Key Exchange) 피어 간의 계약입니다. 트래픽 셀렉터에 부합하는 트래픽만이 보안 연관(SA)을 통해 허용됩니다. 트래픽 선택기는 터널을 생성하는 동안 터널을 설정하고 터널을 통과할 수 있는 트래픽을 결정하는 데 사용됩니다.

프록시 ID

프록시 ID는 IKE(Internet Key Exchange) Virtual Private Network(VPN) 협상의 2단계에서 사용됩니다. VPN 터널의 양쪽 끝에는 수동으로 구성된 프록시 ID(경로 기반 VPN)가 있거나 터널 정책에서 소스 IP, 대상 IP 및 서비스의 조합만 사용합니다. IKE의 2단계가 협상되면 각 엔드는 구성된 로컬 및 원격 프록시 ID를 실제 수신된 프록시 ID와 비교합니다.

트래픽 선택기

프록시 ID는 경로 기반 VPN과 정책 기반 VPN 모두에서 지원됩니다. 그러나 다중 프록시 ID는 루트 기반 VPN에 대해서만 지원됩니다. 다중 프록시 ID는 트래픽 선택기로 알려져 있습니다. 트래픽 선택기는 트래픽이 로컬 및 원격 주소의 특정 한 쌍과 일치하는 경우 터널을 통과하는 트래픽을 허용하는 IKE(Internet Key Exchange) 피어 간의 계약입니다. 특정 경로 기반 VPN 내에서 트래픽 선택기를 정의하면 여러 단계 2 IPsec SA가 발생할 수 있습니다. 트래픽 선택기를 준수하는 트래픽만 SA를 통해 허용됩니다. 원격 게이트웨이 디바이스가 주니퍼 네트워크 디바이스가 아닌 경우 일반적으로 트래픽 선택기가 필요합니다.

IKE(Internet Key Exchange) 인증(사전 공유 키 및 인증서 기반 인증)

IKE 협상은 두 당사자가 통신할 수 있는 보안 채널을 설정할 수 있는 기능을 제공합니다. 사전 공유 키 인증 또는 인증서 기반 인증을 사용하여 두 당사자가 서로 인증하는 방법을 정의할 수 있습니다.

사전 공유 키 인증

인증서 기반 인증

VPN 연결을 설정하는 일반적인 방법

VPN 연결을 설정하는 안전한 방법입니다.

  • 사전 공유 키는 두 당사자 모두에게 동일한 암호입니다. 이 암호는 전화, 구두 교환 또는 보안이 덜한 메커니즘, 심지어 이메일을 사용하여 미리 교환됩니다.

  • 사전 공유 키는 문자, 숫자 및 영숫자가 아닌 문자의 조합을 사용하여 최소 8자(12자 이상 권장)로 구성되어야 하며 문자에 대한 다양한 대소문자도 함께 사용해야 합니다.

  • 사전 공유 키는 사전 단어를 사용할 수 없습니다.

인증서는 공용 키와 개인 키로 구성되며 인증 기관(CA)으로 알려진 기본 인증서로 서명할 수 있습니다.

당사자는 미리 공유된 키를 Diffie-Hellman 교환에서 얻은 피어의 공용 키로 암호화하여 서로 인증합니다.

당사자는 인증서를 확인하여 신뢰할 수 있는 CA에 의해 서명되었는지 확인합니다.

사전 공유 키는 일반적으로 단일 조직 내 또는 다른 조직 간에 사이트 간 IPsec VPN에 배포됩니다.

인증서는 또한 사전 공유 키를 모두 공유하지 않아야 하는 수많은 피어 사이트가 있는 대규모 환경에서 훨씬 더 이상적입니다.

네트워크 주소 변환-통과(NAT-T)

NAT-T(네트워크 주소 변환-Traversal)는 IPsec에 의해 보호되는 데이터가 주소 변환을 위해 네트워크 주소 변환(NAT) 디바이스를 통과할 때 발생하는 IP 주소 변환 문제를 해결하는 방법입니다.

NAT의 기능인 네트워크 주소 변경으로 IKE(Internet Key Exchange)는 패킷을 삭제합니다. 1단계 교환 중 데이터 경로를 따라 하나 이상의 네트워크 주소 변환(NAT) 디바이스를 감지한 후, NAT-T는 IPsec 패킷에 UDP(User Datagram Protocol) 캡슐화의 레이어를 추가하므로 해당 패킷은 주소 변환 후 삭제되지 않습니다. NAT-T는 소스 및 대상 포트 모두로 사용되는 포트 4500과 함께 UDP 내에서 IKE와 ESP 트래픽 모두를 캡슐화합니다. 네트워크 주소 변환(NAT) 디바이스가 교착 UDP 변환을 만료시키므로 피어 간 keepalive 메시지가 필요합니다.

네트워크 주소 변환(NAT) 디바이스의 위치는 다음과 같을 수 있습니다.

  • IKEv1 또는 IKEv2 개시자만이 네트워크 주소 변환(NAT) 디바이스 뒤에 있습니다. 여러 개시자가 분리된 네트워크 주소 변환(NAT) 디바이스 뒤에 있을 수 있습니다. 개시자는 또한 여러 네트워크 주소 변환(NAT) 디바이스를 통해 응답자와 연결할 수 있습니다.

  • IKEv1 또는 IKEv2 응답자만이 네트워크 주소 변환(NAT) 디바이스 뒤에 있습니다.

  • IKEv1 또는 IKEv2 개시자와 응답자가 모두 네트워크 주소 변환(NAT) 디바이스 뒤에 있습니다.

Suite B 및 PRIME 암호화 제품군

Suite B는 미국 국가안보국(NSA)이 지정한 암호화 알고리즘 세트로, 상업용 제품이 비밀 또는 극비 수준으로 분류되는 트래픽을 보호할 수 있습니다. Suite B 프로토콜은 RFC 637 IPsec을 위한 Suite B 암호화에 정의되어 있습니다. Suite B 암호화 제품군은 ESP(Encapsulating Security Payload) 무결성과 기밀성을 제공하며 ESP 무결성 보호와 암호화가 모두 필요한 경우 사용해야 합니다. 영국의 공공 부문 네트워크를 위해 정의된 IPsec 프로파일인 IP 모듈식 암호화를 위한 프로토콜 요구사항(PRIME)은 Suite B 암호화 제품군을 기반으로 하지만 IKEv2 협상을 위해 AES-CBC가 아닌 AES-GCM을 사용합니다.

지원되는 암호화 제품군은 다음과 같습니다.

  • Suite-B-GCM-128

    • ESP: GCM(Galois Counter Mode)에서 128비트 키와 16옥텟 ICV(Integrity Check Value)를 사용하는 AES(Advanced Encryption Standard) 암호화입니다.

    • IKE(Internet Key Exchange): 암호 블록 체인(CBC) 모드에서 128비트 키를 사용한 AES 암호화, SHA-256 인증을 사용한 무결성, DH(Diffie-Hellman) 그룹 19를 사용한 키 설정, ECDSA(Elliptic Curve Digital Signature Algorithm) 256비트 타원 곡선 서명을 사용한 인증.

  • Suite-B-GCM-256

    • ESP: ESP용 GCM에서 256비트 키와 16옥텟 ICV를 사용한 AES 암호화입니다.

    • IKE(Internet Key Exchange): CBC 모드에서 256비트 키를 사용한 AES 암호화, SHA-384 인증을 사용한 무결성, DH 그룹 20을 사용한 키 설정, ECDSA 384비트 타원곡선 서명을 사용한 인증입니다.

  • PRIME-128

    • ESP: GCM에서 128비트 키와 16옥텟 ICV를 사용한 AES 암호화입니다.

    • IKE(Internet Key Exchange): GCM에서 128비트 키를 사용한 AES 암호화, DH 그룹 19를 사용한 키 설정 및 ECDSA 256비트 타원곡선 서명을 사용한 인증입니다.

  • PRIME-256

    • ESP: ESP용 GCM에서 256비트 키와 16옥텟 ICV를 사용한 AES 암호화입니다.

    • IKE(Internet Key Exchange): GCM에서 256비트 키를 사용한 AES 암호화, DH 그룹 20을 사용한 키 설정 및 ECDSA 384비트 타원곡선 서명을 사용한 인증입니다.

Suite-B 암호화 제품군은 IKEv1 및 IKEv2를 지원합니다. PRIME 암호화 제품군은 IKEv2만 지원합니다.