The Cable Guy인증된 인터넷 프로토콜

Joseph Davies

이 칼럼의 일부에서는 Windows Server 2008의 시험판 버전을 다룹니다. 이에 대한 자세한 내용은 변경될 수 있습니다.

Windows Vista 및 Windows Server 2008(현재 베타 테스트 중)에서는 AuthIP(인증된 인터넷 프로토콜) 및 IKE(인터넷 키 교환) 프로토콜의 향상된 버전을 모두 지원합니다. AuthIP와 IKE는 모두 키 자료를 확인하고 IPSec(인터넷 프로토콜 보안)을 사용하여 보호되는 통신을 위한 보안 매개 변수를 협상하는 데 사용되는

프로토콜입니다. AuthIP에서는 다양한 구성에서의 단순화된 IPsec 정책 구성 및 유지 관리 기능을 제공하며 IPsec 피어 인증을 위한 추가적인 유연성을 제공합니다. 이 기사에서는 AuthIP 프로토콜을 자세히 설명하고 AuthIP와 IKE를 모두 지원하거나 IKE만 지원하는 IPsec 피어 간의 공존 동작에 대해 설명합니다.

IKE 개요

협상 예

공존 동작의 이해를 돕기 위해 IPsec 보호 협상을 시도할 때 Windows Vista와 Windows XP 기반 IPsec 피어 간에 발생하는 동작을 살펴보겠습니다.

예 1: 요청 모드에 있는 두 Windows Vista 기반 IPsec 피어

이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이며 응답자에서 Windows Vista(피어 2)가 실행 중입니다. 두 피어 모두 인바운드 및 아웃바운드 통신에 대해 요청 모드로 구성되어 있습니다. 요청 모드에서 IPsec 피어는 IPsec 보호를 요청하지만 이 기능을 필요로 하지는 않습니다. 교환되는 메시지는 다음과 같습니다.

  1. 피어 1이 일반 텍스트 TCP 동기화(SYN) 세그먼트를 보내 피어 2와의 TCP 연결을 초기화합니다.
  2. 피어 2가 TCP SYN-ACK(승인) 세그먼트를 보냅니다.
  3. 피어 1이 TCP ACK 세그먼트를 보냅니다.
  4. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화합니다.
  5. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  6. 피어 2가 AuthIP 기반 ISAKMP 메시지로 응답하여 AuthIP 주 모드 협상을 계속합니다.
  7. 피어 1과 2가 AuthIP 주 모드, 빠른 모드 및 확장 모드(선택 사항) 협상을 완료합니다.
  8. 이제 TCP 연결을 통해 전송되는 이후 세그먼트는 IPsec으로 보호됩니다.

메시지 1 - 5의 정확한 순서는 네트워크 지연에 따라 달라집니다. 이 기사에서 설명하는 예는 TCP 핸드셰이크(메시지 1 - 3)가 완료된 후에 피어 1에서 초기 ISAKMP 메시지(메시지 4 - 5)를 보낼 수 있는 지연이 매우 낮은 네트워크에 해당합니다. 지연이 높은 네트워크에서는 피어 1이 메시지 교환의 처음 세 메시지로 일반 텍스트 TCP SYN 세그먼트, AuthIP 기반 ISAKMP 메시지, IKE 기반 ISAKMP 메시지를 보내는 경우를 볼 수 있습니다.

예 2: 요청 모드의 Windows Vista 기반 IPsec 피어 및 요청 모드의 Windows XP 기반 IPsec 피어

이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이며 응답자에서 Windows XP(피어 2)가 실행 중입니다. 두 피어 모두 인바운드 및 아웃바운드 통신에 대해 요청 모드로 구성되어 있습니다. 교환되는 메시지는 다음과 같습니다.

  1. 피어 1이 일반 텍스트 TCP SYN 세그먼트를 보내 피어 2와의 TCP 연결을 초기화합니다.
  2. 피어 2가 TCP SYN-ACK 세그먼트를 보냅니다.
  3. 피어 1이 TCP ACK 세그먼트를 보냅니다.
  4. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화합니다.
  5. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  6. 피어 2가 IKE 기반 ISAKMP 메시지로 응답하여 IKE 주 모드 협상을 계속합니다.
  7. 피어 1과 2가 IKE 주 모드 및 빠른 모드 협상을 완료합니다.
  8. 이제 TCP 연결을 통해 전송되는 이후 세그먼트는 IPsec으로 보호됩니다.

예 3: 요청 모드의 Windows Vista 기반 IPsec 피어 및 필요 모드의 Windows XP 기반 IPsec 피어

이 예에서는 Windows Vista 기반 IPsec 피어(피어 1)가 초기자이고 응답자에서 Windows XP(피어 2)가 실행 중입니다. 피어 1은 아웃바운드 통신에 대해 요청 모드로 구성되어 있으며 피어 2는 인바운드 통신에 대해 필요 모드로 구성되어 있습니다. 필요 모드에서 IPsec 피어는 IPsec 보호를 필요로 하며 보호되지 않은 패킷은 자동으로 버립니다. 교환되는 메시지는 다음과 같습니다.

  1. 피어 1이 일반 텍스트 TCP SYN 세그먼트를 보내 TCP 연결을 초기화하나 피어 2에서 이를 자동으로 버립니다.
  2. 피어 1이 AuthIP 기반 ISAKMP 메시지를 보내 AuthIP 주 모드 협상을 초기화하나 피어 2에서 이를 자동으로 버립니다.
  3. 피어 1이 IKE 기반 ISAKMP 메시지를 보내 IKE 주 모드 협상을 초기화합니다.
  4. 피어 2가 IKE 기반 ISAKMP 메시지로 응답하여 IKE 주 모드 협상을 계속합니다.
  5. 피어 1과 피어 2가 IKE 주 모드 및 빠른 모드 협상을 완료합니다.
  6. 피어 1이 TCP SYN 세그먼트(IPsec으로 보호됨)를 다시 전송합니다.
  7. 피어 2가 TCP SYN-ACK 세그먼트(IPsec으로 보호됨)를 보냅니다.
  8. 피어 1이 TCP ACK 세그먼트(IPsec으로 보호됨)를 보냅니다.

IKE는 IPsec SA(보안 연결)를 설정하기 위한 메커니즘을 정의하는 RFC 2409(ietf.org/rfc/rfc2409.txt)에 정의된 인터넷 표준입니다. SA는 보안 서비스를 정의하는 상호 협의 가능한 정책과 키 및 IPsec 피어 간의 통신을 보호하는 데 도움이 되는 메커니즘의 조합입니다. 특히, IKE는 RFC 2408의 ISAKMP(인터넷 보안 연결 및 키 관리 프로토콜)와 Oakley Key Determination Protocol(RFC 2412)의 조합하며 통신을 보호하기 위한 비밀 키 자료를 생성하는 데 Oakley Key Determination Protocol을 사용합니다.

IKE는 ISAKMP를 사용하여 SA를 협상합니다. ISAKMP에는 피어를 식별 및 인증하고, SA를 관리하고, 키 자료를 교환하는 기능이 있습니다. ISAKMP는 특정 키 교환 프로토콜, 암호화 및 무결성 알고리즘, 인증 방법과 독립적으로 보호된 통신을 협상하기 위한 프레임워크입니다.

IPsec 피어에서는 IKE를 사용하여 주 모드 및 빠른 모드 협상을 수행합니다. 주 모드 협상에서는 보안 협상을 보호하는 ISAKMP SA를 만듭니다. 주 모드 협상 도중 초기자와 응답자는 ISAKMP SA에 대한 암호화와 해싱 알고리즘을 협상하고, 키 확인 자료를 교환하고, 서로를 식별하고 인증하기 위해 일련의 ISAKMP 메시지를 교환합니다.

빠른 모드 협상 단계에서는 두 IPsec 피어 사이에서 전송되는 데이터를 보호하는 두 IPsec SA(인바운드 데이터를 위한 SA와 아웃바운드 데이터를 위한 SA)가 생성됩니다. 빠른 모드 협상 도중 초기자와 응답자는 일련의 암호화된 ISAKMP 메시지를 교환하여 인바운드 및 아웃바운드 IPsec SA 모두를 위한 암호화 및 해싱 알고리즘을 협상합니다.

IKE 기반 주 모드 및 빠른 모드 협상에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0602.mspx의 "IPsec 보안 연결을 위한 IKE 협상"을 참조하십시오.

AuthIP 개요

AuthIP는 사용자 기반 인증, 여러 자격 증명을 사용한 인증, 향상된 인증 방법 협상 및 비대칭 인증을 지원함으로써 추가적인 유연성을 제공하는 향상된 버전의 IKE입니다. IKE와 마찬가지로 AuthIP는 주 모드 및 빠른 모드 협상을 지원합니다. 또한 AuthIP는 IPsec 피어 협상의 일부로 2차 인증을 수행할 수 있는 확장 모드를 지원합니다. 선택 사항인 확장 모드는 여러 인증에 사용할 수 있습니다. 예를 들어 확장 모드를 사용하면 별도의 컴퓨터 기반 및 사용자 기반 인증을 수행할 수 있습니다.

다중 인증 지원은 NAP(네트워크 액세스 보호) 플랫폼에 대한 IPsec 적용 작업의 일환입니다. 여기서 IPsec 피어는 컴퓨터 자격 증명을 사용하여 인증하며 상태 인증서를 사용하여 시스템 상태 요구 사항을 준수함을 입증합니다. 네트워크 액세스 보호에 대한 자세한 내용은 microsoft.com/nap를 참조하십시오. 또한 AuthIP의 기능에 대한 자세한 내용은 microsoft.com/technet/community/columns/cableguy/cg0806.mspx의 "Windows Vista의 AuthIP"를 참조하십시오.

AuthIP 메시지

IKE와 AuthIP 모두 ISAKMP를 키 교환 및 SA 협상 프로토콜로 사용합니다. ISAKMP 메시지는 UDP(User Datagram Protocol)를 통해 전송되며 ISAKMP 헤더와 하나 이상의 ISAKMP 페이로드로 구성됩니다. ISAKMP 헤더에는 메시지 유형을 포함한 메시지 관련 정보가 포함됩니다. 그림 1에는 ISAKMP 헤더의 형식이 나와 있습니다.

그림 1 ISAKMP 헤더의 형식

그림 1** ISAKMP 헤더의 형식 **

ISAKMP 헤더에서 초기자 쿠키 및 응답자 쿠키는 IPsec 피어가 선택한 0이 아닌 임의의 숫자로 설정됩니다. 다음 페이로드 필드는 ISAKMP 헤더 이외의 ISAKMP 메시지의 첫 번째 페이로드를 나타냅니다. RFC 2408에 다음 페이로드 필드의 정의된 값이 나열되어 있습니다. 페이로드 유형 128-255는 내부용으로 예약되어 있습니다. 주 버전 및 부 버전 필드는 ISAKMP 메시지를 전송하는 IPsec 피어의 ISAKMP 버전을 나타냅니다. IKE 및 AuthIP의 경우 주 버전은 1이고, 부 버전은 0입니다.

교환 유형 필드는 수행되는 ISAKMP 교환의 유형을 나타냅니다. 교환 유형에 따라 ISAKMP 페이로드의 구조와 순서가 결정됩니다. RFC 2408에 교환 유형 필드의 값이 정의되어 있습니다. 교환 유형 128-255는 내부용으로 예약되어 있습니다.

플래그 필드에는 RFC 2408에 정의된 세 개의 플래그가 있습니다. 순위가 낮은 비트(비트 0)는 ISAKMP 페이로드가 암호화되었는지(1로 설정된 경우) 또는 암호화되지 않았는지를(0으로 설정된 경우) 나타내는 암호화 비트입니다. 암호화는 ISAKMP SA에 대해 협상된 알고리즘을 사용하여 수행되며, 이러한 알고리즘은 초기자 쿠키 및 응답자 쿠키 필드의 조합으로 식별됩니다. 다음으로 순위가 낮은 비트(비트 1)는 커밋 비트로, 키 교환이 동기화되었는지(1로 설정된 경우) 또는 동기화되지 않았는지를(0으로 설정된 경우) 나타냅니다. 커밋 비트는 암호화된 데이터가 전송되기 전에 SA가 협상을 완료하도록 하는 데 사용됩니다. 다음으로 순위가 낮은 비트(비트 2)는 인증만 수행 비트로, 메시지에 정보 교환 유형의 전체 알림 페이지로드가 포함되었는지(1로 설정된 경우) 또는 포함되지 않았는지를(0으로 설정된 경우) 나타내고, 인증되었으나 암호화되지 않았음을 나타내는 데 사용됩니다.

메시지 ID 필드에는 메시지에 대한 고유 ID가 포함됩니다. 메시지 ID는 두 IPsec 피어가 동시에 IPsec SA를 설정하려고 할 때 충돌을 방지하는 데 사용됩니다. 길이 필드는 전체 ISAKMP 메시지의 길이를 나타냅니다.

IKE의 경우 ISAKMP 메시지에는 일련의 ISAKMP 페이로드가 포함됩니다. 첫 번째 페이로드는 ISAKMP 헤더의 다음 페이로드 필드로 나타냅니다. 각 ISAKMP 페이로드에는 다음 페이로드를 나타내는 자체 다음 페이로드 필드가 있습니다. 마지막 페이로드의 다음 페이로드 필드는 0으로 설정됩니다. 그림 2에는 IKE 메시지의 형식이 나와 있습니다.

그림 2 IKE 메시지의 형식

그림 2** IKE 메시지의 형식 **

AuthIP는 ISAKMP 헤더의 교환 유형 필드에서 교환 유형이 243(주 모드), 244(빠른 모드), 245(확장 모드) 및 246(알림)인 ISAKMP 메시지를 사용합니다. AuthIP 기반 ISAKMP 메시지의 중요한 차이점은 이 메시지에는 하나의 ISAKMP 페이로드(암호화 페이로드 또는 알림 페이로드)만 포함된다는 점입니다. 암호화 페이로드에는 주 모드, 빠른 모드 또는 확장 모드 협상에 사용되는 포함된 페이로드가 있습니다. 암호화 페이로드에는 ISAKMP 헤더의 플래그 필드에 지정된 암호화 비트에 따라 일반 텍스트 또는 암호화된 페이로드 집합이 포함될 수 있습니다. 그림 3에는 암호화 페이로드가 포함된 AuthIP 메시지의 형식이 나와 있습니다.

그림 3 암호화 페이로드가 포함된 AuthIP 메시지의 형식

그림 3** 암호화 페이로드가 포함된 AuthIP 메시지의 형식 **

AuthIP 및 IKE 공존

Windows Vista® 및 Windows Server® 2008에서는 IKE와 AuthIP를 모두 지원합니다. 하지만 Windows® XP와 Windows Server 2003에서는 IKE만 지원합니다. AuthIP와 IKE를 모두 지원하며 AuthIP와 IKE를 모두 사용하는 연결 보안 정책이 있는 초기 IPsec 피어는 응답 IPsec 피어가 AuthIP 또는 IKE 중 무엇을 지원하는지 확인해야 합니다. 그런 다음 IPsec 보호 협상에 가장 적합한 프로토콜을 사용해야 하며 IKE보다 AuthIP를 사용하는 것이 좋습니다.

응답 IPsec 피어의 협상 프로토콜을 확인하기 위해 AuthIP와 IKE를 모두 사용하는 초기 IPsec 피어는 동시에 다음 메시지를 보냅니다.

  • 메시지 1—주 모드 협상을 초기화하는 AuthIP 메시지
  • 메시지 2—주 모드 협상을 초기화하는 IKE 메시지

응답 노드가 AuthIP를 지원하는 경우에는 메시지 1에 주 모드 협상을 계속하는 AuthIP 메시지로 응답하고 메시지 2는 자동으로 버립니다. AuthIP를 지원하지 않는 응답 노드의 경우 메시지 1에 포함된 교환 유형 필드에 지원하지 않는 값이 있기 때문에 이 메시지를 자동으로 버리고 메시지 2에 응답합니다.

메시지 1이 네트워크에서 버려지거나 메시지 2 다음에 도착하는 경우 Windows Vista 또는 Windows Server 2008이 실행 중인 두 IPsec 피어 간의 IKE 기반 협상이 수행되는 현상을 방지하기 위해 Windows Vista 또는 Windows Server 2008이 실행 중인 IPsec 피어에서는 메시지 2와 함께 AuthIP 지원 공급업체 ID ISAKMP 페이로드를 보냅니다. AuthIP 지원 공급업체 ID 페이로드는 IPsec 피어가 AuthIP를 지원함을 나타냅니다.

따라서 Windows Vista 또는 Windows Server 2008이 실행 중인 IPsec 피어가 AuthIP 지원 공급업체 ID 페이로드와 함께 메시지 2를 수신하면 초기 IPsec 피어가 메시지 1과 2를 다시 전송할 때까지 기다린 후 메시지 1에 응답합니다.

초기 IPsec 피어는 응답을 수신하거나 시간이 만료될 때까지 메시지 1과 2를 계속 다시 전송합니다. 초기자는 응답을 수신하면 응답의 ISAKMP 헤더에서 응답자가 지원하는 교환 유형을 확인합니다. 교환 유형이 243(AuthIP 기반 주 모드 협상에 대한 교환 유형)으로 설정된 경우 응답자는 AuthIP를 지원하며 교환 유형이 2(ID 보호 및 IKE 기반 주 모드 협상에 대한 교환 유형)로 설정된 경우 응답자는 IKE를 지원합니다.

초기자는 응답에 따라 AuthIP 주 모드 협상의 경우 다음 AuthIP 메시지 또는 IKE 주 모드 협상의 경우 다음 IKE 메시지로 응답합니다. IPsec 피어는 SA의 수명 동안 ISAKMP SA를 협상하는 데 사용된 것과 같은 프로토콜을 사용해야 합니다.

Joseph Davies는 Microsoft의 테크니컬 라이터이자 Microsoft.com/technet/community/columns/cableguy의 월간 온라인 TechNet Cable Guy 칼럼의 저자입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..