RFC-2409. Протокол обмена ключевой информацией в Internet (IKE). Ноябрь 1998 года (категория: стандарт)
Подождите немного. Документ загружается.
11
Как отмечалось ранее, согласованный способ аутентификации определяет
содержание и порядок применения сообщений в течении первой фазы (в
различных режимах) согласования, но не изменяет их предназначение.
Когда для аутентификации используются открытые ключи, то тогда
первая фаза информационного обмена может проводиться с использованием
либо ЭЦП, либо шифрования с открытыми ключами (если же выбранный
алгоритм поддерживает их).
5.1. Первая фаза IKE-протокола, аутентифицируемая с помощью ЭЦП
Если используется ЭЦП, то во втором раунде информационного обмена в
качестве служебной информации выступают случайные параметры инициатора
и отвечающей стороны. Информационный обмен аутентифицируется с
помощью подписи обоюдно вычисленного результата хэш-функции. Структура
“Базового режима” информационного обмена с аутентификацией на основе
ЭЦП представлена на рис.1.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения Состав сообщения Раунд
n
HDR; SA
1
2
HDR; SA
n
o
HDR; KE; N
i
3
4
HDR; KE; N
r
o
p
HDR*; ID
ii
; [CERT]; SIG_I
5
6
HDR*; ID
ir
; [CERT]; SIG_R
p
t t
“1” — порядковый номер передаваемого сообщения.
Рис.1. “Базовый режим” информационного обмена с аутентификацией на основе ЭЦП
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения Состав сообщения Раунд
n
HDR; SA; KE; N
i
; ID
ii
;
1
2
HDR; SA; KE; N
r
; ID
ir
; [CERT]; SIG_R
n
o
HDR; [CERT]; SIG_I
3
t t
Рис.2. “Жесткий режим” информационного обмена с аутентификацией на основе ЭЦП
(совместно с ISAKMP-протоколом)
12
Структура “Жесткого режима” информационного обмена с
аутентификацией на основе ЭЦП совместно с ISAKMP-протоколом
представлена на рис.2.
В обоих режимах, подписанные данные,
SIG_I или SIG_R, являются
результатом вычисления по согласованному алгоритму ЭЦП, примененного,
соответственно, к
HASH_I или HASH_R.
В целом, ЭЦП будет вычисляться по
HASH_I и HASH_R, используя для этого
согласованную ПСФ, либо НМАС-версию согласованной хэш-функции (если
ПСФ не согласована). Однако, это вариант может быть отвергнут, если
конструкция ЭЦП основана на алгоритме, который связан индивидуальным
алгоритмом вычисления хэш-функции (например, DSS-стандарт определяет
применение только SHA-алгоритмы с 160-битовой выходной
последовательностью (результатом). В таком случае, ЭЦП будет
рассчитываться по
HASH_I и HASH_R так как это было сказано выше, но за
исключением применения НМАС-версии алгоритма вычисления хэш-функции,
связанного с определенным способом вычисления ЭЦП. Согласованные
параметры ПСФ и хэш-функции могут использоваться в дальнейшем для
применения всех других предписываемых псевдо-случайных функций.
Так как используемый алгоритм вычисления хэш-функции уже известен,
то
тогда нет необходиости кодировать его идентификатор в ЭЦП. Кроме того,
не существует никакой связи между идентификатором объекта, используемого
в стандарте RSA-ЭЦП (PKCS#1, RFC 2437), и тем, который используется в этом
стандарте. Более того, RSA-ЭЦП должны шифроваться так же, как шифруются
секретные ключи в формате PKCS#1, а никак ЭЦП — в формате PKCS#1
(который включает идентификтор алгоритма
вычисления хэш-функции). DSS-
ЭЦП должны шифроваться в соответствии с DSS-стандартом. В период первой
фаза информационного обмена в сообщениях могут дополнительно
передаваться одно или более полей полезной нагрузки “Электронный
сертификат”.
5.2. Первая фаза IKE-протокола, аутентифицируемая с помощью
шифрования с открытыми ключами
При использовании шифрования с открытыми ключами для
аутентификации информационного обмена в качестве служебной информации
выступают зашифрованные случайные параметры инициатора и отвечающей
стороны. Способность каждого участника информационного обмена
(инициатора и отвечающей стороны) воспроизвести вычисление хэш-функции
(доказать, что другой участник расшифровал случайный параметр)
обеспечивает аутентификацию информационного обмена.
13
Для реализации алгоритма шифрования с открытыми ключами инициатор
соединения должен знать заранее открытый ключ вызываемой стороны. В
случае, когда вызываемая сторона обладает несколькими открытыми ключами,
результат вычисления хэш-функции по электронному сертификату, который
используется инициатором соединения для зашифрования служебной
информации, транслируется как часть третьего сообщения. В результате,
вызываемая сторона может определить
какой открытый ключ использовать для
расшифрования зашифрованных полей полезной нагрузки, и таким образом
обеспечивается защита подлинности.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения Состав сообщения Раунд
n
HDR; SA
1
2
HDR; SA
n
o
HDR; KE; [HASH(1)];
<ID
ii
_b>PubKey_r; <N
i
_b>PubKey_r
3
4
HDR; KE; <ID
ir
_b>PubKey_i;
<N
r
_b>PubKey_i
o
p
HDR*; ID
ii
; [ CERT ]; SIG_I
5
6
HDR*; ID
ir
; [ CERT ]; SIG_R
p
t t
Рис.3. “Базовый режим” информационного обмена с аутентификацией на основе
шифрования с открытыми ключами
Кроме случайного параметра процедуре зашифрования подвергаются
верительные (идентификационные) данные участников информационного
обмена (
ID
ii
и ID
ir
). Если в качестве способа аутентификации выступает
шифрование с открытыми ключами, то тогда поля полезной нагрузки
“Случайный параметр” и “Идентификация” должны обязательно
зашифровываться с помощью открытого ключа противоположной стороны. В
последнем случае шифруется только тело полей полезной нагрузки, заголовки
полей транслируются в открытом виде.
Структура “Базового режима” информационного обмена с
аутентификацией
на основе шифрования с открытыми ключами представлена
на рис.3. Структура “Жесткого режима” информационного обмена с
аутентификацией на основе шифрования с открытыми ключами представлена
на рис.4.
Значение
HASH(1) представляет собой результат вычисления хэш-функции
(алгоритм которой был согласован) по электронному сертификату, а сам
14
результат используется инициатором соединения для зашифрования
случайного параметра и верительных данных.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения
Состав сообщения Раунд
n
HDR; SA; [HASH(1)]; KE;
<ID
ii
_b>PubKey_r; <N
i
_b>PubKey_r
1
2
HDR; SA; KE; <ID
ir
_b>PubKey_i;
<N
r
_b>PubKey_i; HASH_R
n
o
HDR; HASH_I
3
t t
Рис.4. “Жесткий режим” информационного обмена с аутентификацией на основе
шифрования с открытыми ключами
Шифрование с использованием RSA-алгоритма должно иметь формат,
представленный в стандарте PKCS#1 (RFC 2437). Так как процедуре
шифрования подвергается только тело поля полезной нагрузки “Случайный
параметр” или “Данные идентификации”, то тогда зашифрованные данные
должны следовать сразу после соответствующего общего ISAKMP-заголовка.
Размер поля полезной нагрузки включает размер зашифрованных данных плюс
размер заголовка. Шифрование в формате PKCS#1
учитывает значение
реального размера открытого текста в поле полезной нагрузки после
дешифрования.
Применение шифрования для аутентификации обеспечивает истинность
информационного обмена в случае возникновения спорных ситуаций,
например, отказ одной из сторон соединения от каких-либо совершенных ею
действий. Но шифрование не является доказательством того (как это было в
случае применения ЭЦП), что
переговоры всегда имели место, то есть еще до
того как каждая сторона соединения смогла восстановить сообщения обих
участников информационного обмена. Кроме того, безопасность
информационного обмена может возрасти, если процедура формирования
секретных данных будет проведена еще до того, как нарушитель сможет
успешно “взломать” DH-алгоритм информационного обмена, но и оба
шифрпотока (двух
сторон соединнения) с использованием RSA-алгоритма.
(
Замечание. В отличие от других способов аутентификации,
аутентификация с помошью шифрования с открытыми ключами обеспечивает
защиту подлинности в “Жестком режиме”.
)
5.3. Первая фаза IKE-протокола, аутентифицируемая с помощью
шифрования с открытыми ключами в скорректированном режиме
15
Аутентификация на основе шифрования с открытыми ключами имеет
существенные преимущества по сравнению с аутентификацией на основе ЭЦП.
К сожалению, это преимущество достигается за счет процедуры,
связанной с формированием четырех ключей: два открытых ключа для
шифрования и два секретных ключа для расшифрования. Однако, данный
режим аутентификации сохраняет все преимущества аутентификации с
помощью
шифрования с открытыми ключами, но только затрачивает на это в
два раза меньше операций по формированию ключей.
В этом режиме, случайный параметр по-прежнему шифруется с помощью
открытого ключа объекта информационного обмена, однако, верительные
данные объекта (и сертификат, если он передается) шифруются с помощью
согласованного симметричного криптоалгоритма (в поле полезной
нагрузки
“SA”) и ключа, “извлеченного” из случайного параметра. Такое решение
незначительно увеличивает сложность процедуры, однако, сохраняет только
две необходимые операции по формированию ключей на каждой стороне
соединения. Кроме этого, поле полезной нагрузки “Обмен ключевой
информацией” также зашифровывается с помощью одного и того же
“извлеченного” ключа. Такая процедура усиливает защищенность относительно
криптоанализа
DH-алгоритма информационного обмена.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения Состав сообщения Раунд
n
HDR; SA
1
2
HDR; SA
n
o
HDR; [HASH(1)]; <N
i
_b>Pubkey_r;
<KE_b>Ke_i; <ID
ii
_b>Ke_i;
[<Cert-I_b>Ke_i]
3
4
HDR; <N
r
_b>PubKey_i; <KE_b>Ke_r;
<ID
ir
_b>Ke_r
o
p
HDR*; HASH_I
5
6
HDR*; HASH_R
p
t t
Рис.5. “Базовый режим” информационного обмена с аутентификацией на основе
шифрования с открытыми ключами в скорректированном режиме
Как и при аутентификации с помощью шифрования с открытыми
ключами, поле полезной нагрузки “Хэш-функция” может быть передана для
идентификации электронного сертификата, если получатель имеет несколько
сертификатов, которые содержат пригодные к применению открытые ключи
(например, если электронный сертификат не предназначен только для ЭЦП, в
16
следствие, либо сертификационных, либо алгоритмических ограничений). Если
поле полезной нагрузки “Хэш-функция” должно передаваться, то тогда оно
должно транслироваться во втором сообщении и следовать сразу после
заголовка и перед зашифрованным полем “Случайный параметр”. Если же поле
“Хэш-функция” не должно передаваться, то тогда во втором сообщении
первым должно следовать зашифрованное
поле “Случайный параметр”. Кроме
этого, инициатор соединения может дополнительно передать поле полезной
нагрузки “Электронный сертификат” для обеспечения вызываемой стороны
открытым ключом, который будет использоваться в ответном сообщении.
Структура “Базового режима” информационного обмена с
аутентификацией на основе шифрования с открытыми ключами в
скорректированном режиме представлена на рис.5. Структура “Жесткого
режима” информационного обмена
с аутентификацией на основе шифрования с
открытыми ключами в скорректированном режиме представлена на рис.6.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения
Состав сообщения Раунд
n
HDR; SA; [ HASH(1)];
<N
i
_b>Pubkey_r; <KE_b>Ke_i;
<ID
ii
_b>Ke_i; [<Cert-I_b>Ke_i]
1
2
HDR; SA; <N
r
_b>PubKey_i;
<KE_b>Ke_r; <ID
ir
_b>Ke_r; HASH_R
n
o
HDR; HASH_I
3
t t
Рис.6. “Жесткий режим” информационного обмена с аутентификацией на основе
шифрования с открытыми ключами в скорректированном режиме
Значение
HASH(1) представляет собой результат вычисления хэш-функции
(алгоритм которой был согласован) по электронному сертификату, а сам
результат используется инициатором соединения для зашифрования
случайного параметра и верительных данных.
Ke_i и Ke_r являются ключами
симметричного криптоалгоритма, согласованного в предшествующем поле
полезной нагрузки “SA”. Процедуре зашифрования подвергается только тело
полей полезной нагрузки (для ассиметричного и симметричного
криптоалгоритмов), а заголовки полей транслируются в открытом виде.
Субполе “Размер поля полезной нагрузки…” учитывает расширение размера
поля после процедуры зашифрования.
Ключи для симметричного криптоалгоритма извлекаются из
расшифрованных случайных
параметров следующим образом. Первые
значения
Ne_i и Ne_r вычисляются как:
17
Ne_i = prf(Ni_b, CKY-I);
Ne_r = prf(Nr_b, CKY-R).
В дальнейшем ключи
Ke_i и Ke_r, извлекаемые из Ne_i и Ne_r,
соответственно, по алгоритму, представленному в Приложении В,
используются для получения симметричных ключей, применяемых в
согласованном криптоалгоритме. Если размер выходной последовательности в
результате вычисления согласованной ПСФ будет больше или равен размеру
ключа, требуемого шифра, то тогда
Ke_i и Ke_r будут определяться по наиболее
старшим битам значений
Ne_i и Ne_r, соответственно. Если же необходимый
размер
Ke_i и Ke_r будет превышать размер выходной последовательности ПСФ,
то тогда необходимое число недостающих битов будет обеспечиваться за счет
многократного последовательного введения результатов вычисления ПСФ
обратно на вход алгоритма вычисления ПСФ и присоединения последующего
результата к предыдущему до тех пор, пока не будет получено требуемое число
битов. Например, если согласованный криптоалгоритм требует 320-битовый
ключ, а размер выходной последовательности ПСФ составляет только 128
битов, то тогда
Ke_i будет представлять собой 320 старших битов
последовательности
K, где
K = K1|K2|K3; K1 = prf(Ne_i, 0); K2 = prf(Ne_i, K1); K3 = prf(Ne_i, K2).
Для краткости показан алгоритм вычисления Ke_i, так как значение Ke_r
вычисляется аналогичным образом. Размер значения “0” привычислении
K1
составляет один октет. (
Замечание. Величины Ne_i, Ne_r , Ke_i и Ke_r являются
кратковременными и после их использования должны уничтожаться.)
Сохраняются требования по размещению в сообщении дополнительного
поля “Хэш-функция” и обязательного поля “Случайный параметр”, однако на
последующие поля никаких требований по размещению не существует. Все
поля полезной нагрузки (в каком бы порядке они не следовали), следующие за
зашифрованным полем “Случайный параметр” должны в обязательном порядке
зашифровываться с помощью
Ke_i и Ke_r, в зависимости от направления
передачи.
Если симметричный криптоалгоритм применяется в СВС-режиме (режим
сцепления шифрблоков), то тогда алгоритм вычисления вектора начальной
установки (ВНУ, Initialization Vector — InV) будет следующий. ВНУ для
зашифрования первого поля полезной нагрузки, следующего за полем
“Случайный параметр”, будет иметь нулевое значение (“0”). ВНУ для
зашифрования последующих поле полезной нагрузки с помощью
кратковременного симметричного шифрключа,
Ke_i, будет представлять собой
последний шифрблок предшествующего поля полезной нагрузки.
Зашифрованные поля полезной нагрузки подвергаются процедуре дополнения
до ближайшего размера блока. Все байты дополнения, за исключением
18
последнего байта, будут иметь значение “0х00”. Последний байт дополнения
содержит значение общего количества байтов дополнения, за исключением его
самого (последнего байта). (
Замечание. Любая процедура дополнения будет
осуществляться подобным образом.)
5.4. Первая фаза IKE-протокола, аутентифицируемая с помощью
предварительно согласованным ключом
Ключ, полученный каким-либо внешним способом также может
использоваться для аутентификации информационного обмена. Сам внешний
способ получения ключа в данном стандарте не рассматривается.
Структура “Базового режима” информационного обмена с
аутентификацией на основе предварительно согласованного ключа
представлена на рис.7. Структура “Жесткого режима” информационного
обмена с аутентификацией на основе предварительно согласованного ключа
представлена на рис.8.
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения Состав сообщения Раунд
n
HDR; SA
1
2
HDR; SA
n
o
HDR; KE; N
i
3
4
HDR; KE; N
r
o
p
HDR*; ID
ii
; HASH_I
5
6
HDR*; ID
ir
; HASH_R
p
t t
Рис.7. “Базовый режим” информационного обмена с аутентификацией на основе
предварительно согласованного ключа
Инициатор соединения INTERNET Отвечающая сторона
Раунд Состав сообщения
Состав сообщения Раунд
n
HDR; SA; KE; N
i
; ID
ii
1
2
HDR; SA; KE; N
r
; ID
ir
; HASH_R
n
o
HDR; HASH_I
3
t t
Рис.8. “Жесткий режим” информационного обмена с аутентификацией на основе
предварительно согласованного ключа
Когда используется аутентификация на основе предварительно
согласованного ключа в “Базовом режиме” информационного обмена, то тогда
19
ключ может быть идентифицирован на основе IP-адресов взаимодействующих
объектов, поскольку значение
HASH_I должно быть вычислено перед тем, как
инициатор обработает значение
ID
ir
. “Жесткий режим” информационного
обмена учитывает широкий диапазон используемых идентификаторов
предварительно согласованного секретного ключа. Кроме того, “Жесткий
режим” позволяет обеим взаимодействующим сторонам иметь несколько
различных предварительно согласованных ключей и корректно
идентифицировать один из них для текущего информационного обмена.
5.5. Вторая фаза IKE-протокола — “Ускоренный режим”
“Ускоренный режим” не является завершающим этапом всего
информационного обмена по согласованию параметров (с этой точки зрения он
граничит с первой фазой информационного обмена), но он используется как
часть второй фазы процесса согласования параметров для определения
ключевой информации и согласования общей стратегии безопасности для SA в
интересах других протоколов (не ISAKMP-SA). Информационный обмен
в
“Ускоренном режиме” должен быть защищен с помощью ISAKMP-SA, то есть
все поля нагрузки, за исключением ISAKMP-заголовка зашифровываются. В
“Ускоренном режиме”, поле полезной нагрузки “Хэш-функция” должно
следовать сразу за ISAKMP-заголовком, а поле полезной нагрузки “SA” —
сразу за полем “Хэш-функция”. Это поле “Хэш-функция” аутентифицирует
сообщение, а также обеспечивает надежность
сообщения.
Идентификатор сообщения в ISAKMP-заголовке определяет
“Ускоренный режим” в процессе эксплуатации соответствующего ISAKMP-SA,
которое само идентифицируется с помощью специфических меток в этом же
ISAKMP-заголовке. Поскольку в “Ускоренном режиме” каждая
взаимодействующая сторона использует уникальный ВНУ, то тогда возможна
ситуация, при которой имеют место одновременно несколько “Ускоренных
режимов”, для нескольких ISAKMP-SA, начавшихся в разное
время.
“Ускоренный режим” является по существу процессом согласования SA и
обмена случайными параметрами, которые обеспечивают защиту от повторной
передачи сообщения. Случайные параметры используются для генерации новой
ключевой информации и предотвращения атак типа повторной передачи
сообщений (на основе фиктивно сформированных SA).
Дополнительное поле полезной нагрузки “Обмен ключевой
информацией” может быть использовано в интересах
дополнительного
информационного обмена с использованием DH-алгоритма и вычисления
экспоненциальной функции в “Ускоренном режиме”. Несмотря на то, что
применение поля полезной нагрузки “Обмен ключевой информацией” в
20
“Ускоренном режиме” является необязательной функцией, оно все равно
должно поддерживаться программным IKE-модулем.
Основной “Ускоренный режим” (без поля полезной нагрузки “Обмен
ключевой информацией”) обновляет ключевую информацию, полученный
путем вычисления экспоненциальной функции в первой фазе согласования. Но
это не обеспечивает PFS (надежной доставки сообщения). Однако, применение
поля полезной нагрузки “Обмен ключевой информацией” совместно
с
вычислением экспоненциальной функции позволяет обеспечить PFS для
ключевой информации.
Характеристические (идентификационные) параметры SA, согласованные
в “Ускоренном режиме”, косвенным образом предполагают наличие IP-адресов
взаимодействующих сторон при ISAKMP-протоколе, без каких-либо указаний
относительно конструкций протокола или допустимых номеров портов, за
исключением идентификаторов клиентов, определенных в “Ускоренном
режиме” информационного обмена. Если ISAKMP-протокол выступает в роли
согласующего субъекта в интересах одного из взаимодействующих объектов,
то тогда идентификационные параметры последних должны передаваться в
форме
ID
ci
, а затем — ID
cr
. Локальная стратегия безопасности будет определять
какие предложения приемлемы относительно идентификационных параметров.
Если эти параметры клиента не приемлемы для противоположной стороны (в
“Ускоренном режиме”), в следствие принятой стратегии безопасноси или по
каким-либо другим причинам, то тогда целесообразно направить передающей
стороне ответное сообщение с полем полезной нагрузки “Уведомление”,
содержащим субполе “Данные
уведомления” с параметром “INVALID-ID-
INFORMATION” (“18”).
Верительные данные клиента используются для идентификации трафика
и направления его в соответствующий виртуальный туннель, когда между
взаимодействующими сторонами имеют место несколько тунелей, а также для
учета уникальности защищенных виртуальных соединений, распределенных в
соответствии с их структурными различиями.
Все предложения передаваемые в период “Ускоренного режима”
информационного обмена являются
логически связанными структурами и
должны быть последовательными. Например, если передается поле полезной
нагрузки “Обмен ключевой информацией”, то тогда атрибут, определяющий
группу DH-алгоритма, должен быть включен в состав каждого субполя
“Преобразование”, входящего в субполе “Предложение” поля полезной
нагрузки “SA”, которое согласовывается на предмет его дальнейшего
применения.
Таким же образом, если используются верительные
данные клиента, то
тогда они должны применяться для каждого SA в период его согласования.