В вычислениях Internet Key Exchange ( IKE , иногда IKEv1 или IKEv2 , в зависимости от версии) - это протокол, используемый для установки ассоциации безопасности (SA) в наборе протоколов IPsec . IKE основан на протоколе Oakley и ISAKMP . [1] IKE использует сертификаты X.509 для аутентификации - либо предварительно совместно используемые, либо распространяемые с использованием DNS (предпочтительно с DNSSEC ) - и обмен ключами Диффи-Хеллмана для установки общего секрета сеанса, из которого криптографические ключиполучены. [2] [3] Кроме того, политика безопасности для каждого узла, который будет подключаться, должна поддерживаться вручную. [2]
История
Целевая группа Internet Engineering (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, The Internet Society (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. Это согласование приводит к единой двунаправленной ассоциации безопасности ISAKMP (SA). [11] Аутентификация может быть выполнена с использованием предварительного общего ключа (общего секрета), подписей или шифрования с открытым ключом. [12] Фаза 1 работает либо в основном режиме, либо в агрессивном режиме. Основной режим защищает идентичность одноранговых узлов и хэш общего ключа путем их шифрования; В агрессивном режиме нет. [10]
На втором этапе IKE одноранговые узлы IKE используют безопасный канал, установленный на этапе 1, для согласования ассоциаций безопасности от имени других служб, таких как IPsec . Согласование приводит как минимум к двум однонаправленным ассоциациям безопасности (одно входящее и одно исходящее). [13] Фаза 2 работает только в быстром режиме. [10]
Проблемы с IKE
Первоначально у IKE было множество вариантов конфигурации, но не было общих средств для автоматического согласования хорошо известного случая по умолчанию, который реализуется повсеместно. Следовательно, обе стороны IKE должны были точно согласовать тип ассоциации безопасности, которую они хотели создать - вариант за вариантом - иначе соединение не могло быть установлено. Дальнейшие сложности возникли из-за того, что во многих реализациях вывод отладки было трудно интерпретировать, если вообще было какое-либо средство для вывода диагностических данных.
Спецификации IKE были открыты в значительной степень интерпретации, граничащие с проектными ошибками ( Dead-Peer-Detection быть примером [ править ] ), что приводит к различным реализациям 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. Это привело к упрощению реализации и сертификации Common Criteria и FIPS 140-2 ( Федеральный стандарт обработки информации (FIPS), которые требуют отдельной проверки каждой криптографической реализации.
- Надежность и управление состоянием: IKEv2 использует порядковые номера и подтверждения для обеспечения надежности и требует некоторой логистики обработки ошибок и общего управления состоянием. IKE мог оказаться в мертвом состоянии из-за отсутствия таких мер надежности, когда обе стороны ожидали, что другая сторона инициирует действие, которое так и не произошло. Обходные решения (такие как Dead-Peer-Detection ) были разработаны, но не стандартизированы. Это означало, что разные реализации обходных путей не всегда были совместимы.
- Устойчивость к атакам типа «отказ в обслуживании» (DoS): IKEv2 не выполняет большой обработки, пока не определит, существует ли на самом деле запрашивающая сторона. Это решило некоторые из проблем DoS, с которыми столкнулся IKE, который выполнял бы много дорогостоящей криптографической обработки из поддельных мест.
- Пред- полагая Хост имеет индекс параметров безопасности (SPI) из
A
и 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
на Хост (инициатор) с уведомят сообщением типаCOOKIE
, и будет ожидать , Хост отправитьIKE_SA_INIT
запрос с этим значением печенья в уведомлении для 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 Vista и Windows Server 2008 . [15] Реализация ISAKMP / IKE была совместно разработана Cisco и Microsoft. [16]
Microsoft Windows 7 и Windows Server 2008 R2 частично поддерживают IKEv2 (RFC 7296), а также MOBIKE (RFC 4555) через функцию повторного подключения VPN (также известную как Agile VPN ).
Существует несколько реализаций IPsec с открытым исходным кодом со связанными возможностями IKE. В Linux , Libreswan , Openswan и strongSwan реализация обеспечивает демон IKE , который можно конфигурировать (т.е. установить контексты) в KLIPS или XFRM / NETKEY ядра на основе IPsec стеков. XFRM / NETKEY - это собственная реализация IPsec для Linux, доступная начиная с версии 2.6.
В дистрибутивах программного обеспечения Berkeley также есть реализация IPsec и демон IKE, и, что наиболее важно, криптографическая структура ( OpenBSD Cryptographic Framework , OCF), которая значительно упрощает поддержку криптографических ускорителей . OCF недавно был перенесен на Linux.
Значительное количество поставщиков сетевого оборудования создали свои собственные демоны IKE (и реализации IPsec) или лицензируют стек друг у друга.
Существует ряд реализаций IKEv2, и некоторые компании, занимающиеся сертификацией IPsec и тестированием совместимости, начинают проводить семинары для тестирования, а также обновляют требования к сертификации, чтобы иметь дело с тестированием IKEv2.
В настоящее время доступны следующие реализации IKEv2 с открытым исходным кодом:
- OpenIKEv2 ,
- strongSwan ,
- Либресван ,
- Openswan ,
- Енот из проекта КАМЕ ,
- взято из проекта OpenBSD .,
- Программное обеспечение Rockhopper VPN
Уязвимости
Утечка презентаций NSA, выпущенных Der Spiegel, указывает на то, что IKE используется неизвестным образом для расшифровки трафика IPSec, как и ISAKMP . [17] Исследователи, обнаружившие атаку Logjam, утверждают, что взлом 1024-битной группы Диффи-Хеллмана приведет к поломке 66% серверов VPN, 18% из миллиона доменов HTTPS и 26% серверов SSH, которые, по утверждению исследователей, являются в соответствии с утечками. [18] Это утверждение было опровергнуто Эялем Роненом и Ади Шамиром в их статье «Критический обзор несовершенной прямой секретности» [19] и Полом Воутерсом из Libreswan в статье «66% VPN на самом деле не сломаны» [20 ]
Конфигурации IPSec VPN, которые позволяют согласовывать несколько конфигураций, подвергаются атакам на понижение версии на основе MITM между предлагаемыми конфигурациями как с IKEv1, так и с IKEv2. [21] Этого можно избежать путем тщательного разделения клиентских систем на несколько точек доступа к услугам с более строгими конфигурациями.
Обе версии стандарта IKE подвержены атаке по словарю в автономном режиме при использовании пароля с низкой энтропией. Для IKEv1 это верно для основного режима и агрессивного режима. [22] [23] [24]
Смотрите также
- IPsec
- Протокол согласования ключей
- Групповой домен интерпретации
- Керберизованное Интернет-согласование ключей
- Компьютерная сеть
Рекомендации
- ^ Обмен ключами в Интернете (IKE), RFC 2409, §1 Аннотация
- ^ a b RFC 3129: Требования к Kerberized Internet Negotiation of Keys , Internet Engineering Task Force , июнь 2001 г., стр. 1
- ^ RFC 4322: Оппортунистическое шифрование с использованием Internet Key Exchange (IKE) , Internet Engineering Task Force , июнь 2001 г., стр. 5
- ^ «RFC 2407 Интерпретация домена безопасности IP для ISAKMP» . Инженерная группа Интернета (IETF).
- ^ «RFC 2408 Internet Security Association и Key Management Protocol (ISAKMP)» . Инженерная группа Интернета (IETF).
- ^ Д. Харкинс. «RFC 2409 Интернет-обмен ключами (IKE)» . Инженерная группа Интернета (IETF).
- ^ К. Кауфман (Microsoft) (декабрь 2005 г.). «Протокол обмена ключами Интернета (IKEv2) RFC 4306» . Инженерная группа Интернета (IETF).
- ^ Eronen, P .; Хоффман, П. (октябрь 2006 г.). «Разъяснения и рекомендации по внедрению RFC 4718 IKEv2» . Инженерная группа Интернета (IETF).
- ^ Кауфман, С .; Hoffman, P .; Nir, Y .; Эронен, П. (сентябрь 2010 г.). «Протокол обмена ключами Интернета (IKEv2) RFC 5996» . Инженерная группа Интернета (IETF).
- ^ a b c "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), стр. 5
- ^ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), стр. 6
- ^ "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), стр. 10–16
- ^ "Протокол обмена ключами в Интернете (IKEv2) RFC 4306", Инженерная группа Интернета (IETF), стр. 11,33
- ^ "RFC 4306: Протокол обмена ключами в Интернете (IKEv2)", Инженерная группа Интернета (IETF), стр. 38-40
- ^ Обмен ключами в Интернете: Безопасность интернет-протокола (IPsec): Technet
- ^ Использование IPSec в Windows 2000 и XP, часть 1
- ^ Полевые возможности: обзор дизайна сквозного VPN SPIN9 (PDF) , АНБ через Der Spiegel, стр. 5
- ^ Адриан, Дэвид; Бхаргаван, Картикеян; Дурумерик, Закир; Годри, Пьеррик; Грин, Мэтью; Халдерман, Дж. Алекс; Хенингер, Надя ; Спринголл, Дрю; Томе, Эммануэль; Валента, Люк; VanderSloot, Бенджамин; Вустров, Эрик; Занелла-Бегелин, Сантьяго; Циммерманн, Пауль (октябрь 2015 г.). Несовершенная прямая секретность: как на практике терпит неудачу Диффи-Хеллман (PDF) . 22-я конференция ACM по компьютерной и коммуникационной безопасности (CCS '15). Денвер . Проверено 15 июня +2016 .
- ^ Ронен, Эял; Шамир, Ади (октябрь 2015 г.). «Критический обзор несовершенной прямой секретности» (PDF) . Цитировать журнал требует
|journal=
( помощь ) - ^ Воутерс, Пол (октябрь 2015 г.). «66% VPN на самом деле не сломаны» .
- ^ Бхаргаван, Картикеян; Брзуска, Кристина; Фурне, Седрик; Кольвейс, Маркульф; Занелла-Бегелин, Сантьяго; Грин, Мэтью (январь 2016 г.). «Понижение устойчивости в протоколах обмена ключами» (PDF) .
- ^ Плиам, Джон (2 октября 1999 г.). «Уязвимости аутентификации в IKE и Xauth со слабыми заранее общими секретами» . Университет Джона Хопкинса . Архивировано 10 июня 2002 года . Дата обращения 5 февраля 2020 .
- ^ МакГрю, Дэвид (5 июля 2011 г.). «Отличный шифр, но где ты взял этот ключ» . Блог Cisco . Архивировано из оригинала 9 июля 2011 года . Дата обращения 11 февраля 2020 .
- ^ Фельш, Деннис (август 2018 г.). «Опасности повторного использования ключей: практические атаки на IPsec IKE» . 27-й симпозиум по безопасности USENIX . Дата обращения 11 февраля 2020 .
Внешние ссылки
- RFC 2407 Internet Security Association and Key Management Protocol (ISAKMP) , Internet Engineering Task Force (IETF)
- RFC 2409 The Internet Key Exchange (IKE) , Internet Engineering Task Force (IETF)
- RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) , Internet Engineering Task Force (IETF)
- Обзор IKE (от Cisco)