5. Вопросы безопасности
Хотя протокол разработан так, чтобы минимизировать раскрытие конфигурационной информации неуполномоченным партнерам, некоторое раскрытие все-таки неизбежно. Один из партнеров в любом случае должен сначала идентифицировать себя и подтвердить эту идентификацию. Для того, чтобы предотвратить зондирование к инициаторам обмена предъявляется требование идентифицировать первым и первым предъявить свои полномочия. Однако инициатор может узнать, что ответчик поддерживает IKE и определить поддерживаемые им криптографические протоколы. Ответчик (или кто-нибудь, прикидывающийся таковым) может не только проверить идентификацию инициатора, но и с помощью элементов CERTREQ определить, какие сертификаты желает использовать инициатор.
Использование идентификации EAP несколько меняет возможности зондирования. При использовании EAP ответчик подтверждает свою идентификацию раньше инициатора, поэтому любой инициатор, которому известно имя корректного инициатора, может зондировать ответчика для выяснения его имени и сертификатов.
Повторяющаяся замена ключей с использованием CREATE_CHILD_SA без дополнительных обменов Diffie-Hellman делает все SA уязвимыми для криптоанализа одного ключа или перегрузки (overrun) другой точки. Разработчикам следует отметить этот факт и установить предел для числа обменов CREATE_CHILD_SA между сторонами. В этом документе данный предел не задается.
Стойкость ключей, созданных в результате обмена Diffie-Hellman с использованием любой из определенных здесь групп, зависит от стойкости самой группы, размера используемой экспоненты и энтропии при генерации случайных значений. По причине большого числа влияющих на стойкость факторов сложно определить стойкость ключа для любой из определенных групп. Группа Diffie-Hellman номер 2 при использовании с качественным генератором случайных чисел и экспонентой не менее 200 битов является общепринятой для 3DES. Группа 5 обеспечивает лучшую защиту по сравнению с группой 2. Группа 1 сохранена в качестве достояния истории и не обеспечивает достаточной защиты за исключением случаев использования с алгоритмом DES, который тоже стал уже достоянием истории. Разработчикам следует принимать во внимание эти оценки при выборе политики и согласовании параметров защиты.
Отметим, что отмеченные выше ограничения относятся к самим группам Diffie-Hellman. В IKE нет запретов на использование более сильных групп и ничто не снижает уровень стойкости, обеспечиваемый наиболее сильными группами (уровень стойкости ограничивается только выбранными при согласовании алгоритмами, включая функцию prf). Фактически, расширяемая схема IKE поощряет определение новых групп; использование групп эллиптических кривых позволяет существенно повысить уровень стойкости при использовании значительно меньших чисел.
Предполагается, что все экспоненты Diffie-Hellman удаляются из памяти после использования. В частности, такие экспоненты недопустимо создавать на базе долгоживущих секретов типа «затравок» (seed) генератора случайных чисел, которые не уничтожаются после использования.
Тойкость всех ключей ограничивается размером результата согласованной функции prf. По этой причине функции prf, выходное значение которых имеет размер менее 128 битов (например, 3DES-CBC) недопустимо использовать с протоколом IKEIKEIKE.
Безопасность данного протокола критически зависит от уровня случайности параметров, использующих случайные значения. Случайные числа должны генерироваться качественным генератором случайных чисел или источником псевдо-случайных чисел с подходящей «затравкой» (см. [RFC4086]). Разработчикам следует обеспечить гарантии того, что использование случайных чисел для создания ключей и nonce не может приводить к снижению уровеня защиты ключей.
Для информации о причинах выбора многих криптографических параметров протокола рекомендуется обратиться к работам [SIGMA] и [SKEME]. Хотя защита согласованных CHILD_SA не зависит от стойкости алгоритмов шифрования и защиты целостности, выбранных для IKE_SA, реализациям недопустимо согласовывать использование NONE в качестве алгоритма защиты целостности IKE или ENCR_NULL в качестве алгоритма шифрования IKE.