Oakley протокол

Протокол Oakley — протокол согласования ключей, который позволяет двум аутентифицированным сторонам безопасно согласовать ключевой материал. Протокол был предложен Хилари К. Орман в 1998 году и лег в основу более широко используемого протокола Internet Key Exchange.

Свойства протокола

• Совершенная прямая секретность (Perfect forward secrecy (PFS)) — свойство, гарантирующее, что сессионные ключи, полученные с помощью набора ключей долговременного пользования, не будет скомпрометирован при компрометации одного из долговременных ключей;
• Совместимость с протоколом ISAKMP для управления ассоциациями безопасности (SA);
• Использование стандартных или пользовательских групп;
• Обновление ключей;
• Использование cookies с целью защиты от DoS-атак;
• Стороны могут выбирать взаимно приемлемые вспомогательные алгоритмы протокола, такие как метод шифрования, метод получения ключа, хеширования и аутентификации.

Общие положения

Целью обработки обмена ключами является безопасное установление общего состояния ключевой информации на двух сторонах. Эта информация о состоянии представляет собой имя ключа, секретный ключевой материал, идентификацию двух сторон и три алгоритма для использования во время аутентификации: шифрование (для конфиденциальности личности двух сторон), хеширование (псевдослучайная функция для защиты целостности сообщения и для аутентификации полей сообщений) и аутентификация (алгоритм, на котором основана взаимная аутентификация двух сторон).

Обмен в основном режиме имеет пять дополнительных функций: обмен файлами cookie без сохранения состояния, совершенная прямая секретность для ключевого материала, секретность для удостоверений, абсолютная прямая секретность для тайны личности, использование подписей (для неотказуемости). Обе стороны могут использовать любую комбинацию этих функций.

Общая схема обработки заключается в том, что Инициатор обмена начинает с указания в своем первом сообщении как можно большего количества информации. Ответчик отвечает, предоставляя столько информации, сколько пожелает. Обе стороны обмениваются сообщениями, каждый раз предоставляя больше информации, пока их требования не будут удовлетворены.

Выбор того, сколько информации включать в каждое сообщение, зависит от того, какие параметры желательны. Например, если куки-файлы без сохранения состояния не являются обязательными, а секретность личности и совершенная прямая секретность для ключевого материала не являются обязательными, и если неотказуемые подписи допустимы, то обмен может быть завершен в трех сообщениях. Дополнительные функции могут увеличить количество циклов, необходимых для определения ключевого материала.

ISAKMP предоставляет поля для указания параметров ассоциации безопасности для использования с протоколами AH и ESP. Эти типы полезной нагрузки сопоставления безопасности указаны в спецификации ISAKMP; типы полезной нагрузки могут быть защищены с помощью ключевого материала и алгоритмов Oakley.

Протокол обмена ключами

Идея

Обмен ключами может быть завершен за три или более сообщений, но точное число сообщений определяется при выборе параметров сторонами.

Основные составляющие протокола:

1. Обмен файлами cookie (возможен режим без сохранения состояния);
2. Обмен частичными ключами Диффи-Хеллмана;
3. Аутентификация (с вариантами для достижения неотказуемости, конфиденциальности для идентификаторов с или без полной прямой секретности).

При начале обмена инициатор может отправить ответчику как минимальный набор данных для запроса на обмен ключей без дополнительной информации, так и предоставить больше информации вплоть до всей необходимой информации для аутентификации и быстрого завершения определения ключа. В ответ инициатор получит, в зависимости от изначально переданной информации, как минимум файл cookie.

Методом аутентификации могут быть как цифровые подписи, так и асимметричное шифрование, внеполосный симметричный ключ. Каждый метод вносит небольшие различия в сообщениях между сторонами.

Инициатор несет ответственность за повторную передачу сообщений ответчику в случае ошибок, поэтому ответчик должен сохранять информацию полученную при обмене, пока эта информация не будет подтверждена.

Обозначения

• «->» — сообщение отправленное от инициатора (I) к ответчику (R)
• «<-» — сообщение отправленное от ответчика (R) к инициатору (I)

Все поля в сообщении именованы и разделяются запятой.

• EHAO — список доступных алгоритмов шифрования, хеширования и аутентификации. Каждый элемент - пара значений название класса и название алгоритма.
• EHAS — три выбранных элемента из EHAO. Один элемент шифрования, хеширования и аутентификации.
• GRP — 32-битное имя для группы и связанных параметров - размер целых чисел, арифметическая операция и элемент генератора.
• Вертикальная черта символа "|" используется для обозначения конкатенации битовых строк. Поля объединяются с использованием их закодированной формы, когда они появляются в полезной нагрузке.
• Ni и Nr — одноразовые номера, выбранные инициатором и ответчиком соответственно.
• ID(I) и ID(R) — идентификаторы, используемые при аутентификации.
• E{x}Ki — шифрование x с помощью открытого ключа инициатора.
• S{x}Ki — подпись над x c помощью закрытого ключа инициатора.
• prf(a, b) — функция хеширования или одностороннего смешивания входных данных "b" с использованием псевдослучайного ключа "a".
• prf(0, b) — применение хеширования к данным «b».
• NIDP — флаг того, что средство PFS для сокрытия идентификационных данных не используется.
• IDP — флаг того, что данные проверки подлинности шифруются с помощью выбранного алгоритма шифрования с использованием ключа prf(0, g^xy).

Агрессивный режим

Агрессивный режим обмена ключами позволяет установить ключевую информацию за три сообщения. При таком режиме идентификаторы сторон не являются секретными, но полученный ключевой материал удовлетворяет условиям полной прямой секретности.

Использование цифровых подписей для аутентификации дает доказательство связи сторонам, а также эти данные могут быть записаны и представлены третьим сторонам.

При этом ключевой материал, подразумеваемый групповыми экспонентами, не требуется для завершения обмена. Если желательно отложить вычисление, возможно сохранение этих значений «x» и «g^y» с пометкой этого ключевого материала как «нерассчитанного».

Инициатор		Ответчик
->	CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ID(I), ID(R), Ni, 0, S{ID(I)|ID(R)|Ni|0|GRP|g^x|0|EHAO}Ki	->
<-	CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, ID(R), ID(I), Nr, Ni, S{ID(R)|ID(I)|Nr|Ni|GRP|g^y|g^x|EHAS}Kr	<-
->	CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ID(I), ID(R), Ni, Nr, S{ID(I)|ID(R)|Ni|Nr|GRP|g^x|g^y|EHAS}Ki	->

Результатом обмена является ключ с идентификатором KEYID и значением sKEYID:

KEYID = CKY-I|CKY-R;

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).

Схема обмена в агрессивном режиме:

1. Инициатор создает уникальный файл cookie, связывает его с ожидаемым IP-адресом ответчика и выбранной информацией о состоянии: GRP (идентификатор группы), псевдослучайным числом x, g^x, EHAO, одноразовый номер Ni (nonce), ID(I), ID(R). Первый вариант проверки подлинности в списке EHAO - это алгоритм, поддерживающий цифровые подписи, и он используется для подписи идентификаторов, одноразового номера и идентификатора группы. Затем инициатор отмечает, что ключ находится в начальном состоянии «неаутентифицированный», и устанавливает таймер для повторной передачи сообщения и/или завершения запроса.
2. Если CKY-I еще не используется исходным адресом в заголовке IP, отвечающая сторона создает уникальный файл cookie CKY-R. Дальнейшие действия зависят от предпочтений ответчика. Ответчик может проигнорировать всю полученную информацию и перейти к стандартному режиму, либо предоставить в ответ группу с идентификатором GRP, первый выбор аутентификации (подтверждение выбора инициатора, так как иначе ответчик не сможет подтвердить подпись инициатора), NIDP, идентификаторы.
3. Инициатор подтверждает CKY-I как действительную ассоциацию для сетевого адреса входящего сообщения, добавляет значение CKY-R к состоянию пары (CKY-I, сетевой адрес) и связывает всю информацию о состоянии с парой (CKY-I, CKY-R), проверяет подпись ответчика, сохраняет g^y и EHAS в состоянии. Может вычислить (g^y)^x (= g^xy) (это можно отложить до отправки ответного сообщения). Помечает KEYID (CKY-I|CKY-R) как аутентифицированный, после чего составляет ответное сообщение, подписывает его и отправляет ответчику.
4. Ответчик, получив сообщение, проверяет подпись, помечает ключ как аутентифицированный, вычисляет g^(xy) и связывает его с KEYID.

Во всех обменах каждая сторона следит за тем, чтобы она не предлагала и не принимала 1 или g^(p-1) в качестве экспоненты. При этом, несмотря на отсутствие PFS для защиты идентификаторов, PFS для полученного ключевого материала присутствует, так как обмениваются частичные ключи Диффи-Хеллмана.

Если ответчик принимает только часть информации инициатора, то инициатор будет считать, что протокол выполняется. Инициатор должен исходить из того, что поля, которые не были приняты ответчиком, не были записаны ответчиком. Если же ответчик не принимает агрессивный обмен и выбирает другой алгоритм для функции аутентификации, то протокол переходит к стандартному режиму и стороны перестают использовать алгоритм подписи из первого сообщения.

Когда ответчик не принимает поля, предложенные инициатором, то он включает пустые значения для этих полей в свой ответ, причем все последующие поля должны быть нулевыми. Если идентификаторы и одноразовые номера имеют нулевые значения, то не будет подписи над этими нулевыми значениями.

Со скрытыми идентификаторами

Криптография с открытым ключом скрывает личность во время аутентификации. Групповые экспоненты обмениваются и аутентифицируются, но подразумеваемый ключевой материал (g^xy) не требуется во время обмена.

Этот обмен имеет важное отличие от предыдущей схемы подписи — в первом сообщении идентификатор ответчика указывается в виде открытого текста: ID(R'). Однако личность, скрытая с помощью криптографии с открытым ключом, отличается: ID(R). Это происходит потому, что инициатор должен сообщить ответчику, какую пару открытого/закрытого ключей использовать для расшифровки, но в то же время личность скрыта за счет шифрования с помощью этого открытого ключа.

Инициатор может принять решение отказаться от секретности личности ответчика, но это нежелательно. Вместо этого, если имеется общеизвестный идентификатор узла ответчика, открытый ключ для этого идентификатора можно использовать для шифрования фактического идентификатора ответчика.

Инициатор		Ответчик
->	CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr'	->
<-	CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, E{ID(R), ID(I), Nr}Ki, prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS)	<-
->	CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS)	->

Kir = prf(0, Ni | Nr)

KEYID = CKY-I|CKY-R

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

Схема обмена в агрессивном режиме со скрытыми идентификаторами:

1. Инициатор создает уникальный файл cookie, связывает этот файл с ожидаемым IP-адресом ответчика и выбранной информацией о состоянии: GRP, g^x, EHAO, идентификаторы. Первый вариант аутентификации в списке EHAO - алгоритм, поддерживающий шифрование с открытым ключом. У инициатора имеется общеизвестный идентификатор машины-ответчика и соответствующий ему открытый ключ, этим ключом шифруются одноразовый номер Ni и два идентификатора соединения. Затем инициатор отмечает, что ключ находится в начальном состоянии «неаутентифицированный», и устанавливает таймер для повторной передачи сообщения и/или завершения запроса.
2. Если CKY-I еще не используется исходным адресом в заголовке IP, отвечающая сторона создает уникальный файл cookie CKY-R. Дальнейшие действия зависят от предпочтений ответчика. Ответчик может проигнорировать всю полученную информацию и перейти к стандартному режиму, либо предоставить в ответ группу с идентификатором GRP, первый выбор аутентификации (подтверждение выбора инициатора, так как иначе ответчик не сможет расшифровать данные инициатора), NIDP, идентификаторы ответчика и инициатора. Ответчик должен расшифровать информацию об идентификаторе и одноразовом номере, используя закрытый ключ для идентификатора R'ID. После этого закрытый ключ R ID будет использоваться для расшифровки поля nonce. Затем ответчик шифрует информацию о состоянии с помощью открытого ключа ID(I), формирует значение prf и отправляет сообщение инициатору.
3. Инициатор подтверждает CKY-I как действительную ассоциацию для сетевого адреса входящего сообщения, добавляет значение CKY-R к состоянию пары (CKY-I, сетевой адрес) и связывает всю информацию о состоянии с парой (CKY-I, CKY-R). Расшифровывает информацию об идентификаторе и одноразовом номере Nr, проверяет вычисление prf, сохраняет g^y и EHAS в состоянии. Может вычислить (g^y)^x (= g^xy) (это можно отложить до отправки ответного сообщения). Помечает KEYID (CKY-I|CKY-R) как аутентифицированный, после чего составляет ответное сообщение, зашифровывает его открытым ключом и отправляет ответчику.
4. Ответчик получает это сообщение, он помечает ключ как находящийся в состоянии аутентификации. Если он еще не сделал этого, он должен вычислить g^xy и связать его с KEYID.

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

При этом, несмотря на отсутствие PFS для защиты идентификаторов, PFS для полученного ключевого материала присутствует, так как обмениваются частичные ключи g^x и g^y Диффи-Хеллмана.

Со скрытыми идентификаторами без Диффи-Хеллмана

Значительных вычислительных затрат можно избежать, если полная секретность пересылки не является требованием для получения сеансового ключа. Обе стороны могут обмениваться одноразовыми номерами и частями секретного ключа для аутентификации и получения ключевого материала. Долгосрочная конфиденциальность данных, защищенных с помощью производного ключевого материала, зависит от закрытых ключей каждой из сторон.

В приведенном ниже обмене GRP имеет значение 0, а поле групповой экспоненты вместо этого используется для хранения одноразового значения. Первый предлагаемый алгоритм должен быть системой шифрования с открытым ключом; отвечая с помощью файла cookie и ненулевого экспоненциального поля, Ответчик неявно принимает первое предложение и отсутствие полной прямой секретности для идентификаторов и производного ключевого материала.

Инициатор		Ответчик
->	CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, ID(R'), E{ID(I), ID(R), sKi}Kr’, Ni	->
<-	CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, E{ID(R), ID(I), sKr}Ki, Nr, prf(Kir, ID(R)|ID(I)|Nr|Ni|EHAS)	<-
->	CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, prf(Kir, ID(I)|ID(R)|Ni|Nr|EHAS)	->

Kir = prf(0, sKi | sKr)

KEYID = CKY-I|CKY-R

sKEYID = prf(Kir, CKY-I | CKY-R)

Стандартный режим

Стандартный режим отличается меньшим количеством информации передаваемым в каждом сообщении.

Приведем пример, в котором стороны используют обмен файлами куки, чтобы отложить создание состояния, используют полную секретность пересылки для защиты личности, а также шифрование с открытым ключом для аутентификации. Но в качестве метода аутентификации могут использоваться также цифровые подписи и предварительные общие ключи.

Ответчик рассматривает способность инициатора повторить CKY-R как слабое доказательство того, что сообщение исходит от «живого» ответчика в сети и ответчик связан с сетевым адресом инициатора. Инициатор делает аналогичные предположения, когда CKY-I повторяется инициатору.

Все сообщения должны иметь либо действительные файлы cookie, либо хотя бы один нулевой файл cookie. Если оба файла cookie равны нулю, это указывает на запрос файла cookie; если только куки-файл инициатора равен нулю, это ответ на запрос куки-файла.

Все неуказанные поля имеют нулевые значения:

Инициатор		Ответчик
->	0, 0, OK_KEYX	->
<-	0, CKY-R, OK_KEYX	<-
->	CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO	->
<-	CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS	<-
->	CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP, ID(I), ID(R), E{Ni}Kr	->
<-	CKY-R, CKY-I, OK_KEYX, GRP, 0, 0, IDP, E{Nr, Ni}Ki, ID(R), ID(I), prf(Kir, ID(R)|ID(I)|GRP|g^y|g^x|EHAS)	<-
->	CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, IDP, prf(Kir, ID(I)|ID(R)|GRP|g^x|g^y|EHAS)	->

Kir = prf(0, Ni | Nr)

sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R)

Схема обмена в стандартном режиме:

1. Обмен файлами cookie. Инициатор может отправить при первом запросе свой куки, но ответчик может не сохранять этот файл, опуская CKY-I в своем ответе, такое поведение возможно и считается допустимым.
2. После завершения обмена файлами cookie стороны вычисляют материал общего ключа sKEYID. (Функция prf, используемая при вычислении ключа, - псевдослучайная функция в классе «хеш» из EHAS.

Как и в случае с файлами cookie, каждая сторона рассматривает возможность удаленной стороны повторить значение Ni или Nr как доказательство того, что Ka, открытый ключ стороны а, говорит от имени удаленной стороны и устанавливает ее личность.

Отметим, что, хотя флаг IDP гарантирует, что удостоверения защищены общим ключом g^xy, сама аутентификация не зависит от g^xy. Важно, чтобы этапы аутентификации проверяли значения g^x и g^y, и поэтому крайне важно, чтобы аутентификация не включала в себя круговую зависимость от них. Третья сторона может вмешаться по схеме «человек посередине», чтобы убедить инициатора и ответчика использовать разные значения g^xy; хотя такая атака может привести к раскрытию личности перехватчику, аутентификация не удастся.

Одноразовые номера Ni и Nr используются для обеспечения дополнительного измерения секретности при получении сеансовых ключей. Это делает секретность ключа зависимой от двух разных проблем: проблемы дискретного логарифмирования в группе G и проблемы взлома схемы шифрования nonce. Если используется шифрование RSA, то эта вторая проблема примерно эквивалентна факторизации открытых ключей RSA как инициатора, так и ответчика.

Быстрый режим

Когда уже существует аутентифицированный KEYID и связанный с ним ключевой материал sKEYID, легко получить дополнительные KEYID и ключи с аналогичными атрибутами (GRP, EHAS и т. д.), используя только функции хеширования.

С другой стороны, аутентифицированный ключ может быть распределенным вручную ключом, который совместно используется инициатором и ответчиком через некоторые внешние по отношению к Oakley средства. Если метод распределения сформировал KEYID с использованием соответствующих уникальных значений для двух половин (CKY-I и CKY-R), то этот метод применим.

Далее в качестве идентификатора обмена ключами используется Oakley Quick Mode. Nonces передаются в полезной нагрузке аутентификации, а значение prf передается в полезной нагрузке аутентификации; Центр аутентификации - «None», а тип - «Pre-Shared».

Протокол:

Инициатор		Ответчик
->	KEYID, INEWKRQ, Ni, prf(sKEYID, Ni)	->
<-	KEYID, INEWKRS, Nr, prf(sKEYID, 1|Nr|Ni)	<-
->	KEYID, INEWKRP, 0, prf(sKEYID, 0|Ni|Nr)	->

NKEYID = Ni | Nr

sNKEYID = prf(sKEYID, Ni | Nr)

Удостоверения и значения EHA, связанные с NKEYID, такие же, как и у KEYID. Каждая сторона должна проверить хеш-значения, прежде чем использовать новый ключ для любых целей.

Совместимость с ISAKMP

Все поля сообщения OAKLEY соответствуют полезной нагрузке сообщения ISAKMP или компонентам полезной нагрузки.

CKY-I - ISAKMP заголовок

CKY-R - ISAKMP заголовок

MSGTYPE - Тип сообщения в ISAKMP заголовке

GRP - SA нагрузка, Раздел предложений

g^x - полезная нагрузка обмена ключами, закодированная как целое число переменной точности

g^y - полезная нагрузка обмена ключами, закодированная как целое число переменной точности

EHAO - полезная нагрузка SA, раздел предложений

EHAS - SA

IDP - бит в зарезервированом поле заголовка AUTH

ID(I) - AUTH нагрузка, поле идентификации

ID(R) - AUTH нагрузка, поле идентификации

Ni - AUTH нагрузка, поле одноразового номера

Nr - AUTH нагрузка, поле одноразового номера

S{...}Kx - AUTH нагрузка, поле данных

prf{K,...} - AUTH нагрузка, поле данных

Внешние ссылки

• RFC 2412 The OAKLEY Key Determination Protocol