WikiDer > Обмен ключами в Интернете

Internet Key Exchange

В вычисление, Обмен ключами в Интернете (АЙКиногда IKEv1 или IKEv2, в зависимости от версии) - это протокол, используемый для настройки ассоциация безопасности (SA) в IPsec набор протоколов. IKE основывается на Протокол Окли и ИСАКМП.[1] IKE использует X.509 сертификаты для аутентификации - либо предварительные, либо распространенные с использованием DNS (желательно с DNSSEC) - и Обмен ключами Диффи – Хеллмана создать общий секрет сеанса откуда криптографические ключи получены.[2][3] Кроме того, необходимо вручную поддерживать политику безопасности для каждого однорангового узла, который будет подключаться.[2]

История

В Инженерная группа Интернета (IETF) первоначально определил IKE в ноябре 1998 г. в серии публикаций (Запрос комментариев) известный как RFC 2407, RFC 2408 и RFC 2409:

  • RFC 2407 определил домен интерпретации IP-безопасности Интернета для ISAKMP.[4]
  • RFC 2408 определил протокол ассоциации безопасности Интернета и управления ключами (ISAKMP). [5]
  • RFC 2409 определил Интернет-обмен ключами (IKE). [6]

RFC 4306 обновил IKE до версии 2 (IKEv2) в декабре 2005 г.[7] RFC 4718 прояснил некоторые открытые детали в октябре 2006 года.[8] RFC 5996 объединили эти два документа и дополнительные пояснения в обновленный IKEv2,[9] опубликовано в сентябре 2010 г. В результате более позднего обновления документ был обновлен с «Предлагаемый стандарт» до Интернет Стандарт, опубликовано как RFC 7296 в октябре 2014 г.

Головная организация IETF, Интернет-общество (ISOC), сохранила авторские права на эти стандарты как свободно доступные для Интернет-сообщества.

Архитектура

Большинство реализаций IPsec состоят из IKE. демон что работает в пространство пользователя и стек IPsec в ядро который обрабатывает фактические IP пакеты.

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

Протокол IKE использует UDP пакетов, обычно на порте 500, и обычно требуется 4–6 пакетов с 2–3 циклическими обходами для создания SA (охранное объединение) с обеих сторон. Затем согласованный ключевой материал передается в стек IPsec. Например, это может быть AES ключ, информация, определяющая конечные IP-точки и порты, которые должны быть защищены, а также тип туннеля IPsec, созданный. Стек IPsec, в свою очередь, перехватывает соответствующие IP-пакеты, если и где это необходимо, и выполняет шифрование / дешифрование по мере необходимости. Реализации различаются в зависимости от того, как выполняется перехват пакетов - например, некоторые используют виртуальные устройства, другие берут часть из брандмауэра и т. Д.

IKEv1 состоит из двух фаз: фазы 1 и фазы 2.[10]

Фазы IKEv1

Первая фаза IKE - установить безопасный канал связи с аутентификацией с помощью Обмен ключами Диффи – Хеллмана алгоритм для генерации общего секретного ключа для шифрования дальнейших коммуникаций IKE. Эти переговоры приводят к единому двунаправленному ИСАКМП Ассоциация безопасности (SA).[11] Аутентификация может быть выполнена с использованием либо предварительный общий ключ (общий секрет), подписи или шифрование с открытым ключом.[12] Фаза 1 работает либо в основном режиме, либо в агрессивном режиме. Основной режим защищает идентичность одноранговых узлов и хэш общего ключа путем их шифрования; В агрессивном режиме нет.[10]

На втором этапе IKE одноранговые узлы IKE используют безопасный канал, установленный на этапе 1, для согласования ассоциаций безопасности от имени других служб, например IPsec. Согласование приводит как минимум к двум однонаправленным ассоциациям безопасности (одно входящее и одно исходящее).[13] Фаза 2 работает только в быстром режиме.[10]

Проблемы с IKE

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

Спецификации IKE были открыты для значительной степени интерпретации, граничащей с проектными ошибками (Обнаружение мертвого узла являясь примером[нужна цитата]), что приводит к тому, что различные реализации IKE не могут вообще создать согласованную ассоциацию безопасности для многих комбинаций параметров, независимо от того, правильно ли они настроены, они могут появляться на любом конце.

Улучшения с IKEv2

Протокол IKEv2 описан в Приложении А к RFC 4306 в 2005 году. Решены следующие вопросы:

  • Меньше Запрос комментариев (RFC): спецификации для IKE были охвачены по крайней мере в трех RFC, и больше, если принять во внимание Обход NAT и другие широко используемые расширения. IKEv2 объединяет их в одном RFC а также внесение улучшений в поддержку Обход NAT (Трансляция сетевых адресов (NAT)) и брандмауэр обход в целом.
  • Поддержка стандартной мобильности: существует стандартное расширение для IKEv2 под названием [rfc: 4555 Mobility and Multihoming Protocol] (MOBIKE) (см. Также, IPsec) используется для поддержки мобильности и множественной адресации для него и Инкапсуляция полезной нагрузки безопасности (ESP). Используя это расширение IKEv2 и IPsec может использоваться мобильными и многосетевыми пользователями.
  • Обход NAT: Инкапсуляция IKE и ESP в Протокол пользовательских датаграмм (Порт UDP 4500) позволяет этим протоколам проходить через устройство или брандмауэр, выполняющий NAT.[14]
  • Протокол передачи управления потоком (SCTP) поддержка: IKEv2 позволяет SCTP протокол, используемый в протоколе Интернет-телефонии, Голос по IP (VoIP).
  • Простой обмен сообщениями: IKEv2 имеет один механизм начального обмена с четырьмя сообщениями, где IKE предоставляет восемь совершенно разных механизмов начального обмена, каждый из которых имеет небольшие преимущества и недостатки.
  • Меньше криптографических механизмов: IKEv2 использует криптографические механизмы для защиты своих пакетов, которые очень похожи на то, что IPsec ESP использует для защиты пакетов IPsec. Это привело к упрощению внедрения и сертификации для Общие критерии и FIPS 140-2 (Федеральный стандарт обработки информации (FIPS), которые требуют отдельной проверки каждой криптографической реализации.
  • Надежность и управление состоянием: IKEv2 использует порядковые номера и подтверждения для обеспечения надежности и требует некоторой логистики обработки ошибок и общего управления состоянием. IKE мог оказаться в мертвом состоянии из-за отсутствия таких мер надежности, когда обе стороны ожидали, что другой инициирует действие, которое так и не произошло. Обходы (например, Обнаружение мертвого узла) были разработаны, но не стандартизированы. Это означало, что разные реализации обходных путей не всегда были совместимы.
  • Отказ в обслуживании Устойчивость к атакам (DoS): IKEv2 не выполняет большой обработки, пока не определит, действительно ли существует запрашивающая сторона. Это решило некоторые проблемы DoS, с которыми сталкивался IKE, который выполнял бы много дорогостоящей криптографической обработки из подделанный локации.
Предположим HostA имеет Указатель параметров безопасности (SPI) из А и HostB имеет SPI из B, сценарий будет выглядеть так:
HostA ------------------------------------------------- - HostB | HDR (A, 0), sai1, kei, Ni --------------------------> | | <---------------------------- HDR (A, 0), N (cookie) | | HDR (A, 0), N (cookie), sai1, kei, Ni ----------------> | | <-------------------------- HDR (A, B), SAr1, ker, Nr |
Если HostB (ответчик) испытывает большое количество полуоткрытых соединений IKE, он отправит незашифрованное ответное сообщение IKE_SA_INIT к HostA (инициатор) с уведомляющим сообщением типа ПЕЧЕНЬЕ, и будет ожидать HostA послать IKE_SA_INIT запрос с этим значением cookie в полезной нагрузке уведомления для HostB. Это необходимо для того, чтобы инициатор действительно мог обрабатывать ответ IKE от ответчика.

Расширения протокола

Рабочая группа IETF ipsecme стандартизировала ряд расширений с целью модернизации протокола IKEv2 и его лучшей адаптации к крупным производственным средам. Эти расширения включают:

  • Возобновление сеанса IKE: возможность возобновить неудачный «сеанс» IKE / IPsec после сбоя, без необходимости проходить весь процесс настройки IKE (RFC 5723).
  • Перенаправление IKE: перенаправление входящих запросов IKE, позволяющее упростить балансировку нагрузки между несколькими конечными точками IKE (RFC 5685).
  • Видимость трафика IPsec: специальная маркировка пакетов ESP, которые аутентифицированы, но не зашифрованы, с целью упрощения работы промежуточных ящиков (например, системы обнаружения вторжений) для анализа потока (RFC 5840).
  • Взаимная аутентификация EAP: Поддержка для EAP- аутентификация только (т. е. без сертификата) обоих узлов IKE; цель - учесть современные аутентификация на основе пароля методы, которые будут использоваться (RFC 5998).
  • Быстрое обнаружение сбоев: минимизация времени до тех пор, пока одноранговый узел IKE не обнаружит, что его противоположный узел потерпел крах (RFC 6290).
  • Расширения высокой доступности: улучшение синхронизации протокола уровня IKE / IPsec между кластером конечных точек IPsec и одноранговым узлом, чтобы уменьшить вероятность разрыва соединения после события аварийного переключения (RFC 6311).

Реализации

IKE поддерживается как часть IPsec реализация в Windows 2000, Windows XP, Windows Server 2003, Виндоус виста и Windows Server 2008.[15] Реализация ISAKMP / IKE была совместно разработана Cisco и Microsoft.[16]

Microsoft Windows 7 и Windows Server 2008 R2 частично поддерживает IKEv2 (RFC 7296) а также МОБАЙК (RFC 4555) сквозь Переподключение VPN функция (также известная как Гибкая VPN).

Существует несколько реализаций IPsec с открытым исходным кодом со связанными возможностями IKE. На Linux, Libreswan, Openswan и сильный реализации предоставляют демон IKE, который может настраивать (т. е. устанавливать SA) стеки IPsec на основе ядра KLIPS или XFRM / NETKEY. XFRM / NETKEY - это Linux собственная реализация IPsec, доступная с версии 2.6.

В Распространение программного обеспечения Berkeley также есть реализация IPsec и демон IKE, и, что наиболее важно, криптографическая структура (Криптографическая структура OpenBSD, OCF), что делает поддержку криптографические ускорители намного легче. OCF недавно был перенесен на Linux.

Значительное количество поставщиков сетевого оборудования создали свои собственные демоны IKE (и реализации IPsec) или лицензируют стек друг у друга.

Существует ряд реализаций IKEv2, и некоторые компании, занимающиеся сертификацией IPsec и тестированием совместимости, начинают проводить семинары по тестированию, а также обновляют требования к сертификации для тестирования IKEv2. ICSA Labs провела свой последний семинар по совместимости IKEv2 в Орландо, штат Флорида, в марте 2007 г. с участием 13 поставщиков со всего мира.

В настоящее время доступны следующие реализации IKEv2 с открытым исходным кодом:

Уязвимости

Утечка АНБ презентации, выпущенные Der Spiegel указывают, что IKE используется неизвестным образом для расшифровки трафика IPSec, как и ИСАКМП.[17] Исследователи, открывшие Тупиковая атака заявить, что нарушение 1024-битного Группа Диффи – Хеллмана приведет к поломке 66% серверов VPN, 18% из миллиона доменов HTTPS и 26% серверов SSH, что, по утверждениям исследователей, согласуется с утечками.[18] Это утверждение было опровергнуто как Эялем Роненом, так и Ади Шамир в своей статье «Критический обзор несовершенной прямой секретности» [19] и Пол Воутерс из Libreswan в статье «66% VPN на самом деле не сломаны» [20]

Конфигурации IPSec VPN, которые позволяют согласовывать несколько конфигураций, подлежат MITM-основан атаки на понижение версии между предлагаемыми конфигурациями, как с IKEv1, так и с IKEv2.[21] Этого можно избежать путем тщательного разделения клиентских систем на несколько точек доступа к услугам с более строгими конфигурациями.

Обе версии стандарта IKE восприимчивы к атаке по словарю в автономном режиме, когда используется пароль с низкой энтропией. Для IKEv1 это верно для основного режима и агрессивного режима.[22][23][24]

Смотрите также

Рекомендации

  1. ^ Интернет-обмен ключами (IKE), RFC 2409, §1 Аннотация
  2. ^ а б RFC 3129: Требования для согласования ключей через Интернет с использованием протокола Kerberized, Инженерная группа Интернета, Июнь 2001 г., стр. 1
  3. ^ RFC 4322: оппортунистическое шифрование с использованием Internet Key Exchange (IKE), Инженерная группа Интернета, Июнь 2001 г., стр. 5
  4. ^ "RFC 2407: домен интерпретации IP-безопасности Интернета для ISAKMP". Инженерная группа Интернета (IETF).
  5. ^ «RFC 2408 Ассоциация интернет-безопасности и протокол управления ключами (ISAKMP)». Инженерная группа Интернета (IETF).
  6. ^ Д. Харкинс. "RFC 2409 Интернет-обмен ключами (IKE)". Инженерная группа Интернета (IETF).
  7. ^ К. Кауфман (Microsoft) (декабрь 2005 г.). "Протокол обмена ключами Интернета (IKEv2) RFC 4306". Инженерная группа Интернета (IETF).
  8. ^ Eronen, P .; Хоффман, П. (октябрь 2006 г.). «Разъяснения и рекомендации по внедрению RFC 4718 IKEv2». Инженерная группа Интернета (IETF).
  9. ^ Кауфман, С .; Hoffman, P .; Nir, Y .; Эронен, П. (сентябрь 2010 г.). «Протокол обмена ключами Интернета (IKEv2) RFC 5996». Инженерная группа Интернета (IETF).
  10. ^ а б c "RFC 2409 Обмен ключами в Интернете (IKE) ", Инженерная группа Интернета (IETF), стр. 5
  11. ^ "RFC 2409 Обмен ключами в Интернете (IKE) ", Инженерная группа Интернета (IETF), стр. 6
  12. ^ "RFC 2409 Обмен ключами в Интернете (IKE) ", Инженерная группа Интернета (IETF), стр. 10-16
  13. ^ "RFC 4306 Протокол обмена ключами в Интернете (IKEv2) ", Инженерная группа Интернета (IETF), стр. 11,33
  14. ^ "RFC 4306: Протокол обмена ключами в Интернете (IKEv2) », Инженерная группа Интернета (IETF), стр. 38-40
  15. ^ Обмен ключами в Интернете: Безопасность протокола Интернета (IPsec): Technet
  16. ^ Использование IPSec в Windows 2000 и XP, часть 1
  17. ^ Полевые возможности: обзор дизайна сквозного VPN SPIN9 (PDF), АНБ через «Шпигель», стр. 5
  18. ^ Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Халдерман, Дж. Алекс; Хенингер, Надя; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; VanderSloot, Бенджамин; Вустров, Эрик; Занелла-Бегелен, Сантьяго; Циммерманн, Пауль (октябрь 2015 г.). Несовершенная прямая секретность: как Диффи-Хеллман терпит неудачу на практике (PDF). 22-я конференция ACM по компьютерной и коммуникационной безопасности (CCS ’15). Денвер. Получено 15 июн 2016.
  19. ^ Ронен, Эял; Шамир, Ади (октябрь 2015 г.). «Критический обзор несовершенной прямой секретности» (PDF). Цитировать журнал требует | журнал = (Помогите)
  20. ^ Воутерс, Пол (октябрь 2015 г.). «66% VPN на самом деле не сломаны».
  21. ^ Бхаргаван, Картикеян; Брзуска, Кристина; Фурне, Седрик; Кольвейс, Маркульф; Занелла-Бегелен, Сантьяго; Грин, Мэтью (январь 2016 г.). «Понижение устойчивости в протоколах обмена ключами» (PDF).
  22. ^ Плиам, Джон (2 октября 1999 г.). «Уязвимости аутентификации в IKE и Xauth со слабыми заранее общими секретами». Университет Джона Хопкинса. В архиве с оригинала от 10 июня 2002 г.. Получено 5 февраля 2020.
  23. ^ МакГрю, Дэвид (5 июля 2011 г.). "Отличный шифр, но где ты взял этот ключ". Блог Cisco. Архивировано из оригинал 9 июля 2011 г.. Получено 11 февраля 2020.
  24. ^ Фельш, Деннис (август 2018 г.). «Опасности повторного использования ключей: практические атаки на IPsec IKE». 27-й симпозиум по безопасности USENIX. Получено 11 февраля 2020.

внешняя ссылка