RFC-2409. Протокол обмена ключевой информацией в Internet (IKE). Ноябрь 1998 года (категория: стандарт)
Подождите немного. Документ загружается.
RFC 2409“Народная целлюлительница и мутновидящая госпожа Клава удалит зубы по фотографии”ноябрь 1998 года
категория: стандарт
ПРОТОКОЛ ОБМЕНА КЛЮЧЕВОЙ
ИНФОРМАЦИЕЙ В
INTERNET
(IKE)
I. ПРЕДИСЛОВИЕ
ISAKMP-стандарт представляет собой протокол для проведения
аутентификации и обмена ключевой информацией (ОКИ), но не определяет их.
ISAKMP-протокол разработан как независимый от типа обмена ключевой
информацией способ, и поэтому он поддерживает несколько различных
протоколов ОКИ.
OAKLEY-протокол реализует серию процедур ОКИ, называемых
“режимы”, и определяет детали услуг, предоставляемых каждым режимом
(например, безошибочная доставка секретного пароля для ключевой
информации, защита подлинности и аутентификация).
SKEME-протокол реализует многосторонний способ ОКИ, который
обеспечивает анонимность, защиту от отказа сторон за совершённые действия и
быстрое обновление ключей.
Данный стандарт определяет протокол, который использует часть
OAKLEY-протокола и часть SKEME-протокола во взаимосвязи с ISAKMP-
протоколом для обеспечения аутентифицированного
обмена ключевым
материалом в интересах самого ISAKMP-протокола и других защищенных
виртуальных соединений (SA), используемых АН-протоколом и ESP-
протоколом в рамках стандарта IPsec DOI.
II. ВСТУПЛЕНИЕ
Этот стандарт представляет собой гибридный протокол, цель которого —
согласовать и обеспечить аутентифицированный ОКИ для формируемых SA в
защищеном режиме.
Поцедуры, которые представлены в данном стандарте могут быть
использованы для согласования частных виртуальных сетей (Virtual Private
Network — VPN), а также для обслуживания удаленного пользователя с
удаленного сайта (чей IP-адрес не должен быть известен заранее) в целях
предоставления ему доступа в защищенный IP-узел или защищенную сеть.
Этот стандарт обеспечивает клиентский режим согласования. В этом
режиме договаривающиеся стороны не являются терминальными (конечными)
точками соединения, в интересах которых согласовывается защищенное
2
виртаульное соединение. При использовании этого режима реальные объекты
информационного обмена остаются “скрытыми”.
III. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
3.1. Условные обозначения
В данном стандарте используются следующие условные обозначения:
“HDR” — заголовок ISAKMP-сообщения (или просто ISAKMP-заголовок). По
типу заголовка определяется режим информационного обмена. Если
имеет место запись
HDR*, то это означает, что поле полезной нагрузки,
следующее после ISAKMP-заголовка, зашифровано;
“SA” — означает поле полезной нагрузки “Защищенное виртуальное
соединение” для согласования параметров SA, содержащее одно или
несколько предложений. Инициатор соединения может предложить
несколько вариантов SA для согласования, а вызываемая сторона должна
выбрать только один вариант и его подтвердить;
“<P>_b” — означает тело (body) любого поля полезной нагрузки <P>;
“SA
i
_b” — означает тело (body) поля полезной нагрузки “SA” (без общего
ISAKMP-заголовка), то есть субполя — “DOI”, “Состояние
защищенности”, “Предложение” (может быть несколько) и
“Преобразование” (может быть несколько), — предлагаемые
инициатором соединения;
“CKY-I” и “CKY-R” — означают специальные метки инициатора и вызываемой
стороны, соответственно, из ISAKMP-заголовка;
“g^x
i
” и “g^x
r
” — означают открытые значения ключей алгоритма Диффи-
Хеллмана (DH-алгоритм), соответственно для инициатора и для
вызываемой стороны;
“g^xy” — означет общий секретный ключ DH-алгоритма;
“KE” — означает поле полезной нагрузки “Обмен ключевой информацией”,
которое содержит открытую информацию (данные), которой
обмениваются при использовании DH-алгоритма. В нем отсутствует
какое-либо кодирование, используемое для данных ОКИ;
“N
x
” — означает поле полезной нагрузки “Случайный параметр”, где “х”
может иметь значения “
i” и “r”, то есть инициатор и вызываемая сторона
соответственно;
“ID
x
” — означает поле полезной нагрузки “Идентификация”, где “х” может
иметь значения “
ii” и “ir” — инициатор и запрашиваемая сторона,
соответственно, в период первой фазы согласования ISAKMP-протокола,
или “
ui” и “ur” — инициатор и запрашиваемая сторона, соответственно, в
период второй фазы согласования ISAKMP-протокола;
3
“SIG” — означает поле полезной нагрузки “ЭЦП”. Это поле содержит
результат вычисления электронной цифровой подписи;
CERT — означает поле полезной нагрузки “Электронный сертификат”;
“HASH” (HASH_R или HASH_I) — означает поле полезной нагрузки “Хэш-
функция”. Это поле содержит результат вычисления хэш-функции;
“prf(key,msg)” — означает какую-либо псевдослучайную функцию (ПСФ),
вычисляемую с использованием ключевой информации. Чаще всего это
бывает хэш-функция с использованием ключевой информации. Эта ПСФ
используется для генерирования детерминированного значения, которое
представляется как псевдослучайное. В данном случае она используется
для формирования ключевой информации и для аутентификации
(например, МАС-алгоритм с использованием ключевой
информации);
“SKEYID” — означает битовую последовательность, получаемую из секретной
информации, известной только активным объектам информационного
обмена;
“SKEYID_e” — означает ключевую информацию, используемую ISAKMP-SA
для защиты конфиденциальности собственных сообщений;
“SKEYID_a” — означает ключевую информацию, используемую ISAKMP-SA
для аутентификации собственных сообщений;
“SKEYID_d” — означает ключевую информацию, используемую для
формирования ключей для SA, но не в интересах ISAKMP-протокола;
“<x>y” — означает, что сообщение “x” зашифровано с использованием ключа
“
y”;
“→” — определяет направление соединения от инициатора к запрашиваемой
стороне (запросы);
“←” — определяет направление соединения от запрашиваемой стороны к
инициатору (ответы);
“|” — определяет сцепление (связность) информации, например, “X|Y”
означает, что последоваетльнось “
X” связана с последовательностью “Y”;
“[x]” — означает, что “x” является дополнительной функцией.
Шифрование сообщения (когда имеет место символ “*”, “HDR*”) должно
начинаться сразу после ISAKMP-заголовка. Когда соединение защищено, то
тогда все поля полезной нагрузки, следующие после ISAKMP-заголовка,
должны в обязательном порядке зашифровываться. В некотором смысле,
криптоключи формируются из “
SKEYID_e”, которая определяется для каждого
алгоритма.
3.2. Надежная доставка секретных данных
Когда в данном стандарте используются ссылки на надежную доставку
секретных данных (Perfect Forward Secrecy — PFS), то это означает, что
4
компрометация одного ключа позволяет обеспечить доступ только к тем
данным, которых зашифровывались (защищались) с помощью этого
криптоключа. Для обеспечения PFS, ключ, используемый для защиты данных,
не должен использоваться для формирования любых других дополнительных
ключей. С другой стороны, если ключ, используемый для защиты данных, был
сформирован с использованием другой ключевой информации, то тогда
последняя не должна использоваться для формирования любых других
дополнительных ключей.
Представленный в этом стандарте IKЕ-протокол реализует PFS в
интересах формирования ключей и верительных (удостоверяющих)
документов.
3.3. Защищенное виртуальное соединение
Защищенное виртуальное соединение (Security Association — SA)
представляет собой, в широком смысле, совокупность стратегий обеспечения
безопасности и ключа(ей), используемых для защиты информации. ISAKMP-
SA представляет собой, в широком смысле, единую согласованную стратегию
обеспечения безопасности и ключ(и), используемые договаривающимися
объектами данного протокола с целью защиты своей информации.
IV. ВВЕДЕНИЕ
Каждый из протоколов OAKLEY и SKEME определяет метод построения
аутентифицируемого ОКИ. Он включает конструкцию полей полезной
нагрузки, дополнительную информацию для транспортировки полей полезной
нагрузки, порядок (алгоритм) их обработки и их дальнейшего использования.
Подобно тому, как OAKLEY-протокол определяет “режимы”
информационного обмена, ISAKMP-протокол определяет “фазы”
информационного обмена. Оба эти понятия связаны между собой напрямую,
так как IKЕ-протокол представляет различные типы информационного обмена
как “режимы” функционирования в одной из двух “фаз” процесса.
Первая фаза
процесса заключается в том, что два объекта ISAKMP-
протокола формируют защищенный, аутентифицированный канал по которому
они будут связываться. Этот виртуальный канал называется защищенное
виртуальное соединение для ISAKMP-протокола (ISAKMP-SA). В этой фазе
допускается реализация двух режимов информационного обмена: “Базовый
режим” и “Жесткий режим”. Эти два режима должны использоваться только в
первой фазе процесса.
Вторая фаза процесса заключается в том, что ISAKMP-SA согласовано и
может функционировать в интересах служб обеспечения безопасности
(например, IPsec-протоколов) или других служб, которым необходима
5
ключевая информация и/или дальнейшее согласование параметров. В этой фазе
допускается реализация одного режима информационного обмена: “Быстрый
(ускоренный) режим”. Этот режим должен использоваться только в второй фазе
процесса. Режим “Новая группа”, на самом деле, не относится ни к первой, ни
ко второй фазам процесса. Этот режим следует сразу за первой
фазой процесса,
но он предназначен для формирования новой группы, которая может быть
использована для последующих процедур согласования. Режим “Новая группа”
должен использоваться только после первой фазы процесса.
ISAKMP-SA является однонаправленным (симплексным) соединением. И
если оно сформировано, то тогда любой из участников может инициировать
“Быстрый режим” информационного обмена, информационный обмен
“Информационный”
или в режиме “Новая группа”. ISAKMP-SA
идентифицирется парой специальных меток, первой идет метка инициатора, а
за ней метка запрашиваемой строны. Роль каждого участника
информационного обмена в первой фазе процесса определяется тем, чья метка
занимает субполе “Метка инициатора соединения” и чья — “Метка
запрашиваемой стороны”. Тем не менее, порядок следования меток,
установленный в первой
фазе процесса сохраняется и в дальнейшем для
идентификации ISAKMP-SA, несмотря на то, что направление
информационного обмена в “Быстром режиме”, “Информационном” режиме
(тоже самое, что и тип обмена “Информационный”) или в режиме “Новая
группа” может измениться. Другими словами, специальные метки не должны
меняться местами, когда направление ISAKMP-SA изменилось.
В период двух фаз ISAKMP-процедуры
согласования, прикладной
процесс может очень быстро провести ОКИ, если он необходим. Одна
процедура согласования в первой фазе процесса может быть в дальнейшим
использована для проведения одной или более процедур согласований во
второй фазе процесса. Кроме этого, процедура согласования во второй фазе
процесса может затребовать организации нескольких защищенных
виртуальных соединений. Применяя
такую оптимизацию процесса, прикладной
процесс может снизить число раундов
*
информационного обмена на каждом SA
до одного, а также уменьшить количество вычислений DH-экспоненты на
каждом SA до одного. “Базовый режим” процесса в период первой фазы
согласования обеспечивает защиту подлинности. Если защита подлинности не
нужна, то тогда использование “Жесткого режима” процесса позволит
уменьшить число раундов информационного обмена и в дальнейшем. Также
необходимо отметить,
что применение криптографии с открытыми ключами
*
Под раундом информационного обмена понимается интервал времени, в течении которого направляется
одно сообщение запрос, а после его получения направляется одно сообщение-ответ.
6
для аутентификации в “Жестком режиме” информационного обмена также
будет обеспечивать защиту подлинности.
Данный стандарт, по своей сути, не определяет свою собственную
область шифрования (DOI). ISAKMP-SA, сформированное в первой фазе,
может использовать стандарт DOI и состояние защищенности других служб
безопасности, то есть не ISAKMP-услуг. В таком случае, прикладной процесс
может выбрать ограниченное применение ISAKMP-SA для построения
SA в
интересах других служб безопасности, относящихся к одному и тому же
стандарту DOI. С другой стороны, ISAKMP-SA может быть сформировано без
указания стандарта DOI и состояния защищенности, то тогда прикладные
процессы будут “свободны” в выборе условий формирования SA в интересах
различных служб безопасности, определяемых любым стандартом DOI,
используя данное ISAKMP-SA. Если при постороении SA в первой фазе
согласования не был указан стандарт DOI, то тогда логическая характеристика
полей полезной нагрузки, используемых в первой фазе согласования
параметров, будет соответствовать той, которая представлена в RFC 2408.
Использование других стандартов логической характеристики полей полезной
нагрузки для ISAKMP-SA не допускается.
Рассматриваемые далее атрибуты, используемые IKЕ-протоколом,
проходят согласование при формировании ISAKMP-SA (Эти атрибуты связаны
только с ISAKMP-SA и
не связаны с любыми другими SA, которые могут
согласовываться с использованием ISAKMP-протокола в интересах других
служб безопасности.):
c алгоритм шифрования;
d алгоритм вычисления хэш-функции;
e метод аутентификации;
f информация о группе, которая используется для реализации DH-
алгоритма (DH-группа).
Все перечисленные атрибуты являются обязательными и должны
согласовываться. Кроме этого, существует возможность дополнительного
согласования параметров ПСФ (“
prf”). Если “prf” не проходит согласование, то
тогда вместо нее используется HMAC(хэш)-алгоритм (RFC 2104), который
выступает в роли ПСФ. Функция выбора хэш-алгоритма должна обеспечивать
обычный режим или режим использования HMAC-алгоритма.
DH-группа должна определяться двумя способами: либо с применением
конкретного определения всей группы, либо путем определения всех атрибутов
группы (групповые атрибуты). Групповые атрибуты не
должны предлагаться
вместе с группой, которая была определена ранее (это может быть
дополнительное определение группы или определение, используемое частным
7
образом, которое было указано после завершение информационного обмена в
режиме “Новая группа”).
Программные IKЕ-модули должны представлять следующие значения
атрибутов:
n DES в режиме СВС с возможностью проверки качества криптоключей
(обнаружение слабых и полу-слабых криптоключей);
o MD5 и SHA;
p аутентификация с использованием предварительно согласованных
ключей;
q MODP (модульная экспоненциальная группа) в режиме “по умолчанию”
имеет значение “1”.
Кроме этого, целесообразно, чтобы программные IKЕ-модули
поддерживали:
1 3DES для шифрования;
2 хэш-алгоритм “Tiger”;
3 стандарт ЭЦП (RSA ЭЦП и аутентификация с использованием RSA-
алгоритма);
4 MODP (модульная экспоненциальная группа) со значением “2”.
Программные IKЕ-модули могут поддерживать и другие дополнительные
алгоритмы шифрования и ECP и EC2N группы элептических кривых.
Представленные здесь режимы процедурной характеристики IKЕ-
протокола должны обязательно применяться во всех случаях использования
стандарта IPsec DOI (RFC 2407). Вместе с тем, и другие стандарты DOI могут
использовать эти режимы.
V. ПРОЦЕДУРНАЯ ХАРАКТЕРИСТКА
Существуют два основных способа проведения аутентифицированного
ОКИ: “Базовый режим” и “Жесткий режим”. Каждый из них формирует
аутентифицированную ключевую информацию с использованием DH-
алгоритма. Применение базового режима обязательно, а жесткого —
целесообразно. Кроме этого, обязательно применение “Ускоренного режима” в
качестве механизма обновления ключевой информации и согласования
параметров служб безопасности, не относящихся к ISAKMP-протоколу.
Также,
целесообразно применение режима “Новая группа” в качестве механизма
определения частных групп для участия в информационном обмене с
использованием DH-алгоритма. Прикладные процессы не должны переходить
от одного типа информационного обмена к другому в середине процесса
информационного обмена.
Процессы информационного обмена приспособлены к стандартному
синтаксису полей полезной нагрузки ISAKMP-сообщений, кодированию
8
атрибутов, процедурам “таймаута” и повторной передачи сообщений и
синтаксису информационных (служебных) сообщений (например, уведомления
о том, что (например) предложение по формированию SA не приемлемо или
процедура проверки ЭЦП или расшифрования закончились не удачно).
Поле полезной нагрузки “SA” должно предшествовать всем другим
полям в первой фазе согласования параметров. В принципе, если это не
оговорено
отдельно, не существует каких-либо требований к порядку
следования полей полезной нагрузки в каком-либо ISAKMP-сообщении.
Открытое значение параметра DH-алгоритма, транслируемого в поле
полезной нагрузки IKЕ-протокола в одной из фаз процесса согласования —
первой или второй, должно иметь размер, который был согласован для DH-
группы, причем, если это необходимо, исходное значение
может быть
принудительно дополнено нулями до требуемого размера.
Размер поля полезной нагрузки “Случайный параметр” должен
составлять 8…256 байтов включительно.
Базовый режим является ярким примером информационного обмена с
защитой подлинности в рамках ISAKMP-протокола. Первые два сообщения (в
этом режиме обмена) согласовывают стратегию обеспечения безопасности;
следующие два сообщения обеспечивают обмен открытыми значениями
параметра DH-алгоритма
и служебными данными (например, случайный
параметр), необходимыми для информационного обмена; последние два
сообщения аутентифицируют обмен открытыми значениями параметра DH-
алгоритма. Способ аутентификации, согласуемый в начале ISAKMP-процесса,
определяет структуру и состав полей полезной нагрузки, но не их
предназначение. Информационный обмен в базовом режиме представляет
собой ISAKMP-процесс, обеспечивающий защиту подлинности.
Аналогично, жесткий режим
является ярким примером жесткого
информационного обмена в рамках ISAKMP-протокола. Первые два сообщения
(в этом режиме обмена) согласовывают стратегию обеспечения безопасности,
обеспечивают обмен открытыми значениями параметра DH-алгоритма и
служебными данными, необходимыми для информационного обмена, а также
верительными документами. Кроме этого, второе сообщение аутентифицирует
вызываемую сторону. И далее, третье сообщение аутентифицирует инициатора
соединения и обеспечивает защиту участия в информационном обмене.
Информационный обмен в жестком режиме представляет собой жесткий
ISAKMP-процесс. Финальное сообщение не должно передаваться с
использованием защиты ISAKMP-SA, предоставляя каждому участнику обмена
возможность отложить операцию возведения в степень, если это требуется, до
завершения процедуры согласования параметров этого информационного
обмена.
9
Разные типы информационного обмена IKЕ-протокола не являются
процессами без окончания, а имеют фиксированное число транслируемых
сообщений. Даже поле полезной нагрузки “Электронный сертификат”,
являющееся ответом на запрос сертификата, не должно увеличивать число
транслируемых или ожидаемых сообщений.
Процедура согласования параметров SA является ограниченной при
использовании жесткого режима. Благодаря тому, что конструкция сообщения,
требующая
применения группы, которая формируется в процессе
информационного обмена с использованием DH-алгоритма, может не
согласовываться. Кроме того, различные способы аутентификации могут в
дальнейшем потребовать в принудительном порядке процедуры согласования
атрибутов. Например, параметры процедуры аутентификации с использованием
ассиметричной криптографии не могут быть согласованы, и когда в интересах
аутентификации используется скорректированный метод шифрования
с
открытыми ключами, ни шифргамма, ни значение хэш-функции не могут быть
согласованы. В ситуациях, в которых для согласования нескольких сложных
атрибутов требуется применение IKЕ-протокола, может быть востребован
“Базовый режим”.
“Ускоренный режим” и режим “Новая группа” не имеют аналогов в
ISAKMP-стандарте.
“Базовый режим”, “Жесткий режим” и “Ускоренный режим
”
предусматривают согласование параметров SA. Предлагаемые к реализации SA
содержатся в поле полезной нагрузки “Защищенное виртуальное соединение”,
включающее несколь субполей “Предложение”, каждое из которых, в свою
очередь, содержит несколько блоков “Преобразование”. Если имеют место
несколько предложений в период первой фазы согласования (“Базовый режим”
и “Жесткий режим”), то тогда они должны быть представлены в
форме
нескольких блоков “Преобразование” в одном субполе “Предложение”,
которое, в свою очередь, размещается в одном поле полезной нагрузки
“Защищенное виртуальное соединение”. Выражаясь другим образом, в первой
фазе согласования не должно быть несколько субполей “Предложение” в одном
поле полезной нагрузки “Защищенное виртуальное соединение”, и не должно
быть несколько полей полезной нагрузки “
Защищенное виртуальное
соединение”. Данный стандарт не накладывает такого ограничения на
предложения во второй фазе согласования.
Не существует ограничений на число предложений, которые может
направить инициатор соединения вызываемой стороне, но совместимые
программные модули могут установить ограничение на число предложений, и
это должно быть тщательно проанализировано на предмет выявления
технолоигческих причин.
10
В течении процесса согласования параметров SA, инициаторы
соединений предлагают вызываемым сторонам возможные варианты SA.
Последние, в свою очередь, не должны изменять атрибуты какого-либо
предложения, за исключением кодирования атрибутов. Если инициатор
информационного обмена замечает, что значения атрибутов были изменены
или атрибуты были добавлены или удалены из направленного предложения, то
тогда ответное сообщение должно
уничтожаться.
В период первой фазы согласования в “Базовом режиме” или “Жестком
режиме” допускаются четыре различных способа аутентификации (ЭЦП, две
формы аутентификации с использованием шифрования с открытыми ключами
и с использованием предварительно согласованного ключа). Значение
SKEYID
вычисляется отдельно для каждого способа аутентификации.
Способ аутентификации Значения параметра
ЭЦП
SKEYID = prf(Ni_b | N
r
_b, g^x
y
)
Шифрование с открытыми ключами
SKEYID = prf(hash(N
i
_b | N
r
_b), CKY-I | CKY-R)
С предварительно согласованным ключом
SKEYID = prf(pre-shared-key, N
i
_b | N
r
_b)
В результате проведения первой фазы согласования в “Базовом режиме”
или “Жестком режиме” имеем три группы аутентифицированной ключевой
информации:
SKEYID_d = prf(SKEYID, g^x
y
| CKY-I | CKY-R | 0),
SKEYID_a = prf(SKEYID, SKEYID_d | g^x
y
| CKY-I | CKY-R | 1),
SKEYID_e = prf(SKEYID, SKEYID_a | g^x
y
| CKY-I | CKY-R | 2)
и согласованную стратегию обеспечения безопасности для защиты
последующих виртуальных соединений. Значения “0”, “1” и “2” кодируются с
помощью одного октета. Ключ используемый для шифрования извлекается из
значения
SKEYID_e в соответствии с алгоритмом формирования ключа.
Для аутентификации информационного обмена инициатор протокола
безопасности формирует
HASH_I, а вызываемая сторона формирует HASH_R, где:
HASH_I = prf(SKEYID, g^x
i
| g^x
r
| CKY-I | CKY-R | SA
i
_b | ID
ii
_b ),
HASH_R = prf(SKEYID, g^x
r
| g^x
i
| CKY-R | CKY-I | SA
i
_b | ID
ir
_b).
Для аутентификации с использованием ЭЦП, значения
HASH_I и HASH_R
подписываются и удостоверяются; для аутентификации с использованием либо
шифрования с открытыми ключами, либо с использованием предварительно
согласованных ключей,
HASH_I и HASH_R напрямую аутентифицируют
информационный обмен. В вычислении
HASH_I и HASH_R участвует все поле
полезной нагрузки “Идентификация” (включая субполя “Тип идентификатора”,
“Порт” и “Протокол”, но исключая общий заголовок).