인터넷 키 교환

3. 구성

인터넷 엔지니어링 태스크 포스(IETF)는 1998년 11월 RFC 2407^[4], RFC 2408^[5], RFC 2409^[6]를 통해 인터넷 키 교환(IKE)을 처음 정의했다. 이후 2005년 12월 RFC 4306^[7]에서 버전 2(IKEv2)로 업데이트되었고, 몇 차례의 수정을 거쳐 2014년 10월 RFC 7296^[9]으로 인터넷 표준이 되었다. IETF의 상위 조직인 인터넷 협회(ISOC)는 이 표준들에 대한 저작권을 인터넷 커뮤니티에서 자유롭게 사용할 수 있도록 유지하고 있다.

대부분의 IPsec 구현은 사용자 공간에서 실행되는 IKE 데몬과 실제 IP 패킷을 처리하는 커널의 IPsec 스택으로 구성된다. 사용자 공간 데몬은 IPsec 엔드포인트 주소, 키, 인증서와 같이 필요한 구성 정보를 담고 있는 저장소에 쉽게 접근할 수 있다. 반면에 커널 모듈은 성능상의 이유로 최소한의 부하로 패킷을 효율적으로 처리할 수 있다.

IKE 프로토콜은 일반적으로 UDP 500번 포트를 사용한다. 양쪽에서 ISAKMP SA를 생성하기 위해 일반적으로 2~3번의 왕복을 거쳐 4~6개의 패킷이 필요하다. 이 과정을 통해 협상된 키 자료(예: AES 키, 보호할 IP 엔드포인트 및 포트를 식별하는 정보, 생성된 IPsec 터널의 유형 등)는 커널의 IPsec 스택에 제공된다. IPsec 스택은 이 정보를 바탕으로 관련 IP 패킷을 가로채고 필요에 따라 암호화 또는 복호화를 수행한다. 패킷 가로채기 방식은 구현에 따라 다양하다.

IKEv1은 1단계와 2단계의 두 단계로 구성된다.^[10] IKEv2는 IKEv1의 여러 문제점을 개선하고 기능을 확장한 버전이다.

3. 1. IKEv1 단계

3. 2. IKEv2 개선 사항

• RFC 문서 통합 및 간소화: 기존 IKE는 최소 3개 이상의 RFC 문서에 명세가 나뉘어 있었고, NAT 통과 등 자주 사용되는 확장을 포함하면 더 많은 문서를 참조해야 했다. IKEv2는 이를 하나의 RFC 문서로 통합하고, NAT 통과(NAT) 및 방화벽 통과 지원을 개선했다.
• 표준 모빌리티 지원: IKEv2는 모빌리티 및 멀티호밍 프로토콜(MOBIKE)이라는 표준 확장(RFC 4555)을 통해 모바일 및 멀티홈 환경을 지원한다. 이 확장은 캡슐화 보안 페이로드(ESP)와 함께 사용되어, 이동 중이거나 여러 네트워크 인터페이스를 가진 사용자도 IKEv2와 IPsec을 안정적으로 사용할 수 있게 한다.
• NAT 통과 지원: IKE 및 ESP 패킷을 UDP 포트 4500으로 캡슐화하여, NAT 장치나 방화벽을 통과할 수 있도록 지원 기능이 내장되었다.^[14]
• SCTP 지원: 인터넷 전화(VoIP) 등에서 사용되는 SCTP 프로토콜을 지원한다.
• 단순한 메시지 교환: IKE는 8가지의 서로 다른 초기 교환 메커니즘을 가졌으나, IKEv2는 이를 4개의 메시지로 구성된 단일 초기 교환 메커니즘으로 단순화했다.
• 암호화 메커니즘 간소화: IKEv2는 IPsec ESP에서 사용하는 것과 유사한 암호화 메커니즘을 사용하여 패킷을 보호한다. 이는 구현을 단순화하고, 공통 기준 및 FIPS 140-2(FIPS) 인증 과정을 용이하게 한다. 각 암호화 구현을 별도로 검증해야 했던 부담을 줄인 것이다.
• 안정성 및 상태 관리 개선: 시퀀스 번호와 응답 확인(Acknowledgement)을 사용하여 통신의 안정성을 높였다. 또한 오류 처리 로직과 공유 상태 관리를 의무화하여, IKE에서 발생할 수 있었던 데드 상태(양측이 서로 응답을 기다리며 교착 상태에 빠지는 현상) 문제를 해결했다. 기존의 비표준화된 데드 피어 감지 방식들이 가진 호환성 문제도 해소되었다.
• DoS 공격 방어 강화: IKEv2는 요청을 보낸 측(개시자)이 실제로 존재하는지 확인하기 전까지는 많은 계산 자원을 소모하지 않는다. 이는 IP 스푸핑된 주소로부터의 요청에 대해 값비싼 암호화 연산을 수행하여 DoS 공격에 취약했던 IKE의 문제점을 개선한 것이다.

HostA -------------------------------------------------- HostB

|HDR(A,0),sai1,kei,Ni-------------------------->   |

|   <----------------------------HDR(A,0),N(cookie)|  (HostB가 부하 상태일 경우)

|HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |  (HostA가 쿠키 포함 재전송)

|   <--------------------------HDR(A,B),SAr1,ker,Nr|  (HostB가 인증 후 응답)

4. 프로토콜 확장

IETF ipsecme 워킹 그룹은 IKEv2 프로토콜을 현대화하고 대규모 운영 환경에 더 잘 적용하기 위해 여러 확장 기능을 표준화했다. 주요 확장 기능은 다음과 같다.

• '''IKE 세션 재개''': 통신 오류 발생 시, 전체 IKE 설정 과정을 다시 거치지 않고 중단된 IKE/IPsec "세션"을 빠르게 복구하는 기능이다 (RFC 5723).
• '''IKE 리다이렉트''': 들어오는 IKE 요청을 다른 서버로 넘겨주어, 여러 IKE 엔드포인트 간의 간단한 로드 밸런싱을 가능하게 한다 (RFC 5685).
• '''IPsec 트래픽 가시성''': 인증은 되었지만 암호화되지 않은 ESP 패킷에 특별한 표시를 하여, 침입 탐지 시스템과 같은 중간 장비가 네트워크 트래픽 흐름을 더 쉽게 분석할 수 있도록 돕는다 (RFC 5840).
• '''상호 EAP 인증''': EAP만을 사용하여 양쪽 IKE 장치 모두를 인증하는 기능이다. 인증서 없이도 최신 비밀번호 기반 인증 방식을 사용할 수 있도록 하는 것이 목표이다 (RFC 5998).
• '''빠른 충돌 감지''': IKE 통신 상대방 장치의 연결 끊김(충돌)을 감지하는 데 걸리는 시간을 최소화한다 (RFC 6290).
• '''고가용성 확장''': IPsec 엔드포인트 클러스터와 통신 상대방 간의 IKE/IPsec 프로토콜 동기화를 개선하여, 장애 조치 발생 시 연결 끊김 가능성을 줄인다 (RFC 6311).

5. 구현

IKE는 윈도우 2000, 윈도우 XP, 윈도우 서버 2003, 윈도우 비스타 및 윈도우 서버 2008의 IPsec 구현의 일부로 지원된다.^[15] ISAKMP/IKE 구현은 시스코와 마이크로소프트가 공동으로 개발했다.^[16]

마이크로소프트의 윈도우 7 및 윈도우 서버 2008 R2는 'VPN 재연결' 기능( '애자일 VPN'이라고도 함)을 통해 IKEv2 (RFC 7296) 및 MOBIKE (RFC 4555)를 부분적으로 지원한다.

리눅스에서는 Libreswan, Openswan 및 strongSwan과 같은 여러 오픈 소스 구현이 존재한다. 이들은 KLIPS 또는 XFRM/NETKEY 커널 기반 IPsec 스택에 대한 IKE 데몬을 제공하여 SA(보안 연관)를 설정하고 관리한다. XFRM/NETKEY는 버전 2.6부터 사용할 수 있는 리눅스 커널 네이티브 IPsec 구현이다.

BSD 계열 운영체제 역시 OpenBSD 암호화 프레임워크 (OCF)를 통해 IPsec과 IKE 데몬을 구현한다. OCF는 암호화 가속기 지원을 용이하게 하며, 최근 리눅스로도 포팅되었다.

많은 네트워크 장비 공급업체들은 자체 IKE 데몬(및 IPsec 구현)을 만들거나 서로의 기술 스택을 라이선스하여 사용한다.

IKEv2의 여러 구현이 있으며, IPsec 인증 및 상호 운용성 테스트를 다루는 일부 회사들은 IKEv2 테스트를 위한 워크샵을 개최하고 업데이트된 인증 요구 사항을 갖추기 시작했다.

다음은 IKEv2의 주요 오픈 소스 구현 목록이다.

6. 취약점

2014년 독일 언론 슈피겔이 공개한 유출된 NSA 발표 자료에 따르면, IKE가 IPsec 트래픽을 해독하기 위해 알려지지 않은 방식으로 악용되고 있으며, ISAKMP도 마찬가지라는 주장이 제기되었다.^[19] 로그잼 공격을 발견한 연구원들은 1024비트 디피-헬만 그룹을 해독하는 것이 VPN 서버의 66%, 상위 100만 HTTPS 도메인의 18%, SSH 서버의 26%를 공격할 수 있게 만들며, 이는 NSA 유출 내용과 일치한다고 주장했다.^[20] 그러나 이 주장은 2015년 에일 로넨과 아디 샤미르의 논문 "불완전한 순방향 비밀성에 대한 비판적 검토"^[21]와 Libreswan 프로젝트의 폴 워터스가 쓴 2015년 기사 "VPN의 66%는 실제로 깨지지 않았다"에서 반박되었다.^[22]

또한, 여러 보안 구성을 협상할 수 있도록 허용하는 IPsec VPN 설정은 IKEv1과 IKEv2 모두에서 제안된 구성들 사이의 중간자 공격(MITM)을 이용한 다운그레이드 공격에 취약할 수 있다.^[23] 이러한 공격은 더 엄격한 보안 구성을 사용하고, 여러 서비스 접근 지점에 클라이언트 시스템을 신중하게 분리함으로써 완화할 수 있다.

IKE 표준의 두 버전(IKEv1, IKEv2) 모두 낮은 엔트로피(추측하기 쉬운) 암호를 사용하면 오프라인 사전 공격에 취약하다. 특히 IKEv1의 경우, 메인 모드와 공격적인 모드 모두 이 취약점의 영향을 받는다.^[24][25][26]

참조

_[1] 문서 The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
_[2] 간행물 RFC 3129: Requirements for Kerberized Internet Negotiation of Keys http://tools.ietf.or[...] Internet Engineering Task Force 2001-06
_[3] 간행물 RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE) http://tools.ietf.or[...] Internet Engineering Task Force 2001-06
_[4] 간행물 The Internet IP Security Domain of Interpretation for ISAKMP
_[5] 간행물 Internet Security Association and Key Management Protocol (ISAKMP)
_[6] 간행물 The Internet Key Exchange (IKE)
_[7] 간행물 Internet Key Exchange (IKEv2) Protocol 2005-12
_[8] 간행물 IKEv2 Clarifications and Implementation Guidelines 2006-10
_[9] 간행물 Internet Key Exchange (IKEv2) Protocol 2010-09
_[10] 문서 "RFC 2409 The Internet Key Exchange (IKE)" Internet Engineering Task Force (IETF)
_[11] 문서 "RFC 2409 The Internet Key Exchange (IKE)" Internet Engineering Task Force (IETF)
_[12] 문서 "RFC 2409 The Internet Key Exchange (IKE)" Internet Engineering Task Force (IETF)
_[13] 문서 "RFC 4306 Internet Key Exchange (IKEv2) Protocol" Internet Engineering Task Force (IETF)
_[14] 문서 "RFC 4306: Internet Key Exchange (IKEv2) Protocol" Internet Engineering Task Force (IETF)
_[15] 웹사이트 Internet Key Exchange: Internet Protocol Security (IPsec): Technet https://technet.micr[...]
_[16] 웹사이트 Using IPSec in Windows 2000 and XP, Part 1 http://www.securityf[...] 2009-12-24
_[17] 웹사이트 OpenIKEv2 https://github.com/O[...] 2023-06-21
_[18] 웹사이트 iked(8) - OpenBSD manual pages http://man.openbsd.o[...] 2023-06-21
_[19] 간행물 Fielded Capability: End-to-end VPN SPIN9 Design Review http://www.spiegel.d[...] NSA via 'Der Spiegel'
_[20] 학회 Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice https://weakdh.org/i[...] 2015-10
_[21] 웹사이트 Critical Review of Imperfect Forward Secrecy http://www.wisdom.we[...] 2015-10
_[22] 웹사이트 66% of VPN's are not in fact broken https://nohats.ca/wo[...] 2015-10
_[23] 웹사이트 Downgrade Resilience in Key-Exchange Protocols https://eprint.iacr.[...] 2016-01
_[24] 웹사이트 Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets http://skysrv.pha.jh[...] 1999-10-02
_[25] 웹사이트 Great Cipher, But Where Did You Get That Key http://blogs.cisco.c[...] 2011-07-05
_[26] 서적 The Dangers of Key Reuse: Practical Attacks on IPsec IKE https://www.usenix.o[...] 2018-08
_[27] 문서 The Internet Key Exchange (IKE), RFC 2409, §1 Abstract