Политика безопасности
Способы аутентификации участников и распределение ключей
IPSec предполагает возможность как автоматического создания SA, так и создания SA вручную. Следует заметить, что детализированность создаваемых SA определяет детализированность выполняемой аутентификации.
Распределение ключей вручную
Распределение ключей вручную является простейшим способом создания SA, определения алгоритмов и ключей, при котором администратор вручную конфигурирует каждую систему, указывая ключи и другие пара-метры. Такая технология применяется в маленьких, статичных окружениях и не масштабируется. Если количество хостов мало, и если все хосты рас-положены в пределах одного административного домена, то возможно применение ручных технологий распределения ключей. В данном случае трафик будет защищаться c использованием вручную сконфигурированных ключей.
Автоматическое создание SA и распределение ключей
Для обеспечения широкого использования 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.
В первом сообщении Инициатор указывает Initiator Cookie в заголовке IKE (см первую строчку таблицы).
Во втором сообщении Получатель включает поля Initiator и Responder Cookie в заголовок IKE (см вторую строчку таблицы).
Взаимодействующие стороны могут обмениваться дополнительными сообщениями в зависимости от типа обмена, используемого в первой фазе переговоров. В течение первой фазы переговоров Cookies Инициатора и Получателя включаются в заголовок IKE всех обменов и определяют IKE SA. Поле SPI в содержимом Proposal установлено в 0 или может содер-жать Сookie взаимодействующих участников.
После завершения I фазы Инициатор определяет Message ID для протоколов, которые будут выполняться в данной SA. Этот Message ID Инициатора указывается для каждого протокола.
SPI будут использоваться для идентификации SA только после завершения второй фазы переговоров (см шестую строчку таблицы).
Формат сообщений
Наличие и последовательность содержимых в сообщении определяется полем Exchange Type.
1. Формат заголовка ISAKMP/IKE
Сообщение IKE имеет фиксированный формат заголовка, за которым следует переменное число содержимых. Этот заголовок содержит информацию, необходимую для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.
В IKE-заголовке определены следующие поля:
- Initiator Cookie (8 октетов) - Cookie участника, который инициировал установление или удаление SA.
- Responder Cookie (8 октетов) - Cookie участника, который является получателем запроса установления или удаления SA.
- Next Payload (1 октет) - определяет тип следующего содержимого в сообщении.
- Major Version (4 бита) - старший номер версии используемого протокола.
- Minor Version (4 бита) - младший номер версии используемого протокола.
- Exchange Type (1 октет) - тип используемого обмена, который определяет последовательность сообщений и упорядоченность содержимых в каждом сообщении.
-
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 октета) - длина всего сообщения (заголовок + полезные содержания) в октетах.
2. Общий заголовок содержимого
Каждое содержимое начинается с общего заголовка, который обеспечивает возможность "связывания" нескольких содержимых и позволяет явно определять границы содержимого.
Поля общего заголовка содержимого определяются следующим образом:
- Next Payload (1 октет) - идентификатор следующего содержимого в сообщении. Это поле обеспечивает возможность "связывания", что предотвращает возможные replay-атаки и атаки, связанные с подделкой одной из сторон.
- Payload Length (2 октета) - длина текущей полезной информации, включая общий заголовок.
3. Атрибуты данных
Существует несколько случаев, когда должны быть переданы атрибуты данных. Примером этого являются атрибуты SA в содержимом Transform. Эти атрибуты данных не являются отдельным содержимым, а присутствуют в других содержимых. Формат атрибутов данных обеспечивает гибкость представления различных типов информации.
Поля атрибутов данных определяются следующим образом:
-
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, при котором ведутся переговоры.
5. Содержимое Proposal
Сообщение 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.
7. Содержимое Key Exchange
Содержимое Key Exchange поддерживает различные технологии обмена ключа. Примерами обменов ключа являются обмен ключа Диффи-Хеллмана, расширенный обмен ключа Диффи-Хеллмана или обмен ключа на основе RSA.
8. Содержимое Identification
В содержимом Identification представлены идентификационные данные.
9. Содержимое Certificate
Содержимое Certificate обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, и может появляться в любом сообщении.
Certificate Encoding - данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data.
Certificate Data - конкретное представление данных сертификата. Тип сертификата определяется полем Certificate Encoding.
10. Содержимое Certificate Request
Содержимое Certificate Request обеспечивает способ запроса сертификатов и может появиться в любом сообщении. Получатель Certificate Request должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request.
Certificate Authority содержит список сертификационных центров, открытые ключи которых есть у принимающей стороны. Например, для сертификата Х.509 оно должно содержать DN CA, принимаемого Инициатором. Это должно помочь Получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос. Если требуемый корневой сертификационный центр не важен, данное поле отсутствует.
11. Содержимое Hash
Hash содержит данные, создаваемые хэш-функцией (определенной при установлении SA), которая вычисляется для некоторой части сообщения и/или состояния протокола. Данное содержимое может использоваться для проверки целостности данных в IKE-сообщении или для аутентификации участников протокола.
12. Содержимое Signature
Signature содержит данные, созданные функцией создания цифровой подписи (выбранной во время установления SA) для некоторой части сообщения и/или состояния протокола. Данное содержимое используется для аутентификации отправителя и проверки целостности данных в IKE-сообщении и может быть использовано для сервисов невозможности отказа.
13. Содержимое Nonce
Nonce содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. Nonce могут передаваться как часть данных обмена ключа или как отдельное содержимое.
14. Содержимое Notification
Notification может содержать как определяемые IKE, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification в одном сообщении IKE.
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 быть не может.
Удаление, которое относится к IKE SA, содержит в качестве идентификатора протокола IKE, в качестве SPI указываются Cookies Инициатора и Получателя из заголовка IKE. Удаление, которое выполняется для таких протоколов, как ESP или АН, будет содержать идентификатор этого протокола (т.е. ESP, AH), и SPI SA.
# of SPIs - количество SPI, содержащихся в Delete. Размер каждого SPI определяется полем SPI Size
Security Parameter Index - идентификаторы, определяющие удаляемые безопасные ассоциации.