IPsec, IKE и смежные технологии Рябко С.Д., к.ф.-м.н.

IPsec, IKE
и смежные технологии
Рябко С.Д., к.ф.-м.н.
СТАНДАРТ СЕТЕВОЙ БЕЗОПАСНОСТИ ДЛЯ РОССИЙСКОГО БИЗНЕСА
Cisco Solution Technology Integrator
IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ
Предпосылки и требования
Архитектура IPsec
Протокол IKE
Применения
Литература
Предпосылки и
требования
Cisco Solution Technology Integrator
Безопасность ... задолго до TCP IP
Paul Baran. RAND MEMORANDUM RM-3765-PR, AUGUST 1964. On Distributed
Communications: IX Security, Secrecy, and Tamper-Free Considerations
DTE
DCE
L2-шифрование
L3-шифрование
© 2003-2007 S-Terra CSP
3
Проблемы безопасности TCP/IP

TCP/IP проектировался, как коммуникационный
протокол с целями:
- надежной передачи данных через гетерогенные физические
среды
- контроля связности сети и маршрутизации
- оптимизации загрузки, адаптации транспортных сервисов к
условиям сети
TCP/IP ИЗНАЧАЛЬНО НЕ ПРОЕКТИРОВАЛСЯ
КАК ЗАЩИЩЕННАЯ КОММУНИКАЦИОННАЯ СРЕДА

Результаты:
-
IP-атаки
ICMP-атаки
атаки на системы маршрутизации
UDP- и TCP-атаки
атаки на уровне прикладных протоколов
© 2003-2007 S-Terra CSP
4
IPsec, зачатие

BOF-сессия IETF в Бостоне в 1992 году, Элтон
Гувер (Alton Hoover):
- «Протокол защиты сетевого уровня будет
создан, чтобы обеспечить криптографические
сервисы защиты: аутентификацию,
целостность, контроль доступа и
конфиденциальность. Первоначальными целями
будет поддержка взаимодействия между
компьютерами, вслед на тем – между двумя
подсетями и между компьютером и подсетью»
© 2003-2007 S-Terra CSP
5
Требования к протоколам защиты
1. Аутентификация, целостность, контроль
доступа и конфиденциальность
2. Cеть-сеть, клиент-сеть, клиент-сервер (др.
клиент)
3. Нейтральность по отношению к
криптоалгоритмам
4. Независимость мастер-ключа и временного
ключа
5. Пересинхронизация ключевых контекстов
-
по мере накопления статистики для криптоанализа
по событиям
6. Целостность потока пакетов  уход от
дейтаграммной природы IP, контекст
соединения, SA
© 2003-2007 S-Terra CSP
6
Требования по управлению ключами
1. Установление ключа (key establishment) – генерация
ключа и доставка его потребителю
2. Аутентификация – поддержка множества механизмов
аутентификации: симметричный ключи и сертификат,
одноразовый пароль и серверы аутентификации
(RADIUS и т.п.), произвольные комбинации этих
механизмов
3. Симметрия – равная способность каждой из сторон
создать ключ для защищенного обмена;
относительная устойчивость к DoS-атаке
4. Защита сеансового ключа (perfect forward secrecy)
5. Независимость сеансовых ключей (back traffic
protection)
6. Согласование политик безопасности сторон
7. Расширяемость (payload, domain of interpretation)
© 2003-2007 S-Terra CSP
7
© 2003-2007 S-Terra CSP
IETF-36, 24-28.VI.1996
IETF-35, 4-8.III.1996
1995
IETF-34, 4-8.XII.1995
(нет информации)
IETF-33, 17-21.VII.1995
IETF-32, 3-7.IV.1995
1994
IETF-31, 5-9.XII.1994
IETF-30, 25-29.VII.1994
IETF-29, 28.III-1.IV.1994
Oakley
RFC 1825-1829
ISAKMP
Photuris
SKIP
История группы IPsec в IETF 1993-1996
40
Общее число рассмотренных предложений
20
Новые спецификации на текущей сессии
0
1996
8
IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ
Предпосылки и требования
Архитектура IPsec
Протокол IKE
Применения
Литература
Архитектура IPsec
Cisco Solution Technology Integrator
IPsec. Основные стандарты


RFC 2402 «IP Authentication Header»
(AH) – обеспечивает целостность и
аутентификацию передаваемых
пакетов, целостность потока пакетов
RFC 2406 «IP Encapsulating Security
Payload» (ESP) – обеспечивает
конфиденциальность (шифрование),
целостность и аутентификацию
источника данных передаваемых
пакетов, ограниченную
конфиденциальность потока данных,
защиту от повторно переданного
пакета
-


© 2003-2007 S-Terra CSP
протоколы AH и ESP могут
использоваться совместно или по
отдельности
RFC 2408 «Internet Security Association
and Key Management Protocol»
(ISAKMP) - обеспечивает согласование
параметров, создание, изменение,
уничтожение контекстов защищенных
соединений (далее – Security
Association, SA) и управление
ключами
RFC 2409 «The Internet Key Exchange»
(IKE) – развитие (адаптация) ISAKMP
для работы с протоколами IPsec
10
Туннельный и транспортный режимы


Протоколы IPsec работают в двух
режимах: транспортном
(взаимодействие хостов) и
туннельном (взаимодействие с
подсетями)
Транспортный режим
-
ниже вычислительные и
коммуникационные накладные
недостатки:
•
•

Туннельный режим
-
-
© 2003-2007 S-Terra CSP
невозможность скрыть топологию сети
ESP в транспортном режиме не защищает
заголовок IP-пакета
взаимодействие сеть-сеть, хостсеть, возможно также – хост-хост
скрывает топологию сети,
поскольку снаружи выставляется
другой заголовок (а исходный
шифруется)
потребляет несколько больше
ресурсов
11
IPsec. Протокол AH



© 2003-2007 S-Terra CSP
Аутентификация
источника и данных
каждого IP пакета
(является
эффективным
методом борьбы с
атаками типа
перехвата,
модификации
трафика и подмены IP
адресов)
Целостность данных
IP пакетов, данные
пакетов передаются в
незашифрованном
виде
Защита от повторной
передачи пакетов
12
IPsec. Протокол AH



При расчете значений хеш-сумм для контроля целостности
данных (integrity check value, ICV) не используются переменные
поля IP-заголовка оригинального пакета
AH заголовок увеличивает длину оригинального IP пакета
приблизительно на 24 байта
Криптографические алгоритмы хеширования поддерживаемые
протоколом AH:
- обязательные (для обеспечения совместимости
продуктов различных производителей):
программных
• HMAC-MD5-96 (RFC 2403)
• HMAC-SHA-1-96 (RFC 2404)
- дополнительные:
• DES-MAC
• HMAC-ГОСТ Р 34.11-94, -2001

Протокол AH может использоваться в туннельном или
транспортном режимах, а также в комбинации с протоколом ESP
© 2003-2007 S-Terra CSP
13
IPsec. Протокол ESP

Протокол ESP
обеспечивает:
- шифрование данных IP
пакета
- дополнительно
(аналогично протоколу
AH):
• аутентификацию
источника каждого IP
пакета
• целостность данных
IP пакетов
• защиту от повторной
передачи пакетов
© 2003-2007 S-Terra CSP
14
IPsec. Протокол ESP


ESP заголовок увеличивает длину оригинального IP пакета
приблизительно на 24 байта
Протокол ESP поддерживает криптографические алгоритмы шифрования:
-
обязательные:
• DES-CBC (RFC 2405)
• NULL (RFC 2410)
-
дополнительные:
•
•
•
•
•

CAST-128 (RFC 2451)
IDEA (RFC 2451)
3DES (RFC 2451)
AES- 128, 192, 256
ГОСТ (ГОСТ 28147-89)
Протокол ESP поддерживает криптографические алгоритмы
хэширования:
-
обязательные:
• HMAC-MD5-96 (RFC 2403)
• HMAC-SHA-1-96 (RFC 2404)
-
дополнительные:
• DES-MAC
• HMAC-ГОСТ Р 34.11-94 , -2001

Протокол ESP может использоваться в туннельном или транспортном
режимах, а также в комбинации с протоколом AH
© 2003-2007 S-Terra CSP
15
AH и ESP в транспортном режиме
© 2003-2007 S-Terra CSP
16
AH и ESP в туннельном режиме
© 2003-2007 S-Terra CSP
17
Контекст безопасности, IPsec SA

Контекст безопасности IPsec, Security Association, SA –
это структура данных, которая организуется при
помощи протокола IKE для защиты трафика в каждом
из направлений
- контекст безопасности уникальным образом определяется,
как комбинация Security Parameter Index (SPI), IP Destination
address и идентификатор протокола AH/ESP


Контексты безопасности соответствуют режиму
AH/ESP – транспортный или туннельный
В случае, если необходимо создать сложную политику
безопасности, которую невозможно описать при
помощи одного контекста (SA), используется «связка
контекстов» (SA bundle). Связки SA применяются для
двух целей:
- в транспортном режиме – для применения одновременно
протоколов AH и ESP
- в туннельном режиме – для создания вложенных туннелей,
которые могут терминироваться в различных точках сети
© 2003-2007 S-Terra CSP
18
Целостность потока пакетов

Целостность пакетов в потоке
обеспечивается механизмами
IPsec AH или IPsec ESP-auth
- эти же механизмы отсекают
«чужой» или «свой»,
модифицированный
злоумышленником, пакет

КАК ЗАЩИТИТЬСЯ ОТ
ПОВТОРНОЙ ПЕРЕДАЧИ
СВОЕГО ПАКЕТА?
- счетчик пакетов 232 (при
инициализации SA
устанавливается в 0 и
инкрементируется для каждого
последующего пакета)
- поскольку пакеты в IP-сети
могут переупорядочиваться,
дуплицироваться и теряться –
оконное управление потоком
© 2003-2007 S-Terra CSP
19
Основные преимущества IPsec


Прозрачность для любых приложений
Полный контроль входящего/исходящего
трафика
- IPsec драйвер размещен в нижней части драйвера,
реализующего IP протокол


Защита от большинства сетевых атак, включая
DoS
Высокая производительность
- используются симметричные криптографические
алгоритмы

Большое количество сценариев защиты
- сочетание AH и ESP протоколов
- туннельный и транспортный режимы
© 2003-2007 S-Terra CSP
20
IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ
Предпосылки и требования
Архитектура IPsec
Протокол IKE
Применения
Литература
Протокол IKE
Cisco Solution Technology Integrator
Протокол IKE



Протоколы IPsec AH и ESP не
самодостаточны в том
смысле, что требуют поставки
ключевого материала и
политики «извне»
Протокол IKE обеспечивает
IPsec необходимыми ключами
и согласованной политикой
Протокол IKE – разработан в
развитие протоколов ISAKMP,
Oakley и SKEME
- полностью защищен
- расширяем (может
применяться для
конфигурирования адресов,
передачи абстрактных данных
- Vendor ID, keep alive и т.п.)
- обеспечивает строгую
взаимную аутентификацию
партнеров
© 2003-2007 S-Terra CSP
22
Функции протокола IKE

Протокол IKE обеспечивает:
- создание ключевого криптографического материала и
взаимную аутентификацию партнеров по взаимодействию при
ключевом обмене
- создание контекстов защищенных взаимно
аутентифицированных соединений (ISAKMP Security
Association, ISAKMP SA) для обмена
ключевой/аутентификационной информацией – первая фаза
протокола IKE
- согласование параметров (политик) защищенных соединений
(IPsec Security Association, IPsec SA) для обмена данными –
вторая фаза протокола IKE
- автоматическую замену криптографических ключей по
задаваемому перечню событий или компрометации
- защиту сеансовых криптографических ключей (Perfect forward
secrecy, PFS)
- строгую взаимную аутентификацию партнеров по
взаимодействию
© 2003-2007 S-Terra CSP
23
Фазы и режимы протокола IKE


Протокол IKE формально разделен на две фазы
Первая фаза может быть реализована в двух разных режимах:
- Main Mode
• более сложен, но при этом более гибок и обеспечивает
анонимность участников (identity protection)

- Aggressive Mode
В рамках первой фазы создается контекст защищенного
соединения ISAKMP SA, все дальнейшие информационные
обмены производятся под его защитой
- однажды созданный на первой фазе контекст ISAKMP SA может
использоваться для нескольких вторых фаз, таким образом, на его
основе может быть создано несколько IPsec SA
© 2003-2007 S-Terra CSP
24
Фазы и режимы протокола IKE




(продолжение)
Вторая фаза реализована в Quick Mode
На второй фазе производится:
- обновление ключевого материала для обеспечения
защищенного обмена данными в рамках IPsec AH и/или ESP
- согласование параметров IPsec SA
- защита сеансовых криптографических ключей (Perfect forward
secrecy, PFS)
Для согласования параметров «собственной» группы DH должна
быть использована New Group Mode, которая должна следовать
сразу за первой фазой, но не является частью Quick Mode
Контекст соединения - ISAKMP SA двунаправленный, т.е. в его
рамках любой из участников взаимодействия может быть
инициатором Quick Mode, New Group Mode и информационных
обменов (Informational Exchanges)
© 2003-2007 S-Terra CSP
25
Структура обменов в IKE



Задача любой фазы (Main, Aggressive и Quick
Modes) – согласовать параметры
взаимодействия, обменяться открытыми
ключами DH и аутентифицировать ключевой
обмен
Согласование параметров производится в
рамках обменов (Exchange)
структурированными (стандартизованными)
сообщениями (Message)
Каждое сообщение формализовано как набор
вложенных структур данных (Payload)
© 2003-2007 S-Terra CSP
26
Первая фаза протокола IKE, Main Mode

Согласование параметров ISAKMP
SA - сообщения 1, 2:
-



Обмен открытыми ключами DH и
служебными данными (Nonces) –
сообщения 3, 4
Расчет ключевого материала для
процедур шифрования и
аутентификации в рамках ISAKMP SA
Взаимная аутентификация –
сообщения 5, 6
-

© 2003-2007 S-Terra CSP
метод аутентификации
время жизни ISAKMP SA
группа DH
алгоритм хэширования
алгоритм шифрования
в Main Mode аутентификационная
информация передается в
зашифрованном виде
Дальнейшие информационные
обмены производятся под защитой
созданного контекста (SA)
27
Первая фаза IKE, Aggressive Mode


Выбор между
безопасностью и
производительностью
Как и в Main Mode партнеры
должны согласовать:
-


метод аутентификации
время жизни ISAKMP SA
группу DH
алгоритм хэширования
алгоритм шифрования
Произвести обмен
открытыми ключами DH и
служебными данными и
расчет ключевого материала
Провести взаимную
аутентификацию
- аутентификационная
информация передается в
открытом виде
© 2003-2007 S-Terra CSP
28
Методы аутентификации

В рамках протокола IKE стандартизованы
четыре метода аутентификации:
- на предопределенных ключах - with a Pre-Shared
Key
- на электронной цифровой подписи - with Signature
- шифрование на открытых ключах
• with Public Key Encryption
• with a Revised Mode of Public Key Encryption
- наиболее широко используемые методы – на
предопределенных ключах и ЭЦП
© 2003-2007 S-Terra CSP
29
Вторая фаза протокола IKE, Quick Mode

Вторая фаза
протокола IKE
реализуется в Quick
Mode
- согласование
параметров IPsec SA
- обновление
ключевого материала
для обеспечения
защищенного обмена
данными в рамках
IPsec AH и/или ESP
- защита сеансовых
криптографических
ключей (Perfect
forward secrecy, PFS)
© 2003-2007 S-Terra CSP
30
IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ
Предпосылки и требования
Архитектура IPsec
Протокол IKE
Применения
Литература
Применения
Cisco Solution Technology Integrator
Роль и место IKE/IPsec

Что мне лучше использовать – защиту
сетевого, транспортного и прикладного
уровня?
- И то, и другое, и третье, но в разных сценариях
- Защита сетевого уровня нужна там, где требуется
создать изолированную доверенную среду
предприятия, единую для всех приложений
- Защита транспортного уровня пригодится там, где у
Вас нет возможности установить для всех
пользователей VPN-клиента, например, в задачах
защиты доступа граждан к порталу госорганов или
в задачах электронной коммерции
- Защита прикладного уровня незаменима при работе
с электронными документами
© 2003-2007 S-Terra CSP
32
L3 или L4 VPN?

Равнозначны (равнозащищены) ли технологии VPN
сетевого (IPsec) и транспортного (SSL, TLS) уровней?
- С точки зрения стойкости криптографий – да
- С точки зрения дизайна криптографических протоколов
предпочтение экспертов принадлежит IKE/IPsec (The Burton
group)
- По целям дизайна протоколы 4го уровня рассчитаны на
защиту отдельного приложения (защита транспортного
соединения порт-порт в системе клиент-сервер). Другие порты
на том же сервере могут быть открыты (и атакованы). VPN
сетевого уровня может защитить сетевую инфраструктуру или
сервер в целом
• Однако в последнее время появились и приобретают
популярность «шлюзовые» L4 VPN-продукты, которые «умеют»
инкапсулировать IP-трафик в SSL/TLS. Такие продукты
функционально практически эквивалентны L3 VPN с двумя
отличиями: (1) функциональность протокола управления
ключами в SSL/TLS много уступает IKE и (2) поскольку это –
«нетрадиционное» использование протокола на сегодня
«шлюзовые» продукты L4 VPN от разных производителей плохо
совместимы между собой
© 2003-2007 S-Terra CSP
33
IPsec в «реальной сети»

Как работает IPsec AH при наличии NAT? (Целостность заголовка
противоречит трансляции адресов)
- В хороших реализациях IKE/IPsec – без проблем. IKE автоматически
детектирует NAT на пути туннеля и включает режим «NAT traversal
IPsec»

Как обстоят дела с фрагментацией?
- Корректный VPN-продукт умеет фрагментировать/
дефрагментировать шифрованный трафик. Однако при этом
производительность шифрования падает. Рекомендуется настройка
MTU «с запасом» на заголовки IPsec

Насколько повышают общую защищенность системы контроля
целостности ESP-auth и AH?
- Полезная функция, однако может приводить к «узкому горлу» в
производительности. Поэтому ряд наших заказчиков устраивает
политика безопасности, когда для защиты трафика используется
IPsec ESP, а целостность потока данных «обеспечивает» TCP
- Также интересным является решение, когда целостность
обеспечивается на «внешних» маршрутизаторах на базе IPsec
AH/MD5, а конфиденциальность – во внутреннем периметре на базе
IPsec ESP/ГОСТ
© 2003-2007 S-Terra CSP
34
Какова избыточность протоколов IPsec?

Зависит от политики безопасности и криптографии. Расчет
Кирилла Корнилова (для IPv4):
- Протокол AH:
• 12 байт + длина digest, все это округляется кратного 4 в большую сторону,
если туннель - еще +20 байт
• длина digest:
• HMAC 96 (SHA1, MD5, ГОСТ) - 12 байт (полное увеличение пакета – 24..44)
• KPDK (MD5) - 16 байт (полное увеличение пакета – 28..48)
-
Протокол ESP:
•
•
•
•
•
•
•
8 байт + длина IV + длина digest + 2 байта, длина шифрованных данных
дополняется до блока алгоритма
если туннель - еще +20 байт
если NAT traversal - еще +8 байт
если нет integrity - длина digest = 0
если нет шифрования - длина блока = 1, длина IV = 0
Длина IV, длина блока:
• DES, 3DES, ГОСТ - 8 байт
• AES - 16 байт
• Например, ESP/ГОСТ без integrity, туннельный режим, без NAT traversal
увеличивает пакет на 38..45 байт
© 2003-2007 S-Terra CSP
35
Еще пара вопросов

Нужен ли IPcomp?
- по нашему опыту статистическая база пакета не
дает возможности обеспечить его существенное
сжатие
- Cisco не рекомендует IPcomp по причинам
снижения производительности (при малой
эффективности сжатия) и плохой совместимости
ПО

Совместимы ли VPN-продукты различных
производителей?
- В базовых протоколах IKE/IPsec – да. Однако из-за
несовместимости дополнительных спецификаций и
различной инфраструктуры/логики управления
целесообразно минимизировать количество
используемых VPN-продуктов
© 2003-2007 S-Terra CSP
36
IPsec, IKE И СМЕЖНЫЕ ТЕХНОЛОГИИ
Предпосылки и требования
Архитектура IPsec
Протокол IKE
Применения
Литература
Литература
Cisco Solution Technology Integrator
Источники разработки
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
RFC 2401, Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November
1998
RFC 2402, IP Authentication Header. S. Kent, R. Atkinson. November 1998
RFC 2403, The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn.
November
1998
RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn.
November 1998
RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N.
Doraswamy.
November 1998
RFC 2406, IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson.
November 1998
RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November
1998
RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). D.
Maughan, M. Schertler, M. Schneider, J. Turner. November 1998
RFC 2409, The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November
1998
RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent.
November 1998
RFC 2411, IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November
1998
RFC 2412, The OAKLEY Key Determination Protocol. H. Orman. November 1998
Московиц Р. Протокол IPSec для групп по интересам // Network Computing. - 2000. - №11.
Busby M. Demystifying Virtual Private Networks. Wordware Publishing, Inc. 2001. 249 p.
A Comprehensive Guide to Virtual Private Networks, Volume II: IBM Nways Router Solutions.
IBM. International Technical Support Organization SG24-5234-01. November 1999. 642 p.
Davies C.R. IPSec: Securing VPNs. Osborne/McGraw-Hill, 2001. - 404 p.
Using IPSec to Construct Secure Virtual Private Networks. International Business Machines
Corporation. 1998. 61 p.
© 2003-2007 S-Terra CSP
38
КОНТАКТЫ
e-mail: information@s-terra.com
web: http://www.s-terra.com/
Тел.:
+7 (495) 531 9789
+7 (495) 726 9891
Факс: +7 (495) 531 9789
Вопросы?
Обращайтесь к нам!
Cisco Solution Technology Integrator