КабельщикПротокол IP с проверкой подлинности

Джозеф Дэвис (Joseph Davies)

В некоторых частях этой статьи обсуждается предварительная версия Windows Server 2008. Эти детали в дальнейшем могут измениться.

Операционные системы Windows Vista и Windows Server 2008 (сейчас проходит этап бета-тестирования) поддерживают протокол IP с проверкой подлинности (AuthIP), улучшенную версию протокола IKE. Протоколы AuthIP и IKE используются для определения материала ключа и согласования параметров безопасности для связи, защищенной с помощью

протокола IPsec. AuthIP обеспечивает упрощенную поддержку и настройку политики IPsec во множестве конфигураций и предоставляет дополнительную гибкость для проверки подлинности узлов IPsec. В данной статье описывается протокол AuthIP и совместная работа узлов IPsec, поддерживающих AuthIP и IKE или только IKE.

Обзор протокола IKE

Примеры согласования

Для демонстрации совместной работы давайте посмотрим, что происходит между узлами IPsec под управлением Windows Vista и Windows XP при попытке согласования защиты IPsec.

Пример 1: два узла IPsec под управлением Windows Vista в режиме запроса

В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент также работает под управлением Windows Vista (Узел 2). Для обоих узлов установлен режим запроса для входящей и исходящей связи. В режиме запроса узел IPsec запрашивает защиту IPsec, но не требует ее. Узлы обмениваются следующими сообщениями.

1. Узел 1 отправляет сегмент TCP synchronize (SYN) открытым текстом, инициализируя подключение по TCP с Узлом 2.
2. Узел 2 отправляет сегмент TCP SYN-Acknowledgment (ACK).
3. Узел 1 отправляет сегмент ACK TCP.
4. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP.
5. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
6. Узел 2 отвечает сообщением ISAKMP на основе AuthIP, продолжая согласование основного режима AuthIP.
7. Узлы 1 и 2 завершают согласование основного, быстрого и расширенного (дополнительно) режимов AuthIP.
8. Последующие отправляемые через подключение по TCP сегменты защищены по протоколу IPsec.

Точный порядок сообщений 1 – 5 зависит от задержки сети. В этой статье описываются примеры для сети с очень маленькой задержкой, в которой подтверждение TCP (сообщения 1 – 3) завершается до отправки Узлом 1 первоначальных сообщений ISAKMP (сообщения 4 и 5). В сети с высокой задержкой узел 1 отправляет сегмент TCP SYN открытым текстом, сообщение ISAKMP на основе AuthIP, а затем сообщение ISAKMP на основе IKE как первые три сообщения процесса обмена сообщениями.

Пример 2: узел IPsec под управлением Windows Vista в режиме запроса и узел IPsec под управлением Windows XP в режиме запроса

В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент работает под управлением Windows XP (Узел 2). Для обоих узлов установлен режим запроса для входящей и исходящей связи. Узлы обмениваются следующими сообщениями.

1. Узел 1 отправляет сегмент SYN TCP открытым текстом, инициализируя подключение по TCP с Узлом 2.
2. Узел 2 отправляет сегмент SYN-ACK TCP.
3. Узел 1 отправляет сегмент ACK TCP.
4. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP.
5. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
6. Узел 2 отвечает сообщением ISAKMP на основе IKE, продолжая согласование основного режима IKE.
7. Узлы 1 и 2 завершают согласование основного и быстрого режимов IKE.
8. Последующие отправляемые через подключение TCP сегменты защищены по протоколу IPsec.

Пример 3: узел IPsec под управлением Windows Vista в режиме запроса и узел IPsec под управлением Windows XP в режиме требования

В этом примере узел IPsec под управлением Windows Vista (Узел 1) является инициатором, а респондент работает под управлением Windows XP (Узел 2). Для Узла 1 установлен режим запроса для исходящей связи, а для Узла 2 установлен режим требования для входящей связи. В режиме требования узел IPsec запрашивает защиту IPsec и отвергает незащищенные пакеты без уведомления. Узлы обмениваются следующими сообщениями.

1. Узел 1 отправляет сегмент SYN TCP в открытом тексте, инициируя подключение по TCP, которое Узел 2 отвергает без уведомления.
2. Узел 1 отправляет сообщение ISAKMP на основе AuthIP, инициируя согласование основного режима AuthIP, которое Узел 2 отвергает без уведомления.
3. Узел 1 отправляет сообщение ISAKMP на основе IKE, инициируя согласование основного режима IKE.
4. Узел 2 отвечает сообщением ISAKMP на основе IKE, продолжая согласование основного режима IKE.
5. Узлы 1 и 2 завершают согласование основного и быстрого режимов IKE.
6. Узел 1 пересылает сегмент TCP SYN (защищенный по протоколу IPsec).
7. Узел 2 отправляет сегмент TCP SYN-ACK (защищенный по протоколу IPsec).
8. Узел 1 отправляет сегмент TCP ACK (защищенный по протоколу IPsec).

IKE – это стандарт Интернета, определенный в RFC 2409 (ietf.org/rfc/rfc2409.txt) и определяющий механизм установления сопоставлений безопасности IPsec. Сопоставления безопасности – это взаимно согласовываемые политики и ключи, определяющие механизмы и службы обеспечения безопасности для защиты связи между узлами IPsec. В частности, IKE объединяет протокол ISAKMP (Internet Security Association and Key Management Protocol) в RFC 2408 и протокол Oakley Key Determination Protocol (RFC 2412). IKE использует протокол Oakley Key Determination для создания данных секретных ключей для защищенной связи.

IKE использует протокол ISAKMP для согласования сопоставлений безопасности. ISAKMP включает средства для определения и проверки подлинности узлов, управления сопоставлениями безопасности и обмена данными ключей. ISAKMP – это платформа для согласования защищенной связи, независимая от определенных протоколов обмена ключами, алгоритмов шифрования и целостности и методов проверки подлинности.

Узлы IPsec используют IKE для выполнения согласования основного и быстрого режимов. При согласовании основного режима создается сопоставление безопасности ISAKMP, защищающее согласования безопасности. Во время согласования основного режима инициатор и респондент обмениваются сериями сообщений ISAKMP для согласования алгоритмов шифрования и хеширования для сопоставления безопасности ISAKMP, обмена данными определения ключей и взаимной идентификации и проверки подлинности.

В фазе согласования быстрого режима создаются два сопоставления безопасности IPsec (одно для входящих данных, а второе для исходящих данных), защищающие данные, передаваемые между двумя узлами IPsec. Во время согласования быстрого режима инициатор и респондент обмениваются сериями зашифрованных сообщений ISAKMP для согласования алгоритмов шифрования и хеширования для входящих и исходящих сопоставлений безопасности IPsec.

Дополнительные сведения о согласовании основного и быстрого режимов на основе IKE приведены в статье «IKE Negotiation for IPsec Security Associations» (Согласование IKE для сопоставлений безопасности IPsec) по адресу microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Обзор AuthIP

AuthIP – это улучшенная версия IKE, предоставляющая дополнительную гибкость с поддержкой проверки подлинности на основе пользователей, проверки подлинности с множеством учетных данных, улучшенного согласования метода проверки подлинности и асимметричной проверки подлинности. Как и IKE, AuthIP поддерживает согласование основного и быстрого режимов. AuthIP также поддерживает расширенный режим, часть согласования узла IPsec, во время которого может быть выполнен второй цикл проверки подлинности. Дополнительный расширенный режим может использоваться для многократной проверки подлинности. Например, в расширенном режиме можно выполнить отдельную проверку подлинности на основе компьютера и отдельную проверку подлинности на основе пользователя.

Поддержка многократной проверки подлинности является частью использования IPsec для платформы защиты доступа к сети (NAP), в которой узлы IPsec выполняют проверку подлинности с учетными данными компьютера и также используют сертификат работоспособности для подтверждения соответствия требованиями исправности системы. Дополнительные сведения о защите доступа к сети приведены на веб-узле microsoft.com/nap. Дополнительные сведения о функциях AuthIP приведены в статье «AuthIP in Windows Vista» (AuthIP в Windows Vista) по адресу microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Сообщения AuthIP

IKE и AuthIP используют протокол ISAKMP в качестве протокола обмена ключами и согласования сопоставления безопасности. Сообщения ISAKMP отправляются по протоколу UDP (User Datagram Protocol) и состоят из заголовка ISAKMP и одного или нескольких воспроизводимых фрагментов ISAKMP. Заголовок ISAKMP содержит сведения о сообщении, включая его тип. На рис. 1 показан формат заголовка ISAKMP.

Рис. 1** Формат заголовка ISAKMP **

В заголовке ISAKMP для полей «Файлы «Cookie» инициатора» и «Файлы «Cookie» респондента» устанавливаются случайные числа, не равные нулю, выбранные узлами IPsec. В поле «Следующие полезные данные» указывается первые полезные данные сообщения ISAKMP, находящиеся сразу за заголовком ISAKMP. В списке RFC 2408 определяются значения поля «Следующие полезные данные». Типы полезных данных 128-255 зарезервированы для частного использования. В полях «Основная версия» и «Дополнительная версия» указываются версии ISAKMP на узле IPsec, отправляющем сообщение ISAKMP. Для IKE и AuthIP основная версия – 1, а дополнительная версия – 0.

В поле «Тип обмена» указывается тип выполняемого обмена ISAKMP. Тип обмена определяет структуру и порядок полезных данных ISAKMP. RFC 2408 определяет значения поля «Тип обмена». Типы обмена128-255 зарезервированы для частного использования.

В поле «Флаги» содержатся три флага, определенные в RFC 2408. Младший бит (бит 0) – это бит Encryption, обозначающий шифрование полезных данных ISAKMP (если установлено значение 1) или отсутствие шифрования (если установлено значение 0). Шифрование осуществляется с помощью алгоритма, согласованного для сопоставления безопасности ISAKMP, который определяется сочетанием полей «Файлы «cookie» инициатора» и «Файлы «cookie» респондента». Следующий младший бит (бит 1) – это бит Commit, обозначающий синхронизацию обмена ключами (если установлено значение 1) или отсутствие такой синхронизации (если установлено значение 0). Бит Commit используется для удостоверения выполнения согласования сопоставления безопасности до отправки зашифрованных данных. Следующий младший бит (бит 2) – это бит Authentication Only, используемый для обозначения того, что в сообщении содержатся (если установлено значение 1) или не содержатся (если установлено значение 0) все полезные данные извещения типа информационного обмена и выполнена проверка подлинности, но отсутствует шифрование.

В поле «Код сообщения» содержится уникальный идентификатор сообщения. Поле «Код сообщения» используется для предотвращения коллизий, когда оба узла IPsec одновременно пытаются установить сопоставление безопасности IPsec. В поле «Длина» указывается длина всего сообщения ISAKMP.

В случае IKE сообщение ISAKMP содержит ряд полезных данных ISAKMP. Первыми полезными данными, указанными в поле «Следующие полезные данные», является заголовок ISAKMP. Все полезные данные ISAKMP имеют собственные поля «Следующие полезные данные» для обозначения следующих полезных данных. Для поля «Следующие полезные данные» в последних полезных данных установлено значение 0. На рис. 2 показан формат сообщений IKE.

Рис. 2** Формат сообщений IKE **

AuthIP использует сообщения ISAKMP, для которых в поле «Тип обмена» заголовка ISAKMP установлены типы обмена 243 (основной режим), 244 (быстрый режим), 245 (расширенный режим) и 246 (уведомление). Важным отличием сообщений ISAKMP на основе AuthIP является то, что они содержат только один тип полезных данных ISAKMP: полезные данные уведомления или шифрования. Полезные данные шифрования содержат внедренные полезные данные, используемые для согласования основного, быстрого и расширенного режимов. Полезные данные шифрования могут содержать набор зашифрованных полезных данных или полезных данных в открытом тексте в зависимости от бита Encryption поля «Флаги» заголовка ISAKMP. На рис. 3 показан формат сообщений AuthIP с полезными данными шифрования.

Рис. 3** Формат сообщений AuthIP с полезными данными шифрования **

Совместное использование AuthIP и IKE

Операционные системы Windows Vista® и Windows Server® 2008 поддерживают как IKE, так и AuthIP. Однако операционные системы Windows® XP и Windows Server 2003 поддерживают только IKE. Инициализирующий узел IPsec, поддерживающий AuthIP и IKE и имеющий политику безопасности соединения, использующую AuthIP и IKE, должен определить поддержку AuthIP или IKE отвечающим узлом IPsec. Затем он должен использовать наиболее подходящий протокол для согласования защиты IPsec, отдавая предпочтение использованию AuthIP, а не IKE.

Для определения протокола согласования отвечающего узла IPsec инициализирующий узел IPsec, использующий AuthIP и IKE, одновременно отправляет следующие сообщения.

• Сообщение 1 — сообщение AuthIP, инициирующее согласование основного режима
• Сообщение 2 — сообщение IKE, инициирующее согласование основного режима

Если отвечающий узел поддерживает AuthIP, на сообщение 1 он должен ответить сообщением AuthIP, продолжая согласование основного режима, и отвергнуть сообщение 2 без уведомления. Отвечающий узел, не поддерживающий AuthIP, отвергает сообщение 1 без уведомления, поскольку в поле «Тип обмена» содержится неподдерживаемое значение, и отвечает на сообщение 2.

Для предотвращения согласования на основе IKE между узлами IPsec под управлением Windows Vista или Windows Server 2008, когда сообщение 1 отвергается из сети или приходит после сообщения 2, узлы IPsec под управлением Windows Vista или Windows Server 2008 отправляют сообщение 2 с полезными данными ISAKMP идентификатора поддерживаемого поставщика AuthIP. Полезные данные идентификатора поддерживаемого поставщика AuthIP указывают на то, что узел IPsec поддерживает AuthIP.

Поэтому, когда узел IPsec под управлением Windows Vista или Windows Server 2008 получает сообщение с 2 с полезными данными идентификатора поддерживаемого поставщика AuthIP, он ждет, когда инициализирующий узел IPsec повторно отправит сообщения 1 и 2, затем отвечает на сообщение 1.

Инициализирующий узел IPsec повторно отправляет сообщения 1 и 2 до получения ответа или истечения времени ожидания. После получения инициатором ответа он определяет возможности респондента с помощью заголовка ISAKMP ответа. Если для поля «Тип обмена» установлено значение 243 (тип обмена для согласования основного режима на основе AuthIP), респондент поддерживает AuthIP. Если для поля «Тип обмена» установлено значение 2 (тип обмена для согласования основного режима на основе IKE и защиты удостоверения), респондент поддерживает IKE.

В зависимости от ответа инициатор отвечает следующим сообщением AuthIP для согласования основного режима AuthIP или следующим сообщением IKE для согласования основного режима IKE. В течение срока действия сопоставления безопасности ISAKMP узел IPsec должен использовать протокол, использовавшийся для согласования сопоставления.

Джозеф Дэвис (Joseph Davies) работает составителем технической документации в корпорации Майкрософт и ведет ежемесячную рубрику TechNet «Кабельщик» по адресу Microsoft.com/technet/community/columns/cableguy.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.