IPSec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP-трафика. Защита основана на требованиях, определенных в базе данных политики безопасности (SPD), которая создается администратором.
Для каждого пакета может быть выполнено одно из трех действий:
Многие детали, связанные с обработкой IP-трафика в протоколах IPSec не являются предметом стандартизации. Тем не менее, для обеспечения интероперабильности IPSec некоторые внешние аспекты обработки стандартизованы. Рассмотрим общие принципы, на которых основана SPD.
SPD задается для каждого интерфейса, на котором необходима IPSec-обработка.
На хосте с поддержкой IPSec по крайней мере для одного сетевого ин-терфейса должна быть определена SPD. Шлюз безопасности всегда имеет по крайней мере два сетевых интерфейса, но сетевой интерфейс, подклю-ченный к локальной сети, может не поддерживать IPSec, поэтому для шлю-за безопасности также может требоваться только одна SPD. Однако если хост или шлюз безопасности имеет несколько сетевых интерфейсов, на которых будут использоваться протоколы IPSec, необходимо иметь отдельные SPD для каждого сетевого интерфейса.
Параметры SA определяются в SPD, которая описывает сервисы, при-меняемые к IP-дейтаграммам.
Для любой исходящей или входящей дейтаграммы существует три возможных способа обработки: отбросить дейтаграмму, обойти IPSec или применить IPSec. Первый вариант означает, что трафик не разрешен для хоста, не может проходить через шлюз безопасности или не может быть доставлен на уровень приложения. Второй вариант означает, что трафику разрешено проходить без какой-либо обработки IPSec. Третий вариант означает, что к трафику применяется IPSec-защита, и для такого трафика в SPD должны быть указаны необходимые сервисы безопасности, которые включают указание протоколов, алгоритмов и т.д.
Шлюз безопасности часто обладает как функциональностями IPSec, так и функциональностями межсетевого экрана. Поэтому правила фильтрования могут указываться как для IPSec-трафика, так и для не-IPSec-трафика. В этом случае используются принципы, которые применяются при создании правил фильтрования межсетевого экрана:
Каждая реализация IPSec имеет пользовательский интерфейс, который позволяет администратору задавать SPD, т.е. указывает обработку, применяемую к входящему или исходящему пакету. Для указания детализированности (гранулированности) обработки трафика возможно использование символа "*" в различных полях селектора, чтобы указать, что все пакеты для одного UDP- или ТСР-соединения соответствуют одной записи SPD.
SPD содержит упорядоченный список записей политики. Записи SPD указываются вместе с правилами межсетевого экрана.
(рис 8.1) Пример описания в SPD конечных точек IPSec
(рис 8.2) Задание правил фильтрования для IPSec-трафика
Каждая запись содержит селектор, который определяет IP-трафик, соответствующий данной записи. Селектор определяет детализированность политики и создаваемых SA. Каждая запись указывает действие, в соответствии с которым пакет должен быть пропущен, отброшен или обработан IPSec. Если применяется обработка IPSec, запись содержит параметры SA, список применяемых протоколов, режимов и алгоритмов, включая необходимые дополнительные параметры.
В селекторе могут быть указаны диапазоны значений. Для каждого пакета ищется соответствующая ему запись в SPD. После этого создается запись в SAD, в которой значения для селектора берутся из пакета, а не из SPD, если в записи SPD указан больший диапазон значений. Например, для всего трафика между двумя хостами может создаваться единственная SA. В другом случае трафик между парой хостов может передаваться через несколько SA, которые создаются для отдельных приложений. Это может определяться требованиями к безопасности конкретных приложений. Аналогично, весь трафик между двумя шлюзами безопасности может передаваться через единственную SA, или для каждой пары хостов, расположен-ных за шлюзом безопасности, может быть определена отдельная SA.
Селектор на сеть:
(рис 8.3) Пример селектора на сеть
Селектор на хост:
(рис 8.4) Пример селектора на хост
Селектор на порт (отдельное приложение):
(рис 8.5) Пример селектора на порт
Но при этом создается несколько SA:
(рис 8.6) SAD с несколькими SA между одними и теми же конечными точками
(рис 8.7) SAD с несколькими SA между одними и теми же конечными точками
База данных безопасной ассоциации (SAD)
В IPSec существует база данных безопасных ассоциаций, в которой каждая запись определяет параметры, связанные с установленной SA. Соответственно, каждая существующая SA имеет запись в SAD. Для исходящей обработки записи ссылаются на записи в SPD. Если при обработке очередного пакета обнаружено, что запись SPD не ссылается на SA в SAD, отсутствующая SA создается в SAD, и запись в SPD связывается с записью в SAD.
Следующие поля SAD используются для IPSec-обработки:
Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в АН- или ESP-заголовках для исходящего трафика.Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызыватьсобытие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).IPSec предполагает возможность как автоматического создания SA, так и создания SA вручную. Следует заметить, что детализированность создаваемых SA определяет детализированность выполняемой аутентификации.
Распределение ключей вручную является простейшим способом создания SA, определения алгоритмов и ключей, при котором администратор вручную конфигурирует каждую систему, указывая ключи и другие пара-метры. Такая технология применяется в маленьких, статичных окружениях и не масштабируется. Если количество хостов мало, и если все хосты рас-положены в пределах одного административного домена, то возможно применение ручных технологий распределения ключей. В данном случае трафик будет защищаться c использованием вручную сконфигурированных ключей.
Для обеспечения широкого использования IPSec требуется стандартный, масштабируемый протокол создания и управления SA. Такой протокол необходим для возможности автоматического создания SA.
Таким протоколом является протокол IKE.
Форматы сообщений в протоколе IKE
Основные понятия
В IKEv1 для описания форматов передаваемых сообщений используется стандарт, называемый "Безопасная ассоциация интернет и протокол управления ключом - Internet Security Association and Key Management Protocol (ISAKMP)". ISAKMP определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA.
ISAKMP определяет содержимое пакетов, которые передаются в протоколе для обмена ключей и аутентификации сторон. Эти форматы обеспечивают основу для интероперабельности реализаций IPSec различными производителями.
В атрибутах SA, которые используются для определения параметров протоколов AH и ESP, как минимум, должны быть указаны способ аутентификации, криптографический алгоритм, режим алгоритма, длина ключа и инициализационный вектор (IV). Установление SA является частью протокола управления ключом.
Протокол IKE обеспечивает полную безопасность последующих обменов (Perfect Forward Secrecy - PFS). Это означает, что при компрометации одного ключа возможен только доступ к данным, защищенным этим одним ключом.
Транспортный протокол: IKE может быть реализован поверх UDP или поверх IP. Производители посылают и получают IKE-сообщения протокола, используя UDP-порт 500. Этот UDP-порт зарезервирован для IKE в IANA. Производители могут дополнительно поддерживать IKE поверх других транспортных протоколов или поверх IP.
В протоколе IKE определены следующие понятия:
Предложение (Proposal): Список требуемых для защиты трафика сервисов, упорядоченный по уменьшению предпочтений.
Содержимое (Payload): Определены различные типы содержимого, которые используются в сообщениях протокола. В одном сообщении может быть послано несколько содержимых.
Тип обмена (Exchange Type): тип обмена определяет число сообщений в протоколе и типы содержимого, которые содержатся в каждом из этих сообщений. Определено стандартное множество типов обмена. При необходимости могут быть добавлены другие типы для поддержки дополнительных сервисов.
В IKE существует две фазы переговоров. Во время первой фазы два участника, которые называются IKE/ISAKMP-серверами, договариваются о том, как защищать дальнейший трафик управления SA, устанавливая IKE SA. Эта IKE SA затем используется для защиты создания требуемой SA.
Вторая фаза переговоров используется для установления SA для протокола АН или ESP. При этом во второй фазе может быть установлено несколько безопасных ассоциаций.
Хотя подход, основанный на двух фазах, является достаточно дорогостоящим в самых простых сценариях, во многих случаях он себя оправдывает.
Участники, которые ведут переговоры во время первой фазы, определяют свойства безопасности для второй фазы. Например, после первой фазы переговоров шифрование, выполняемое IKE SA, обеспечивает защиту идентификации, что дает возможность использовать меньшее число обме-нов во второй фазе. С другой стороны, если соединение, устанавливаемое в течение первой фазы, адекватно не защищает идентификации, во второй фазе переговоры должны учитывать это.
Заметим, что в I и II фазах переговоров могут применяться разные сервисы безопасности. В частности, в каждой из фаз может выполняться аутентификация разных участников. Во время первой фазы выполняется аутентификация на уровне сетевых адресов шлюзов безопасности или хостов, во второй фазе аутентификация осуществляется на уровне пользователей или прикладных программ.
Сервисы безопасности в протоколе IKE
Защита от DoS-атак
Защита от DoS-атак является одной из наиболее трудно решаемых задач. Обмены, в которых присутствуют операции с открытым ключом, интенсивно используют ЦП. Для защиты от DoS-атак, которые направлены на интенсивное использование вычислительных ресурсов, могут использоваться "Cookie" или Anti-Clogging Token (ACT). Использование таких Cookie может препятствовать некоторым попыткам DoS-атак, которые состоят в простом наводнении пакетами (flooding-атаки). Абсолютная защита от DoS-атак невозможна, но такие Cookie обеспечивают возможность более быстрого ее определения.
Следует заметить, что такие Cookie должны использоваться вместе с механизмом сбора мусора, так как атакующий может завалить сервер, используя пакеты с поддельными IP-адресами.
Защита от атак подделки одной из сторон
Протокол IKE предотвращает возможность установления соединения с нарушителем после того, как выполнена аутентификация, так как обеспечивается аутентификация всех последующих обменов в I и II фазах и в протоколах АН и ESP.
Защита от атак man-in-the-middle
Атаки man-in-the-middle могут состоять в перехвате, вставке, уничтожении и модификации сообщений, в отражении сообщений обратно отправителю, повторе старых сообщений и перенаправлении сообщений. Протокол IKE предотвращает все эти типы атак. Для всех сообщений IKE обеспечивается целостность и аутентификация источника, что предотвращает от возможности любых модификаций сообщений. Создание новых Cookie для каждого нового установления SA предотвращает атаки, которые состо-ят в повторе старых сообщений. Выполнение сильной аутентификации предотвращает установление SA с кем-либо, кроме требуемого участника.
Идентификация SA
Идентификация IKE SA отличается от идентификации ESP SA или AH SA. Для идентификации SA на разных этапах установления SA используются разные поля: два поля Cookie и поле Message ID в заголовке IKE используются для идентификации IKE SA на разных стадиях установления SA. Поле SPI, определяемое в содержимом Proposal, в дальнейшем используется для идентификации SA в протоколах ESP и АН.
В следующей таблице показано наличие перечисленных полей при установлении SA. "0" означает, что значение отсутствует, "X" означает, что значение присутствует, "NA" означает, что значение не используется в данной стадии установления SA.
(рис 8.8) Способы идентификации IKE SA в протоколе IKE
В первом сообщении Инициатор указывает Initiator Cookie в заголовке IKE (см первую строчку таблицы).
(рис 8.9) Начальное сообщение с Cookie Инициатора
Во втором сообщении Получатель включает поля Initiator и Responder Cookie в заголовок IKE (см вторую строчку таблицы).
(рис 8.10) Ответное сообщение с Cookie Инициатора и Получателя
Взаимодействующие стороны могут обмениваться дополнительными сообщениями в зависимости от типа обмена, используемого в первой фазе переговоров. В течение первой фазы переговоров Cookies Инициатора и Получателя включаются в заголовок IKE всех обменов и определяют IKE SA. Поле SPI в содержимом Proposal установлено в 0 или может содер-жать Сookie взаимодействующих участников.
После завершения I фазы Инициатор определяет Message ID для протоколов, которые будут выполняться в данной SA. Этот Message ID Инициатора указывается для каждого протокола.
(рис 8.11) Идентификация SA по Message ID в Quick Mode
SPI будут использоваться для идентификации SA только после завершения второй фазы переговоров (см шестую строчку таблицы).
Формат сообщений
Наличие и последовательность содержимых в сообщении определяется полем Exchange Type.
1. Формат заголовка ISAKMP/IKE
Сообщение IKE имеет фиксированный формат заголовка, за которым следует переменное число содержимых. Этот заголовок содержит информацию, необходимую для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.
В IKE-заголовке определены следующие поля:
Initiator Cookie (8 октетов) - Cookie участника, который инициировал установление или удаление SA.Responder Cookie (8 октетов) - Cookie участника, который является получателем запроса установления или удаления SA.
(рис 8.12) Формат заголовка IKENext Payload (1 октет) - определяет тип следующего содержимого в сообщении.
(рис 8.13) Возможные типы содержимыхMajor Version (4 бита) - старший номер версии используемого протокола.Minor Version (4 бита) - младший номер версии используемого протокола.Exchange Type (1 октет) - тип используемого обмена, который определяет последовательность сообщений и упорядоченность содержимых в каждом сообщении.
(рис 8.14) Возможные типы обменовFlags (1 октет) - определяет конкретные параметры данного обмена.
E (encryption bit) - если установлен, то все содержимые, следующие после заголовка, шифруются, используя алгоритм шифрования, определенный в SA. IKE SA идентифицируется комбинацией Сookie Инициатора и Получателя. Шифрование начинается после того, как оба участника обменяются содержимыми Key Exchange.C (Commit Bit) - используется для синхронизации обмена ключа. Он используется для гарантирования того, что зашифрованный материал не получен прежде, чем участники обменяются сообщениями KE. Commit Bit может быть установлен в любое время любым из участников и может использоваться в обеих фазах. Значение сбрасывается после фазы I. Участник, который не установил Commit Bit, должен ждать информационного обмена, содержащего Notify. Получение информационного обмена говорит о том, что установление SA прошло успешно, и оба участника могут продолжать взаимодействие по зашифрованному каналу. Кроме синхронизации обмена ключа Commit Bit может использоваться для защиты от падения соединения по ненадежным сетям и предохранять от необходимости многочисленных повторных восстановлений.A (authentication only bit) - данный бит используется в информационном обмене, в котором есть содержимое Notify и позволяет передавать информацию с контролем целостности, но без шифрования (так называемый "аварийный режим").Message ID (4 октета) - уникальный идентификатор сообщения используется для идентификации в фазе II. Данное значение создается Инициатором в фазе II переговоров. Во время фазы I переговоров значение должно быть установлено в 0.Length (4 октета) - длина всего сообщения (заголовок + полезные содержания) в октетах.
(рис 8.15) Пример IKE-заголовка2. Общий заголовок содержимого
Каждое содержимое начинается с общего заголовка, который обеспечивает возможность "связывания" нескольких содержимых и позволяет явно определять границы содержимого.
(рис 8.16) Общий заголовок содержимого
Поля общего заголовка содержимого определяются следующим образом:
Next Payload (1 октет) - идентификатор следующего содержимого в сообщении. Это поле обеспечивает возможность "связывания", что предотвращает возможные replay-атаки и атаки, связанные с подделкой одной из сторон.Payload Length (2 октета) - длина текущей полезной информации, включая общий заголовок.3. Атрибуты данных
Существует несколько случаев, когда должны быть переданы атрибуты данных. Примером этого являются атрибуты SA в содержимом Transform. Эти атрибуты данных не являются отдельным содержимым, а присутствуют в других содержимых. Формат атрибутов данных обеспечивает гибкость представления различных типов информации.
(рис 8.17) Атрибуты данных
Поля атрибутов данных определяются следующим образом:
i>Attribute Type (2 октета) - уникальный идентификатор типа атрибута. Типы атрибутов определяются в DOI.
Attribute Format (AF), определяет будут ли атрибуты данных определяться форматом Type/Length/Value (TLV) или короткой формой формата Type/Value (TV). Если бит AF = 0, то атрибуты данных имеют форму TLV. Если бит AF = 1, то атрибуты данных имеют форму TV.
Attribute Length (2 октета) - длина в октетах значения атрибута. При AF = 1 значение атрибута имеет только 2 октета, и поле длины атрибута не представлено.Attribute Value (переменной длины) - значение атрибута, связанное с определенным DOI Attribute Type. Если бит AF = 0, то это поле имеет переменную длину, определяемую полем Attribute Length. Если бит AF = 1, то Attribute Value имеет длину 2 октета.4. Содержимое SA
Содержимое SA используется для выбора алгоритмов, которые будут применяться для защиты трафика. Содержимым SA может быть несколько сообщений Proposal.
В содержимое SA также указано DOI и Situation, при котором ведутся переговоры.
(рис 8.18) Содержимое SA
5. Содержимое Proposal
Сообщение Proposal содержит предложения Инициатора и выбор Получателя о наборах алгоритмов, используемых для защиты трафика.
(рис 8.19) Содержимое Proposal
(рис 8.20) Пример Proposal
Proposal # определяет номер Proposal для текущего содержимого.
Protocol-Id определяет идентификатор протокола. Примерами являются IKE, ESP, AH.
SPI Size - длина SPI. В случае протокола IKE пара Сookie Инициатора и Получателя из заголовка идентифицируют IKE, следовательно, SPI Size не имеет значения и может быть от нуля до 16.
# of Transforms определяет количество преобразований для Proposal. Каждое из них указано в содержимом Transform.
6. Содержимое Transform
Содержимое Transform состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности соединения. Transform также может содержать атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты определяются DOI.
(рис 8.21) Содержимое Transform
7. Содержимое Key Exchange
Содержимое Key Exchange поддерживает различные технологии обмена ключа. Примерами обменов ключа являются обмен ключа Диффи-Хеллмана, расширенный обмен ключа Диффи-Хеллмана или обмен ключа на основе RSA.
(рис 8.22) Содержимое Key Exchange
8. Содержимое Identification
В содержимом Identification представлены идентификационные данные.
(рис 8.23) Содержимое Identification
9. Содержимое Certificate
Содержимое Certificate обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, и может появляться в любом сообщении.
(рис 8.24) Содержимое Certificate
Certificate Encoding - данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data.
Certificate Data - конкретное представление данных сертификата. Тип сертификата определяется полем Certificate Encoding.
10. Содержимое Certificate Request
Содержимое Certificate Request обеспечивает способ запроса сертификатов и может появиться в любом сообщении. Получатель Certificate Request должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request.
(рис 8.25) Содержимое Certificate Request
Certificate Authority содержит список сертификационных центров, открытые ключи которых есть у принимающей стороны. Например, для сертификата Х.509 оно должно содержать DN CA, принимаемого Инициатором. Это должно помочь Получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос. Если требуемый корневой сертификационный центр не важен, данное поле отсутствует.
11. Содержимое Hash
Hash содержит данные, создаваемые хэш-функцией (определенной при установлении SA), которая вычисляется для некоторой части сообщения и/или состояния протокола. Данное содержимое может использоваться для проверки целостности данных в IKE-сообщении или для аутентификации участников протокола.
(рис 8.26) Содержимое Hash
12. Содержимое Signature
Signature содержит данные, созданные функцией создания цифровой подписи (выбранной во время установления SA) для некоторой части сообщения и/или состояния протокола. Данное содержимое используется для аутентификации отправителя и проверки целостности данных в IKE-сообщении и может быть использовано для сервисов невозможности отказа.
(рис 8.27) Содержимое Signature
13. Содержимое Nonce
Nonce содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. Nonce могут передаваться как часть данных обмена ключа или как отдельное содержимое.
(рис 8.28) Содержимое Nonce
14. Содержимое Notification
Notification может содержать как определяемые IKE, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification в одном сообщении IKE.
(рис 8.29) Содержимое Notification
Notification, которые посылаются фазе I переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE. Идентификатором протокола в данном случае является IKE, значение SPI равно 0. Если Notification передается до обмена ключевой информацией, то оно не будет защищено.
Notification, которые передаются во время фазы II переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE, а также Message ID и SPI, если они определены на данной стадии протокола.
Protocol-Id определяет идентификатор протокола для данного уведомления. Примерами протокола являются IKE, ESP, AH.
SPI Size - длина SPI в октетах как определено в Protocol-Id. В случае IKE пара Cookie Инициатора и Получателя из заголовка IKE выполняют функции IKE SPI, следовательно, SPI Size не имеет значения и может быть от 0 до 16.
Notify Message Type определяет тип сообщения уведомления. Дополнительная информация размещается в поле Notification Data.
15. Содержимое Delete
Delete содержит идентификатор SA, которую Инициатор удаляет из своей SAD. Возможна посылка нескольких SPI в одном Delete, однако каждый SPI должен быть предназначен для того же самого протокола. Нескольких идентификаторов протоколов в Delete быть не может.
(рис 8.30) Содержимое Delete
Удаление, которое относится к IKE SA, содержит в качестве идентификатора протокола IKE, в качестве SPI указываются Cookies Инициатора и Получателя из заголовка IKE. Удаление, которое выполняется для таких протоколов, как ESP или АН, будет содержать идентификатор этого протокола (т.е. ESP, AH), и SPI SA.
# of SPIs - количество SPI, содержащихся в Delete. Размер каждого SPI определяется полем SPI Size
Security Parameter Index - идентификаторы, определяющие удаляемые безопасные ассоциации.
Будем использовать следующие обозначения.
HDR – заголовок сообщения. Запись HDR* означает, что одержимое сообщения зашифровано.
SA – сообщение SA, которое содержит один или более Proposal. Инициатор посылает несколько Proposal, упорядоченных в соответствии со своим приоритетом. Получатель должен выбрать только один Proposal.
CKY-I и CKY-R есть Cookie Инициатора и Получателя соответственно.
gXi и gXr – открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно.
КЕ – сообщение обмена ключа, т.е. открытые значения, которыми обмениваются в алгоритме Диффи-Хеллмана.
Nx – сообщение Nonce; x может быть i или r для Инициатора и Получателя соответственно.
IDx – содержимое идентификации для х. Х может быть ii или ir для Инициатора и Получателя во время фазы I; или ui или ur для Инициатора и Получателя во время фазы II.
SIG – сообщение подписи. Подписываемые данные зависят от типа обмена.
CERT – сообщение, содержащее сертификат.
HASH (HASH(2)или HASH_I) – сообщение, содержащее хэш данных, которые зависят от способа аутентификации.
PRF (key, msg) – псевдослучайная функция. Чаще всего используется хэш-функция с ключом, результатом которой является значение, которое удовлетворяет требованиям к случайным числам. PRF используется как для получения ключа, так и для аутентификации участников при использовании аутентификации по общему секрету.
SKEYID – значение, полученное из секрета и известное только участникам обмена.
SKEYID_e – ключ, используемый для обеспечения конфиденциальности сообщений.
SKEYID_а – ключ, используемый для проверки целостности сообщений.
SKEYID_d – ключ, используемый для получения ключей для безопасных ассоциаций, создаваемых в фазе II, т.е. АН SA и ESP SA.
Обзор протокола
Протокол IKE имеет две фазы, в каждой из которых может быть выполнено несколько обменов.
В результате фазы I участники устанавливают защищенный канал, который называется IKE SA. В фазе I определено два режима: Main Mode и Aggressive Mode.
Фаза II начинается после установления IKE SA. Для второй фазы обмена определен режим Quick Mode.
Преимущество использования двух фаз обмен ключа состоит в том, что для создания нескольких SA требуется выполнение только одной фазы I. Main Mode фазы I обеспечивает защиту идентификации. Когда нет необходимости в защите идентификации, может использоваться Aggressive Mode для уменьшения числа взаимных передач.
Участники фазы I договариваются о следующих параметрах.
Все эти параметры являются обязательными, и о них должны вестись переговоры. Кроме того, возможны дополнительные переговоры о псевдослучайной функции (PRF). Если переговоры о ней не ведутся, то используется HMAC с хэш-алгоритмом, о котором договорились.
Группа Диффи-Хеллмана определяется по номеру.
(рис 8.31) Задание группы Диффи-Хеллмана
Обмены
Существует два режима, используемых в фазе I: Main Mode и Aggressive Mode. В обоях случаях создается аутентифицированный ключевой материал, полученный из обмена открытыми значениями алгоритма Диффи-Хеллмана. В фазе II используется Quick Mode для создания нового материала ключа и ведения переговоров о AH SA или ESP SA.
Первым посылается сообщение SA.
Открытое значение Диффи-Хеллмана передается в содержимом КЕ в фазе I, оно может передаваться в фазе II обмена, если требуется PFS. Длина открытого значения Диффи-Хеллмана определяется в сообщении SA.
Main Mode обеспечивает защиту идентификаций. В первых двух сообщениях договариваются об используемых алгоритмах; в следующих двух сообщениях обмениваются открытыми значениями Диффи-Хеллмана и случайными значениями; последние два сообщения аутентифицируют обмен Диффи-Хеллмана. Метод аутентификации определяется при переговорах в первых сообщениях и влияет на последовательность сообщений.
В первых двух сообщениях Aggressive Mode договариваются об используемых алгоритмах, обмениваются открытыми значениями Диффи-Хеллмана, случайными значениями и идентификациями. Второе сообщение аутентифицирует Получателя. Третье сообщение аутентифицирует Инициатора.
Определено два метода аутентификации как для Main Mode, так и для Aggressive Mode - цифровая подпись и предварительно распределенный секрет.
Значение SKEYID для каждого метода аутентификации вычисляется по своему алгоритму.
Для подписей:
SKEYID = PRF (Ni | Nr, gxy)
Для предварительно распределенного секрета:
SKEYID = PRF (pre-shared-key, Ni | Nr)
Результатом как Main Mode, так и Aggressive Mode являются три ключа:
SKEYID_d = PRF (SKEYID, gxy | CKY-I | CKY-R|0) SKEYID_a = PRF (SKEYID, SKEYID_d | gxy | CKY-I | CKY-R|1) SKEYID_e = PRF (SKEYID, SKEYID_a | gxy | CKY-I | CKY-R|2)
и согласованные алгоритмы для защиты дальнейших взаимодействий. Ключ, используемый для шифрования, получается из SKEYID_e с помощью алгоритма, о котором договорились в первых сообщениях.
Для проверки целостности обмена и аутентификации участников Инициатор вычисляет HASH_I, и Получатель создает HASH_R, где:
HASH_I = PRF (SKEYID, gXi | gXr | CKY-I | CKY-R |SAi|IDii) HASH_R = PRF (SKEYID, gXr | gXi | CKY-R | CKY-I |SAi|IDir)
При аутентификации с помощью цифровых подписей HASH_I и HASH_R подписаны; при аутентификации предварительно распределенным секретом HASH_I и HASH_R непосредственно аутентифицируют обмен.
Метод аутентификации влияет на последовательность сообщений и использование сообщений в фазе I.
Фаза I с аутентификацией с помощью подписей
Последовательность сообщений в Main Mode с аутентификацией с помощью подписей следующая:
(рис 8.32) Main Mode с аутентификацией с помощью цифровых подписей
Последовательность сообщений в Aggressive Mode с аутентификацией с помощью подписей следующая:
(рис 8.33) Aggressive Mode с аутентификацией с помощью цифровых подписей
В обоих режимах подписи SIG_I или SIG_R выполняются для HASH_I и HASH_R соответственно.
Фаза I с аутентификацией по предварительно распределенному секрету
Общий ключ, разделяемый Инициатором и Получателем, используется для аутентификации участников и обеспечения целостности сообщений.
Когда выполняется аутентификация по предварительно распределенному секрету, последовательность сообщений в Main Mode следующая:
(рис 8.34) Main Mode с аутентификацией по предварительно распределенному секрету
В Aggressive Mode с аутентификацией по предварительно распределенному секрету последовательность сообщений следующая:
(рис 8.35) Aggressive Mode с аутентификацией по предварительно распределенному секрету
При использовании аутентификации по предварительно распределенному секрету в Main Mode ключ может идентифицироваться только по IP-адресу противоположной стороны, так как HASH_I вычисляется до того, как Инициатор получит IDir.
Фаза II – Quick Mode
Quick Mode сам по себе законченным обменом не является. Это означает, что он связан с фазой I обмена, так как использует ключи, вычисленные на фазе I. Сообщения, которыми обмениваются в Quick Mode, зашифрованы алгоритмами и ключами, определенными в фазе I, т.е. все сообщения, за исключением заголовка будут зашифрованы. Первое сообщение HASH проверяет, что соединение не сброшено и аутентифицирует участников.
Quick Mode выполняет переговоры об SA и обменивается Nonce, которые обеспечивают защиту от повторов. Nonce используются для создания нового материала ключа и предотвращения replay-атак, в результате которых могут быть созданы ложные SA. Можно произвести обмен дополнительным сообщением KE, чтобы для SA, созданной на фазе II, полностью обновить ключи.
Базовый Quick Mode (без содержимого KE) вычисляет ключи, из клю-чевого материала, созданного в фазе I. Считается, что это хуже, так как не обеспечивается PFS. При использовании дополнительного сообщения KE ключи полностью обновляются.
При Quick Mode последовательность сообщений следующая:
(рис 8.36) Quick Mode
HASH(1)вычисляется PRF для поля Message-ID (M-ID) из заголовка, присоединенного ко всему сообщению.
HASH(2)вычисляется аналогично HASH(1). Включение Nonce как Инициатора, так и Получателя в HASH(2)сделано для того, чтобы подтвердить жизнеспособность SA.
HASH (3) также вычисляется для доказательства жизнеспособности.
HASH(1) = PRF (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | Idcr ]) HASH(2) = PRF (SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDci | Idcr ]) HASH (3) = PRF (SKEYID_a, 0 | M-ID | Ni | Nr)
Если политика не требует PFS, т.е. обмен сообщениями KE не выполняется, то новый материал ключа вычисляется следующим образом:
KEYMAT = PRF (SKEYID_d, protocol | SPI | Ni | Nr)
Если PFS требуется, и участники обмениваются содержимым KE, то новый материал ключа вычисляется следующим образом:
KEYMAT = PRF (SKEYID_d, g (qm)xy | protocol | SPI | Ni | Nr)
Где g (qm)xy является разделяемым секретом из последнего обмена Диффи-Хеллмана, выполненного в Quick Mode.
Значения Protocol и SPI берутся из сообщения Proposal из Quick Mode.
В ситуации, когда суммарная длина требуемых ключей больше, чем длина выходного значения PRF, KEYMAT расширяется конкатенацией результатов до тех пор, пока не будет получено необходимое количество битов ключа.
KEYMAT = K1 | K2 | K3 | …
Где
K1 = PRF (SKEYID_d, [g (qm)xy | ] protocol | SPI |Ni| Nr) K2 = PRF (SKEYID_d, K1 | [g (qm)xy |]protocol|SPI|Ni| Nr) K3 = PRF (SKEYID_d, K2 | [g (qm)xy |]protocol|SPI|Ni| Nr)
В Quick Mode за один обмен можно договориться о создании нескольких SA:
(рис 8.37) Quick Mode с созданием нескольких SA
В различные моменты при выполнении IKE SA стороны могут захотеть сообщить друг другу о возникших ошибках или уведомить о возникших событиях. Для выполнения этого определен информационный обмен. Информационные обмены должны осуществляться только после выполнения обмена ключом, чтобы они были криптографически защищены.
Управляющие сообщения, которые относятся к IKE SA, должны быть посланы в IKE SA. Управляющие сообщения, которые относятся к ESP или АН SA, должны быть посланы под защитой IKE SA, под управлением которой они созданы.
Сообщения информационного обмена могут содержать несколько Notification, Delete и Configuration содержимых. Получатель запроса информационного обмена должен послать ответ, так как в противном случае Инициатор будет предполагать, что сообщение было потеряно, и будет повторять его.
Использование таймеров ретрансмиссии
Для каждой пары сообщений Инициатор выполняет повторную передачу, если по истечению таймаута он не получил подтверждение о получении. Получатель никогда не должен повторять ответ, пока он не получит повтор запроса. В этом случае Получатель должен отправить повторный ответ. Инициатор должен запоминать каждый запрос до тех пор, пока он не получит ответ, чей последовательный номер больше, чем последовательный номер в ответе плюс его собственный размер окна.
IKE является надежным протоколом в том смысле, что Инициатор должен повторять запрос до тех пор, пока он не получит соответствующий ответ или он решит, что IKE SA упала, и он сбросит все состояния, связанные с ней и все дочерние SA для протоколов ESP и АН, созданные с использованием данной IKE SA.
Использование последовательных номеров для Message ID
Каждое сообщение IKE содержит в заголовке Message ID. Данный Message ID используется для идентификации сообщений в протоколе IKE.
Заметим, что Message ID криптографически защищен, и обеспечивается защита против повторных сообщений.
Для увеличения производительности конечные точки соединения могут создавать несколько запросов до того, как получат ответ на любой из них, если другая конечная точка указывает возможность обработки таких запросов.
Синхронизация состояния и таймауты соединения
Состояния IKE SA и связанных с ней AH SA и ESP SA могут быть в любой момент потеряны. Это обычно происходит в случае останова или перезапуска конечной точки. Важно, что когда происходит сбой конечной точки или повторная инициализация ее состояния, то противоположная конечная точка должна иметь возможность определить эту ситуацию и не продолжать бессмысленную посылку пакетов по разрушенной SА.
Так как IKE разрабатывался для противодействия DoS-атакам, конечная точка не должна делать вывод о падении противоположной конечной точки, основываясь на какой-либо информации маршрутизации (например, ICMP-сообщениях) или IKE-сообщениях, которые были получены без криптографической защиты (например, Notify-сообщения, уведомляющие о проблемах неизвестных SPI). Конечная точка должна делать вывод, что другая конечная точка упала только тогда, когда она не получает ответа за определенный период на повторные попытки связаться или когда получено криптографически защищенное уведомление INITIAL_CONTACT по другой IKE SA для той же самой аутентифицированной идентификации. Конечная точка может подозревать, что на противоположной стороне произошел сбой, основываясь на информации маршрутизации, и инициировать запрос, который бы показал ей, что данная конечная точка жизнеспособна. Для проверки жизнеспособности другой стороны определено пустое INFORMATIONAL сообщение, которое (подобно всем IKE-запросам) требует подтверждения о получении. Если криптографически защищенное сообщение получено от другой стороны недавно, незащищенные уведомления могут игнорироваться. Производители могут ограничить темп, с которым они будут действовать, основываясь на незащищенных сообщениях.
Если существует только исходящий трафик по всем SA, связанным с IKE SA, то особенно важно подтверждение жизнеспособности другой ко-нечной точки, чтобы избежать появления черных дыр. Если не было полу-чено никаких криптографически защищенных сообщений по IKE SA или по любой ESP или AH SA в течение определенного периода времени, необходимо выполнить проверку жизнеспособности, чтобы избежать посылки сообщений прекратившему существование участнику. Получение свежего криптографически защищенного сообщения по IKE SA или по любой ESP или AH SA гарантирует жизнеспособность IKE SA или ESP и AH SA.
IPSec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP-трафика. Защита основана на требованиях, определенных в базе данных политики безопасности (SPD), которая создается администратором.
Для каждого пакета может быть выполнено одно из трех действий:
Многие детали, связанные с обработкой IP-трафика в протоколах IPSec не являются предметом стандартизации. Тем не менее, для обеспечения интероперабильности IPSec некоторые внешние аспекты обработки стандартизованы. Рассмотрим общие принципы, на которых основана SPD.
SPD задается для каждого интерфейса, на котором необходима IPSec-обработка.
На хосте с поддержкой IPSec по крайней мере для одного сетевого ин-терфейса должна быть определена SPD. Шлюз безопасности всегда имеет по крайней мере два сетевых интерфейса, но сетевой интерфейс, подклю-ченный к локальной сети, может не поддерживать IPSec, поэтому для шлю-за безопасности также может требоваться только одна SPD. Однако если хост или шлюз безопасности имеет несколько сетевых интерфейсов, на которых будут использоваться протоколы IPSec, необходимо иметь отдельные SPD для каждого сетевого интерфейса.
Параметры SA определяются в SPD, которая описывает сервисы, при-меняемые к IP-дейтаграммам.
Для любой исходящей или входящей дейтаграммы существует три возможных способа обработки: отбросить дейтаграмму, обойти IPSec или применить IPSec. Первый вариант означает, что трафик не разрешен для хоста, не может проходить через шлюз безопасности или не может быть доставлен на уровень приложения. Второй вариант означает, что трафику разрешено проходить без какой-либо обработки IPSec. Третий вариант означает, что к трафику применяется IPSec-защита, и для такого трафика в SPD должны быть указаны необходимые сервисы безопасности, которые включают указание протоколов, алгоритмов и т.д.
Шлюз безопасности часто обладает как функциональностями IPSec, так и функциональностями межсетевого экрана. Поэтому правила фильтрования могут указываться как для IPSec-трафика, так и для не-IPSec-трафика. В этом случае используются принципы, которые применяются при создании правил фильтрования межсетевого экрана:
Каждая реализация IPSec имеет пользовательский интерфейс, который позволяет администратору задавать SPD, т.е. указывает обработку, применяемую к входящему или исходящему пакету. Для указания детализированности (гранулированности) обработки трафика возможно использование символа "*" в различных полях селектора, чтобы указать, что все пакеты для одного UDP- или ТСР-соединения соответствуют одной записи SPD.
SPD содержит упорядоченный список записей политики. Записи SPD указываются вместе с правилами межсетевого экрана.
(рис 8.1) Пример описания в SPD конечных точек IPSec
(рис 8.2) Задание правил фильтрования для IPSec-трафика
Каждая запись содержит селектор, который определяет IP-трафик, соответствующий данной записи. Селектор определяет детализированность политики и создаваемых SA. Каждая запись указывает действие, в соответствии с которым пакет должен быть пропущен, отброшен или обработан IPSec. Если применяется обработка IPSec, запись содержит параметры SA, список применяемых протоколов, режимов и алгоритмов, включая необходимые дополнительные параметры.
В селекторе могут быть указаны диапазоны значений. Для каждого пакета ищется соответствующая ему запись в SPD. После этого создается запись в SAD, в которой значения для селектора берутся из пакета, а не из SPD, если в записи SPD указан больший диапазон значений. Например, для всего трафика между двумя хостами может создаваться единственная SA. В другом случае трафик между парой хостов может передаваться через несколько SA, которые создаются для отдельных приложений. Это может определяться требованиями к безопасности конкретных приложений. Аналогично, весь трафик между двумя шлюзами безопасности может передаваться через единственную SA, или для каждой пары хостов, расположен-ных за шлюзом безопасности, может быть определена отдельная SA.
Селектор на сеть:
(рис 8.3) Пример селектора на сеть
Селектор на хост:
(рис 8.4) Пример селектора на хост
Селектор на порт (отдельное приложение):
(рис 8.5) Пример селектора на порт
Но при этом создается несколько SA:
(рис 8.6) SAD с несколькими SA между одними и теми же конечными точками
(рис 8.7) SAD с несколькими SA между одними и теми же конечными точками
База данных безопасной ассоциации (SAD)
В IPSec существует база данных безопасных ассоциаций, в которой каждая запись определяет параметры, связанные с установленной SA. Соответственно, каждая существующая SA имеет запись в SAD. Для исходящей обработки записи ссылаются на записи в SPD. Если при обработке очередного пакета обнаружено, что запись SPD не ссылается на SA в SAD, отсутствующая SA создается в SAD, и запись в SPD связывается с записью в SAD.
Следующие поля SAD используются для IPSec-обработки:
Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в АН- или ESP-заголовках для исходящего трафика.Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызыватьсобытие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).IPSec предполагает возможность как автоматического создания SA, так и создания SA вручную. Следует заметить, что детализированность создаваемых SA определяет детализированность выполняемой аутентификации.
Распределение ключей вручную является простейшим способом создания SA, определения алгоритмов и ключей, при котором администратор вручную конфигурирует каждую систему, указывая ключи и другие пара-метры. Такая технология применяется в маленьких, статичных окружениях и не масштабируется. Если количество хостов мало, и если все хосты рас-положены в пределах одного административного домена, то возможно применение ручных технологий распределения ключей. В данном случае трафик будет защищаться c использованием вручную сконфигурированных ключей.
Для обеспечения широкого использования IPSec требуется стандартный, масштабируемый протокол создания и управления SA. Такой протокол необходим для возможности автоматического создания SA.
Таким протоколом является протокол IKE.
Форматы сообщений в протоколе IKE
Основные понятия
В IKEv1 для описания форматов передаваемых сообщений используется стандарт, называемый "Безопасная ассоциация интернет и протокол управления ключом - Internet Security Association and Key Management Protocol (ISAKMP)". ISAKMP определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA.
ISAKMP определяет содержимое пакетов, которые передаются в протоколе для обмена ключей и аутентификации сторон. Эти форматы обеспечивают основу для интероперабельности реализаций IPSec различными производителями.
В атрибутах SA, которые используются для определения параметров протоколов AH и ESP, как минимум, должны быть указаны способ аутентификации, криптографический алгоритм, режим алгоритма, длина ключа и инициализационный вектор (IV). Установление SA является частью протокола управления ключом.
Протокол IKE обеспечивает полную безопасность последующих обменов (Perfect Forward Secrecy - PFS). Это означает, что при компрометации одного ключа возможен только доступ к данным, защищенным этим одним ключом.
Транспортный протокол: IKE может быть реализован поверх UDP или поверх IP. Производители посылают и получают IKE-сообщения протокола, используя UDP-порт 500. Этот UDP-порт зарезервирован для IKE в IANA. Производители могут дополнительно поддерживать IKE поверх других транспортных протоколов или поверх IP.
В протоколе IKE определены следующие понятия:
Предложение (Proposal): Список требуемых для защиты трафика сервисов, упорядоченный по уменьшению предпочтений.
Содержимое (Payload): Определены различные типы содержимого, которые используются в сообщениях протокола. В одном сообщении может быть послано несколько содержимых.
Тип обмена (Exchange Type): тип обмена определяет число сообщений в протоколе и типы содержимого, которые содержатся в каждом из этих сообщений. Определено стандартное множество типов обмена. При необходимости могут быть добавлены другие типы для поддержки дополнительных сервисов.
В IKE существует две фазы переговоров. Во время первой фазы два участника, которые называются IKE/ISAKMP-серверами, договариваются о том, как защищать дальнейший трафик управления SA, устанавливая IKE SA. Эта IKE SA затем используется для защиты создания требуемой SA.
Вторая фаза переговоров используется для установления SA для протокола АН или ESP. При этом во второй фазе может быть установлено несколько безопасных ассоциаций.
Хотя подход, основанный на двух фазах, является достаточно дорогостоящим в самых простых сценариях, во многих случаях он себя оправдывает.
Участники, которые ведут переговоры во время первой фазы, определяют свойства безопасности для второй фазы. Например, после первой фазы переговоров шифрование, выполняемое IKE SA, обеспечивает защиту идентификации, что дает возможность использовать меньшее число обме-нов во второй фазе. С другой стороны, если соединение, устанавливаемое в течение первой фазы, адекватно не защищает идентификации, во второй фазе переговоры должны учитывать это.
Заметим, что в I и II фазах переговоров могут применяться разные сервисы безопасности. В частности, в каждой из фаз может выполняться аутентификация разных участников. Во время первой фазы выполняется аутентификация на уровне сетевых адресов шлюзов безопасности или хостов, во второй фазе аутентификация осуществляется на уровне пользователей или прикладных программ.
Сервисы безопасности в протоколе IKE
Защита от DoS-атак
Защита от DoS-атак является одной из наиболее трудно решаемых задач. Обмены, в которых присутствуют операции с открытым ключом, интенсивно используют ЦП. Для защиты от DoS-атак, которые направлены на интенсивное использование вычислительных ресурсов, могут использоваться "Cookie" или Anti-Clogging Token (ACT). Использование таких Cookie может препятствовать некоторым попыткам DoS-атак, которые состоят в простом наводнении пакетами (flooding-атаки). Абсолютная защита от DoS-атак невозможна, но такие Cookie обеспечивают возможность более быстрого ее определения.
Следует заметить, что такие Cookie должны использоваться вместе с механизмом сбора мусора, так как атакующий может завалить сервер, используя пакеты с поддельными IP-адресами.
Защита от атак подделки одной из сторон
Протокол IKE предотвращает возможность установления соединения с нарушителем после того, как выполнена аутентификация, так как обеспечивается аутентификация всех последующих обменов в I и II фазах и в протоколах АН и ESP.
Защита от атак man-in-the-middle
Атаки man-in-the-middle могут состоять в перехвате, вставке, уничтожении и модификации сообщений, в отражении сообщений обратно отправителю, повторе старых сообщений и перенаправлении сообщений. Протокол IKE предотвращает все эти типы атак. Для всех сообщений IKE обеспечивается целостность и аутентификация источника, что предотвращает от возможности любых модификаций сообщений. Создание новых Cookie для каждого нового установления SA предотвращает атаки, которые состо-ят в повторе старых сообщений. Выполнение сильной аутентификации предотвращает установление SA с кем-либо, кроме требуемого участника.
Идентификация SA
Идентификация IKE SA отличается от идентификации ESP SA или AH SA. Для идентификации SA на разных этапах установления SA используются разные поля: два поля Cookie и поле Message ID в заголовке IKE используются для идентификации IKE SA на разных стадиях установления SA. Поле SPI, определяемое в содержимом Proposal, в дальнейшем используется для идентификации SA в протоколах ESP и АН.
В следующей таблице показано наличие перечисленных полей при установлении SA. "0" означает, что значение отсутствует, "X" означает, что значение присутствует, "NA" означает, что значение не используется в данной стадии установления SA.
(рис 8.8) Способы идентификации IKE SA в протоколе IKE
В первом сообщении Инициатор указывает Initiator Cookie в заголовке IKE (см первую строчку таблицы).
(рис 8.9) Начальное сообщение с Cookie Инициатора
Во втором сообщении Получатель включает поля Initiator и Responder Cookie в заголовок IKE (см вторую строчку таблицы).
(рис 8.10) Ответное сообщение с Cookie Инициатора и Получателя
Взаимодействующие стороны могут обмениваться дополнительными сообщениями в зависимости от типа обмена, используемого в первой фазе переговоров. В течение первой фазы переговоров Cookies Инициатора и Получателя включаются в заголовок IKE всех обменов и определяют IKE SA. Поле SPI в содержимом Proposal установлено в 0 или может содер-жать Сookie взаимодействующих участников.
После завершения I фазы Инициатор определяет Message ID для протоколов, которые будут выполняться в данной SA. Этот Message ID Инициатора указывается для каждого протокола.
(рис 8.11) Идентификация SA по Message ID в Quick Mode
SPI будут использоваться для идентификации SA только после завершения второй фазы переговоров (см шестую строчку таблицы).
Формат сообщений
Наличие и последовательность содержимых в сообщении определяется полем Exchange Type.
1. Формат заголовка ISAKMP/IKE
Сообщение IKE имеет фиксированный формат заголовка, за которым следует переменное число содержимых. Этот заголовок содержит информацию, необходимую для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.
В IKE-заголовке определены следующие поля:
Initiator Cookie (8 октетов) - Cookie участника, который инициировал установление или удаление SA.Responder Cookie (8 октетов) - Cookie участника, который является получателем запроса установления или удаления SA.
(рис 8.12) Формат заголовка IKENext Payload (1 октет) - определяет тип следующего содержимого в сообщении.
(рис 8.13) Возможные типы содержимыхMajor Version (4 бита) - старший номер версии используемого протокола.Minor Version (4 бита) - младший номер версии используемого протокола.Exchange Type (1 октет) - тип используемого обмена, который определяет последовательность сообщений и упорядоченность содержимых в каждом сообщении.
(рис 8.14) Возможные типы обменовFlags (1 октет) - определяет конкретные параметры данного обмена.
E (encryption bit) - если установлен, то все содержимые, следующие после заголовка, шифруются, используя алгоритм шифрования, определенный в SA. IKE SA идентифицируется комбинацией Сookie Инициатора и Получателя. Шифрование начинается после того, как оба участника обменяются содержимыми Key Exchange.C (Commit Bit) - используется для синхронизации обмена ключа. Он используется для гарантирования того, что зашифрованный материал не получен прежде, чем участники обменяются сообщениями KE. Commit Bit может быть установлен в любое время любым из участников и может использоваться в обеих фазах. Значение сбрасывается после фазы I. Участник, который не установил Commit Bit, должен ждать информационного обмена, содержащего Notify. Получение информационного обмена говорит о том, что установление SA прошло успешно, и оба участника могут продолжать взаимодействие по зашифрованному каналу. Кроме синхронизации обмена ключа Commit Bit может использоваться для защиты от падения соединения по ненадежным сетям и предохранять от необходимости многочисленных повторных восстановлений.A (authentication only bit) - данный бит используется в информационном обмене, в котором есть содержимое Notify и позволяет передавать информацию с контролем целостности, но без шифрования (так называемый "аварийный режим").Message ID (4 октета) - уникальный идентификатор сообщения используется для идентификации в фазе II. Данное значение создается Инициатором в фазе II переговоров. Во время фазы I переговоров значение должно быть установлено в 0.Length (4 октета) - длина всего сообщения (заголовок + полезные содержания) в октетах.
(рис 8.15) Пример IKE-заголовка2. Общий заголовок содержимого
Каждое содержимое начинается с общего заголовка, который обеспечивает возможность "связывания" нескольких содержимых и позволяет явно определять границы содержимого.
(рис 8.16) Общий заголовок содержимого
Поля общего заголовка содержимого определяются следующим образом:
Next Payload (1 октет) - идентификатор следующего содержимого в сообщении. Это поле обеспечивает возможность "связывания", что предотвращает возможные replay-атаки и атаки, связанные с подделкой одной из сторон.Payload Length (2 октета) - длина текущей полезной информации, включая общий заголовок.3. Атрибуты данных
Существует несколько случаев, когда должны быть переданы атрибуты данных. Примером этого являются атрибуты SA в содержимом Transform. Эти атрибуты данных не являются отдельным содержимым, а присутствуют в других содержимых. Формат атрибутов данных обеспечивает гибкость представления различных типов информации.
(рис 8.17) Атрибуты данных
Поля атрибутов данных определяются следующим образом:
i>Attribute Type (2 октета) - уникальный идентификатор типа атрибута. Типы атрибутов определяются в DOI.
Attribute Format (AF), определяет будут ли атрибуты данных определяться форматом Type/Length/Value (TLV) или короткой формой формата Type/Value (TV). Если бит AF = 0, то атрибуты данных имеют форму TLV. Если бит AF = 1, то атрибуты данных имеют форму TV.
Attribute Length (2 октета) - длина в октетах значения атрибута. При AF = 1 значение атрибута имеет только 2 октета, и поле длины атрибута не представлено.Attribute Value (переменной длины) - значение атрибута, связанное с определенным DOI Attribute Type. Если бит AF = 0, то это поле имеет переменную длину, определяемую полем Attribute Length. Если бит AF = 1, то Attribute Value имеет длину 2 октета.4. Содержимое SA
Содержимое SA используется для выбора алгоритмов, которые будут применяться для защиты трафика. Содержимым SA может быть несколько сообщений Proposal.
В содержимое SA также указано DOI и Situation, при котором ведутся переговоры.
(рис 8.18) Содержимое SA
5. Содержимое Proposal
Сообщение Proposal содержит предложения Инициатора и выбор Получателя о наборах алгоритмов, используемых для защиты трафика.
(рис 8.19) Содержимое Proposal
(рис 8.20) Пример Proposal
Proposal # определяет номер Proposal для текущего содержимого.
Protocol-Id определяет идентификатор протокола. Примерами являются IKE, ESP, AH.
SPI Size - длина SPI. В случае протокола IKE пара Сookie Инициатора и Получателя из заголовка идентифицируют IKE, следовательно, SPI Size не имеет значения и может быть от нуля до 16.
# of Transforms определяет количество преобразований для Proposal. Каждое из них указано в содержимом Transform.
6. Содержимое Transform
Содержимое Transform состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности соединения. Transform также может содержать атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты определяются DOI.
(рис 8.21) Содержимое Transform
7. Содержимое Key Exchange
Содержимое Key Exchange поддерживает различные технологии обмена ключа. Примерами обменов ключа являются обмен ключа Диффи-Хеллмана, расширенный обмен ключа Диффи-Хеллмана или обмен ключа на основе RSA.
(рис 8.22) Содержимое Key Exchange
8. Содержимое Identification
В содержимом Identification представлены идентификационные данные.
(рис 8.23) Содержимое Identification
9. Содержимое Certificate
Содержимое Certificate обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, и может появляться в любом сообщении.
(рис 8.24) Содержимое Certificate
Certificate Encoding - данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data.
Certificate Data - конкретное представление данных сертификата. Тип сертификата определяется полем Certificate Encoding.
10. Содержимое Certificate Request
Содержимое Certificate Request обеспечивает способ запроса сертификатов и может появиться в любом сообщении. Получатель Certificate Request должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request.
(рис 8.25) Содержимое Certificate Request
Certificate Authority содержит список сертификационных центров, открытые ключи которых есть у принимающей стороны. Например, для сертификата Х.509 оно должно содержать DN CA, принимаемого Инициатором. Это должно помочь Получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос. Если требуемый корневой сертификационный центр не важен, данное поле отсутствует.
11. Содержимое Hash
Hash содержит данные, создаваемые хэш-функцией (определенной при установлении SA), которая вычисляется для некоторой части сообщения и/или состояния протокола. Данное содержимое может использоваться для проверки целостности данных в IKE-сообщении или для аутентификации участников протокола.
(рис 8.26) Содержимое Hash
12. Содержимое Signature
Signature содержит данные, созданные функцией создания цифровой подписи (выбранной во время установления SA) для некоторой части сообщения и/или состояния протокола. Данное содержимое используется для аутентификации отправителя и проверки целостности данных в IKE-сообщении и может быть использовано для сервисов невозможности отказа.
(рис 8.27) Содержимое Signature
13. Содержимое Nonce
Nonce содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. Nonce могут передаваться как часть данных обмена ключа или как отдельное содержимое.
(рис 8.28) Содержимое Nonce
14. Содержимое Notification
Notification может содержать как определяемые IKE, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification в одном сообщении IKE.
(рис 8.29) Содержимое Notification
Notification, которые посылаются фазе I переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE. Идентификатором протокола в данном случае является IKE, значение SPI равно 0. Если Notification передается до обмена ключевой информацией, то оно не будет защищено.
Notification, которые передаются во время фазы II переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE, а также Message ID и SPI, если они определены на данной стадии протокола.
Protocol-Id определяет идентификатор протокола для данного уведомления. Примерами протокола являются IKE, ESP, AH.
SPI Size - длина SPI в октетах как определено в Protocol-Id. В случае IKE пара Cookie Инициатора и Получателя из заголовка IKE выполняют функции IKE SPI, следовательно, SPI Size не имеет значения и может быть от 0 до 16.
Notify Message Type определяет тип сообщения уведомления. Дополнительная информация размещается в поле Notification Data.
15. Содержимое Delete
Delete содержит идентификатор SA, которую Инициатор удаляет из своей SAD. Возможна посылка нескольких SPI в одном Delete, однако каждый SPI должен быть предназначен для того же самого протокола. Нескольких идентификаторов протоколов в Delete быть не может.
(рис 8.30) Содержимое Delete
Удаление, которое относится к IKE SA, содержит в качестве идентификатора протокола IKE, в качестве SPI указываются Cookies Инициатора и Получателя из заголовка IKE. Удаление, которое выполняется для таких протоколов, как ESP или АН, будет содержать идентификатор этого протокола (т.е. ESP, AH), и SPI SA.
# of SPIs - количество SPI, содержащихся в Delete. Размер каждого SPI определяется полем SPI Size
Security Parameter Index - идентификаторы, определяющие удаляемые безопасные ассоциации.
Будем использовать следующие обозначения.
HDR – заголовок сообщения. Запись HDR* означает, что одержимое сообщения зашифровано.
SA – сообщение SA, которое содержит один или более Proposal. Инициатор посылает несколько Proposal, упорядоченных в соответствии со своим приоритетом. Получатель должен выбрать только один Proposal.
CKY-I и CKY-R есть Cookie Инициатора и Получателя соответственно.
gXi и gXr – открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно.
КЕ – сообщение обмена ключа, т.е. открытые значения, которыми обмениваются в алгоритме Диффи-Хеллмана.
Nx – сообщение Nonce; x может быть i или r для Инициатора и Получателя соответственно.
IDx – содержимое идентификации для х. Х может быть ii или ir для Инициатора и Получателя во время фазы I; или ui или ur для Инициатора и Получателя во время фазы II.
SIG – сообщение подписи. Подписываемые данные зависят от типа обмена.
CERT – сообщение, содержащее сертификат.
HASH (HASH(2)или HASH_I) – сообщение, содержащее хэш данных, которые зависят от способа аутентификации.
PRF (key, msg) – псевдослучайная функция. Чаще всего используется хэш-функция с ключом, результатом которой является значение, которое удовлетворяет требованиям к случайным числам. PRF используется как для получения ключа, так и для аутентификации участников при использовании аутентификации по общему секрету.
SKEYID – значение, полученное из секрета и известное только участникам обмена.
SKEYID_e – ключ, используемый для обеспечения конфиденциальности сообщений.
SKEYID_а – ключ, используемый для проверки целостности сообщений.
SKEYID_d – ключ, используемый для получения ключей для безопасных ассоциаций, создаваемых в фазе II, т.е. АН SA и ESP SA.
Обзор протокола
Протокол IKE имеет две фазы, в каждой из которых может быть выполнено несколько обменов.
В результате фазы I участники устанавливают защищенный канал, который называется IKE SA. В фазе I определено два режима: Main Mode и Aggressive Mode.
Фаза II начинается после установления IKE SA. Для второй фазы обмена определен режим Quick Mode.
Преимущество использования двух фаз обмен ключа состоит в том, что для создания нескольких SA требуется выполнение только одной фазы I. Main Mode фазы I обеспечивает защиту идентификации. Когда нет необходимости в защите идентификации, может использоваться Aggressive Mode для уменьшения числа взаимных передач.
Участники фазы I договариваются о следующих параметрах.
Все эти параметры являются обязательными, и о них должны вестись переговоры. Кроме того, возможны дополнительные переговоры о псевдослучайной функции (PRF). Если переговоры о ней не ведутся, то используется HMAC с хэш-алгоритмом, о котором договорились.
Группа Диффи-Хеллмана определяется по номеру.
(рис 8.31) Задание группы Диффи-Хеллмана
Обмены
Существует два режима, используемых в фазе I: Main Mode и Aggressive Mode. В обоях случаях создается аутентифицированный ключевой материал, полученный из обмена открытыми значениями алгоритма Диффи-Хеллмана. В фазе II используется Quick Mode для создания нового материала ключа и ведения переговоров о AH SA или ESP SA.
Первым посылается сообщение SA.
Открытое значение Диффи-Хеллмана передается в содержимом КЕ в фазе I, оно может передаваться в фазе II обмена, если требуется PFS. Длина открытого значения Диффи-Хеллмана определяется в сообщении SA.
Main Mode обеспечивает защиту идентификаций. В первых двух сообщениях договариваются об используемых алгоритмах; в следующих двух сообщениях обмениваются открытыми значениями Диффи-Хеллмана и случайными значениями; последние два сообщения аутентифицируют обмен Диффи-Хеллмана. Метод аутентификации определяется при переговорах в первых сообщениях и влияет на последовательность сообщений.
В первых двух сообщениях Aggressive Mode договариваются об используемых алгоритмах, обмениваются открытыми значениями Диффи-Хеллмана, случайными значениями и идентификациями. Второе сообщение аутентифицирует Получателя. Третье сообщение аутентифицирует Инициатора.
Определено два метода аутентификации как для Main Mode, так и для Aggressive Mode - цифровая подпись и предварительно распределенный секрет.
Значение SKEYID для каждого метода аутентификации вычисляется по своему алгоритму.
Для подписей:
SKEYID = PRF (Ni | Nr, gxy)
Для предварительно распределенного секрета:
SKEYID = PRF (pre-shared-key, Ni | Nr)
Результатом как Main Mode, так и Aggressive Mode являются три ключа:
SKEYID_d = PRF (SKEYID, gxy | CKY-I | CKY-R|0) SKEYID_a = PRF (SKEYID, SKEYID_d | gxy | CKY-I | CKY-R|1) SKEYID_e = PRF (SKEYID, SKEYID_a | gxy | CKY-I | CKY-R|2)
и согласованные алгоритмы для защиты дальнейших взаимодействий. Ключ, используемый для шифрования, получается из SKEYID_e с помощью алгоритма, о котором договорились в первых сообщениях.
Для проверки целостности обмена и аутентификации участников Инициатор вычисляет HASH_I, и Получатель создает HASH_R, где:
HASH_I = PRF (SKEYID, gXi | gXr | CKY-I | CKY-R |SAi|IDii) HASH_R = PRF (SKEYID, gXr | gXi | CKY-R | CKY-I |SAi|IDir)
При аутентификации с помощью цифровых подписей HASH_I и HASH_R подписаны; при аутентификации предварительно распределенным секретом HASH_I и HASH_R непосредственно аутентифицируют обмен.
Метод аутентификации влияет на последовательность сообщений и использование сообщений в фазе I.
Фаза I с аутентификацией с помощью подписей
Последовательность сообщений в Main Mode с аутентификацией с помощью подписей следующая:
(рис 8.32) Main Mode с аутентификацией с помощью цифровых подписей
Последовательность сообщений в Aggressive Mode с аутентификацией с помощью подписей следующая:
(рис 8.33) Aggressive Mode с аутентификацией с помощью цифровых подписей
В обоих режимах подписи SIG_I или SIG_R выполняются для HASH_I и HASH_R соответственно.
Фаза I с аутентификацией по предварительно распределенному секрету
Общий ключ, разделяемый Инициатором и Получателем, используется для аутентификации участников и обеспечения целостности сообщений.
Когда выполняется аутентификация по предварительно распределенному секрету, последовательность сообщений в Main Mode следующая:
(рис 8.34) Main Mode с аутентификацией по предварительно распределенному секрету
В Aggressive Mode с аутентификацией по предварительно распределенному секрету последовательность сообщений следующая:
(рис 8.35) Aggressive Mode с аутентификацией по предварительно распределенному секрету
При использовании аутентификации по предварительно распределенному секрету в Main Mode ключ может идентифицироваться только по IP-адресу противоположной стороны, так как HASH_I вычисляется до того, как Инициатор получит IDir.
Фаза II – Quick Mode
Quick Mode сам по себе законченным обменом не является. Это означает, что он связан с фазой I обмена, так как использует ключи, вычисленные на фазе I. Сообщения, которыми обмениваются в Quick Mode, зашифрованы алгоритмами и ключами, определенными в фазе I, т.е. все сообщения, за исключением заголовка будут зашифрованы. Первое сообщение HASH проверяет, что соединение не сброшено и аутентифицирует участников.
Quick Mode выполняет переговоры об SA и обменивается Nonce, которые обеспечивают защиту от повторов. Nonce используются для создания нового материала ключа и предотвращения replay-атак, в результате которых могут быть созданы ложные SA. Можно произвести обмен дополнительным сообщением KE, чтобы для SA, созданной на фазе II, полностью обновить ключи.
Базовый Quick Mode (без содержимого KE) вычисляет ключи, из клю-чевого материала, созданного в фазе I. Считается, что это хуже, так как не обеспечивается PFS. При использовании дополнительного сообщения KE ключи полностью обновляются.
При Quick Mode последовательность сообщений следующая:
(рис 8.36) Quick Mode
HASH(1)вычисляется PRF для поля Message-ID (M-ID) из заголовка, присоединенного ко всему сообщению.
HASH(2)вычисляется аналогично HASH(1). Включение Nonce как Инициатора, так и Получателя в HASH(2)сделано для того, чтобы подтвердить жизнеспособность SA.
HASH (3) также вычисляется для доказательства жизнеспособности.
HASH(1) = PRF (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | Idcr ]) HASH(2) = PRF (SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDci | Idcr ]) HASH (3) = PRF (SKEYID_a, 0 | M-ID | Ni | Nr)
Если политика не требует PFS, т.е. обмен сообщениями KE не выполняется, то новый материал ключа вычисляется следующим образом:
KEYMAT = PRF (SKEYID_d, protocol | SPI | Ni | Nr)
Если PFS требуется, и участники обмениваются содержимым KE, то новый материал ключа вычисляется следующим образом:
KEYMAT = PRF (SKEYID_d, g (qm)xy | protocol | SPI | Ni | Nr)
Где g (qm)xy является разделяемым секретом из последнего обмена Диффи-Хеллмана, выполненного в Quick Mode.
Значения Protocol и SPI берутся из сообщения Proposal из Quick Mode.
В ситуации, когда суммарная длина требуемых ключей больше, чем длина выходного значения PRF, KEYMAT расширяется конкатенацией результатов до тех пор, пока не будет получено необходимое количество битов ключа.
KEYMAT = K1 | K2 | K3 | …
Где
K1 = PRF (SKEYID_d, [g (qm)xy | ] protocol | SPI |Ni| Nr) K2 = PRF (SKEYID_d, K1 | [g (qm)xy |]protocol|SPI|Ni| Nr) K3 = PRF (SKEYID_d, K2 | [g (qm)xy |]protocol|SPI|Ni| Nr)
В Quick Mode за один обмен можно договориться о создании нескольких SA:
(рис 8.37) Quick Mode с созданием нескольких SA
В различные моменты при выполнении IKE SA стороны могут захотеть сообщить друг другу о возникших ошибках или уведомить о возникших событиях. Для выполнения этого определен информационный обмен. Информационные обмены должны осуществляться только после выполнения обмена ключом, чтобы они были криптографически защищены.
Управляющие сообщения, которые относятся к IKE SA, должны быть посланы в IKE SA. Управляющие сообщения, которые относятся к ESP или АН SA, должны быть посланы под защитой IKE SA, под управлением которой они созданы.
Сообщения информационного обмена могут содержать несколько Notification, Delete и Configuration содержимых. Получатель запроса информационного обмена должен послать ответ, так как в противном случае Инициатор будет предполагать, что сообщение было потеряно, и будет повторять его.
Использование таймеров ретрансмиссии
Для каждой пары сообщений Инициатор выполняет повторную передачу, если по истечению таймаута он не получил подтверждение о получении. Получатель никогда не должен повторять ответ, пока он не получит повтор запроса. В этом случае Получатель должен отправить повторный ответ. Инициатор должен запоминать каждый запрос до тех пор, пока он не получит ответ, чей последовательный номер больше, чем последовательный номер в ответе плюс его собственный размер окна.
IKE является надежным протоколом в том смысле, что Инициатор должен повторять запрос до тех пор, пока он не получит соответствующий ответ или он решит, что IKE SA упала, и он сбросит все состояния, связанные с ней и все дочерние SA для протоколов ESP и АН, созданные с использованием данной IKE SA.
Использование последовательных номеров для Message ID
Каждое сообщение IKE содержит в заголовке Message ID. Данный Message ID используется для идентификации сообщений в протоколе IKE.
Заметим, что Message ID криптографически защищен, и обеспечивается защита против повторных сообщений.
Для увеличения производительности конечные точки соединения могут создавать несколько запросов до того, как получат ответ на любой из них, если другая конечная точка указывает возможность обработки таких запросов.
Синхронизация состояния и таймауты соединения
Состояния IKE SA и связанных с ней AH SA и ESP SA могут быть в любой момент потеряны. Это обычно происходит в случае останова или перезапуска конечной точки. Важно, что когда происходит сбой конечной точки или повторная инициализация ее состояния, то противоположная конечная точка должна иметь возможность определить эту ситуацию и не продолжать бессмысленную посылку пакетов по разрушенной SА.
Так как IKE разрабатывался для противодействия DoS-атакам, конечная точка не должна делать вывод о падении противоположной конечной точки, основываясь на какой-либо информации маршрутизации (например, ICMP-сообщениях) или IKE-сообщениях, которые были получены без криптографической защиты (например, Notify-сообщения, уведомляющие о проблемах неизвестных SPI). Конечная точка должна делать вывод, что другая конечная точка упала только тогда, когда она не получает ответа за определенный период на повторные попытки связаться или когда получено криптографически защищенное уведомление INITIAL_CONTACT по другой IKE SA для той же самой аутентифицированной идентификации. Конечная точка может подозревать, что на противоположной стороне произошел сбой, основываясь на информации маршрутизации, и инициировать запрос, который бы показал ей, что данная конечная точка жизнеспособна. Для проверки жизнеспособности другой стороны определено пустое INFORMATIONAL сообщение, которое (подобно всем IKE-запросам) требует подтверждения о получении. Если криптографически защищенное сообщение получено от другой стороны недавно, незащищенные уведомления могут игнорироваться. Производители могут ограничить темп, с которым они будут действовать, основываясь на незащищенных сообщениях.
Если существует только исходящий трафик по всем SA, связанным с IKE SA, то особенно важно подтверждение жизнеспособности другой ко-нечной точки, чтобы избежать появления черных дыр. Если не было полу-чено никаких криптографически защищенных сообщений по IKE SA или по любой ESP или AH SA в течение определенного периода времени, необходимо выполнить проверку жизнеспособности, чтобы избежать посылки сообщений прекратившему существование участнику. Получение свежего криптографически защищенного сообщения по IKE SA или по любой ESP или AH SA гарантирует жизнеспособность IKE SA или ESP и AH SA.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.