인터넷 키 교환

Internet Key Exchange

컴퓨팅에서 인터넷키 익스체인지(IKE, 버전에 따라서는 IKEv1 또는 IKEv2)는 IPsec 프로토콜 스위트에서 Security Association(SA; 보안 어소시에이션)을 설정하기 위해 사용되는 프로토콜입니다.IKE는 Oakley 프로토콜과 ISAKMP를 [1]기반으로 구축됩니다.IKE는 인증에 X.509 증명서를 사용합니다.DNSEC와 Diffie를 사용하여 사전 공유 또는 배포됩니다.Hellman 키 교환을 통해 암호화 키가 [2][3]파생되는 공유 세션비밀을 설정합니다.또한 접속하는 모든 피어에 대한 보안 정책을 수동으로 [2]유지해야 합니다.

역사

Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)는 1998년 11월에 RFC 2407, RFC 2408 및 RFC 2409로 알려진 일련의 자료(Request for Comments)에서 IKE를 처음 정의했습니다.

  • RFC2407에서는 ISAKMP의 [4]Internet IP Security Domain of Interpretation이 정의되어 있습니다.
  • RFC 2408에서는 Internet Security Association and Key Management Protocol(ISAKMP)이 정의되어 있습니다.[5]
  • RFC 2409에서는 Internet Key Exchange(IKE; 인터넷키 익스체인지)가 정의되어 있습니다.[6]

RFC 4306은 2005년 [7]12월에 IKE를 버전2(IKEv2)로 갱신했습니다.RFC 4718은 2006년 [8]10월에 몇 가지 미해결 세부사항을 명확히 했다.RFC 5996에서는 이 2개의 문서와 더불어 2010년9월에 발행된 갱신된 IKEv2에 [9]대한 설명이 추가되어 있습니다.이후 업데이트로 2014년 10월에 RFC 7296으로 발행된 인터넷 표준으로 문서가 업그레이드되었습니다.

IETF의 모조직인 Internet Society(ISOC; 인터넷 협회)는 인터넷 커뮤니티에서 자유롭게 이용할 수 있는 이러한 표준의 저작권을 유지하고 있습니다.

아키텍처

대부분의 IPsec 실장은 사용자 공간에서 실행되는IKE 데몬과 실제 IP 패킷을 처리하는 커널 내의 IPsec 스택으로 구성됩니다.

사용자 공간 데몬은 필요에 따라 IPsec 엔드포인트 주소, 키 및 인증서 등의 구성 정보를 포함하는 대용량 스토리지에 쉽게 액세스할 수 있습니다.반면 커널 모듈은 최소한의 오버헤드로 효율적으로 패킷을 처리할 수 있습니다.이것은 퍼포먼스상의 이유로 중요합니다.

IKE 프로토콜은 보통 포트 500에서 UDP 패킷을 사용하며, 일반적으로 양쪽에서 ISAKMP Security Association(SA; 보안 어소시에이션)을 작성하려면 4~6개의 패킷과 2~3개의 라운드 트립이 필요합니다.다음으로 네고시에이트된 키 자료가 IPsec 스택에 주어집니다.예를 들어, 이것은 AES 키, 보호되는 IP 엔드 포인트 및 포트를 식별하는 정보, 작성된IPsec 터널의 타입을 나타냅니다.다음으로 IPsec 스택은 필요에 따라 적절한 경우 관련 IP 패킷을 대행 수신하고 암호화/복호화를 수행합니다.구현은 패킷 대행 수신 방법에 따라 달라집니다.예를 들어 가상 디바이스를 사용하는 경우도 있고 방화벽에서 슬라이스를 꺼내는 경우도 있습니다.

IKEv1은 단계1과 단계2의 [10]2가지 단계로 구성됩니다.

IKEv1 단계

IKE 단계1의 목적은 Diffie를 사용하여 안전한 인증 통신 채널을 확립하는 것입니다.IKE 통신을 암호화하기 위한 공유 개인 키를 생성하는 Hellman 키 교환 알고리즘.이 네고시에이션에 의해, 1개의 쌍방향 ISAKMP 시큐러티 [11]어소시에이션이 확립됩니다.인증은 사전 공유 키(공유 비밀 키), 서명 또는 공개 키 암호화를 사용하여 [12]실행할 수 있습니다.단계 1은 메인모드 또는 어그레시브 모드 중 하나로 동작합니다.메인 모드는 피어를 암호화하여 피어 ID와 공유 키의 해시를 보호합니다.어그레시브 모드는 보호하지 않습니다.[10]

IKE 단계2 중 IKE 피어는 단계1에서 확립된 시큐어 채널을 사용하여 IPsec 등의 다른 서비스를 대신하여 Security Associations를 네고시에이트합니다.네고시에이션에 의해, 적어도 2개의 단방향 시큐러티 어소시에이션이 발생합니다(1개는 착신, 1개는 발신).[13]단계 2는 빠른 [10]모드에서만 작동합니다.

IKE에 관한 문제

원래 IKE에는 다수의 설정 옵션이 있었지만 보편적으로 구현되어 있는 기존의 디폴트케이스 자동 네고시에이션을 위한 일반적인 기능은 없었습니다.그 결과, IKE의 양쪽은 작성하는 보안 어소시에이션의 타입에 대해서, 옵션 마다 정확하게 합의할 필요가 있었습니다.그렇지 않으면 접속을 확립할 수 없었습니다.많은 구현에서 진단 출력을 생성하는 기능이 있다면 디버깅 출력을 해석하기 어렵다는 사실에서 더 많은 문제가 발생했습니다.

그 IKE 규격 해석의 중요한 정도 디자인의 결함에, 다른 IKE 구현에 옵션의 많은 조합에 대한 합의된 보안 협회 만들 수 있는 것이 아니고(point[표창 필요한]에 Dead-Peer-Detection 사건)국경과 가까운 하지만 정확하게 그들은 migh 구성되어 열려 있었다.teithe에 나타납니다r end.

IKEv2에 의한 개량점

IKEv2 프로토콜은 2005년 RFC 4306의 부록 A에 설명되어 있습니다.다음과 같은 문제가 해결되었습니다.

  • 코멘트 요구(RFC) 감소:IKE의 사양은 적어도3개의 RFC에서 다루어졌습니다.일반적으로 사용되고 있는NAT 트래버설 및 기타 확장기능을 고려하는 경우에는 더 커집니다.IKEv2 에서는, 이것들을 1 개의 RFC 에 조합해, NAT 트래버설(Network Address Translation(NAT; 네트워크주소 변환) 및 방화벽트래버설의 일반적인 서포트를 향상시킵니다.
  • 표준 모빌리티 지원:[rfc:4555 Mobility and Multihoming Protocol](MOBIKE)(「IPSec」도 참조)라는 이름의 IKEv2 의 표준 확장이 있어, 모빌리티와 멀티호밍, 및 Encapsulating Security Payload(ESP)를 서포트하기 위해서 사용됩니다.이 확장자를 사용하면 모바일 사용자 및 멀티홈 사용자가 IKEv2 및 IPsec을 사용할 수 있습니다.
  • NAT 통과:User Datagram Protocol(UDP 포트 4500)에서 IKE 및 ESP를 캡슐화하면 이러한 프로토콜이 [14]NAT을 실행하는 디바이스 또는 방화벽을 통과할 수 있습니다.
  • Stream Control Transmission Protocol(SCTP) 지원: IKEv2에서는 인터넷 텔레포니프로토콜 Voice over IP(VoIP)에서 사용되는SCTP 프로토콜을 사용할 수 있습니다.
  • 단순한 메시지 교환: IKEv2에는 4개의 메시지로 이루어진 첫 번째 교환 메커니즘이1개 있습니다.여기서 IKE는 8개의 서로 다른 초기 교환 메커니즘을 제공합니다.각 메커니즘에는 약간의 장점과 단점이 있습니다.
  • 암호 메커니즘 감소: IKEv2는 IPsec ESP가 IPsec 패킷 보호에 사용하는 것과 매우 유사한 암호화 메커니즘을 사용하여 패킷을 보호합니다.이것에 의해, 공통 기준과 FIPS 140-2(Federal Information Processing Standard)의 실장 및 인증이 간단하게 되었습니다.이것에 의해, 각 암호화 실장은 개별적으로 검증할 필요가 있습니다.
  • 신뢰성과 상태 관리: IKEv2는 시퀀스 번호와 확인 응답을 사용하여 신뢰성을 제공하고 오류 처리 로지스틱스와 공유 상태 관리를 요구합니다.IKE는 이러한 신뢰성 측정이 부족하기 때문에 데드 상태가 될 수 있습니다.이 경우, 쌍방이 상대방이 액션을 개시할 것으로 예상되고 있습니다만, 이 액션은 실행되지 않습니다.작업 환경(예: Dead-Peer-Detection)은 개발되었지만 표준화되지는 않았습니다.즉, 서로 다른 회피책의 구현이 항상 호환성이 있는 것은 아닙니다.
  • Denial of Service(DoS; 서비스 거부) 공격 복원력: IKEv2는 요청자가 실제로 존재하는지 여부를 판단할 때까지 많은 처리를 수행하지 않습니다.이를 통해 스푸핑된 장소에서 대량의 고가의 암호화 처리를 실행하는 IKE에 의해 발생하는 DoS 문제에 대처했습니다.
호스트 A의 SPI(Security Parameter Index)가 다음과 같은 경우A호스트 B의 SPI는B시나리오는 다음과 같습니다.
호스트 A ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SAr1, ker, Nr
HostB(응답측)에서 대량의 하프 오픈 IKE 접속이 발생하고 있는 경우, HostB는 다음의 암호화되지 않은 응답 메시지를 송신합니다.IKE_SA_INIT호스트 A(이니시에이터)에 대한 알림 메시지 유형COOKIE호스트 A가 호스트 A를 통해IKE_SA_INIT호스트 B 에의 통지 페이로드내의 cookie 값을 가지는 요구.이것은, 발신측이 응답측으로부터의 IKE 응답을 실제로 처리할 수 있는 것을 보증하기 위해서입니다.

프로토콜 확장

IETF ipsecme 작업 그룹은 IKEv2 프로토콜을 현대화하고 대량 생산 환경에 더 잘 적응시키는 것을 목표로 많은 확장을 표준화했습니다.이러한 확장에는 다음이 포함됩니다.

  • IKE 세션 재개: IKE 셋업 프로세스 전체를 거치지 않고 장애가 발생한 후 IKE/IPSec 세션을 재개하는 기능(RFC 5723)
  • IKE 리다이렉트: 착신 IKE 요구의 리다이렉트.여러 IKE 엔드포인트(RFC 5685)간에 심플한 로드밸런싱을 가능하게 합니다.
  • IPsec 트래픽 가시성: 인증되었지만 암호화되지 않은ESP 패킷의 특별한 태그 부착. 미들박스(침입검출시스템 등)가 플로우 분석을 용이하게 하는 것을 목적으로 합니다(RFC 5840).
  • 상호 EAP 인증: 양쪽 IKE 피어에서 EAP 전용(증명서 없음) 인증 지원.목표는 최신 패스워드 기반 인증방식을 사용하는 것입니다(RFC 5998).
  • 퀵 크래시 검출: IKE 피어가 반대쪽 피어가 크래시 한 것을 검출할 때까지의 시간을 최소한으로 억제합니다(RFC 6290).
  • 고가용성 확장: IPsec 엔드포인트 클러스터와 피어 간의 IKE/IPSec 레벨의 프로토콜 동기화를 개선하여 페일오버 이벤트 후 연결이 끊어질 가능성을 줄입니다(RFC 6311).

실장

IKE는, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, 및 Windows Server 2008 [15]에서의 IPsec 실장의 일부로서 서포트되고 있습니다.ISAKMP/IKE 실장은 시스코와 Microsoft가 [16]공동으로 개발했습니다.

Microsoft Windows 7 및 Windows Server 2008 R2 는, VPN 재접속 기능(일명 Agile VPN)을 개입시켜, IKEv2(RFC 7296)와 MOBIKE(RFC 4555)를 부분적으로 서포트하고 있습니다.

관련된 IKE 기능을 갖춘 IPsec에는 몇 가지 오픈소스 실장이 있습니다.Linux, Libreswan, Openswan 및 strongSwan 구현에서는 KLIPS 또는 XFRM/NETKE 커널 기반 IPsec 스택을 구성할 수 있는 IKE 데몬이 제공됩니다.XFRM/NETKE는 버전 2.6에서 사용할 수 있는 Linux 네이티브 IPsec 구현입니다.

Berkeley Software Distributions에는 IPsec 구현과 IKE 데몬, 그리고 가장 중요한 암호화 프레임워크(OpenBSD Cryptographic Framework, OCF)도 있어 암호화 액셀러레이터를 훨씬 쉽게 지원할 수 있습니다.OCF는 최근 Linux로 이식되었습니다.

다수의 네트워크 기기 벤더가 독자적인 IKE 데몬(및 IPsec 실장)을 작성하거나 서로 스택에 라이선스를 부여하고 있습니다.

IKEv2의 실장은 다수 있어 IPsec 인증 및 상호 운용성 테스트를 취급하는 기업 중 일부는 테스트를 위한 워크숍과 IKEv2 테스트에 대처하기 위한 갱신된 인증 요건을 개최하기 시작했습니다.

IKEv2의 다음 오픈소스 실장을 현재 사용할 수 있습니다.

취약성

Der Spiegel에 의해 공개된 누전된 NSA 프레젠테이션은 IKE가 ISAKMP와 [17]마찬가지로 IPsec 트래픽 복호화에 불분명한 방법으로 악용되고 있음을 나타냅니다.Logjam 공격 상태를 발견한 연구진은 1024비트 Diffie를 해제했습니다.Hellman 그룹은 VPN 서버의 66%, 상위 100만 HTTPS 도메인의 18%, SSH 서버의 26%를 파괴할 수 있습니다.이러한 현상은 [18]유출과 일치한다고 연구자들은 주장합니다.이 주장은 Eyal Ronen과 Adi Shamir에 의해 논문 "Critical Review of Implete Forward Secrecy"에서, 그리고 Libreswan의 Paul Wouters에 의해 "VPN의 66%가 실제로 파손되지 않았습니다."라는 기사에서 반박되었습니다.

복수의 설정을 네고시에이트 할 수 있다IPsec VPN 설정에서는, 제공되는 설정간에, IKEv1 와 IKEv2 [21]의 양쪽 모두에서, MITM 베이스의 다운그레이드 공격의 대상이 됩니다.이는 클라이언트 시스템을 보다 엄격한 구성의 여러 서비스 액세스포인트로 신중하게 분리함으로써 회피할 수 있습니다.

양쪽 버전의 IKE 표준에서는 낮은 엔트로피 패스워드를 사용하면 오프라인 딕셔너리 공격에 취약합니다.이것은 IKEv1의 경우 메인 모드와 어그레시브 [22][23][24]모드에 적용됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Internet Key Exchange(IKE), RFC 2409, 1 Abstract
  2. ^ a b RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 1
  3. ^ RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE), Internet Engineering Task Force, June 2001, p. 5
  4. ^ The Internet IP Security Domain of Interpretation for ISAKMP. doi:10.17487/RFC2407. RFC 2407.
  5. ^ Internet Security Association and Key Management Protocol (ISAKMP). doi:10.17487/RFC2408. RFC 2408.
  6. ^ D. Harkins. The Internet Key Exchange (IKE). doi:10.17487/RFC2409. RFC 2409.
  7. ^ C. Kaufman (Microsoft) (December 2005). Internet Key Exchange (IKEv2) Protocol. doi:10.17487/RFC4306. RFC 4306.
  8. ^ Eronen, P.; Hoffman, P. (October 2006). IKEv2 Clarifications and Implementation Guidelines. doi:10.17487/RFC4718. RFC 4718.
  9. ^ Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (September 2010). Internet Key Exchange (IKEv2) Protocol. doi:10.17487/RFC5996. RFC 5996.
  10. ^ a b c "RFC 2409 인터넷 키 교환(IKE)", 인터넷 기술 특별 조사위원회(IETF), 페이지 5
  11. ^ "RFC 2409 인터넷 키 교환(IKE)", 인터넷 기술 특별 조사위원회(IETF), 페이지 6
  12. ^ "RFC 2409 인터넷 키 교환(IKE)", 인터넷 기술 특별 조사위원회(IETF), 페이지 10-16
  13. ^ "RFC 4306 Internet Key Exchange (IKEv2) Protocol", IETF (Internet Engineering Task Force), 페이지 11,33
  14. ^ "RFC 4306: IKEv2 프로토콜", 인터넷 기술 특별 조사위원회(IETF), 페이지 38-40
  15. ^ 인터넷 키 교환:IPsec(인터넷 프로토콜 보안):테크넷
  16. ^ Windows 2000 및 XP에서의 IPSec 사용, 파트 1
  17. ^ Fielded Capability: End-to-end VPN SPIN9 Design Review (PDF), NSA via 'Der Spiegel', p. 5
  18. ^ Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; VanderSloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (October 2015). Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (PDF). 22nd ACM Conference on Computer and Communications Security (CCS ’15). Denver. Retrieved 15 June 2016.
  19. ^ Ronen, Eyal; Shamir, Adi (October 2015). "Critical Review of Imperfect Forward Secrecy" (PDF). {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  20. ^ Wouters, Paul (October 2015). "66% of VPN's are not in fact broken".
  21. ^ Bhargavan, Karthikeyan; Brzuska, Christina; Fournet, Cédric; Kohlweiss, Markulf; Zanella-Béguelin, Santiago; Green, Matthew (January 2016). "Downgrade Resilience in Key-Exchange Protocols" (PDF).
  22. ^ Pliam, John (2 October 1999). "Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets". Johns Hopkins University. Archived from the original on 10 June 2002. Retrieved 5 February 2020.
  23. ^ McGrew, David (5 July 2011). "Great Cipher, But Where Did You Get That Key". Cisco Blog. Archived from the original on 9 July 2011. Retrieved 11 February 2020.
  24. ^ Felsch, Dennis (August 2018). The Dangers of Key Reuse: Practical Attacks on IPsec IKE. 27th USENIX Security Symposium. ISBN 9781939133045. Retrieved 11 February 2020.

외부 링크