Войти
В вычислениях, Internet Key Exchange (IKE, иногда IKEv1 или IKEv2, в зависимости от версии) - это протокол, используемый для установки сопоставления безопасности (SA) в набор протоколов IPsec. IKE основан на протоколе Oakley и ISAKMP. IKE использует сертификаты X.509 для аутентификации - либо предварительно совместно используемые, либо распределенные с использованием DNS (предпочтительно с DNSSEC ) - и ключ Диффи – Хеллмана. exchange для установки общего секрета сеанса, из которого происходят криптографические ключи. Кроме того, необходимо вручную поддерживать политику безопасности для каждого узла, который будет подключаться.
Интернет-разработка Целевая группа (IETF) первоначально определила IKE в ноябре 1998 года в серии публикаций (Запрос комментариев ), известных как RFC 2407, RFC 2408 и RFC 2409 :
RFC 4306 обновил IKE до версии 2 (IKEv2) в декабре 2005 года. RFC 4718 прояснил некоторые открытые детали в октябре 2006 года. RFC 5996 объединил эти два документа плюс дополнительные пояснения к обновленному протоколу IKEv2, опубликованному в сентябре 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.
Первая фаза IKE - установить безопасный аутентифицированный канал связи с использованием алгоритма обмена ключами Диффи – Хеллмана для генерации общего секретного ключа для дальнейшего шифрования IKE коммуникации. Это согласование приводит к одному двунаправленному ISAKMP Security Association (SA). Аутентификация может быть выполнена с использованием либо общего ключа (общий секрет), подписей, либо шифрования с открытым ключом. Фаза 1 работает либо в основном режиме, либо в агрессивном режиме. Основной режим защищает идентичность одноранговых узлов и хэш общего ключа путем их шифрования; В агрессивном режиме этого не происходит.
На втором этапе IKE узлы IKE используют безопасный канал, установленный на этапе 1, для согласования ассоциаций безопасности от имени других служб, например IPsec. Согласование приводит как минимум к двум однонаправленным ассоциациям безопасности (одно входящее и одно исходящее). Фаза 2 работает только в быстром режиме.
Первоначально у IKE было множество вариантов конфигурации, но не было общих средств для автоматического согласования хорошо известного случая по умолчанию, который реализуется повсеместно. Следовательно, обе стороны IKE должны были точно согласовать тип ассоциации безопасности, которую они хотели создать - вариант за вариантом - иначе соединение не могло быть установлено. Дальнейшие сложности возникли из-за того, что во многих реализациях вывод отладки было трудно интерпретировать, если вообще было какое-либо средство для вывода диагностических данных.
Спецификации IKE были открыты для значительной степени интерпретации, граничащей с проектными ошибками (Dead-Peer-Detection в данном случае), что привело к тому, что различные реализации IKE не смогли для создания согласованной ассоциации безопасности вообще для многих комбинаций параметров, независимо от того, правильно ли они настроены, они могут появляться на любом конце.
Протокол IKEv2 был описан в Приложении A к RFC 4306 в 2005 году. Были устранены следующие проблемы:
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|
IKE_SA_INITна HostA ( инициатор) с уведомляющим сообщением типа COOKIE, и будет ожидать, что HostA отправит запрос IKE_SA_INITс этим значением cookie в уведомляющей полезной нагрузке на HostB . Это необходимо для того, чтобы инициатор действительно мог обрабатывать ответ IKE от ответчика.Рабочая группа IETF ipsecme стандартизировала ряд расширений с целью модернизации протокола IKEv2. и лучше адаптировать его к крупным производственным средам. Эти расширения включают в себя:
IKE поддерживается как часть Реализация IPsec в Windows 2000, Windows XP, Windows Server 2003, Windows Vista и Windows Server 2008. Реализация ISAKMP / IKE была совместно разработана Cisco и Microsoft.
Microsoft Windows 7 и Windows Server 2008 R2 частично поддерживают IKEv2 (RFC 7296 ), а также MOBIKE (RFC 4555 ) с помощью функции повторного подключения VPN (также известной как Agile VPN).
Существует несколько реализаций IPsec с открытым исходным кодом с соответствующими возможностями IKE. В Linux, Libreswan, Openswan и strongSwan реализации предоставляют демон IKE, который может настраивать (т. Е. Устанавливать SA) для KLIPS или Стеки IPsec на основе ядра XFRM / NETKEY. XFRM / NETKEY - это встроенная реализация IPsec для Linux, доступная с версии 2.6.
В дистрибутивах программного обеспечения Berkeley также есть реализация IPsec и демон IKE, и, что наиболее важно, криптографическая структура (OpenBSD Cryptographic Framework, OCF), что обеспечивает поддержку криптографические ускорители намного проще. OCF недавно был перенесен на Linux.
Значительное количество поставщиков сетевого оборудования создали свои собственные демоны IKE (и реализации IPsec) или лицензируют стек друг у друга.
Существует ряд реализаций IKEv2, и некоторые компании, занимающиеся сертификацией IPsec и тестированием совместимости, начинают проводить семинары по тестированию, а также обновляют требования к сертификации для тестирования IKEv2. ICSA Labs провела свой последний семинар по взаимодействию IKEv2 в Орландо, штат Флорида, в марте 2007 года с участием 13 поставщиков со всего мира.
В настоящее время доступны следующие реализации IKEv2 с открытым исходным кодом:
Утечка NSA, выпущенные Der Spiegel, указывают, что IKE используется неизвестным образом для дешифрования трафика IPSec, как и ISAKMP. Исследователи, обнаружившие атаку Logjam, заявляют, что взлом 1024-битной группы Диффи – Хеллмана приведет к поломке 66% серверов VPN, 18% из миллиона доменов HTTPS с наибольшим числом разрядов и 26% SSH-серверов, что, по утверждениям исследователей, согласуется с утечками. Это утверждение было опровергнуто Эялем Роненом и Ади Шамиром в их статье «Критический обзор несовершенной прямой секретности» и Полом Воутерсом из Libreswan в статье «66% VPN на самом деле не сломаны»
Конфигурации IPSec VPN, которые позволяют согласовывать несколько конфигураций, подлежат на основе MITM атаки перехода на более раннюю версию между предлагаемыми конфигурациями, как с IKEv1, так и с IKEv2. Этого можно избежать путем тщательного разделения клиентских систем на несколько точек доступа к услугам с более строгими конфигурациями.
Обе версии стандарта IKE уязвимы для автономной атаки по словарю, когда используется пароль с низкой энтропией. Для IKEv1 это верно для основного режима и агрессивного режима.
