Технологии туннелирования

Содержание


Лекция 1. Алгоритмы симметричного шифрования

Основные понятия

Рассмотрим общую схему симметричной, или традиционной, криптографии.

Общая схема симметричного шифрования


Рис. 1.1.  Общая схема симметричного шифрования

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

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

Незашифрованное сообщение будем обозначать P или M, от слов plaintext и message. Зашифрованное сообщение будем обозначать С, от слова chiphertext.

Безопасность, обеспечиваемая традиционной криптографией, зависит от нескольких факторов.

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

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

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

Клод Шеннон ввел понятия диффузии и конфузии для описания стойкости алгоритма шифрования.

Диффузия – это рассеяние статистических особенностей и закономерностей незашифрованного текста в широком диапазоне статистических особенностей и закономерностей зашифрованного текста. Это достигается тем, что каждый бит или группа битов незашифрованного сообщения влияет на значения многих битов зашифрованного сообщения или, что то же самое, любой бит зашифрованного сообщения зависит от многих битов незашифрованного сообщения.

Конфузия – это уничтожение статистической взаимосвязи между зашифрованным текстом и ключом.

Если P – это исходное сообщение и K – криптографический ключ, то зашифрованный передаваемый текст можно записать в виде

C = EK[P], где EK – алгоритм шифрования.

Получатель, используя тот же ключ, расшифровывает сообщение

P = DK[C], где DK – алгоритм расшифрования

Противник, не имея доступа к K и P, должен попытаться узнать P, K или и то, и другое.

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

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

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

Структура алгоритма симметричного шифрования


Рис. 1.2.  Структура алгоритма симметричного шифрования

Области применения

Необходимо, чтобы алгоритм симметричного шифрования мог приме-няться в следующих областях:

Платформы

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

Специальная аппаратура. Алгоритм должен эффективно реализовы-ваться на специализированной аппаратуре, предназначенной для выполне-ния шифрования / расшифрования.

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

Процессоры среднего размера. Алгоритм должен работать на микро-контроллерах и других процессорах среднего размера.

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

Дополнительные требования

Алгоритм шифрования должен, по возможности, удовлетворять неко-торым дополнительным требованиям.

Сеть Фейштеля

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

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

Сеть Фейштеля имеет следующую структуру. Входной блок делится на несколько равной длины подблоков, называемых ветвями. В случае, если блок имеет длину 64 бита, используются две ветви по 32 бита каждая. Каж-дая ветвь обрабатывается независимо от другой, после чего осуществляется циклический сдвиг всех ветвей влево. Такое преобразование выполняется циклически. В случае двух ветвей каждый раунд имеет структуру, показанную на рисунке:

I-ый раунд сети Фейштеля


Рис. 1.3.  I-ый раунд сети Фейштеля

Функция F называется образующей. Каждый раунд состоит из вычис-ления функции F для одной ветви и побитового выполнения операции XOR результата F с другой ветвью. После этого ветви меняются местами. Считается, что оптимальное число раундов должно быть от 8 до 32. Важно то, что увеличение количества раундов значительно увеличивает криптостой-кость алгоритма. Возможно эта особенность и повлияла на столь активное распространение сети Фейштеля, так как для большей криптостойкости достаточно просто увеличить количество раундов, не изменяя сам алго-ритм. В последнее время количество раундов не фиксируется, а лишь указываются допустимые пределы.

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

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

Основной характеристикой алгоритма, построенного на основе сети Фейштеля, является функция F. Различные варианты касаются также начального и конечного преобразований. Подобные преобразования, назы-ваемые забеливанием (whitening),осуществляются для того, чтобы выпол-нить начальную рандомизацию входного текста.

Криптоанализ

Процесс, при котором предпринимается попытка узнать P, K или и то, и другое, называется криптоанализом. Одной из возможных атак на алго-ритм шифрования является "лобовая атака", называемая также "атакой грубой силы" - "brute force атака". Данная атака состоит в простом переборе всех возможных ключей. Если множество ключей достаточно большое, то подобрать ключ нереально. При длине ключа n бит количество возмож-ных ключей равно2n. Таким образом, чем длиннее ключ, тем более стойким считается алгоритм для лобовой атаки.

Существуют различные типы атак, основанные на том, что противнику известно определенное количество пар незашифрованное сообщение – за-шифрованное сообщение. При анализе зашифрованного сообщения про-тивник часто применяет статистические методы анализа текста. При этом он может иметь общее представление о типе сообщения, например, англий-ский или русский текст, выполняемый файл конкретной ОС, исходный текст на некотором языке программирования и т.д. Во многих случаях криптоаналитик имеет достаточно много информации об исходном тексте. Криптоаналитик может иметь возможность перехвата одного или несколь-ких незашифрованных сообщений вместе с их зашифрованным видом. Или криптоаналитик может знать основной формат или основные характери-стики сообщения. Говорят, что криптографическая схема абсолютно безопасна, если зашифрованное сообщение не содержит никакой информации об исходном сообщении. Говорят, что криптографическая схема вычислительно безопасна, если:

Используемые критерии при разработке алгоритмов

Принимая во внимание перечисленные требования, обычно считается, что алгоритм симметричного шифрования должен:

Алгоритм DES

Принципы разработки

Самым распространенным и наиболее известным алгоритмом симмет-ричного шифрования является DES (Data Encryption Standard). Алгоритм был разработан в 1977 году, в 1980 году был принят NIST (National Institute of Standards and Technolody США) в качестве стандарта (FIPS PUB 46).

DES является классической сетью Фейштеля с двумя ветвями. Данные шифруются 64-битными блоками, используя 56-битный ключ. Процесс шифрования состоит из четырех этапов. На первом из них выполняется начальная перестановка (Initial Permutation - IP) 64-битного исходного сообщения, так называемое забеливание, во время которой биты переупорядочиваются в соответствии со стандартной таблицей. Следующий этап состоит из 16 раундов одной и той же функции, которая использует операции сдвига и подстановки. На третьем этапе левая и правая половины выхода последней (16-й) итерации меняются местами. Наконец, на четвертом этапе выполняется перестановка IP-1 результата, полученного на третьем этапе. Перестановка IP-1 инверсна начальной перестановке.

Общая схема DES


Рис. 1.4.  Общая схема DES

Справа на рисунке показан способ, которым используется 56-битный ключ. Первоначально ключ подается на вход функции перестановки. Затем для каждого из 16 раундов подключ Ki является комбинацией левого циклического сдвига и перестановки. Функция перестановки одна и та же для каждого раунда, но подключи Ki для каждого раунда получаются разные вследствие повторяющегося сдвига битов ключа.

Шифрование

Начальная перестановка

Начальная перестановка и ее инверсия определяются стандартной таблицей. Если X – это произвольные 64 бита, то Y = IP(X) – переставленные 64 бита. Если применить обратную функцию перестановки

то получится первоначальная последовательность битов.

Последовательность преобразований отдельного раунда

Теперь рассмотрим последовательность преобразований, используе-мую в каждом раунде.

I-ый раунд DES


Рис. 1.5.  I-ый раунд DES

64-битный входной блок проходит через 16 раундов, при этом на каждой итерации получается промежуточное 64-битное значение. Левая и правая части каждого промежуточного значения трактуются как отдельные 32-битные значения, обозначенные L и R. Каждую итерацию можно описать следующим образом:

где \oplus обозначает операцию XOR.

Таким образом, выход левой половиныLi равен входу правой половины Ri-1. Выход правой половины Riявляется результатом применения операции XOR к Li-1 и функции F, зависящей от Ri-1 и Ki.

Рассмотрим функцию F более подробно.

Ri, которое подается на вход функции F, имеет длину 32 бита. Вначале Ri расширяется до 48 битов, используя таблицу, которая определяет пере-становку плюс расширение на 16 битов. Расширение происходит следующим образом. 32 бита разбиваются на группы по 4 бита и затем расширяются до 6 битов, присоединяя крайние биты из двух соседних групп. Например, если часть входного сообщения

…efgh ijkl mnop…

то в результате расширения получается сообщение

…defghi hijklm lmnopq…

После этого для полученного 48-битного значения выполняется операция XOR с 48-битным подключом Ki. Затем полученное 48-битное значение подается на вход функции подстановки, результатом которой является 32-битное значение.

Подстановка состоит из восьми S-box, каждый из которых на входе получает 6 бит, а на выходе создает 4 бита. Эти преобразования определяются специальными таблицами. Первый и последний биты входного значения S-box определяют номер строки в таблице, средние 4 бита определяют номер столбца. Значение, стоящее на пересечении строки и столбца является 4-битным выходом. Например, если входом является 011011, то номер строки равен 01 (строка 1) и номер столбца равен 1101 (столбец 13). Если значение на пересечении строки 1 и столбца 13 равно 5, то выходом S-box является 0101.

Далее полученное 32-битное значение обрабатывается с помощью перестановки Р, целью которой является максимальное переупорядочивание битов, чтобы в следующем раунде каждый бит обрабатывался другим S-box.

Создание подключей

Ключ для отдельного раунда Kiсостоит из 48 битов. Ключи Ki получаются по следующему алгоритму. Для 56-битного ключа, используемого на входе алгоритма, вначале выполняется перестановка в соответствии с таб-лицей Permuted Choice 1 (РС-1). Полученный 56-битный ключ разделяется на две 28-битные части, обозначаемые как C0 и D0 соответственно. На каж-дом раунде Ci и Di независимо циклически сдвигаются влево на 1 или 2 бита, в зависимости от номера раунда. Полученные значения являются входом следующего раунда. Они также представляют собой вход в Permuted Choice 2 (РС-2), который создает 48-битное выходное значение, являю-щееся входом функции F(Ri-1,Ki).

Расшифрование

Процесс расшифрования аналогичен процессу шифрования. На входе алгоритма подается зашифрованное сообщение, но ключи Ki используются в обратной последовательности. K16 используется на первом раунде, K1 используется на последнем раунде. Пусть выходом i-ого раунда шифрования будет Li||Ri. Тогда соответствующий вход (16-i)-ого раунда расшифрования будет Ri||Li.

После последнего раунда процесса расшифрования две половины выхода меняются местами так, чтобы вход заключительной перестановки IP-1 былR16||L16. Выходом этой стадии является незашифрованное сообщение.

Таким образом, вход первого раунда расшифрования равен 32-битному выходу 16-ого раунда шифрования, у которого левая и правая части записаны в обратном порядке.

Теперь мы должны показать, что выход первого раунда процесса рас-шифрования равен 32-битному входу 16-ого раунда процесса шифрования. Во-первых, рассмотрим процесс шифрования.

При расшифровании:

XOR имеет следующие свойства:

Таким образом, мы имеем Ld1= R15 и Rd1 = L15. Следовательно, выход первого раунда процесса расшифрования есть L15||R15, который является перестановкой входа 16-го раунда шифрования. Данное соответствие вы-полняется все 16 раундов. Мы можем описать этот процесс в общих терми-нах. Для i-ого раунда шифрующего алгоритма:

Эти равенства можно записать по-другому:

Таким образом, мы описали входы i-ого раунда как функцию выходов.

Выход последней стадии процесса расшифрования есть R0||L0. Чтобы входом IP-1 стадии было L0||R0, необходимо поменять местами левую и правую части. Но

В результате получаем незашифрованное сообщение, что и означает возможность расшифрования DES.

Так как длина ключа равна 56 битам, существует 256 возможных ключей. На сегодняшний день такая длина ключа недостаточна, поскольку допускает успешное применение лобовых атак. Альтернативой DES можно считать тройной DES, а также алгоритм Rijndael, принятый в качестве но-вого стандарта на алгоритмы симметричного шифрования.

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

Алгоритм тройной DES

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

Атака на двойной DES

Простейший способ увеличить длину ключа состоит в повторном при-менении алгоритма DES с двумя разными ключами. Используя незашифрованное сообщение P и два ключа K1 и K2, зашифрованное сообщение С можно получить следующим образом:

Для расшифрования требуется, чтобы два ключа применялись в обратном порядке:

В этом случае длина ключа равна 56 * 2= 112 бит.

Опишем атаку "встреча посередине". Она основана на следующем свойстве алгоритма.

Требуется, чтобы атакующий знал хотя бы одну пару незашифрованное сообщение и соответствующее ему зашифрованное сообщение: (Р,С). В этом случае, во-первых, он шифрует Р на всех возможных 256 значений ключей.

Этот результат запоминается в таблице, и затем таблица упорядочивается по значению Х. Затем нарушитель расшифровывает С, используя все возможные 256 значения ключа. Для каждого расшифрованного значения ищется равное ему значение в первой таблице. Если соответствующее значение найдено, то это возможные ключи.

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

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

Тройной DES с двумя ключами

Очевидное противодействие атаке "встреча посередине" состоит в использовании третьей стадии шифрования с тремя различными ключами. Это поднимает стоимость атаки с известным незашифрованным текстом до 2168, которая на сегодняшний день считается выше практических возможностей. Но при этом длина ключа равна 56 * 3 = 168 бит, что иногда бывает громоздко.

В качестве альтернативы можно использовать тройное шифрование с двумя ключами. В этом случае выполняется последовательность шифрова-ние-расшифрование-шифрование (EDE).

Шифрование тройным DES с двумя ключами


Рис. 1.6.  Шифрование тройным DES с двумя ключами

Расшифрование тройным DES с двумя ключами


Рис. 1.7.  Расшифрование тройным DES с двумя ключами

Не имеет большого значения, что используется на второй стадии: шифрование или расшифрование. В случае использования расшифрования существует только то преимущество, что можно тройной DES свести к обычному одиночному DES, используя K1=K2:

Тройной DES является достаточно популярной альтернативой DES и используется при управлении ключами в стандартах ANSIX9.17 и ISO 8732 и в PEM (Privacy Enhanced Mail).

Известных криптографических атак на тройной DES не существует. Цена подбора ключа в тройном DES с двумя ключами равна 2112.

1.10 Алгоритм ГОСТ 28147

Алгоритм ГОСТ 28147 является отечественным стандартом на алго-ритмы симметричного шифрования. ГОСТ 28147 разработан в 1989 году, является блочным алгоритмом шифрования, длина блока равна 64 битам, длина ключа равна 256 битам, количество раундов равно 32. Алгоритм представляет собой классическую сеть Фейштеля.

Функция F проста. Сначала правая половина и i-ый подключ склады-ваются по модулю 232. Затем результат разбивается на восемь 4-битовых значений, каждое из которых подается на вход S-box. ГОСТ 28147 использует восемь различных S-box, каждый из которых имеет 4-битовый вход и 4-битовый выход. Выходы всех S-box объединяются в 32-битное слово, которое затем циклически сдвигается на 11 битов влево. Наконец, с помощью XOR результат объединяется с левой половиной, в результате чего получается новая правая половина.

I- ый раунд алгоритма ГОСТ 28147


Рис. 1.8.  I- ый раунд алгоритма ГОСТ 28147

Генерация ключей проста. 256-битный ключ разбивается на восемь 32-битных подключей. Алгоритм имеет 32 раунда, поэтому каждый подключ используется в четырех раундах по следующей схеме:

Таблица 1.1.
Раунд12345678
Подключ12345678
Раунд910111213141516
Подключ12345678
Раунд1718192021222324
Подключ12345678
Раунд2526272829303132
Подключ87654321

Считается, что стойкость алгоритма ГОСТ 28147 во многом определяется структурой S-box. Долгое время структура S-box в открытой печати не публиковалась. В настоящее время известны S-box, которые используются в приложениях Центрального Банка РФ и считаются достаточно сильными. Напомню, что входом и выходом S-box являются 4-битные числа, поэтому каждый S-box может быть представлен в виде строки цифр от 0 до 15, расположенных в некотором порядке. Тогда порядковый номер цифры будет являться входным значением S-box, а сама цифра – выходным значением S-box.

Таблица 1.2.
1-ый S-box 4 10 9 2 13 8 0 14
61111271553
2-ой S-box14114126131510
23810759
3-ий S-box5811310342
141512760911
4-ый S-box71310108915
14461211253
5-ый S-box61271515138
41091403112
6-ой S-box41110072113
36859121514
7-ой S-box13114131559
01014768212
8-ой S-box11513057104
92314611812

Основные различия между алгоритмами DES и ГОСТ 28147 следующие:

Лекция 2. Алгоритм AES. Режимы выполнения алгоритмов симметричного шифрования. Создание случайных чисел

Алгоритм AES

Инициатива в разработке AES (Advanced Encryption Standard) принад-лежит NIST. Основная цель состояла в создании алгоритма симметричного шифрования, который мог бы использоваться для защиты информации как в государственном, так и в частном секторе.

В результате длительного процесса оценки был выбран алгоритм Rijndael в качестве алгоритма AES. Мы кратко рассмотрим основные принципы выбора алгоритма, характеристики алгоритмов, которые рассматривались в качестве претендентов на AES.

В январе 1997 года NIST объявил о начале разработки AES, и в сентяб-ре 1997 года были представлены официальные требования к алгоритмам. В этих требованиях указывалось, что целью NIST является разработка неклассифицированного, хорошо проанализированного алгоритма шифрования, доступного для широкого применения. Алгоритм должен быть сим-метричным, блочным, поддерживать длину блока 128 бит и длину ключа 128, 192 и 256 бит.

В августе 1998 года NIST анонсировал пятнадцать кандидатов на алгоритм AES на первой конференции по кандидатам AES. Данные алгоритмы были разработаны промышленными и академическими кругами двенадцати стран. Вторая конференция по кандидатам AES была проведена в марте 1999 года с целью обсуждения результатов анализа предложенных алгоритмов. В августе 1999 года были представлены выбранные NIST пять финалистов. Ими стали MARS, RC6TM, Rijndael, Serpent и Twofish.

Обзор алгоритмов

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

Первое и последнее преобразования могут отличаться от преобразования остальных раундов. Такие операции, используемые на начальном шаге первого раунда и заключительном шаге последнего раунда, называются pre- и post-забеливанием (whitening) и могут быть определены отдельно.

Рассмотрим основные особенности алгоритмов. В четырех алгоритмах существуют таблицы подстановки, называемые S-box: A x B-битный S-box преобразует А входных битов в В выходных битов. Три алгоритма основаны на сети Фейштеля. В классической сети Фейштеля в каждом раунде преобразуется только одна половина блока данных, затем половины блока меняются местами. Два алгоритма не используют сеть Фейштеля, в результате этого в каждом раунде обрабатывается весь блок данных, используя различные подстановки и преобразования.

MARS выполняет последовательность преобразований в следующем порядке: сложение с ключом в качестве pre-whitening, 8 раундов прямого перемешивания без использования ключа, 8 раундов прямого преобразова-ния с использованием ключа, 8 раундов обратного преобразования с использованием ключа, 8 раундов обратного перемешивания без использования ключа и вычитание ключа в качестве post-whitening. 16 раундов с использованием ключа называются криптографическим ядром. Раунды без ключа используют два 8X16- битных S-box и операции сложения и XOR. В дополнение к этим элементам раунды с ключом используют 32-битное умножение ключа, зависимые от данных циклические сдвиги и добавление ключа. Как раунды перемешивания, так и раунды ядра являются раундами модифицированной сети Фейштеля, в которых четверть блока данных используется для изменения остальных трех четвертей блока данных. MARS был предложен корпорацией IBM.

RC6 является параметризуемым семейством алгоритмов шифрования, основанных на сети Фейштеля; в качестве AES было предложено использовать 20 раундов. Функция раунда в алгоритме RC6использует переменные циклические сдвиги, которые определяются квадратичной функцией от данных. Каждый раунд также включает умножение по модулю 32, сложение, XOR и сложение с ключом. Сложение с ключом также используется для pre- и pos-whitening. RC6 был предложен лабораторией RSA.

Rijndael представляет собой алгоритм, использующий линейно-подстановочные преобразования и состоящий из 10, 12 или 14 раундов в зависимости от длины ключа. Блок данных, обрабатываемый алгоритмом Rijndael, представляется в виде последовательности байтов, и в этом смысле каждое преобразование является байт-ориентированным. Функция раунда Rijndael состоит из четырех слоев. В первом слое для каждого байта применяется S-box размерностью 8х8 бит. Второй и третий слои являются линейными перемешиваниями, в которых строки рассматриваются в качестве сдвигаемых массивов и столбцы перемешиваются. В четвертом слое выполняется операция XOR байтов подключа и массива. В последнем раунде перемешивание столбцов опущено. Rijndael предложен Joan Daemen (Proton World International) и Vincent Rijmen (Katholieke Universiteit Leuven).

Serpent является алгоритмом, использующим линейно-подстановочные преобразования и состоящим из 32 раундов. Serpent также определяет не криптографические начальную и заключительную перестановки, которые облегчают альтернативный режим реализации, называемый bit slice. Функция раунда состоит из трех слоев: операция XOR с ключом, 32-х параллельное применение одного из восьми фиксированных S-box и линейное преобразование. В последнем раунде слой операции XOR с ключом заменен на линейное преобразование. Serpent предложен Ross Anderson (University of Cambridge), Eli Biham (Technion) и Lars Knudsen (University of California San Diego).

Twofish является сетью Фейштеля с 16 раундами. Сеть Фейштеля не-значительно модифицирована с использованием однобитных ротаций. Функция раунда влияет на 32-битные слова, используя четыре зависящих от ключа S-box, за которыми следуют фиксированные максимально удаленные отдельные матрицы в GF(28), преобразование псевдо-Адамара и добавление ключа. Twofish был предложен Bruce Schneier, John Kelsey и Niels Ferguson (Counterpane Internet Security, Inc.), Doug Whiting (Hi/fn, Inc.), David Wagner (University of California Berkley) и Chris Hall (Princeton University).

Критерий оценки

В сентябре 1997 года были определены общие критерии, которые должны использоваться для сравнения алгоритмов.

В сентябре 1997 года были определены общие критерии, которые должны использоваться для сравнения алгоритмов.

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

Стоимость является вторым по важности параметром оценки, который характеризует лицензионные требования, вычислительную эффективность (скорость) на различных платформах и требования к памяти. Так как одной из целей была возможность широкого использования алгоритма AES без лицензионных ограничений, обсуждались в основном требования защиты интеллектуальной собственности и потенциальные конфликты, связанные с этим. Рассматривалась также скорость работы алгоритма на различных платформах. В первую очередь основное внимание уделялось скорости, связанной со 128-битными ключами. Затем рассматривались аппаратные реализации и производительность алгоритма при использовании 192- и 256-битных ключей. Также рассматривались требования к памяти и ограничения программной реализации.

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

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

Принципы выбора алгоритма

До выбора алгоритма следовало принять несколько фундаментальных решений:

Качественный или количественный критерий

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

Количество алгоритмов AES

Высказывались несколько аргументов относительно количества алго-ритмов, которые должны быть выбраны в качестве AES. Также обсуждался вопрос относительно "запасного" алгоритма для случая, если будет выбран единственный AES-алгоритм, и его модификация в случае обнаружения уязвимости окажется невозможной.

Были также высказаны мнения в пользу единственного алгоритма (против нескольких алгоритмов). Некоторые из этих аргументов таковы:

Существует вероятность, что в подавляющем большинстве случаев приложения будут реализовывать несколько алгоритмов, что определяется нуждами потребителей, требованиями интероперабельности с наследуемыми или собственными системами и так далее. Тройной DES, который NIST предлагает оставить в обозримом будущем FIPS-алгоритмом, доступен во многих коммерческих продуктах, как и другие FIPS и не-FIPS алгоритмы. Считается, что наличие подобных нескольких алгоритмов в конкретном приложении обеспечивает большую степень надежности, как и наличие нескольких длин ключей в AES. В случае атаки на выбранный алгоритм предлагается задействовать соответствующие исследованные параметры других кандидатов AES, у которых отсутствуют подобные атаки, либо в случае необходимости определить полностью новые подходы.

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

В результате было решено выбрать единственный алгоритм.

Запасной алгоритм

Как уже отмечалось, существует взаимосвязь между проблемой, связанной с выбором нескольких алгоритмов AES и выбором запасного алгоритма, особенно в случае единственного алгоритма AES. Запасной алгоритм может иметь несколько форм, от алгоритма, который требуется реализовывать в продуктах AES ("hot backup"), до определяемого в AES за-пасного алгоритма ("cold backup"). Было доказано, что запасной алгоритм во многом эквивалентен второму AES-алгоритму, так как многие пользова-тели пожелают, чтобы даже "cold backup" был реализован в продуктах.

Итак, имея

было принято решение не выбирать запасной алгоритм.

Модификация алгоритмов

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

Было принято решение не изменять количество раундов AES-алгоритма. Причины этого в следующем:

Безопасность AES

Безопасность является самым важным фактором при оценке алгоритмов. В отношении ни одного из алгоритмов никаких атак не выявлено.

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

Трудно оценить важность атак на варианты с уменьшенным числом раундов. С одной стороны, варианты с уменьшенным числом раундов на самом деле являются другими алгоритмами, и таким образом атаки на них никак не характеризуют безопасность исходных алгоритмов. Алгоритм может быть безопасен при n раундах, даже если он уязвим при n-1 раунде. С другой стороны, обычной практикой в современном криптоанализе являются попытки сконструировать атаки на варианты с уменьшенным числом раундов. С этой точки зрения вполне понятны попытки оценить "резерв безопасности" рассматриваемых алгоритмов, основываясь на атаках на варианты с уменьшенным числом раундов.

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

Программные реализации

Программные реализации алгоритмов могут быть выполнены в широ-ком диапазоне языков программирования и аппаратных архитектур. В не-которых случаях память никак не ограничена; в других случаях RAM и/или ROM могут быть существенно ограничены. Иногда большое количество данных шифруется и расшифровываются единственным ключом. В остальных случаях ключ изменяется часто, возможно, для каждого блока данных.

Скорость шифрования и/или расшифрования часто является противо-положностью безопасности. Это означает, что число раундов, указанное для алгоритма, является фактором безопасности; скорость шифрования или расшифрования приблизительно пропорциональна числу раундов. Таким образом, скорость не может исследоваться независимо от безопас-ности.

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

Размер машинного слова

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

Считается, что в ближайшие годы 8-битные, 32-битные и 64-битные архитектуры будут играть важнейшую роль (в какой-то момент будут добавлены 128-битные архитектуры). Хотя 8-битные архитектуры используются приложениями, которые имеют и 32-битные версии, 8-битные архитектуры не исчезнут окончательно. Между тем некоторые 32-битные архитектуры будут вытеснены 64-битными версиями, но 32-битные архитектуры будут использоваться приложениями с более низкими требованиями, т.е. важность 32-битных архитектур также останется высокой. Важность 64-битных архитектур будет возрастать. Таким образом, AES должен хорошо выполняться на различных архитектурах.

Следует заметить, что выполнение не может оцениваться только на ос-нове длины слова. Должны учитываться также дополнительные факторы, предоставляемые ПО, которые обсуждаются далее.

Языки реализации

Выполнение также зависит от использования конкретного языка (например, ассемблер, компилируемый или интерпретируемый язык высокого уровня). В некоторых случаях играет роль конкретное ПО. Существует целый спектр возможностей. Как одна из крайностей, вручную созданный ассемблерный код обеспечивает выполнение лучшее, чем даже оптимизирующий компилятор. Другая крайность - это интерпретируемые языки, которые в общем случае плохо решают задачи оптимизации. Оптимизация, выполняемая компиляторами, находится где-то посередине. Также следует заметить, что некоторые компиляторы работают лучше других, обеспечивая поддержку предоставляемых архитектурой операций, например, 32-битную ротацию. Это увеличивает трудность оценки выполнения на различных платформах.

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

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

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

Окружения с ограничениями пространства

В некоторых окружениях, обладающих небольшими объемами RAM и/или ROM для таких целей, как хранение кода (обычно в ROM), представление объектов данных, таких как S-box (которые могут храниться в RAM или ROM в зависимости от того, известны ли они заранее или нет) и хранение подключей (в RAM), существуют значительные ограничения. Теоретически могут использоваться промежуточные формы хранения, например, EEPROM, для таких значений как подключи. Тем не менее, можно предполагать, что подключи также хранятся в RAM.

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

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

Алгоритм Rijndael

В качестве AES был выбран алгоритм Rijndael.

Предварительные математические понятия

Практически все операции Rijndael определяются на уровне байта. Байты можно рассматривать как элементы конечного поля GF (28). Некоторые операции определены в терминах четырехбайтных слов. Введем основные математические понятия, необходимые для обсуждения алгоритма.

Поле GF (2^8)

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

Байт b, состоящий из битов b7, b6, b5, b4, b3, b2, b1, b0, можно записать в виде полинома с коэффициентами из {0, 1}:

Пример: байт с шестнадцатеричным значением 57 (двоичное значение 01010111) соответствует полиному

Определим операцию сложения.

Сумма двух элементов, представленных в виде полинома, является полиномом с коэффициентами, равными сумме по модулю 2 (т.е. 1 + 1 = 0) коэффициентов слагаемых.

Пример:

В полиномиальной нотации:

В бинарной нотации:

Введенное таким образом сложение есть XOR битов в байте.

Выполнены все необходимые условия Абелевой группы: определена операция сложения, обладающая свойством, что каждой паре элементов сопоставляется третий элемент группы, называемый их суммой. Существует нулевой элемент, равный ‘00’, обратный элемент относительно опера-ции сложения. Операция обладает свойствами ассоциативности и коммутативности.

Определим операцию умножения.

В полиномиальном представлении умножение в GF (28) соответствует умножению полиномов по модулю неприводимого двоичного полинома степени 8. Полином называется неприводимым, если он не имеет делителей, кроме 1 и самого себя. Для Rijndael такой полином является m(x):

или ‘11B’ в шестнадцатеричном представлении.

Пример:

Сначала перемножим два полинома

Теперь найдем остаток от деления на полином m(x)

Таким образом, получили

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

Введенная операция умножения является ассоциативной, существует единичный элемент ‘01’. Для любого двоичного полинома b(x) не выше 7-й степени можно использовать расширенный алгоритм Евклида для вычисления полиномов a(x) и c(x) таких, что

Это можно записать как

или

Более того, можно показать, что

Из всего этого следует, что множество из 256 возможных значений байта образует конечное поле GF (28) c XOR в качестве сложения и умножением, определенным выше.

Умножение на х

При умножении b(x)на полином х получаем:

Для вычисления x • b(x) необходимо результат взять по модулю m(x). Если b7 = 0, то результатом является исходный полином, для которого выполнен сдвиг на 1 бит влево. Если b7 = 1, то кроме сдвига влево на 1 бит следует выполнить операцию XOR с m(x). Следовательно, умножение на х на уровне байта есть левый сдвиг и в зависимости от значения b7 побитовый XOR c ‘1B’. Данная операция обозначается как xtime (b).

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

Полиномы с коэффициентами из GF (2^8)

Полиномы могут быть определены с коэффициентами из GF (28). В этом случае четырехбайтный вектор соответствует полиному степени 4.

Операцию сложения можно ввести как XOR соответствующих коэффи-циентов.

Умножение вводится более сложным способом. Предположим, что мы имеем два полинома в GF (28).

определяется следующим образом:

Ясно, что в таком виде с(х)не может быть представлен четырехбайтным вектором. Если понизить с(х) по модулю полинома 4-й степени, то результат будет полиномом не выше 3 степени. В Rijndael для этого используется полином

В этом случае

Остаток от деления а(х)•b(x)на M(x)обозначим d(x) = a(x)⊗ b(x).

Коэффициенты d(x)равны:

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

Умножение на фиксированный полином в GF (2^8)


Рис. 2.1.  Умножение на фиксированный полином в GF (2^8)

Заметим, что х4+ 1 не является несократимым полиномом в GF (28), следовательно, умножение на фиксированный полином необязательно обратимо. В алгоритме Rijndael выбран фиксированный полином, который имеет обратный.

Умножение на х

При умножении b(x)на полином х имеем:

x × b(x)получается понижением полученного результата по модулю х4+1. Получаем

Умножение на х эквивалентно умножению на матрицу, как описано выше, со всеми ai=‘00’ за исключением а1 = ‘01’.

Имеем:

Умножение на х в GF (2^8)


Рис. 2.2.  Умножение на х в GF (2^8)

Следовательно, умножение на х соответствует циклическому сдвигу байтов внутри вектора.

Обоснование разработки

В основу разработки алгоритма были положены следующие три критерия:

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

Каждый слой разрабатывался с учетом противодействия линейному и дифференциальному криптоанализу. В основу каждого слоя положена своя функция:

Перед первым раундом применяется дополнительное забеливание с ис-пользованием ключа. Причина того, что в забеливании используется ключ, состоит в следующем. Любой слой после последнего или до первого добавления ключа может быть просто снят без знания ключа и тем самым не добавляет безопасности в алгоритм (например, начальная и конечная перестановки в DES).

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

Описание алгоритма

Rijndael является блочным алгоритмом шифрования с переменной длиной блока и переменной длиной ключа. Длина блока и длина ключа могут быть независимо друг от друга установлены в 128, 192 или 256 бит.

Понятие состояния, ключ шифрования и число раундов

Различные преобразования выполняются над промежуточным значением блока, называемым состоянием

Состояние можно рассматривать как двумерный массив байтов. Этот массив имеет четыре строки и различное число столбцов, обозначаемое как Nb, равное длине блока, деленной на 32. Ключ также можно рассматривать как двумерный массив с четырьмя строками. Число столбцов ключа шифрования, обозначаемое как Nk, равно длине ключа, деленной на 32.

В некоторых случаях блок шифруемого сообщения рассматривается как одномерный массив четырехбайтных векторов, где значениями каждого вектора являются значения соответствующего столбца. Такие массивы имеют длину 4, 6 или 8 соответственно, и индексы в диапазонах 0…3, 0…5 или 0…7. Четырехбайтные вектора иногда мы будем называть словами.

Если необходимо указать четыре отдельных байта в четырехбайтном векторе, будет использоваться нотация (a, b, c, d), где a, b, c и d являются байтами в позициях 0, 1, 2 и 3, соответственно, в рассматриваемом столбце, векторе или слове.

Пример состояния (с Nb = 6) и ключа шифрования (с Nk = 4)


Рис. 2.3.  Пример состояния (с Nb = 6) и ключа шифрования (с Nk = 4)

Входы и выходы Rijndael считаются одномерными массивами из 8 бай-тов, пронумерованными от 0 до 4* Nb – 1. Следовательно, эти блоки имеют длину 16, 24 или 32 байта, и массив индексируется в диапазонах 0 … 15, 0 … 23 или 0 … 31. Ключ считается одномерным массивом 8-битных байтов, пронумерованных от 0 до 4* Nk – 1. Следовательно, эти блоки имеют длину 16, 24 или 32 байта, и массив индексируется в диапазонах 0 … 15, 0 … 23 или 0 … 31.

Входные байты алгоритма отображаются в байты состояния в следующем порядке: А0,0, А1,0, А2,0, А3,0, А0,1, А1,1, А2,1, А3,1, А0,2, … Байты ключа шифрования отображаются в массив в следующем порядке: K0,0, K1,0, K2,0, K3,0, K0,1, K1,1, K2,1, K3,1, … После выполнения операции шифрования выход алгоритма получается из байтов состояния аналогичным образом.

Следовательно, если одномерный индекс байта в блоке есть n, и двухмерный индекс есть (i,j), то мы имеем:

Более того, индекс i является также номером байта в четырехбайтном векторе или слове, j является индексом вектора или слова во вложенном блоке.

Число раундов обозначается Nr и зависит от значений Nb и Nk, что показано в следующей таблице.

Число раундов как функция от длины блока и длины ключа)


Рис. 2.4.  Число раундов как функция от длины блока и длины ключа)

Преобразование раунда

Преобразование раунда состоит из четырех различных преобразований. В нотации на псевдо С это можно записать следующим образом:

Round (State, RoundKey)
	{
		ByteSub (State);
		ShiftRow (State);
		MixColumn (State);
		AddRoundKey (State, RoundKey);
	}

Заключительный раунд алгоритма немного отличается и выглядит сле-дующим образом:

FinalRound (State, RoundKey)
	{
		ByteSub (State);
		ShiftRow (State);
		AddRoundKey (State, RoundKey);
	}

Как мы видим, заключительный раунд эквивалентен остальным, за ис-ключением того, что отсутствует слой MixColumn.

Преобразование ByteSub

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

Во-первых, выполняется мультипликативная инверсия в GF (28) для определенного выше представления байта в виде полинома 7 степени. ‘00’ отображается сам в себя.

Затем выполняется аффинное (в GF (2)) преобразование, определяемое следующим образом:

Аффинное преобразование


Рис. 2.5.  Аффинное преобразование

Применение описанного S-box ко всем байтам состояния обозначается как

ByteSub (State)

На следующем рисунке показан результат применения преобразования ByteSub к State.

 Применение ByteSub для каждого байта в State


Рис. 2.6.  Применение ByteSub для каждого байта в State

Обратное преобразование ByteSub есть применение байтовой подста-новки в соответствии с инверсной таблицей. Это получается инверсией аффинного отображения и мультипликативной инверсией в GF (28).

Преобразование ShiftRow

В ShiftRow строки состояния циклически сдвигаются на различные значения. Нулевая строка не сдвигается. Строка 1 сдвигается на С1 байтов, строка 2 на С2 байтов, строка 3 на С3 байтов. Величины С1, С2 и С3 зависят от Nb. Значения приведены в следующей таблице.

 Величина сдвига в зависимости от длины блока


Рис. 2.7.  Величина сдвига в зависимости от длины блока

Операция сдвига строк на указанные значения обозначается как

ShiftRow (State)

Инверсией для ShiftRow является циклический сдвиг трех нижних строк соответственно на Nb – С1, Nb – С2 и Nb – С3 байт, чтобы байт в позиции j в строке i перемещался в позицию (j + Nb – Ci) mod Nb.

Преобразование MixColumn

В MixColumn столбцы состояния рассматриваются как полиномы в GF(28) и умножаются по модулю х4 + 1 на фиксированный полином:

Данный полином является взаимно простым с х4 + 1 и, следовательно, имеет обратный. Как обсуждалось, это может быть записано в виде умножения матрицы.

Пусть b(x) = c(x) /otimes a(x)

 Преобразование MixColumn умножением на полином c(x)


Рис. 2.8.  Преобразование MixColumn умножением на полином c(x)

Применение данной операции ко всем столбцам состояния обозначает-ся как

MixColumn (State)

Инверсия MixColumn является преобразованием, аналогичным MixColumn. Каждый столбец преобразуется умножением его на полином d(x), определяемый следующим образом:

В результате получаем

Сложение с ключом раунда

Выполняется операция побитового XOR ключа раунда с текущим состоянием. Длина ключа раунда равна длине блока Nb. Данное преобразование обозначается как

AddRoundKey (State, RoundKey)

AddRoundKey является инверсией самого себя.

Создание ключей раунда

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

Расширение ключа

Расширенный ключ является линейным массивом четырехбайтных слов и обозначается как W [Nb * (Nr + 1)]. Первые Nk слов состоят из ключа шифрования. Остальные слова определяются рекурсивно. Функция расширения ключа зависит от значения Nk: существует версия функции для Nk, равным или меньшим 6, и версия для Nk больше 6.

Для Nk ≤ 6 мы имеем:

KeyExpansion (byte Key [4*Nk] word W[Nb * (Nr + 1)])
{
for (i = 0; i < Nk; i++)
W[i] =(Key [4*i], Key [4*i+1], Key [4*i+2], Key [4*i+3]);
	for (i = Nk; i < Nb * (Nr + 1); i++) {
		temp = W [i – 1];
		if (i % Nk == 0)
temp = SubByte (RotByte (temp)) ^ Rcon [i / Nk];
		W [i] = W [i- Nk] ^ temp;
	}
}

В данном случае SubByte (W) является функцией, которая возвращает четырехбайтное слово, в котором каждый байт является результатом применения S-box Rijndael к байту в соответствующей позиции во входном слове. Функция RotByte(W) возвращает слово, в котором байты циклически переставлены таким образом, что для входного слова (a, b, c, d) создается выходное слово (b, c, d, a).

Можно заметить, что первые Nk слов заполняются ключом шифрования. Каждое следующее слово W[i] равно XOR предыдущего слова W[i-1] и позиций слова Nk до W[i – Nk]. Для слов в позициях, которые кратны Nk, сначала применяется преобразование XOR к W[i-1] и константой раунда. Данное преобразование состоит из циклического сдвига байтов в слове (RotByte), после чего выполняется табличная подстановка для всех четырех байтов в слове (SubByte).

Для Nk > 6 мы имеем:

KeyExpansion (byte Key [4*Nk] word W [Nb* (Nr+1)])
{
	for (i=0; i < Nk; i++) 
W[i]= (key [4*i], key [4*i+1], key [4*i+2], key [4*i+3]);
	for (i = Nk; i < Nb * (Nr + 1); i++) {
		temp = W [i-1];
		if (i % Nk == 0)
temp = SubByte (RotByte (temp)) ^ Rcon [i / Nk];
		else if (i % Nk == 4)
			temp = SubByte (temp);
		W[i] = W[i – Nk] ^ temp;
	}
}

Отличие для Nk ≤ 6 состоит в том, что для i-4, кратных Nk, SubByte применяется для W[i-1] перед выполнением XOR.

Константы раунда не зависят от Nk и определяются следующим образом:

Rcon [i] = (RC [i], ‘00’, ‘00’, ‘00’)

RC [i] являются элементами в GF (28) со значением x(i-1) таким, что:

RC [1] = 1 (т.е. ‘01’)
RC [i] = x (т.е. ‘02’) • (RC [i-1]) = x(i-1)

Ключ раунда i получается из слов буфера ключа раунда W [Nb * i] до W [Nb * (i+1)].

Преимущества алгоритма

Преимущества, относящиеся к аспектам реализации:

Простота разработки:

Переменная длина блока:

Расширения:

Расширения алгоритма

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

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

Структура алгоритма допускает длину блока, кратную 4 байтам. Минимальная длина блока должна быть 16 байтов. Увеличение длины ключа, ByteSub и MixColumn преобразования не зависят от длины блока. Единственным преобразованием, которое зависит от длины блока, является ShiftRow. Для каждой длины блока должны быть определены соответствующие константы С1, С2, С3.

Можно определить расширение Rijndael, которое также поддерживает длины блока и ключа между 128 и 256 битами с шагом 32 бита. Число раундов определяется следующим образом:

Данное выражение задает правило определения количества раундов для альтернативных значений длины блока и длины ключа.

Соответствующие значения С1, С2 и С3 указаны в следующей таблице.

Таблица 2.1.
Nb C1 C2 C3
5 1 2 3
7 1 2 4

Режимы выполнения алгоритмов симметричного шифрования

Для симметричных блочных алгоритмов шифрования определено четыре режима выполнения.

ECB – Electronic Codebook – каждый блок незашифрованного сообщения шифруется независимо от остальных блоков, с применением одного и того же ключа шифрования. Типичное применение – передача небольшого значения (например, криптографического ключа), длина которого сопоставима с длиной блока.

CBC – Cipher Block Chaining – на вход алгоритму шифрования подается результат операции XOR предыдущего блока зашифрованного сообщения и следующего блока незашифрованного сообщения. Типичное применение – шифрование больших сообщений.

CFB – Cipher Feedback – при каждом вызове алгоритма обрабатывается J битов входного значения. Предыдущий зашифрованный блок используется в качестве входа в алгоритм; к J битам выхода алгоритма и следующему незашифрованному блоку из J битов применяется операция XOR, результатом которой является следующий зашифрованный блок из J битов. Типичное применение – шифрование потока небольших сообщений в режиме реального времени, когда нецелесообразно ждать завершения формирования всего сообщения.

OFB – Output Feedback – аналогичен CFB, за исключением того, что на вход алгоритма при шифровании следующего блока подается результат шифрования предыдущего блока; только после этого выполняется операция XOR с очередными J битами незашифрованного сообщения. Типичное применение – потоко ориентированная передача по зашумленному каналу, в котором возможны потери пакетов.

Режим ECB

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

Режим ЕСВ идеален для небольшого количества данных, например, для шифрования ключа сессии.

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

Режим CBC

Для преодоления недостатков ECB используют способ, при котором одинаковые незашифрованные блоки преобразуются в различные зашифрованные. Для этого в качестве входа алгоритма используется результат применения операции XOR к текущему незашифрованному блоку и предыдущему зашифрованному блоку.

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

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

 Шифрование в режиме СВС


Рис. 2.9.  Шифрование в режиме СВС

 Расшифрование в режиме СВС


Рис. 2.10.  Расшифрование в режиме СВС

Режим CFB

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

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

Будем считать, что блок данных, используемый для передачи, состоит из J бит; обычным значением является J=8. Как и в режиме CBC, здесь используется операция XOR для предыдущего блока зашифрованного текста и следующего блока незашифрованного текста. Таким образом, любой блок зашифрованного текста является функцией от всего предыдущего незашифрованного текста.

Рассмотрим шифрование. Входом функции шифрования является регистр сдвига, который первоначально устанавливается в инициализационный вектор IV. Для левых J битов выхода алгоритма выполняется операция XOR с первыми J битами незашифрованного сообщения Р1 для получения первого блока зашифрованного сообщения С1. Кроме того, содержи-мое регистра сдвигается влево на J битов, и С1 помещается в правые J битов этого регистра. Этот процесс продолжается до тех пор, пока не будет зашифровано все сообщение.

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

 Шифрование в режиме СFВ


Рис. 2.11.  Шифрование в режиме СFВ

 Расшифровывание в режиме СFВ


Рис. 2.12.  Расшифровывание в режиме СFВ

Режим OFB

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

Основное преимущество режима OFB состоит в том, что если при передаче произошла ошибка, то она не распространяется на следующие зашифрованные блоки, и тем самым сохраняется возможность расшифрования последующих блоков. Например, если появляется ошибочный бит в Сi, то это приведет только к невозможности расшифрования этого блока и получения Рi. Дальнейшая последовательность блоков будет расшифрована корректно. При использовании режима CFB Сi подается в качестве входа в регистр и, следовательно, является причиной последующего искажения потока.

Недостаток OFB в том, что он более уязвим к атакам модификации потока сообщений, чем CFB.

 Шифрование в режиме OFB


Рис. 2.13.  Шифрование в режиме OFB

 Расшифровывание в режиме OFВ


Рис. 2.14.  Расшифровывание в режиме OFВ

Создание случайных чисел

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

Требования к случайным числам

Большинство алгоритмов сетевой безопасности, основанных на криптографии, использует случайные числа. Например:

  1. Схемы взаимной аутентификации. В большинстве сценариев аутентификации и распределения ключа для предотвращения атак повтора (replay-атак) используются случайные числа, ко-торые в этом случае называются nonсe (number only once – число, используемое только один раз). Применение действительно случайных чисел в качестве nonce не дает противнику возможности вычислить или угадать nonce.
  2. Ключ сессии, созданный центром распределения ключей (Key Distribution Center – KDC) или кем-либо из участников.

Двумя основными требованиями к последовательности случайных чисел являются случайность и непредсказуемость.

  1. Случайность

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

    Однородное распределение: распределение чисел в последовательности должно быть однородным; это означает, что частота появления каждого числа должна быть приблизительно одинаковой.

    Независимость: ни одно значение в последовательности не должно зависеть от других.

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

  2. Непредсказуемость

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

Источники случайных чисел

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

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

Рассмотрим несколько алгоритмов генерации псевдослучайных чисел.

Генераторы псевдослучайных чисел

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

  1. Циклическое шифрование

    В данном случае применяется способ создания ключа сессии из мастер-ключа. Счетчик с периодом N используется в качестве входа в шифрующее устройство. Например, в случае использования 56-битного ключа DES может применяться счетчик с периодом 256. После каждого созданного ключа значение счетчика увеличивается на 1. Таким образом, псевдослучайная последовательность, полученная по данной схеме, имеет полный период: каждое выходное значение Х0, Х1,...ХN-1 основано на различных значениях счетчика и, следовательно, Х0 ≠ X1 ≠ XN-1. Так как мастер-ключ защищен, то полученное случайное число не зависит от предыдущих случайных чисел.

     Циклическое шифрование


    Рис. 2.15.  Циклическое шифрование

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

  2. Режим Output Feedback DES

    Режим OFB DES может применяться для генерации ключа, аналогично тому, как он используется для потокового шифрования. Заметим, что выхо-дом каждой стадии шифрования является 64-битное значение, из которого только левые j битов подаются обратно для шифрования. 64-битные выходы составляют последовательность псевдослучайных чисел с хорошими статистическими свойствами.

  3. Генератор псевдослучайных чисел ANSI X9.17

    Один из наиболее сильных генераторов псевдослучайных чисел описан в стандарте ANSI X9.17. В число приложений, использующих эту технологию, входят приложения финансовой безопасности и PGP.

    Используется алгоритм шифрования тройной DES. Генератор ANSI X9.17 состоит из следующих частей:

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

    Ключи: генератор трижды использует алгоритм тройного DES. Все три раза используется одна и та же пара 56-битных ключей, которая должна держаться в секрете и применяться только для генерации псевдослучайного числа.

    Выход состоит из 64-битного псевдослучайного числа и 64-битного значения, которое будет использоваться в качестве начального значения при создании следующего числа.

     Генератор псевдослучайных чисел ANSIX9.17


    Рис. 2.15.  Генератор псевдослучайных чисел ANSIX9.17

    DTi – значение даты и времени создания i-го псевдослучайного числа.

    Vi – начальное значение при создании i-го псевдослучайного числа.

    Rii-ое псевдослучайное число.

    Rii-ое псевдослучайное число.

    Даже если псевдослучайное число Ri будет скомпрометировано, вычислить Vi+1 из Ri невозможно, и, следовательно, невозможно найти следующее псевдослучайное значение Ri+1.

Лекция 3. Хэш-функции

Требования к криптографическим хэш-функциям

Хэш-функцией называется односторонняя функция, предназначенная для получения дайджеста или "отпечатков пальцев" файла, сообщения или некоторого блока данных.

Хэш-код создается функцией Н:

h = H (M)

гдеМ является сообщением произвольной длины и h является хэш-кодом фиксированной длины.

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

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

  1. Хэш-функция Н должна применяться к блоку данных любой длины.
  2. Хэш-функция Н должна создавать выход фиксированной длины.
  3. Н(М) относительно легко (за полиномиальное время) вычисляется для любого значения М.
  4. Для любого данного значения хэш-кода h вычислительно невозможно найти M такое, что Н(M)=h.
  5. Для любого данного М вычислительно невозможно найти М′ ≠ M такое, что H(M)=H(M′).
  6. Вычислительно невозможно найти произвольную пару (M,M′) такую, что H(M)=H(M′).

Первые три свойства требуют, чтобы хэш-функция создавала хэш-код для любого сообщения.

Четвертое свойство означает, что хэш-функция должна обладать свойством односторонности: легко создать хэш-код по данному сообщению, но невозможно восстановить сообщение по хэш-коду. Это свойство важно, если для аутентификации с помощью хэш-функции используется секретное значение. Само секретное значение может не посылаться, тем не менее, если хэш-функция не является односторонней, противник может легко раскрыть секретное значение следующим образом. Перехватив передаваемое сообщение, атакующий получает сообщение М и хэш-код h=Н(S||M). Если атакующий может инвертировать хэш-функцию, то он получает S||M=H–1(h). Так как атакующий теперь знает и М, и S||M, получить S совсем просто.

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

Хэш-функция, которая удовлетворяет первым пяти свойствам, называется простой или слабой хэш-функцией. Если кроме того выполняется шестое свойство, то такая функция называется сильной хэш-функцией. Шестое свойство защищает против класса атак, известных как атака "день рождения".

"Парадокс дня рождения"

Так называемый "парадокс дня рождения" состоит в следующем.

Первая задача. Каким должно быть число k, чтобы для данного значения X и значений Y1, …, Yk, каждое из которых принимает значения от 1 до n, вероятность того, что хотя бы для одного Yi выполнялось равенство X=Y

P (X = Y) ≥ 0.5

Для одного значения Y вероятность того, что X=Y, равна 1/n.

P (X = Y) = 1/n

Соответственно, вероятность того, что X ≠ Y, равна 1 – 1/n.

P (X ≠ Y) = 1 – 1/n

Если создать k значений, то вероятность того, что ни для одного из них не будет совпадений, равна произведению вероятностей, соответствующих одному значению, т.е. (1 – 1/n)k.

Следовательно, вероятность по крайней мере одного совпадения равна

P (X = Yi) = 1 – (1 – 1/n)k

По формуле бинома Ньютона

Таким образом, для хэш-кода длиной m бит достаточно выбрать 2m-1 сообщений, чтобы вероятность совпадения хэш-кодов была больше 0,5.

Теперь рассмотрим вторую задачу. Обозначим P(n,k) вероятность того, что в множестве из k элементов, каждый из которых может принимать n значений, есть хотя бы два с одинаковыми значениями. Чему должно быть равно k, чтобы P(n,k) была бы больше 0,5?

Число различных способов выбора элементов таким образом, чтобы при этом не было дублей, равно

Всего возможных способов выбора элементов равно

Вероятность того, что дублей нет, равна

Вероятность того, что есть дубли, соответственно равна

Известно, что Если хэш-код имеет длину m бит, т.е. принимает 2m значений, то

Подобный результат называется "парадоксом дня рождения", потому что в соответствии с приведенными выше рассуждениями для того, чтобы вероятность совпадения дней рождения у двух человек была больше 0,5, в группе должно быть всего 23 человека. Этот результат кажется удивительным, возможно, потому, что для каждого отдельного человека вероятность того, что с его днем рождения совпадет день рождения у кого-то другого в группе, достаточно мала.

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

Н (М′) = Н (М)

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

Тем не менее, возможны различного рода атаки, основанные на "парадоксе дня рождения". Возможна следующая стратегия:

  1. Противник создает 2m/2 вариантов сообщения, каждое из ко-торых имеет некоторый определенный смысл. Противник под-готавливает такое же количество сообщений, каждое из которых является поддельным и предназначено для замены насто-ящего сообщения.
  2. Два набора сообщений сравниваются в поисках пары сообщений, имеющих одинаковый хэш-код. Вероятность успеха в соответствии с "парадоксом дня рождения" больше, чем 0,5. Если соответствующая пара не найдена, то создаются дополни-тельные исходные и поддельные сообщения до тех пор, пока не будет найдена пара.
  3. Атакующий предлагает отправителю исходный вариант сообщения для подписи. Эта подпись может быть затем присоединена к поддельному варианту для передачи получателю. Так как оба варианта имеют один и тот же хэш-код, подпись будет соответствовать обоим сообщениям. Противник подписал поддельное сообщение, не зная при этом ключа, защищающего хэш-код.

Таким образом, если используется 64-битный хэш-код, то для подбора двух сообщений с одинаковым хэш-кодом в среднем необходимо перебрать 232 сообщений.

Вследствие этого длина хэш-кода должна быть достаточно большой. Длина, равная 64 битам, в настоящее время не считается безопасной. Пред-почтительнее, чтобы длина составляла не менее 100 битов.

Хэш-функция MD5

Рассмотрим алгоритм получения дайджеста сообщения MD5 (RFC 1321), разработанный Роном Ривестом из MIT.

Алгоритм получает на входе сообщение произвольной длины и создает в качестве выхода дайджест сообщения длиной 128 бит. Алгоритм состоит из следующих шагов:

Логика выполнения MD5


Рис. 3.1.  Логика выполнения MD5

Шаг 1: добавление недостающих битов

Сообщение дополняется таким образом, чтобы его длина стала равна 448 по модулю 512 (длина = 448 (mod 512)). Это означает, что длина добавленного сообщения на 64 бита меньше, чем число, кратное 512. Добавление производится всегда, даже если сообщение имеет нужную длину. Например, если длина сообщения 448 битов, оно дополняется 512 битами до 960 битов. Таким образом, число добавляемых битов находится в диапазоне от 1 до 512.

Добавление состоит из единицы, за которой следует необходимое ко-личество нулей.

Шаг 2: добавление длины

64-битное представление длины исходного (до добавления) сообщения в битах присоединяется к результату первого шага. Если первоначальная длина больше, чем 264, то используются только последние 64 бита. Таким образом, поле содержит длину исходного сообщения по модулю 264.

В результате первых двух шагов создается сообщение, длина которого кратна 512 битам. Это расширенное сообщение представляется как после-довательность 512-битных блоковY0, Y1, . . ., YL-1, при этом общая длина расширенного сообщения равна L * 512 битам. Таким образом, длина полученного расширенного сообщения кратна шестнадцати 32-битным словам.

Структура  расширенного сообщения


Рис. 3.2.  Структура расширенного сообщения

Шаг 3: инициализация MD-буфера

Используется 128-битный буфер для хранения промежуточных и окон-чательных результатов хэш-функции. Буфером являются четыре 32-битных регистра (A, B, C, D). Эти регистры инициализируются следующими шестнадцатеричными числами:

А = 01234567

В = 89ABCDEF

C = FEDCBA98

D = 76543210

Шаг 4: обработка последовательности 512-битных (16-словных) блоков

Основой алгоритма является модуль, состоящий из четырех циклических обработок, обозначенный как HMD5. Четыре цикла имеют похожую структуру, но каждый цикл использует свою элементарную логическую функцию, обозначаемую fF, fG, fH и fI соответственно (рис. 3.3).

Каждый цикл принимает в качестве входа текущий 512-битный блок Yq, обрабатывающийся в данный момент, и 128-битное значение буфера ABCD, которое является промежуточным значением дайджеста, и изменяет содержимое этого буфера. На каждом цикле также используется четвертая часть 64-элементной таблицы T[1] ... T[64], построенной на основе функции sin.

Где [ ] в правой части означает целую часть числа, i задано в радианах. Так как abs (sin(i))является числом между 0 и 1, каждый элемент Т [i] является целым, которое может быть представлено 32 битами. Таблица обеспечивает "случайный" набор 32-битных значений, которые должны ликвидировать любую регулярность во входных данных.

Для получения MDq+1 выход четырех циклов складывается по модулю 232 с MDq. Сложение выполняется независимо для каждого из четырех слов в буфере.

Обработка очередного 512-битного блока


Рис. 3.3.  Обработка очередного 512-битного блока

Шаг 5: выход

После обработки всех L 512-битных блоков выходом L-ой стадии является 128-битный дайджест сообщения.

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

где A, B, C, D - четыре слова буфера; после выполнения каждого отдельного шага происходит циклический сдвиг влево на одно слово.

f - одна из элементарных функций fF, fG, fH, fI.

CLSs- циклический сдвиг влево на s битов 32-битного аргумента.

X[k] - M[q*16 + k] - k-ое 32-битное слово в q-ом 512 блоке сообщения.

T[i]- i-ое 32-битное слово в таблице Т.

+ - сложение по модулю 232.

Логика выполнения отдельного шага


Рис. 3.4.  Логика выполнения отдельного шага

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

Массив из 32-битных слов X[0..15] содержит значение текущего 512-битного входного блока, который обрабатывается в настоящий момент. Каждый цикл выполняется 16 раз, а так как каждый блок входного сообщения обрабатывается в четырех циклах, то каждый блок входного сообщения обрабатывается по описанной выше схеме 64 раза. Если представить входной 512-битный блок в виде шестнадцати 32-битный слов, то каждое входное 32-битное слово используется четыре раза, по одному разу в каждом цикле, и каждый элемент таблицы Т, состоящей из 64 32-битных слов, используется только один раз. После каждого шага цикла происходит циклический сдвиг влево четырех слов A, B, C и D. На каждом шаге изменяется только одно из четырех слов буфера ABCD. Следовательно, каждое слово буфера изменяется 16 раз, и затем 17-ый раз в конце для получения окончательного выхода данного блока.

Можно суммировать алгоритм MD5 следующим образом:

Где

IV - начальное значение буфера ABCD, определенное на шаге 3.

Yq - q-ый 512-битный блок сообщения.

L - число блоков в сообщении (включая поля дополнения и длины).

MD - окончательное значение дайджеста сообщения.

Хэш-функция SHA-1

Безопасный хэш-алгоритм (Secure Hash Algorithm) был разработан NIST и опубликован в качестве федерального информационного стандарта (FIPS PUB 180) в 1993 году. У алгоритмов MD5 и SHA-1 много общего.

Алгоритм получает на входе сообщение произвольной длины и создает в качестве выхода дайджест сообщения длиной 160 бит.

Алгоритм состоит из следующих шагов:

Логика выполнения SHA-1


Рис. 3.5.  Логика выполнения SHA-1

Шаг 1: добавление недостающих битов

Сообщение добавляется таким образом, чтобы его длина была кратна 448 по модулю 512 (длина = 448 (mod 512)). Добавление осуществля-ется всегда, даже если сообщение уже имеет нужную длину. Таким образом, число добавляемых битов находится в диапазоне от 1 до 512.

Добавление состоит из единицы, за которой следует необходимое количество нулей.

Шаг 2: добавление длины

К сообщению добавляется блок из 64 битов. Этот блок трактуется как беззнаковое 64-битное целое и содержит длину исходного сообщения до добавления.

Результатом первых двух шагов является сообщение, длина которого кратна 512 битам. Расширенное сообщение может быть представлено как последовательность 512-битных блоков Y0, Y1, . . . ,YL-1, так что общая длина расширенного сообщения есть L * 512 бит. Таким образом, результат кратен шестнадцати 32-битным словам.

Шаг 3: инициализация SHA-1 буфера

Используется 160-битный буфер для хранения промежуточных и окон-чательных результатов хэш-функции. Буфер может быть представлен как пять 32-битных регистров A, B, C, D и E. Эти регистры инициализируются следующими шестнадцатеричными числами:

A = 67452301
B = EFCDAB89
C = 98BADCFE
D = 10325476
E = C3D2E1F0

обработка сообщения в 512-битных (16-словных) блоках

Основой алгоритма является модуль, состоящий из 80 циклических обработок, обозначенный как HSHA. Все 80 циклических обработок имеют одинаковую структуру (рис. 3.6).

Каждый цикл получает на входе текущий 512-битный обрабатываемый блок Yq и 160-битное значение буфера ABCDE, и изменяет содержимое этого буфера.

В каждом цикле используется дополнительная константа Кt которая принимает только четыре различных значения:

Для получения SHAq+1 выход 80-го цикла складывается со значением SHAq. Сложение по модулю 232 выполняется независимо для каждого из пяти слов в буфере с каждым из соответствующих слов в SHAq.

Обработка очередного 512-битного блока


Рис. 3.6.  Обработка очередного 512-битного блока

Шаг 5: выход

После обработки всех 512-битных блоков выходом L-ой стадии является 160-битный дайджест сообщения.

Рассмотрим более детально логику в каждом из 80 циклов обработки одного 512-битного блока. Каждый цикл можно представить в виде:

Где

A,B,C,D,E - пять слов из буфера.

t - номер цикла, 0 ≤ t ≤ 779.

ft - элементарная логическая функция.

CLSs - циклический левый сдвиг 32-битного аргумента на s битов.

Wt - 32-битное слово, полученное из текущего входного 512-битного блока.

Kt - дополнительная константа.

+ - сложение по модулю 232.

Логика выполнения отдельного цикла


Рис. 3.7.  Логика выполнения отдельного цикла

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

Таблица 3.1



На самом деле используются только три различные функции. Для 0 ≤ t ≤ 19 функция является условной: if B then C else D Для 20 ≤ t ≤ 39 и 60 ≤ t ≤ 79 функция создает бит четности. Для 40 ≤ t ≤ 59 функция является истинной, если два или три аргумента истинны.

32-битные слова Wt получаются из очередного 512-битного блока сообщения следующим образом.

Получение входных значений каждого цикла из очередного блока


Рис. 3.9.  Получение входных значений каждого цикла из очередного блока

Первые 16 значений Wt берутся непосредственно из 16 слов текущего блока. Оставшиеся значения определяются следующим образом:

В первых 16 циклах вход состоит из 32-битного слова данного блока. Для оставшихся 64 циклов вход состоит из XOR нескольких слов из блока сообщения.

Алгоритм SHA-1 можно суммировать следующим образом:

SHA0= IV
SHAq+1= ∑ 32(SHAq, ABCDEq)
SHA = SHAL-1

Где

IV - начальное значение буфера ABCDE.

ABCDEq - результат обработки q-того блока сообщения.

L - число блоков в сообщении, включая поля добавления и длины.

∑32 - сумма по модулю 232, выполняемая отдельно для каждого слова буфера.

SHA - значение дайджеста сообщения.

Сравнение SHA-1 и MD5

Оба алгоритма, SHA-1 и MD5, произошли от MD4, поэтому имеют много общего.

Можно суммировать ключевые различия между алгоритмами.

Таблица 3.2



Сравним алгоритмы MD5 и SHA-1.

  1. Безопасность: наиболее очевидное и наиболее важное различие состоит в том, что дайджест SHA-1 на 32 бита длиннее, чем дайджест MD5. Если предположить, что оба алгоритма не содержат каких-либо структурированных данных, которые уязвимы для аналитиче-ских атак, то SHA-1 является более стойким алгоритмом. Используя лобовую атаку, труднее создать произвольное сообщение, имеющее данный дайджест, если требуется порядка 2159 операций, как в случае алгоритма SHA-1, чем порядка 2127 операций, как в случае алгоритма MD5. Используя лобовую атаку, труднее создать два сообщения, имеющие одинаковый дайджест, если требуется порядка 280 как в случае алгоритма SHA-1, чем порядка 264 операций как в случае алгоритма MD5.
  2. Скорость: так как оба алгоритма выполняют сложение по модулю 232, они рассчитаны на 32-битную архитектуру. SHA-1 содержит больше шагов (80 вместо 64) и выполняется на 160-битном буфере по сравнению со 128-битным буфером MD5. Таким образом, SHA-1 должен выполняться приблизительно на 25% медленнее, чем MD5 на той же аппаратуре.
  3. Простота и компактность: оба алгоритма просты и в описании, и в реализации, не требуют больших программ или подстановочных таблиц. Тем не менее, SHA-1 применяет одношаговую структуру по сравнению с четырьмя структурами, используемыми в MD5. Более того, обработка слов в буфере одинаковая для всех шагов SHA-1, в то время как в MD5 структура слов специфична для каждого шага.
  4. Архитектуры little-endian и big-endian: MD5 использует little-endian схему для интерпретации сообщения как последовательности 32-битных слов, в то время как SHA-1 задействует схему big-endian. Каких-либо преимуществ в этих подходах не существует.

Хэш-функции SHA-2

В 2001 году NIST принял в качестве стандарта три хэш-функции с су-щественно большей длиной хэш-кода. Часто эти хэш-функции называют SHA-2 или SHA-256, SHA-384 и SHA-512 (соответственно, в названии ука-зывается длина создаваемого ими хэш-кода). Эти алгоритмы отличаются не только длиной создаваемого хэш-кода, но и длиной обрабатываемого блока, длиной слова и используемыми внутренними функциями. Сравним характеристики этих хэш-функций.

Таблица 3.3



Под безопасностью здесь понимается стойкость к атакам типа "парадокса дня рождения".

В SHA-256 размер блока сообщения m = 512, в SHA-384 и SHA-512 размер блока сообщения m = 1024. Каждый алгоритм оперирует с w-битными словами. Для SHA-256 w = 32, для SHA-384 и SHA-512 w = 64. В алгоритмах используются обычные булевские операции словами, а также сложение по модулю 2w, правый сдвиг на n бит SHRn(x), где х – w-битное слово, и циклические (ротационные) правый и левый сдвиги на n бит ROTRn(x)и ROTLn(x), где х – w-битное слово.

SHA-256 использует шесть логических функций, при этом каждая из них выполняется с 32-битными словами, обозначенными как x, y и z. Результатом каждой функции тоже является 32-битное слово.

SHA-384 и SHA-512 также используют шесть логических функций, каждая из которых выполняется над 64-битными словами, обозначенными как x, y и z. Результатом каждой функции является 64-битное слово.

Предварительная подготовка сообщения, т.е. добавление определенных битов до целого числа блоков и последующее разбиение на блоки выполняется аналогично тому, как это делалось в SHA-1 (конечно, с учетом длины блока каждой хэш-функции). После этого каждое сообщение можно представить в виде последовательности N блоков M(1), M(2), …, M(N).

Рассмотрим SHA-256. В этом случае инициализируются восемь 32-битных переменных, которые после выполнения преобразования над очередным блоком будут являться промежуточным значением хэш-кода:

a, b, c, d, e, f, g, h

Основой алгоритма является модуль, состоящий из 64 циклических обработок каждого блока M(i):

где Ki{256} – шестьдесят четыре 32-битных константы, каждая из которых является первыми 32-мя битами дробной части кубических корней первых 64 простых чисел.

Wt вычисляются из очередного блока сообщения по следующим прави-лам:

i-ое промежуточное значение хэш-кода H(t) вычисляется следующим образом:

Теперь рассмотрим SHA-512. В данном случае инициализируются во-семь 64-битных переменных, которые будут являться промежуточным зна-чением хэш-кода:

a, b, c, d, e, f, g, h

Основой алгоритма является модуль, состоящий из 80 циклических обрабо-ток каждого блока M(i):

где Ki{512} – восемьдесят 64-битных констант, каждая из которых является первыми 64-мя битами дробной части кубических корней первых восьми-десяти простых чисел.

Wt вычисляются из очередного блока сообщения по следующим формулам:

i-ое промежуточное значение хэш-кода H(t) вычисляется следующим образом:

Рассмотрим SHA-384. Отличия этого алгоритма от SHA-512:

  1. Другое начальное значение хэш-кода H(0).
  2. 384-битный дайджест получается из левых 384 битов оконча-тельного хэш-кода H(N):

    H0(N) || H1(N) || H2(N) || H3(N) || H4(N) || H5(N)

Хэш-функция ГОСТ 3411

Алгоритм ГОСТ 3411 является отечественным стандартом на хэш-функции. Его структура довольно сильно отличается от структуры алгоритмов SHA-1,2 или MD5, в основе которых лежит алгоритм MD4.

Длина хэш-кода, создаваемого алгоритмом ГОСТ 3411, равна 256 битам. Алгоритм разбивает сообщение на блоки, длина которых также равна 256 битам. Кроме того, алгоритм имеет параметр, который называется стартовый вектор хэширования Н – произвольное фиксированное значение длиной также 256 бит.

Сообщение обрабатывается справа налево блоками по 256 бит.

Каждый блок сообщения обрабатывается по следующему алгоритму.

  1. Генерация четырех ключей длиной 256 бит каждый.
  2. Шифрование 64-битных значений промежуточного хэш-кода H на ключах Ki, (i = 1, 2, 3, 4) с использованием алгоритма ГОСТ 28147 в режиме простой замены.
  3. Перемешивание результата шифрования.

Для генерации ключей используются следующие данные:

Используются две формулы, определяющие перестановку и сдвиг.

Перестановка Р битов определяется следующим образом: каждое 256-битное значение рассматривается как последовательность тридцати двух 8-битных значений.

Перестановка Р элементов 256-битной последовательности выполняется по формуле y=ϕ(x), где x – порядковый номер 8-битного значения в исходной последовательности; y – порядковый номер 8-битного значения в результирующей последовательности.

Сдвиг А определяется по формуле

Где xi – соответствующие 64 бита 256-битного значения х, || обозначает конкатенацию.

Присваиваются следующие начальные значения:

Ключи K2, K3, K4 вычисляются последовательно по следующему алгоритму:

Далее выполняется шифрование 64-битных элементов текущего значе-ния хэш-кода Н с ключами K1, K2, K3 и K4. При этом хэш-код Н рассматривается как последовательность 64-битных значений:

Выполняется шифрование алгоритмом ГОСТ 28147:

Наконец на заключительном этапе обработки очередного блока выполняется перемешивание полученной последовательности. 256-битное значение рассматривается как последовательность шестнадцати 16-битных значений. Сдвиг обозначается ψ и определяется следующим образом:

-исходное значение

- результирующее значение

Результирующее значение хэш-кода определяется следующим образом:

Где H – предыдущее значение хэш-кода, М – текущий обрабатываемый блок, ψi – i-ая степень преобразования y.

Входными параметрами алгоритма являются:

Сообщение М делится на блоки длиной 256 бит и обрабатывается справа налево. Очередной блок i обрабатывается следующим образом:

  1. H = χ (Mi, H)
  2. ∑ = ∑⊕' Mi
  3. L рассматривается как неотрицательное целое число, к этому числу прибавляется 256 и вычисляется остаток от деления получившегося числа на 2256. Результат присваивается L.

Где ⊕' обозначает следующую операцию: ∑ и Mi рассматриваются как неотрицательные целые числа длиной 256 бит. Выполняется обычное сложение этих чисел и находится остаток от деления результата сложения на 2256. Этот остаток и является результатом операции.

Самый левый, т.е. самый последний блок М' обрабатывается следующим образом:

  1. Блок добавляется слева нулями так, чтобы его длина стала равна 256 битам.
  2. Вычисляется ∑ = ∑ ⊕' M'.
  3. L рассматривается как неотрицательное целое число, к этому числу прибавляется длина исходного сообщения М и находится остаток от деления результата сложения на 2256.
  4. Вычисляется Н = χ (М', Н).
  5. Вычисляется Н = χ (L, Н)
  6. Вычисляется Н = χ (∑, Н).

Значением функции хэширования является Н.

Код аутентификации сообщения

Рассмотрим обеспечение целостности сообщений с использованием общего секрета. Напомним, что обеспечение целостности сообщения – это невозможность изменения сообщения так, чтобы получатель этого не обнаружил. Под аутентификацией понимается подтверждение того, что ин-формация получена от законного источника, и получателем является тот, кто нужно. Один из способов обеспечения целостности – это вычисление МАС (Message Authentication Code). В данном случае под МАС понимается некоторый аутентификатор, являющийся определенным способом вычис-ленным блоком данных, с помощью которого можно проверить целостность сообщения. В некоторой степени симметричное шифрование всего сообщения может выполнять функцию аутентификации этого сообщения. Но в таком случае сообщение должно содержать достаточную избыточность, которая позволяла бы проверить, что сообщение не было изменено. Избыточность может быть в виде определенным образом отформатированного сообщения, текста на конкретном языке и т.п. Если сообщение допус-кает произвольную последовательность битов (например, зашифрован ключ сессии), то симметричное шифрование всего сообщения не может обеспечивать его целостность, так как при расшифровании в любом случае получится последовательность битов, правильность которой проверить нельзя. Поэтому гораздо чаще используется критографически созданный небольшой блок данных фиксированного размера, так называемый аутентификатор или имитовставка, с помощью которого проверяется целост-ность сообщения. Этот блок данных может создаваться с помощью секретного ключа, который разделяют отправитель и получатель. МАС вычисля-ется в тот момент, когда известно, что сообщение корректно. После этого МАС присоединяется к сообщению и передается вместе с ним получателю. Получатель вычисляет МАС, используя тот же самый секретный ключ, и сравнивает вычисленное значение с полученным. Если эти значения совпа-дают, то с большой долей вероятности можно считать, что при пересылке изменения сообщения не произошло.

MAC = CK (M)

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

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

Предположим, что k > n, т.е. длина ключа больше длины МАС. Тогда, зная М1 и МАС1= СK(M1), оппонент может вычислить МАС1= СKi(M1) для всех возможных ключей Ki. При этом, по крайней мере, для одного из ключей будет получено совпадение MACi = MAC1. Оппонент вычислит 2k значений МАС, тогда как при длине МАС n битов существует всего 2n значений МАС. Мы предположили, что k > n, т.е. 2k> 2n. Таким образом, правильное значение МАС будет получено для нескольких значений ключей. В среднем совпадение будет иметь место для 2k/2n = 2(k-n) ключей. По-этому для вычисления единственного ключа оппоненту требуется знать несколько пар сообщение и соответствующий ему МАС.

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

Функция вычисления МАС должна обладать следующими свойствами:

  1. Должно быть вычислительно трудно, зная М и СK(M), найти сообщение М', такое, что СK(M) = СK(M').
  2. Значения СK(M) должны быть равномерно распределенными в том смысле, что для любых сообщений М и M' вероятность того, что СK(M) = СK(M')., должна быть равна 2-n, где n – длина значения МАС.

Стандарт НМАС

Использование хэш-функции для получения МАС состоит в том, чтобы определенным образом добавить секретное значение к сообщению, которое подается на вход хэш-функции. Такой алгоритм носит название НМАС, и он описан в RFC 2104.

При разработке алгоритма НМАС преследовались следующие цели:

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

2. возможность легкой замены встроенных хэш-функций на более быстрые или более стойкие.

3. Сохранение скорости работы алгоритма, близкой к скорости работы соответствующей хэш-функции.

4. Возможность применения ключей и простота работы с ними.

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

Введем следующие обозначения:

Н – встроенная хэш-функция.

b – длина блока используемой хэш-функции.

n – длина хэш-кода.

K – секретный ключ. К этому ключу слева добавляют нули, чтобы получить b-битовый ключ K+.

Вводится два вспомогательных значения:

Ipad - значение ‘00110110’, повторенное b/8 раз.

Opad – значение ‘01011010’, повторенное b/8 раз.

Далее НМАС вычисляется следующим образом:

Лекция 4. Алгоритмы асимметричного шифрования

Основные требования к алгоритмам асимметричного шифрования

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

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

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

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

Второй задачей является необходимость создания таких механизмов, при использовании которых невозможно было бы подменить кого-либо из участников, т.е. нужен аналог подписи, которая используется в реальном мире. Такой аналог обычно называется цифровой или электронной подписью (англ. вариант – Digital Signature). При использовании коммуникаций для решения широкого круга задач, например в коммерческих и частных целях, электронные сообщения и документы должны иметь эквивалент подписи, содержащейся в бумажных документах. Необходимо создать метод, при использовании которого все участники будут убеждены, что электронное сообщение было послано конкретным участником. Это более сильное требование, чем аутентификация с использованием пароля или общего секрета.

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

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

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

Сначала рассмотрим алгоритмы, обладающие обеими характеристиками, а затем перейдем к алгоритмам открытого ключа, которые не обладают вторым свойством.

При описании симметричного шифрования и шифрования с открытым ключом будем использовать следующую терминологию. Ключ, используемый в симметричном шифровании, будем называть секретным ключом. Два ключа, используемые при шифровании с открытым ключом, будем называть открытым ключом (Key Public – KU) и закрытым ключом (Key Private – KR). Закрытый ключ держится в секрете, но называть его будем закрытым ключом, а не секретным, чтобы избежать путаницы с ключом, используемым в симметричном шифровании. Закрытый ключ будем обозначать KR, открытый ключ - KU.

Будем предполагать, что все участники имеют доступ к открытым ключам друг друга, а закрытые ключи создаются локально каждым участником и, следовательно, распределяться не должны.

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

Диффи и Хеллман описывают требования, которым должен удовлетворять алгоритм шифрования с открытым ключом.

  1. Вычислительно легко создавать пару (открытый ключ KU, закрытый ключ KR).
  2. Вычислительно легко, имея открытый ключ и незашифрованное сообщение М, создать соответствующее зашифрованное сообщение:
  3. Вычислительно легко расшифровать сообщение, используя закрытый ключ:
  4. Вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR.
  5. Вычислительно невозможно, зная открытый ключ KU и зашифрованное сообщение С, восстановить исходное сообщение М.

    Можно добавить шестое требование, хотя оно не выполняется для всех алгоритмов с открытым ключом:

  6. Шифрующая и расшифровывающая функции могут применяться в любом порядке:

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

Y = f (X)– вычислительно легко

X = f-1 (Y)– вычислительно трудно

В данном случае термин "вычислительно легко" означает полиномиальную сложность от длины входа. Таким образом, если алгоритму на вход подается значение длиной n битов, то время вычисления функции пропорционально na, где а – фиксированная константа. Таким образом, говорят, что алгоритм принадлежит классу полиномиальных алгоритмов Р. Термин "вычислительно трудно" означает более сложное понятие. В общем случае будем считать, что проблему решить невозможно, если усилия для ее решения больше полиномиального времени от величины входа. Например, если длина входа n битов, и время вычисления функции пропорционально 2n, то это считается вычислительно невозможной задачей. К сожалению, тяжело определить, проявляет ли конкретный алгоритм такую сложность. Более того, традиционные представления о вычислительной сложности фокусируются на поведении алгоритмов в худшем случае или в среднем случае. Это неприемлемо для криптографии, где требуется невозможность инвертировать функцию для всех или почти всех значений входов.

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

Y = fk (X) - легко, если k и Х известны

X = fk-1 (Y) - легко, если k и Y известны

Х = fk-1 (Y) - трудно, если Y известно, но k неизвестно

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

Криптоанализ алгоритмов с открытым ключом

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

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

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

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

Основные способы использования алгоритмов с открытым ключом

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

Шифрование с открытым ключом состоит из следующих шагов:

. Схема шифрования с открытым ключом


Рис. 4.1.  . Схема шифрования с открытым ключом

  1. Пользователь В создает пару ключей KUb и KRb, которые могут использоваться для шифрования и расшифрования передаваемых сообщений.
  2. Пользователь В передает пользователю A некоторым надежным способом свой ключ шифрования, т.е. открытый ключ KUb. Составляющий пару закрытый ключ KRb держится в секрете.
  3. Если А хочет послать конфиденциальное сообщение В, он шифрует сообщение, используя открытый ключ В KUb.
  4. Когда В получает сообщение, он расшифровывает его, используя свой закрытый ключKRb. Никто другой не сможет расшифровать сообщение, так как этот закрытый ключ знает только В.
  5. Если пользователь В надежно хранит свой закрытый ключ, никто не сможет расшифровать передаваемые сообщения.

Создание и проверка подписи состоит из следующих шагов:

Схема создания и проверки подписи


Рис. 4.2.  Схема создания и проверки подписи

  1. Пользователь A создает пару ключей KRA и KUA, которые могут использоваться для создания и проверки подписи.
  2. Пользователь A передает пользователю В некоторым надежным способом свой ключ проверки подписи, т.е. открытый ключ KUA. Составляющий пару закрытый ключ KRA держится в секрете.
  3. Если A хочет послать подписанное сообщение пользователю В, он создает подпись SignKRa[M] этого сообщения, используя свой закрытый ключ KRA.
  4. Когда В получает подписанное сообщение, он проверяет подпись VerKUa[M], используя открытый ключ KUA пользователя A. Никто другой не может подписать сообщение, так как этот закрытый ключ знает только A.
  5. До тех пор, пока пользователь A надежно хранит свой закрытый ключ, его подписи достоверны. Кроме того, невозможно изменить сообщение, не имея доступа к закрытому ключу А; тем самым обеспечивается аутентификация отправителя и целостность передаваемых данных. Все алгоритмы создания и проверки подписи имеют большую вычислительную нагрузку, так как связаны с возведением в большие степени. Более эффективным способом является подписывание небольшого блока битов, который является функцией от сообщения. Такой блок, называемый аутентификатором, должен обладать таким свойством, что любое изменение сообщения с большой веро-ятностью приводит к изменению его аутентификатора. Этот аутентификатор подписывается закрытым ключом отправителя, т.е. создается цифровая подпись. Далее эта технология будет рассматриваться в деталях.

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

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

Например, предположим, что A посылает B аутентифицированное сообщение, и аутентификация осуществляется на основе общего секрета. Рассмотрим возможные проблемы, которые могут при этом возникнуть:

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

A может отрицать, что он посылал сообщение B. Так как B может подделать сообщение, у него нет способа доказать, что A действительно посылал его.

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

1. Должна быть возможность проверить автора, дату и время создания подписи.

2. Должна быть возможность аутентифицировать содержимое во время создания подписи.

3. Подпись должна быть проверяема третьей стороной для разрешения споров.

Таким образом, создание цифровой подписи включает сервис аутентификации отправителя.

На основании этих свойств можно сформулировать следующие требования к цифровой подписи:

  1. Подпись должна быть битовым образцом, который зависит от подписываемого сообщения.
  2. Подпись должна использовать некоторую уникальную информацию отправителя для предотвращения подделки или отказа.
  3. Создавать цифровую подпись должно быть относительно легко.
  4. Должно быть относительно легко проверять цифровую подпись.
  5. Должно быть вычислительно невозможно подделать цифровую подпись как созданием нового сообщения для существующей цифровой подписи, так и созданием ложной цифровой подписи для данного сообщения.
  6. Цифровая подпись должна быть достаточно компактной и не занимать много памяти.

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

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

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

Перечислим наиболее популярные алгоритмы с открытым ключом и возможные способы их применения.

Таблица 4.1



Алгоритм RSA

Описание алгоритма

Диффи и Хеллман определили новый подход к шифрованию, что вы-звало к жизни разработку алгоритмов шифрования, удовлетворяющих тре-бованиям систем с открытым ключом. Одним из первых результатов был алгоритм, разработанный в 1977 году Роном Ривестом, Ади Шамиром и Леном Адлеманом и опубликованный в 1978 году. С тех пор алгоритм Rivest-Shamir-Adleman (RSA) широко применяется практически во всех приложениях, использующих криптографию с открытым ключом.

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

Алгоритм RSA представляет собой блочный алгоритм шифрования, где зашифрованные и незашифрованные данные являются целыми между 0 и n–1 для некоторого n.

Алгоритм, разработанный Ривестом, Шамиром и Адлеманом, использует выражения с экспонентами. Данные шифруются блоками, каждый блок рассматривается как число, меньшее некоторого числа n. В результате шифрования числа М, М < n, получается число С.

Расшифрование выполняется следующим образом:

Как отправитель, так и получатель должны знать число n. Отправитель знает число, получатель знает число d. Таким образом, открытый ключ есть KU = {e, n} и закрытый ключ есть KR = {d, n}. При этом должны выполняться следующие условия:

  1. Возможность найти значения е, d и n такие, что Med = M (mod n) для всех М < n.
  2. Относительно легко вычислить Ме и Сd для всех значений М < n.
  3. Невозможность определить d, зная е и n.

Сначала рассмотрим первое условие. Нам необходимо выполнение равенства:

Рассмотрим некоторые математические понятия, свойства и теоремы, которые позволят нам определить e, d и n.

  1. Если а · b = a·c (mod n), то b = c (mod n), если а и n взаимнопростые, т.е НОД (a, n) = 1.
  2. Обозначим Zp - все числа, взаимнопростые с p и меньшие p. Если p - простое, то Zp - это все остатки. Обозначим w-1 такое число, что w · w-1 = 1 (mod p).

    Тогда ∀ w ∈ Zp∃ z: w · z = 1 (mod p)

    Доказательство этого следует из того, что т.к. w и p взаимнопростые, то при умножении всех элементов Zp на w по модулю р остатками будут все элементы Zp, возможно, переставленные. Таким образом, хотя бы один остаток будет равен 1.

  3. Определим функцию Эйлера следующим образом: ϕ(n)- число положительных чисел, меньших n и взаимнопростых с n. Если p - простое, то ϕ (р) = p-1.

    Покажем, что если p и q - простые, то ϕ(p · q) = (p-1)·(q-1).

    Перечислим числа, меньшие p · q, которые не являются взаимнопросты-ми с p · q:

    Числа, которые делятся на р: {p, 2·p, ..., (q-1)·p}. Таких чисел (q – 1).

    Числа, которые делятся на q: {q, 2·q, ..., (p-1)·q}. Таких чисел (р - 1).

    Таким образом

    ϕ(p·q) = p·q - 1 - [(q-1)+(p-1)] = p·q - (p+q) + 1 = (p-1)·(q-1)

  4. Теорема Ферма

    an-1 = 1 (mod n), если n - простое.

    Если все элементы Zn умножить на а по модулю n, то в результате получим все элементы Zn, быть может, в другом порядке. Рассмотрим следующие числа:

    {a (mod n), 2·a (mod n), ·, (n-1)·a (mod n)} являются числами {1, 2, ..., (n-1)}, быть может, в некотором другом порядке. Теперь перемножим по модулю n числа из этих двух множеств.

    n и (n-1)! являются взаимнопростыми, если n – простое.

    Следовательно, an-1 = 1 (mod n).

  5. Теорема Эйлера

    aϕ(n) = 1 (mod n)для всех взаимнопростых a и n.

    Это верно, если n - простое, т.к. в этом случае ϕ(n) = n-1. Рассмотрим множество R = {x1, x2,..., xf(n)}. Теперь умножим по модулю n каждый элемент этого множества на a. Получим множество S = {a·x1 (mod n), a·x2 (mod n), ..., a·xϕ(n) (mod n)}. Это множество является перестановкой множества R по следующим причинам.

    Так как а является взаимнопростым с n и xi являются взаимнопростыми с n, то a· xi также являются взаимнопростыми с n. Таким образом, S - это множество целых, меньших n и взаимнопростых с n.

    В S нет дублей, т.к. если a · xi (mod n) = a·xj (mod n) · xi = xj.

    Следовательно, перемножив элементы множеств S и R, получим:

    Теперь рассмотрим сам алгоритм RSA. Пусть p и q - простые.

    Надо доказать, что

    Если НОД (M, n) = 1, то равенство выполняется. Теперь предположим, что НОД (M, n) ≠ 1, т.е. НОД (M, p · q) ≠ 1. Пусть НОД (M, p) ≠ 1, т.е. M = c · p, следовательно НОД (M, q) = 1, так как в противном случае M = c · p и M = l · q, но по условию M < p · q.

    Следовательно,

    По определению модуля это означает, что M ϕ(n) = 1 + k· q. Умножим обе части равенства на M = c · p. Получим M ϕ(n)+1 = c·p + k·q·c·p.

    Таким образом, следует выбрать e и d такие, что е ·d = 1 (mod ϕ(n))

    Или e = d -1 (mod ϕ (n))

    e и d являются взаимнообратными по умножению по модулю ϕ(n). Заметим, что в соответствии с правилами модульной арифметики, такие взаимнообратные элементы существуют только в том случае, если d (и, следовательно, е) являются взаимнопростыми с ϕ(n). Таким образом, НОД(ϕ(n), d) = 1.

    Теперь рассмотрим все элементы алгоритма RSA.

    p, q - два простых целых числа- закрыты, выбираемы.

    n = p·q - открыто, вычисляемо.

    d, НОД (ϕ (n), d) = 1; 1 < d < ϕ (n) - закрыто, вычисляемо.

    е = d –1 (mod ϕ (n)) - открыто, выбираемо.

Закрытый ключ состоит из {d, n}, открытый ключ состоит из {e, n}. Предположим, что пользователь А опубликовал свой открытый ключ, и что пользователь В хочет послать пользователю А сообщение М. Тогда В вычисляет С = Ме (mod n) и передает С. При получении этого зашифрованного текста пользователь А расшифрует вычислением М = Сd (mod n).

Суммируем алгоритм RSA:

Создание ключей

Выбрать простые р и q

Вычислить n = p•q

Выбрать d: НОД (ϕ(n), d) = 1; 1 < d <ϕ(n)

Вычислить е: е = d –1 (mod ϕ(n))

Открытый ключ KU = {e, n}

Закрытый ключ KR = {d, n}

Шифрование

Незашифрованное сообщение: М < n

Зашифрованное сообщение: С = Ме (mod n)

Расшифрование

Зашифрованное сообщение: С

Незашифрованное сообщение: М = Сd (mod n)

Рассмотрим конкретный пример:

Выбрать два простых числа: р = 7, q = 17.

Вычислить n = p•q = 7 • 17 = 119.

Вычислить ϕ(n) = (p – 1)•(q – 1) = 96.

Выбрать е так, чтобы е было взаимнопростым с ϕ(n) = 96 и меньше, чем ϕ(n): е = 5.

Определить d так, чтобы d•e = 1 (mod 96) и d < 96.

d = 77, так как 77 • 5 = 385 = 4 • 96 + 1.

Результирующие ключи открытый KU={5,119} и закрытый KR={77,119}.

Например, требуется зашифровать сообщение М = 19.

195 = 66 (mod 119); С = 66.

Для расшифрования вычисляется 6677 (mod 119) = 19.

Вычислительные аспекты

Рассмотрим сложность вычислений в алгоритме RSA при создании ключей и при шифровании / расшифровании.

1. Шифрование / расшифрование

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

Другая оптимизация состоит в эффективном использовании показателя степени, так как в случае RSA показатели степени очень большие. Предположим, что необходимо вычислить х16. Прямой подход требует 15 умножений. Однако можно добиться того же конечного результата с помощью только четырех умножений, если использовать квадрат каждого промежуточного результата: х2, х4, х8, х16.

2. Создание ключей

Создание ключей включает следующие задачи:

Прежде всего, рассмотрим проблемы, связанные с выбором р и q. Так как значение n = p•q будет известно любому потенциальному противнику, для предотвращения раскрытия р и q эти простые числа должны быть выбраны из достаточно большого множества, т.е. р и q должны быть большими числами. С другой стороны, метод, используемый для поиска большого простого числа, должен быть достаточно эффективным.

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

Были разработаны различные тесты для определения того, является ли число простым. Это тесты вероятностные, то есть тест показывает, что данное число вероятно является простым. Несмотря на это проверка числа на таких тестах делает вероятность того, что число простой, близкой к единице. Если n "проваливает" тест, то оно не является простым. Если n "пропускает" тест, то n может как быть, так и не быть простым. Если n пропускает много таких тестов, то можно с высокой степенью достоверности сказать, что n является простым. Это достаточно долгая процедура, но она выполняется относительно редко: только при создании новой пары (KU, KR).

На сложность вычислений также влияет то, какое количество чисел будет отвергнуто перед тем, как будет найдено простое число. Результат из теории чисел, известный как теорема простого числа, говорит, что простых чисел, расположенных около n в среднем одно на каждые ln(n)чисел. Таким образом, в среднем требуется проверить последовательность из ln(n) целых, прежде чем будет найдено простое число. Так как все четные числа могут быть отвергнуты без проверки, то требуется выполнить приблизительно ln(n)/2 проверок. Например, если простое число ищется в диапазоне величин 2200, то необходимо выполнить около ln(2200) / 2 = 70 проверок.

Выбрав простые числа р и q, далее следует выбрать значение е так, чтобы НОД (ϕ(n), e) = 1 и вычислить значение d, d = e–1 (mod ϕ(n)). Существует единственный алгоритм, называемый расширенным алгоритмом Евклида, который за фиксированное время вычисляет наибольший общий делитель двух целых и если этот общий делитель равен единице, определяет инверсное значение одного по модулю другого. Таким образом, процедура состоит в генерации серии случайных чисел и проверке каждого относительно 1ϕ(n) до тех пор, пока не будет найдено число, взаимнопростое с ϕ(n). Возникает вопрос, как много случайных чисел придется проверить до тех пор, пока не найдется нужное число, которое будет взаимнопростым с ϕ(n). Результаты показывают, что вероятность того, что два случайных числа являются взаимнопростыми, равна 0.6.

Обсуждение криптоанализа

Можно определить четыре возможных подхода для криптоанализа алгоритма RSA:

  1. Лобовая атака: перебрать все возможные закрытые ключи.
  2. Разложить n на два простых сомножителя. Это даст возможность вычислить ϕ(n)=(p–1)•(q–1) и d=e–1 (mod ϕ(n)).
  3. Определить ϕ(n) непосредственно, без начального определения р и q. Это также даст возможность определить d=e–1(mod ϕ(n)).
  4. Определить d непосредственно, без начального определения ϕ(n).

Защита от лобовой атаки для RSA и ему подобных алгоритмов состоит в использовании большой длины ключа. Таким образом, чем больше битов в е и d, тем лучше. Однако, так как вычисления, связанные с возведением в степень, необходимы как при создании ключей, так и при шифровании / расшифровании, чем больше размер ключа, тем медленнее работает система.

Большинство дискуссий о криптоанализе RSA фокусируется на задаче разложения n на два простых сомножителя. В настоящее время неизвестны алгоритмы, с помощью которых можно было бы разложить число на два простых множителя для очень больших чисел (т.е. несколько сотен десятичных цифр). Лучший из известных алгоритмов дает результат, пропорциональный

Пока не разработаны лучшие алгоритмы разложения числа на простые множители, можно считать, что величина n от 100 до 200 цифр в настоящее время является достаточно безопасной. На современном этапе считается, что число из 100 цифр может быть разложено на множители за время порядка двух недель. Для дорогих конфигураций (т.е. порядка $10 млн) число из 150 цифр может быть разложено приблизительно за год. Разложение числа из 200 цифр находится за пределами вычислительных возможностей. Например, даже если вычислительный уровень в 1012 операций в секунду достижим, что выше возможностей современных технологий, то потребуется свыше 10 лет для разложения на множители числа из 200 цифр с использованием существующих алгоритмов.

Для известных в настоящее время алгоритмов задача определения ϕ(n) по данным е и n, по крайней мере сопоставима по времени с задачей разложения числа на множители.

Для того чтобы избежать выбора значения n, которое могло бы легко раскладываться на сомножители, на р и q должно быть наложено много дополнительных ограничений:

Алгоритм Диффи-Хеллмана

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

Цель алгоритма состоит в том, чтобы два участника могли безопасно обменяться ключом, который в дальнейшем может использоваться в каком-либо алгоритме симметричного шифрования. Сам алгоритм Диффи-Хеллмана может применяться только для обмена ключом.

Алгоритм основан на трудности вычислений дискретных логарифмов. Дискретный логарифм определяется следующим образом. Вводится понятие примитивного корня простого числа Q как числа, чьи степени создают все целые от 1 до Q–1. Это означает, что если А является примитивным корнем простого числа Q, тогда числа

являются различными и состоят из целых от 1 до Q–1 возможно с некоторыми перестановками.

В этом случае для любого целого B<Q и примитивного корня A простого числа Q можно найти единственную экспоненту Х, такую, что

Экспонента X называется дискретным логарифмом, или индексом Y, по основанию A (mod Q). Это обозначается как

Теперь опишем алгоритм обмена ключей Диффи-Хеллмана.

Общеизвестные элементы

Q - Простое число

A - A<Q и A является примитивным корнем Q

Предполагается, что существуют два известных всем числа: простое число Q и целое A, которое является примитивным корнем Q.

Создание пары ключей пользователем I

Выбор случайного числа Хi - закрытый ключ

Вычисление числа Yi - открытый ключ

Создание открытого ключа пользователем J

Выбор случайного числа Хj - закрытый ключ

Вычисление случайного числа Yj - открытый ключ

Теперь предположим, что пользователи I и J хотят обменяться ключом для алгоритма симметричного шифрования. Пользователь I выбирает случайное число Хi< Q и вычисляет Yi = AXi (mod Q). Аналогично пользователь J независимо выбирает случайное целое число Хj< Q и вычисляет Yj= AXj (mod Q).

Пользователи I и J обмениваются открытыми ключами Yi и Yj

Каждая сторона держит значение Х в секрете и делает значение Y доступным для другой стороны.

Создание общего секретного ключа пользователем I

Создание общего секретного ключа пользователем J

Теперь пользователь I вычисляет ключ К = (Yj)Xi (mod Q), и пользователь J вычисляет ключК = (Yi)Xj (mod Q). В результате оба получат одно и то же значение:

по правилам модульной арифметики

Таким образом, две стороны обменялись секретным ключом. Так как Хi и Хj являются закрытыми, противник может получить только следующие значения: Q, A, Yi и Yj. Для вычисления общего ключа атакующий должен взломать дискретный логарифм, т.е. вычислить

Безопасность обмена ключа в алгоритме Диффи-Хеллмана вытекает из того факта, что, хотя относительно легко вычислить экспоненты по модулю простого числа, но очень трудно вычислить дискретные логарифмы. Для больших простых чисел задача считается неразрешимой.

Следует заметить, что данный алгоритм уязвим для атак типа "man-in-the-middle". Если противник может осуществить активную атаку, т.е. имеет возможность не только перехватывать сообщения, но и заменять их другими, он может перехватить открытые ключи участников Yi и Yj, создать свою пару открытого и закрытого ключа (Xоп, Yоп)и послать каждому из участников свой открытый ключ. После этого каждый участник вычислит ключ, который будет общим с противником, а не с другим участником. Если нет аутентификации хотя бы одной из сторон внешним по отношению к алгоритму Диффи-Хеллмана способом, то участники не смогут обнаружить подобную подмену.

Стандарт цифровой подписи DSS

Национальный институт стандартов и технологии США (NIST) разработал федеральный стандарт цифровой подписи DSS. Для создания цифро-вой подписи используется алгоритм DSA (Digital Signature Algorithm). В качестве хэш-алгоритма стандарт предусматривает использование алго-ритма SHA-1 (Secure Hash Algorithm). DSS первоначально был предложен в 1991 году и пересмотрен в 1993 году в ответ на публикации, касающиеся безопасности его схемы.

Подход DSS

Стандарт DSS может использоваться только для создания цифровой подписи. В отличие от RSA, его нельзя использовать для шифрования или обмена ключами. Тем не менее, это технология открытого ключа.

Рассмотрим отличия цифровых подписей, создаваемых DSS, от цифровых подписей, создаваемых такими алгоритмами как RSA.

Создание и проверка подписи с помощью алгоритма RSA


Рис. 4.4.  Создание и проверка подписи с помощью алгоритма RSA

Создание и проверка подписи с помощью стандарта DSS


Рис. 4.5.  Создание и проверка подписи с помощью стандарта DSS

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

В DSS также используется сильная хэш-функция. Хэш-код является входом функции подписи вместе со случайным числом k, созданным для этой конкретной подписи. Функция подписи также зависит от закрытого ключа отправителя KRА и множества параметров, известных всем участникам. Можно считать, что это множество состоит из глобального открытого ключа KUG. Результатом является подпись, состоящая из двух компонент, обозначаемых какS и R.

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

Теперь рассмотрим детали алгоритма, используемого в DSS.

Алгоритм цифровой подписи DSS

DSS основан на трудности вычисления дискретных логарифмов и базируется на схеме, определенной ElGamal и Schnorr.

Общие компоненты группы пользователей

Существует три параметра, которые являются открытыми и могут быть общими для большой группы пользователей.

160-битное простое число q, т.е. 2159< q < 2160.

Простое число р длиной между 512 и 1024 битами должно быть таким, чтобы q делилось на (р – 1), т.е. 2L-1< p < 2L, где 512 < L < 1024 и (p-1)/q является целым.

g = h(p-1)/q (mod p), где h является целым между 1 и (р-1), и g должно быть больше единицы.

Зная эти значения, отправитель выбирает закрытый ключ и создает открытый ключ.

Закрытый ключ отправителя

Закрытый ключ х должен быть числом между 1 и (q-1)и должен быть выбран случайно или псевдослучайно.

x - случайное или псевдослучайное целое, 0 < x < q

Открытый ключ отправителя

Открытый ключ вычисляется следующим образом:

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

Случайное число, уникальное для каждой подписи.

k - случайное или псевдослучайное целое, 0<k<q, уникальное для каждого подписывания.

Подписывание

Для создания подписи отправитель вычисляет две величины, r и s, которые являются функцией от компонент открытого ключа (p, q, g), закрытого ключа пользователя х, хэш-кода сообщения Н(М) и целого k, которое должно быть создано случайно или псевдослучайно и должно быть уникальным при каждом подписывании.

Подпись равна (r, s).

Проверка подписи

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

Подпись корректна, если v = r

Докажем, что v = r в случае корректной подписи.

Лемма 1. Для любого целого t, если

По теореме Ферма, так как h является взаимнопростым с p, то

Следовательно, для любого неотрицательного целого n

Таким образом, для неотрицательных целых n и z мы имеем

Любое неотрицательное целое t может быть представлено единственным способом как t = nq + z, где n и z являются неотрицательными целыми и 0<z<q. Таким образом z = t (mod q).

Лемма 2. Для неотрицательных чисел a и b: g(a mod q + b mod q)(mod p) = g(a+b) mod q(mod p).

По лемме 1 мы имеем

Лемма 3. y(rw) mod q(mod p) = g(xrw) mod q(mod p)

По определению y = gx(mod p). Тогда:

Лемма 4. ((H(M) + x•r) • w) (mod q) = k

По определению s = (k-1• (H(M) + x•r)) (mod q). Кроме того, так как q является простым, любое неотрицательное целое меньшее q имеет мультипликативную инверсию. Т.е. (k •k-1) (mod q = 1). Тогда:

По определению w = s-1(mod q), следовательно, (w•s) (mod q)=1. Следовательно:

Так как 0 < k < q, то k (mod q) = k.

Теорема. Используя введенные выше определения для v и r, докажем, что v=r.

Отечественный стандарт цифровой подписи ГОСТ 3410

В отечественном стандарте ГОСТ 3410, принятом в 1994 году, исполь-зуется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS. Оба алгоритма относятся к семейству алгоритмов ElGamal.

В стандарте ГОСТ 3410 используется хэш-функция ГОСТ 3411, которая создает хэш-код длиной 256 бит. Это во многом обуславливает требования к выбираемым простым числам p и q:

Аналогично выбирается и параметр g. При этом требуется, чтобы gq(mod p ) = 1.

В соответствии с теоремой Ферма это эквивалентно условию в DSS, что g = h(p-1)/q(mod p).

Закрытым ключом является произвольное число х

Открытым ключом является число y

Для создания подписи выбирается случайное число k

Подпись состоит из двух чисел (r, s), вычисляемых по следующим формулам:

Еще раз обратим внимание на отличия DSS и ГОСТ 3410.

Используются разные хэш-функции: в ГОСТ 3410 применяется отечественный стандарт на хэш-функции ГОСТ 3411, в DSS используется SHA-1, которые имеют разную длину хэш-кода. Отсюда и разные требования на длину простого числа q: в ГОСТ 3410 длина q должна быть от 254 бит до 256 бит, а в DSS длина q должна быть от 159 бит до 160 бит.

По-разному вычисляется компонента s подписи. В ГОСТ 3410 компонента s вычисляется по формуле

В DSS компонента s вычисляется по формуле

Последнее отличие приводит к соответствующим отличиям в формулах для проверки подписи.

Получатель вычисляет

Подпись корректна, если v = r.

Структура обоих алгоритмов довольно интересна. Заметим, что значение r совсем не зависит от сообщения. Вместо этого r есть функция от k и трех общих компонент открытого ключа. Мультипликативная инверсия k(mod p)(в случае DSS) или само значение k (в случае ГОСТ 4310) подается в функцию, которая, кроме того, в качестве входа имеет хэш-код сообщения и закрытый ключ пользователя. Эта функция такова, что получатель может вычислить r, используя входное сообщение, подпись, открытый ключ пользователя и общий открытый ключ.

В силу сложности вычисления дискретных логарифмов нарушитель не может восстановить k из r или х из s.

Другое важное замечание заключается в том, что экспоненциальные вычисления при создании подписи необходимы только для gk(mod p). Так как это значение от подписываемого сообщения не зависит, оно может быть вычислено заранее. Пользователь может заранее просчитать некоторое количество значений r и использовать их по мере необходимости для подписи документов. Еще одна задача состоит в определении мультипликативной инверсии k-1 (в случае DSS). Эти значения также могут быть вычислены заранее.

Подписи, созданные с использованием стандартов ГОСТ 3410 или DSS, называются рандомизированными, так как для одного и того же сообщения с использованием одного и того же закрытого ключа каждый раз будут создаваться разные значения подписи (r,s), поскольку каждый раз будет использоваться новое значение k. Подписи, созданные с применением алгоритма RSA, называются детерминированными, так как для одного и того же сообщения с использованием одного и того же закрытого ключа каждый раз будет создаваться одна и та же подпись.

Криптография с использованием эллиптических кривых

Математические понятия

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

В общем случае уравнение эллиптической кривой Е имеет вид:

В качестве примера рассмотрим эллиптическую кривую Е, уравнение которой имеет вид:

На этой кривой лежат только четыре точки, координаты которых являются целыми числами. Это точки

А (0, 0), В (1, -1), С (1, 0) и D (0, -1)

Пример эллиптической кривой с четырьмя точками


Рис. 4.6.  Пример эллиптической кривой с четырьмя точками

Для определения операции сложения двух точек на эллиптической кривой сделаем следующие предположения:

Сложение точек на эллиптической кривой


Рис. 4.7.  Сложение точек на эллиптической кривой

Введем следующие правила сложения точек на эллиптической кривой:

Если прямая является касательной к кривой в какой-либо из точек P или Q, то в этом случае следует положить S=P или S=Q соответственно.

Чтобы удвоить точку Q, следует провести касательную в точке Q и найти другую точку пересечения S с эллиптической кривой. Тогда Q + Q = 2?Q = -S.

Введенная таким образом операция сложения подчиняется всем обычным правилам сложения, в частности коммутативному и ассоциативному законам. Умножение точки Р эллиптической кривой на положительное число k определяется как сумма k точек Р.

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

Такую кривую будем обозначать Ep(a,b). При этом числа а и b должны быть меньше р и должны удовлетворять условию . Множество точек на эллиптической кривой вычисляется следующим образом.

Для каждого такого значения х, что , вычисляется .

Для каждого из полученных таким образом значений выясняется, имеет ли это значение целочисленный квадратный корень. Если нет, то в Ep (a,b) нет точек с этим значением х. Если целочисленный корень существует, имеется два значения y, равные этим значениям квадратного корня. Исключением является случай, когда y равен нулю. Эти значения (x,y) и будут точками Ep(a,b).

Алгоритм цифровой подписи на основе эллиптических кривых ECDSA

Создание ключей:

Выбирается эллиптическая кривая Ep(a,b). Число точек на ней должно делиться на большое целое n.

Выбирается точка Р ∈ Ep(a,b).

Выбирается случайное число d ∈ [1,n-1].

Вычисляется Q = d×P.

Закрытым ключом является d, открытым ключом (E, P, n, Q).

Создание подписи:

Выбирается случайное число k ∈ [1,n-1].

Вычисляется k×P = (x1, y1) и r = x1 (mod n). Проверяется, чтобы r не было равно нулю, так как в этом случае подпись не будет зависеть от закрытого ключа. Если r = 0, то выбирается другое случайное число k.

Вычисляется

Вычисляется

Проверяется, чтобы s не было равно нулю, так как в этом случае необходимого для проверки подписи числа s-1(mod n) не существует. Если s=0, то выбирается другое случайное число k.

Подписью для сообщения М является пара чисел (r,s).

Проверка подписи:

Проверяется, что целые числа r и s принадлежат диапазону чисел [0,n-1]. В противном случае результат проверки отрицательный, и подпись отвергается.

Вычисляется

Вычисляется

Вычисляется

Подпись верна в том и только том случае, когда v = r.

Инфраструктура Открытого Ключа

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

Сначала рассмотрим уязвимости, связанные с открытым ключом, и необходимость создания Инфраструктуры Открытого Ключа (Public Key Infrastructure - PKI). Затем определим ключевые термины, используемые в Инфраструктуре Открытого Ключа.

Одним из требований к алгоритмам цифровой подписи является требование, чтобы было вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR. Казалось бы, открытый ключ KU можно распространять по небезопасным сетям и хранить в небезопасных репози-торях. Но при этом следует помнить, что при использовании цифровой подписи необходимо быть уверенным, что субъект, с которым осуществляется взаимодействие с использованием алгоритма открытого ключа, является собственником соответствующего закрытого ключа. В противном случае возможна атака, когда оппонент заменяет открытый ключ законного участника своим открытым ключом, оставив при этом идентификатор законного участника без изменения. Это позволит ему создавать подписи от имени законного участника и читать зашифрованные сообщения, послан-ные законному участнику, используя для этого свой закрытый ключ, соответствующий подмененному открытому ключу. Для предотвращения такой ситуации следует использовать сертификаты, которые являются структу-рами данных, связывающими открытый ключ с субъектом. Для связывания необходимо наличие доверенного сертификационного центра (Certification Authority – СА), который проверяет идентификацию субъекта и подписы-вает его открытый ключ и некоторую дополнительную информацию своим закрытым ключом.

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

Основным понятием Инфраструктуры Открытого Ключа является понятие сертификата.

Сертификат участника, созданный СА, имеет следующие характеристики:

Мы будем рассматривать сертификаты Х.509, хотя существует доста-точно много сертификатов других форматов.

Стандарт Х.509 первоначально являлся частью стандарта Х.500 и описывал основные требования к аутентификации в Каталогах Х.500. Но Х.509 используется не только в контексте сервиса Каталога Х.500. Сертификаты, определяемые данным стандартом, используются практически всеми программными продуктами, относящимися к обеспечению сетевой безопасности.

Стандарты ITU-TX.509 и ISO/IEC 9594-8, которые впервые были опубликованы в 1988 году как часть рекомендаций Х.500 Директории, определили формат сертификата Х.509. Формат сертификата в стандарте 1988 года называется форматом версии 1 (v1). Стандарт Х.500 был пересмотрен в 1993 году, в результате чего было добавлено несколько новых полей в формат сертификата Х.509, который был назван форматом версии 2 (v2).

Опыт реализации первой и второй версий говорит о том, что форматы сертификата v1 и v2 имеют ряд недостатков. Самое важное, что для хранения различной информации требуется больше полей. В результате ISO/IEC, ITU-T и ANSI X9 разработали формат сертификата Х.509 версии 3 (v3). Формат v3 расширяет формат v2, обеспечивая возможность добавления дополнительных полей расширения. Конкретные типы полей расширения могут быть определены в стандартах или определены и зарегистрированы любой организацией или сообществом. В 1996 году стандартизация базового формата v3 была завершена.

Стандарт ISO/IEC, ITU-T и ANSI X9 являются очень общими, чтобы применять их на практике. Для того чтобы разрабатывать интероперабельные реализации, использующие сертификаты Х.509 v3, необходимо четко специфицировать формат сертификата Х.509 v3. Специалисты IETF разработали профиль сертификата X.509 v3 и опубликовали его в RFC 3280.

Основные элементы сертификата представлеы в таблице 1.8.

Часто используется следующая нотация для обозначения сертификата:

- сертификат пользователя А, выданный сертификационным центром СА.

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

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

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

Таблица 4.1



При большом количестве пользователей неразумно подписывать сертификаты всех пользователей у одного СА. Кроме того, если существует единственный СА, который подписывает сертификаты, каждый пользователь должен иметь копию открытого ключа СА, чтобы проверять подписи. Этот открытый ключ должен быть передан каждому пользователю абсолютно безопасным способом (с обеспечением целостности и аутентифика-ции), чтобы пользователь был уверен в подписанных им сертификатах. Таким образом, в случае большого количества пользователей лучше иметь несколько СА, каждый из которых безопасно предоставляет свой открытый ключ некоторому подмножеству пользователей.

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

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

2. Затем А получает сертификат В, подписанный СА2. Так как А теперь имеет открытый ключ СА2 надежным способом, А может проверить подпись и безопасно получить открытый ключ В.

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

Аналогично В может получить открытый ключ А с помощью такой же цепочки:

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

В этом случае каждая пара СА в цепочке (САi , САi+1 ) должна создать сертификаты друг для друга.

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

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

Х.509 определяет следующий способ отмены сертификата. Предполагается, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (Certificate Revo-cation List – CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечис-лены отмененные на текущий момент сертификаты с неистекшим периодом действительности, указанным в сертификате. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат, эта система не только проверяет подпись сертификата и действительность, но также полу-чает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие "свежий" может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.

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

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

Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRLv2. Существуют также специальные про-токолы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправ-кой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА получает сообщение об отмене, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.

В Инфраструктуре Открытого Ключа используются следующие термины и понятия.

Public Key Infrastructure (PKI)– инфраструктура открытого ключа – это множество аппаратуры, ПО, людей, политик и процедур, необходимых для создания, управления, хранения, распределения и отмены сертифика-тов, основанных на криптографии с открытым ключом.

End Entity (ЕЕ)– конечный участник, для которого выпущен данный сертификат. Важно заметить, что здесь под конечными участниками подразумеваются не только люди и используемые ими приложения, но также и исключительно сами приложения (например, для безопасности уровня IP).

Certificate Authority (CA)– сертификационный или удостоверяющий центр – это уполномоченный орган, который создает и подписывает сертификаты открытого ключа. Дополнительно СА может создавать пары закрытый/открытый ключ для конечного участника. Важно заметить, что СА отвечает за сертификаты открытого ключа в течение всего времени их жизни, а не только в момент выпуска.

Public Key Certificate (PKC)– сертификат открытого ключа или просто сертификат – это структура данных, содержащая открытый ключ конечного участника и другую информацию, которая подписана закрытым ключом СА, выпустившим данный сертификат.

Registration Authority (RA)– регистрационный центр - необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

Причины, по которым могут создаваться RA, разделяют на технические и организационные. К техническим относятся следующие причины:

Организационные причины для использования RA следующие:

Выпускающий CRL- необязательный компонент, которому СА делегирует функции опубликования списков отмененных сертификатов.

Certificate Policy (CP)– политика сертификата - поименованное множество правил, которое определяет применимость сертификата открытого ключа для конкретного сообщества или класса приложений с общими требованиями безопасности. Например, конкретная политика сертификата может указывать применимость сертификата открытого ключа для аутентификации транзакций данных при торговле товарами в данном ценовом диапазоне.

Certificate Practice Statement (CPS)– утверждение об используемой практике, в соответствии с которой сотрудники сертификационного центра выпускают сертификаты открытого ключа.

Relying Party (RP)– проверяющая сторона - пользователь или агент (например, клиент или сервер), который использует сертификат для надежного получения открытого ключа субъекта и, быть может, некоторой дополнительной информации.

Root CA – СА, которому непосредственно доверяет конечный участник; это означает безопасное получение открытого ключа корневого СА, требующее некоторых внешних по отношению к PKI шагов. Этот термин не означает, что корневой СА обязательно должен быть вершиной иерархии. Заметим, что термин "доверенный якорь" имеет то же значение, что и корневой СА в данном случае.

Репозиторий - система или набор распределенных систем, которые хранят сертификаты и CRL и предназначены для распределения этих сертификатов и CRL между конечными участниками.

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

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

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

Лекция 5. Технологии тунеллирования

Протокол GRE

Существуют различные способы инкапсуляции одного протокола в другой. Рассмотрим протокол GRE (Generic Routing Encapsulation), который позволяет инкапсулировать любой протокол. Это может быть использовано для любых целей.

Будем считать, что имеется пакет, который необходимо инкапсулировать и доставить некоторому получателю. Этот пакет будет являться содержимым GRE-пакета. Получившийся GRE-пакет затем инкапсулируется в пакет некоторого другого протокола, и отправляется. Будем называть этот внешний протокол протоколом доставки.

Результирующий пакет имеет следующий формат:

Формат GRE-пакета


Рис. 5.1.  Формат GRE-пакета

В GRE-заголовке содержится тип инкапсулированного протокола. Если содержимым пакета является IPv4, то тип протокола должен быть 0х800.

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

В качестве протокола доставки может также использоваться протокол IPv4.

Протокол GRE


Рис. 5.2.  Протокол GRE

Виртуальные частные сети

Virtual Private Network (VPN) – это различные технологии, которые позволяют создавать логические сети, использующие в качестве транспорта другие сетевые протоколы. При этом характеристики безопасности созданной логической сети могут отличаться от характеристик безопасности сети, которая используется в качестве транспорта. Такие сети могут создаваться на разных уровнях стека OSI исходной транспортной сети. Создаваемая логическая сеть не обязательно должна быть маршрутизируемой, она может обеспечивать соединение типа точка-точка.

VPN используются в двух основных сценариях:

  1. Для соединения двух удаленных локальных сетей, используя в качестве транспорта сеть с другими параметрами безопасности.
  2. Для входа удаленного пользователя в локальную сеть, используя в качестве транспорта сеть с другими параметрами безопасности.

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

Безопасность, обеспечиваемая VPN, зависит от многих параметров операционного окружения, в котором VPN выполняется. Например, от безопасности ОС, источника случайных чисел, способов управления системой и т.д.

Рассмотрим основные протоколы создания VPN и проанализируем их характеристики с точки зрения безопасности создаваемых соединений, возможностей масштабирования и наличия каких-либо дополнительных возможностей.

Таблица 5.1



Протоколы канального уровня

Терминология

Протокол РРР определяет механизм инкапсуляции для пересылки пакетов, принадлежащих любым сетевым протоколам, по каналам точка-точка 2 уровня. Обычно пользователь получает соединение канального уровня (так называемое L2-соединение) к Network Access Server (NAS), используя одну из технологий доступа типа точка-точка: dial-up POTS, ISDN, ADSL и т.п. Протокол РРР выполняется поверх данного соединения. В простейшем случае завершение L2-соединения и конечная точка РРР-протокола расположены на одном и том же физическом устройстве NAS.

L2TP расширяет возможности РРР, допуская, чтобы конечные точки L2 и РРР были расположены на разных устройствах, соединенных между собой сетью, по которой могут передаваться пакеты. При использовании L2TP пользователь создает L2-соединение с концентратором (например, модемом, ADSL DSLAM и т.п.), затем концентратор туннелирует отдельные РРР-кадры к NAS. Это позволяет обрабатывать РРР-кадры отдельно от точки завершения L2-соединения.

Одно очевидное преимущество такого разделения состоит в том, что вместо требования завершения L2-соединения на NAS (что может требовать тянуть провода на большие расстояния), соединение может заканчиваться на локальном концентраторе, который создает логическую РРР-сессию поверх разделяемой инфраструктуры такой, как frame relay или интернет. С точки зрения пользователя не существует различия между завершением L2 непосредственно на NAS или использованием L2TP.

Протокол L2TP определяет создание туннелей между двумя узлами и последующую инкапсуляцию туннелируемых РРР сессий.

В протоколах, выполняющих пересылку РРР-данных по сети Ethernet, используется следующая терминология.

Таблица 5.2.
L2TP концентратор доступа (L2TP Access Concentrator - LAC)Узел, который является одной из конечных точек L2TP-туннеля. LAC является противоположной сто-роной L2TP сетевого сервера (LNS). LAC расположен между LNS и удаленной системой и перенаправляет пакеты к каждой из них. Пакеты, посылаемые от LAC к LNS, туннелируются по протоколу L2TP. Соедине-ние между LAC и удаленной системой является либо локальным, либо выполняется по протоколу РРР. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР концентратор доступа – РАС.
L2TP сетевой сервер (L2TP Network Server - LNS)Узел, который является одной из конечных точек L2TP-туннеля. LNS является противоположной стороной LAC. LNS является логической конечной точкой РРР-сессии, которая туннелируется от удаленной системы с помощью LAC. LNS также является конечной точкой туннеля между LNS и LAC. Если вместо L2TP используется протокол РРТР, то аналогичный узел называется РРТР сетевой сервер – PNS.
Сервер сетевого доступа (NAS) Устройство, предоставляющее пользователям сетевой доступ по требованию. Этот доступ является доступом типа точка-точка, использующим PSTN или ISDN каналы. Функции NAS может выполнять и LAC, и LNS.
L2TP/PPTP-туннельТуннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более L2TP-сессий. L2TP/PPTP-туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS.
L2TP/PPTP-сессияВ протоколах РРТР и L2TP определено понятие сес-сии. LNS и LAC поддерживают состояние для каждого вызова, который инициирован LAC или на который ответил LAC. L2TP-сессия создается между LAC и LNS, когда РРР-соединение установлено между удаленной системой и LNS. Дейтаграммы, относящиеся к РРР-соединению, посылаются по туннелю между LAC и LNS. Между установленными сессиями и соответствующими вызовами существует взаимнооднозначное соответствие.
Управляющее соединение L2TP/PPTPУправляющее соединение используется для установ-ление и поддержки как для сессий, так и самого L2TP/PPTP-туннеля и создается для каждой пары LАС, LNS. Управляющее соединение определяет все характеристики туннеля и связанных с ним сессий.
Point-to-Point Protocol (PPP)

Обзор

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

Протокол обеспечивает инкапсуляцию различных протоколов сетевого уровня в один канал.

Протокол РРР определяет способ передачи дейтаграмм по последова-тельным каналам. Протокол РРР состоит из следующих протоколов:

  1. Протокол управления каналом (Link Control Protocol – LCP) для установления, конфигурирования и тестирования последовательного соединения.
  2. Семейство протоколов управления сетью (Network Control Protocol – NCP) для установления и конфигурирования различных протоколов сетевого уровня.

Для согласования параметров канала используется протокол управления каналом LCP. Протокол LCP может также выполнять аутентификацию конечных точек канала.

В РРР-каналах необходимо задавать многие параметры маршрутизируемых сетевых протоколов. Например, назначение и управление IP-адресами. Для решения этих проблем используются протоколы управления сетью NCP.

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

Для того, чтобы установить соединение точка-точка, каждый конец РРР-канала должен во-первых послать LCP-пакеты для конфигурирования и тестирования канала данных. После того, как канал установлен и выпол-нены переговоры о дополнительных опциях, которые необходимы LCP, РРР должен послать NCP-пакеты для выбора и конфигурирования прото-колов сетевого уровня. После того, как протокол сетевого уровня сконфигурирован, по каналу могут посылаться дейтаграммы.

Канал будет оставаться открытым до тех пор, пока явно не будет закрыт LCP- или NCP-пакетами, или пока не произойдет какое-нибудь внешнее событие.

Диаграмма состояний

В течение своего жизненного цикла РРР-канал проходит через следующие состояния.

Диаграмма состояний РРР-канала


Рис. 5.3.  Диаграмма состояний РРР-канала

Установление канала

Для установления соединения используется LCP-протокол, в котором выполняется обмен конфигурационными пакетами. Инициализация канала выполняется с помощью пакета Configure-Request, на который получатель отвечает Configure-Ack. Инициализация канала завершается, и состояние LCP становится открытым после того, как пакет Configure-Ack отправлен и получен.

Протоколом LCP конфигурируются только те опции, которые не зависят от конкретных протоколов сетевого уровня. Конфигурированием протоколов сетевого уровня занимается отдельные протоколы управления сетью (NCP).

Любые не-LCP-пакеты, полученные в этом состоянии, отбрасываются.

Получатель LCP-запроса на конфигурацию переходит в состояние пересылки дейтаграмм сетевого уровня после инициализации канала и выполнения аутентификации.

Пример LCP-запроса


Рис. 5.4.  Пример LCP-запроса

Пример запроса на аутентификацию


Рис. 5.5.  Пример запроса на аутентификацию

Аутентификация

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

Аутентификация должна иметь место сразу же после установления канала.

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

СНАР- аутентификация в протоколе РРР


Рис. 5.6.  СНАР- аутентификация в протоколе РРР

Протокол аутентификации Challenge-Handshake (CHAP)

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

Преимущества

СНАР обеспечивает защиту от replay-атак, если в качестве запроса по-сылается случайное значение.

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

Хотя аутентифицируется только одна сторона, СНАР-переговоры можно вести в обоих направлениях с тем же самым секретом, обеспечивая взаимную аутентификацию.

Так как данный протокол может использоваться для аутентификации многими различными системами, поле name может использоваться для нахождения нужного секрета. С помощью данного поля можно также поддерживать несколько пар name/secret для каждой системы.

Недостатки

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

Это неудобно при большом количестве участников, так как каждый секрет должен храниться на обоих концах канала.

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

Требования разработки

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

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

Формат конфигурационного параметра

Формат конфигурационного параметра протокола Аутентификации следующий:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type	| Length 	| Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Algorithm 	|
+-+-+-+-+-+-+-++-+
Type				3
Length				5
Authentication Protocol	c223
Algorithm		

определяет используемый алгоритм. Значения алгоритмов определяются IANA. Для MD5 значением является 5.

Формат пакета

В информационное поле РРР-кадра инкапсулируется ровно один СНАР-пакет.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Code 	| Identifier 	| Length 	|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Data ...
+-+-+-+-+

Code определяет тип СНАР-пакета.

1 Запрос

2 Ответ

3 Успех

4 Неуспех

Identifier используется для определения пар соответствующих запросов и ответов.

Length определяет длину СНАР-пакета.

Data формат данного поля определяется полем Code.

Пакет Challenge используется в качестве первого пакета протокола СНАР. Аутентифицирующая сторона посылает СНАР-пакет с полем Code, установленным в 1 (Challenge). Могут посылаться дополнительные пакеты Challenge до тех пор, пока не будет получен пакет Response или не истечет счетчик повторов.

Пакет Challenge также может передаваться в любое время в течение выполнения протокола сетевого уровня, чтобы гарантировать, что не было подмены участников соединения.

Противоположная сторона ожидает пакеты Challenge в течение фаз аутентификации и протокола сетевого уровня. После получения пакета Challenge участник посылает СНАР-пакет и полем Code, установленным в 2 (Response).

После того, как пакет Response получен, аутентифицирующая сторона сравнивает значение, полученное в ответе, с собственным вычисленным значением. В зависимости от результата аутентифицирующая сторона посылает либо пакет Success, либо пакет Failure.

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

Если пакет Failure потерян, аутентифицирующая сторона завершает соединение, и пакеты Terminate-Request и Terminate-Ack протокола сетевого уровня обеспечивают альтернативный способ определения, что аутентификация была неудачной.

Поле Identifier изменяется в каждом новом пакете Challenge. Поле Identifier в пакете Response копируется из поля Identifier соответствующего пакета Challenge.

В поле Data содержатся значения Value и Name. Значение Value в пакете Challenge должно быть уникальным и не зависеть от секрета. Значение Value в пакете Response является результатом вычисления хэш-функции от следующих значений: Identifier, secret, значение Value из пакета Challenge.

В поле Name записана идентификация системы, которая послала пакет. В этом случае синтаксис может быть любой, как строка символов ASCII, так и уникальный идентификатор в ASN.1 синтаксисе.

Обсуждение безопасности

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

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

Расширения Microsoft РРР СНАР версии 1

Обзор

Microsoft разработал протокол MS-CHAP для аутентификации удаленных рабочих станций, который с одной стороны имел бы привычную для локальных пользователей функциональность, а с другой стороны использовал бы алгоритмы шифрования и хэширования.

MS-CHAP основан на протоколе СНАР. Различия между этими протоколами следующие:

Конфигурирование LCP

Конфигурирование LCP для MS-CHAP аналогично конфигурированию стандартного СНАР, за исключением того, что поле Algorithm имеет значение 0x80, а не 0x05. Реализации РРР, который не поддерживают MS-CHAP, но корректно реализуют LCP Config-Rej, не должны иметь проблем с данным нестандартным параметром.

Пакет Challenge

Пакет Challenge в протоколе MS-CHAP аналогичен пакету Challenge в стандартном протоколе СНАР.

Аутентифицирующая сторона посылает 8-октетное значение в поле Value.

Пакет Response

Формат пакета Response аналогичен формату пакета Response в стандартном протоколе СНАР. Однако поле Value отличается:

Совместимый с LAN Manager ответ является результатом выполнения функции LmChallengeResponse()от пароля и полученного запроса. Пароль LAN Manager не может быть длиннее 14 символов и чувствителен к регистру.

Совместимый с Window NT ответ является результатом выполнения функции NTChallengeResponse()от пароля и полученного запроса. Пароль Windows NT является строкой от 0 до 256 символов Unicode, пароль чувствителен к регистру. Обычно длина пароля в Windows NT ограничена 14 символами.

Если установлен флаг "Используется совместимость ответа с Windows NT", то используется Windows NT ответ. Ответ "LAN Manager" может ис-пользоваться, если аккаунт не имеет хэша пароля Windows NT, например, еасли пароль не был изменен после загрузки из базы данных аккаунтов LAN Manager 2.x. Если флаг установлен, то ответ Windows NT игнорирует-ся и используется ответ LAN Manager.

Поле Name содержит имя пользовательского аккаунта противоположной стороны. Имя домена Windows NT может являться префиксом имени пользователя.

Пакет Success

Формат пакета Success аналогичен формату стандартного пакета Success в СНАР.

Пакет Failure

Формат пакеты Failure аналогичен формату стандартного пакета Failure в протоколе СНАР. Однако, в отличии от стандартных правил СНАР, содержимое поля Message влияет на протокол. Формат поля Message следующий:

E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv

Где "eeeeeeeeee" есть десятичный код ошибки, который может быть одним из следующих значений:

646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD

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

"cccccccccccccccc" является новым значением вызова (challenge). Данное поле не является обязательным. Если оно не посылается, то аутентифицирующая сторона считает, что повторный ответ будет вычислен с использованием предыдущего значения вызова, к которому прибавлено десятичное число 23.

10 цифр "vvvvvvvvvv" содержат код версии, обозначающий версию протокола MS-CHAP, поддерживаемую сервером. Это важно только при выборе пакета Change Password. Если поле отсутствует, то считается, что используется версия 1.

Пакет Change Password

Пакет Change Password не посылается в стандартном протоколе СНАР. Допускается, чтобы противоположная сторона изменила пароль аккаунта, указанного в последнем пакете Response. В версии 1 пакет Change Password должен посылаться только в том случае, если аутенти-фицирующая сторона возвратила ERROR_PASSWD_EXPIRED.

Обсуждение безопасности

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

Расширения Microsoft PPP CHAP версии 2

Протокол MS-CHAP-V2 максимально соответствует как протоколу MS-CHAP-V1, так и стандартному протоколу СНАР. Различия между про-токолами MS-CHAP-V1 и MS-CHAP-V2 следующие:

Конфигурация LCP

Конфигурация LCP аналогична той, которая используется в стандартном СНАР, за исключением того, что поле Algorithm имеет значение 0x81, а не значение 0x05 (MD5). Реализации РРР, которые не поддерживают MS-CHAP-V2, но корректно реализуют LCP Config-Rej, не имеют проблем с подобной нестандартной опцией.

Пакет Challenge

Пакет Challenge в протоколе MS-CHAP-V2 имеет тот же самый формат, что и в стандартном протоколе СНАР.

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

Пакет Response

Формат пакета Response в протоколе MS-CHAP-V2 аналогичен формату пакета Response в стандартном протоколе СНАР. Отличается только формат поля Value.

16 октетов: вызов противоположной стороны.

8 октетов: зарезервировано, должно быть установлено в ноль.

24 октета: NT-Response.

1 октет: флаги

Поле Peer-Challenge содержит созданное противоположной стороной 16-октетное случайное число. Данное случайное число используется при вычислении поля NT-Response.

Поле NT-Response является функцией от пароля, имени пользователя, содержимого поля Peer-Challenge и содержит результат функции GenerateNTResponse(). Пароль Windows является строкой длины от 0 до 256 чувствительных к регистру символов Unicode. При вычислении значения поля NT-Response используется только имя пользователя без имени соответствующего домена, не зависимо от того, присутствует ли имя домена в поле Name или нет.

Поле Name является строкой длиной от 0 до 256 чувствительных к регистру символов ASCII, которые являются именем пользователя.

Пакет Success

Формат пакета Success аналогичен формату пакета Success в стандартном протоколе СНАР. Однако поле Message содержит строку ответа длиной 42 октета и сообщение в печатаемом формате. Формат данного поля следующий:

S=<auth_string> M=<message>

<auth_string> состоит из 20 октетов чисел, представленных в коди-ровке ASCII в виде 40 шестнадцатеричных чисел. Данное значение получено из вызова в пакете Challenge, полей Peer-Challenge и NT-Response из пакета Response, пароля противоположной стороны. Данное значение является результатом функции GenerateAuthenticatorResponse(). Аутентификатор проверяется при получении пакета Success. Если аутентификатор отсутствует или не корректный, противоположная сторона завершает сессию.

Пакет Failure

Формат пакета Failure аналогичен формату пакета Failure в стандартном протоколе СНАР. Однако текст хранится в поле Message, значение которого, в отличие от стандартного протокола СНАР, не влияет на операции протокола. Формат поля Message следующий:

E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
M=<msg>

Где "eeeeeeeeee" представление в ASCII десятичного кода ошибки (не более 10 цифр), соотвествующего одному из перечисленных:

646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD

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

"cccccccccccccccccccccccccccccccc" является представлением в ASCII шестнадцатеричного значения вызова. Данное поле всегда присутствует и имеет длину 32 октета.

"vvvvvvvvvv" является представлением в ASCII кода версии, который указывает на то, что сервер поддерживает протокол изменения пароля. Для протокола MS-CHAP-V2 данное значение должно быть равно 3.

<msg> является текстом в соответствующей кодировке и языке.

Пакет Change-Password

Пакет Change-Password не поддерживается ни стандартным протоколом СНАР, ни протоколом MS-CHAP-V1. Данный пакет позволяет противоположной стороне изменить пароль, указанный в предыдущем пакете Response. Пакет Change-Password должен посылаться только если аутентифицирующая сторона присылает ERROR_PASWD_EXPIRED в поле Message пакета Failure.

Формат данного пакета следующий:

Таблица 5.3.
Длина поляНазвание поляПримечание
1 октет Code
1 октет Identifier Данное поле позволяет определить пары запросов и ответов.
2 октета Length
516 октетов Encrypted-Password Данное поле содержит результат выполнения функции NewPasswordEncruptedWithOldNtPasswordHash().
16 октетов Encrypted-Hash Данное поле содержит результат выполнения функции OldNtPasswordHashEncryptedWithNewNtPasswordHash().
16 октетов Peer-Challenge 16-октетное случайное число, аналогичное случайному числу в пакете Response.
8 октетов Зарезервировано.
24 октета NT-Response Аналогично соответствующему полю в пакете Response, но вычисленное для нового пароля и вызова, полученного в пакете Failure.
2 октета Флаги.
Пересылка дейтаграмм сетевого уровня

После завершения выполнения LCP-протокола должен быть сконфигурирован протокол сетевого уровня, такой как IP, IPX и т.п. Конфигурирование протокола сетевого уровня выполняется протоколом управления сетью (Network Control Protocol – NCP).

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

Протокол шифрования МРРЕ Microsoft

Протокол предназначен для шифрования РРР-пакетов. В протоколе ис-пользуется поточный алгоритм шифрования RC4. О длине ключа ведутся переговоры. МРРЕ (Microsoft Point-to-Point Encryption) поддерживает 40-битные, 56-битные и 128-битные ключи. Ключи сессии меняются часто, частота смены ключей зависит от установленных опций.

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

Переговоры об используемой длине ключа


Рис. 5.7.  Переговоры об используемой длине ключа

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

Завершение переговоров об используемой длине ключа


Рис. 5.8.  Завершение переговоров об используемой длине ключа

Для того, чтобы передавать МРРЕ-пакеты, протокол РРР должен перейти в состояние пересылки дейтаграмм сетевого уровня. В информаци-онное поле РРР инкапсулируется одна МРРЕ-дейтаграмма. Для всех зашифрованный дейтаграмм в поле Protocol указан тип 0х00FD.

Обмен зашифрованными дейтаграммами в протоколе РРР


Рис. 5.9.  Обмен зашифрованными дейтаграммами в протоколе РРР

Протокол конфигурирования IP - IPCP

Протокол управления IP (Internet Protocol Control Protocol – IPCP) предназначен для конфигурирования IP-протокола на обоих концах канала точка-точка. IPCP использует тот же самый механизм обмена пакетами, что и протокол управления каналом LCP. Обмен IPCP-пакетами начинается в состоянии обмена дейтаграммами сетевого уровня. IPCP отличается от LCP следующим:

Перед тем, как посылать любые IP-пакеты, протокол IPCP должен перейти в открытое состояние. Максимальная длина IP-пакета, передаваемого по РРР-каналу, та же самая, что и максимальная длина информационного поля РРР-данных канального уровня. IP-дейтаграммы большего размера будут фрагментированы. Если необходимо избежать фрагментирования и последующего сбора пакетов, то следует использовать опции ТСР Maximum Segment Size и MTU discovery.

Конфигурационные опции IPCP позволяют вести переговоры о требуемых параметрах IP. IPCP использует тот же самый формат конфигурацион-ных опций, что и LCP.

Задание диапазона IP-адресов, которые будут выдаваться клиенту


Рис. 5.10.  Задание диапазона IP-адресов, которые будут выдаваться клиенту

  1. Протокол сжатия IP

    Данный параметр позволяет договориться об использовании конкрет-ного протокола сжатия. По умолчанию сжатие не требуется.

    .
  2. IP-адрес.

    Данный параметр предоставляет способ ведения переговоров об IP-адресе, который будет назначен локальной стороне канала. Он позволяет отправителю Configure-Request указать желаемый IP-адрес или запросить противоположную сторону выдать ему IP-адрес. Противоположная сторона может предоставить данную информацию в параметре Nak, указав IP-адрес, который будет использоваться.

  3. Адреса DNS-серверов и узлов NetBIOS Name Серверов (NBNS) в удаленной сети.

    Могут быть указаны IP-адреса первичного и вторичного DNS-серверов. Возможность использования информации об адресах DNS-серверов зависит от топологии удаленной сети и от приложения на локальной стороне.

    Параметры позволяют договориться об IP-адресах первичного и вторичного DNS-серверов, которые будут использоваться на локальной стороне.

Назначение IP-адреса клиенту


Рис. 5.11.  Назначение IP-адреса клиенту

Лекция 6. Соединение сетей GRE-туннелем

Цель

Соединить две локальные сети, каждая из которых расположена за своим межсетевым экраном, туннелем с использованием GRE-протокола.

  1. Обе локальные сети знают IP-адреса друг друга.
  2. Одна из локальных сетей находится за NAT.

Все лабораторные работы выполняются с использованием межсетевых экранов D-Link DFL-860E.

Топология сети



Между интерфейсами wan2 на МЭ 1и МЭ 2 требуется поднять GRE-туннель.

Описание практической работы

Создать статическую маршрутизацию и политики доступа, которые разрешают доступ между удаленными локальными сетями. При этом трафик между МЭ 1 и МЭ 2 проходит по GRE-туннелю.

Обе локальные сети знают IP-адреса друг друга

Межсетевой Экран 1



Объекты Адресной Книги

Создать объект, описывающий IP-адрес локальной стороны GRE-туннеля.

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: gre
Object → Address Book → gre → Add

Командная строка:

add Address AddressFolder gre
cc Address AddressFolder gre
add IP4Address gre_ip Address=192.168.35.10

GRE-Интерфейс

Веб-интерфейс:

Interfaces → GRE → Add → GRE Tunnel

На вкладке General указать IP-адрес локальной точки туннеля, удаленную сеть и IP-адрес удаленной точки.



Если на вкладке Advanced оставить флаг Automatically add a route for this interface …, то в таблицу маршрутизации main добавится маршрут к данной сети с указанной метрикой.



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

Командная строка:

add Interface GRETunnel gre Network=remote/rem_lan IP=gre/gre_ip RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты с интерфейсов wan2 и gre к соответствующим сетям.



Правила фильтрования

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre
Rules → IP Rules → gre → Add



Командная строка:

add IPRuleFolder Name=gre
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=gre DestinationNetwork=remote/rem_lan Service= all_services Name=gre_out
add IPRule Action=Allow SourceInterface=gre SourceNetwork=remote/rem_lan DestinationInterface=lan DestinationNetwork=lan/lan_net Service=all_services Name=gre_in
add IPRule Action=Allow SourceInterface=gre SourceNetwork=remote/rem_lan DestinationInterface=core DestinationNetwork=lan/lan_net Service=all_services Name=gre_in_core

Последнее правило разрешает доступ к lan-интерфейсу самого межсетевого экрана.

Межсетевой экран 2



Объекты Адресной Книги

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: gre
Object → Address Book → gre → Add



Командная строка:

add Address AddressFolder gre
cc Address AddressFolder gre
add IP4Address gre_ip Address=192.168.35.20

GRE-Интерфейс

Веб-интерфейс:

Interfaces → GRE → Add → GRE Tunnel

На вкладке General указать IP-адрес локальной точки туннеля, удаленную сеть и IP-адрес удаленной точки.



Командная строка:

add Interface GRETunnel gre1 Network=remote/rem_lan IP=gre/gre_ip RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты с интерфейсов wan2 и gre к соответствующим сетям.



Правила фильтрования

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre
Rules → IP Rules → gre ? Add



Команднаястрока:

Add IPRuleFolder Name=gre
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan 
SourceNetwork=lan/lan_net 
DestinationInterface=gre 
DestinationNetwork=remote/rem_lann 
Service=all_services 
Name=gre_out
add IPRule Action=Allow S
ourceInterface=gre 
SourceNetwork=remote/rem_lan 
DestinationInterface=gre 
DestinationNetwork=lan/lan_net 
Service=all_services Name=gre_in
add IPRule Action=Allow 
SourceInterface=gre 
SourceNetwork=remote/rem_lan 
DestinationInterface=core 
DestinationNetwork=lan/lan_net 
Service=all_services 
Name=gre_in_core

Последнее правило разрешает доступ к lan-интерфейсу самого межсетевого экрана.

Проверка конфигурации



Смотрим трафик на интерфейсах wan2, gre и lan Межсетевого Экрана 2.

На интерфейсе wan2 внешними IP-адресами является IP-адреса интерфейсов wan2 межсетевых экранов.



На интерфейсе gre видим только ICMP-трафик с адресами из локальных сетей.



На интерфейсе lan видим также только ICMP-трафик с адресами из локальных сетей.



В данной топологии IP-адреса gre-интерфейсов используются исключительно для конфигурирования, в трафике они отсутствуют.

Одна из локальных сетей находится за NAT

Межсетевой Экран 1



Правила фильтрования

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre_nat
Rules → IP Rules → gre_nat → Add



Командная строка:

add IPRuleFolder Name=gre_nat
cc IPRuleFolder < N folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=gre
DestinationNetwork=remote/rem_lann Service=all_services Name=gre_out

Межсетевой Экран 2



Объекты Адресной Книги

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: gre
Object → Address Book → gre → Add



Командная строка:

add Address AddressFolder gre
cc Address AddressFolder gre
add IP4Address gre_ip Address=192.168.35.20
add IP4Address gre_ip_rem Address=192.168.35.10

GRE-Интерфейс

Веб-интерфейс:

Interfaces → GRE → Add → GRE Tunnel

На вкладке General указать IP-адрес локальной точки туннеля, IP-адрес удаленной точки gre-туннеля, на котором выполняется преобразование NAT, и IP-адрес удаленного интерфейса.

Командная строка:

add Interface GRETunnel gre1 Network=gre/gre_ip_rem IP=gre/gre_ip RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты с интерфейсов wan2 и gre к соответствующим сетям.



Правила фильтрования

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre_nat
Rules → IP Rules → gre_nat → Add



Командная строка:

Add IPRuleFolder Name=gre_nat
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=gre SourceNetwork=gre/gre_ip_rem DestinationInterface=gre DestinationNetwork=lan/lan_net Service=all_services Name=gre_in
add IPRule Action=Allow SourceInterface=gre SourceNetwork=gre/gre_ip_rem DestinationInterface=core DestinationNetwork=lan/lan_net Service=all_services Name=gre_in_core

Последнее правило разрешает доступ к lan-интерфейсу самого межсетевого экрана.

Лекция 7. Способы передачи РРР по Ethernet

Протокол L2TP

Топология

Рассмотрим классический L2TP-сценарий. Цель состоит в том, чтобы туннелировать РРР-кадры между удаленной системой (Remote System – оконечная система или маршрутизатор, соединенный с сетью удаленного доступа, которая является либо инициатором, либо получателем вызова. Также может являться dial-up или виртуальным dial-up клиентом) или LAC (L2TP Access Concentrator – узел, который действует как одна из сторон конечной точки L2TP-туннеля и является противоположной стороной L2TP Network Server – LNS) клиентом и LNS, расположенным в сети организации.

Типичная топология сети при использовании протокола L2TP


Рис. 6.1.  Типичная топология сети при использовании протокола L2TP

Удаленный хост инициализирует РРР-соединение, например, через вы-деленный канал или интернет к LAC. LAC – устройство, функционирующее как одна из сторон конечной точки L2TP-туннеля и являющееся противоположной стороной L2TP Network Server – LNS. LAC расположен между LNS и удаленной системой и перенаправляет пакеты каждой из них. Между LAC и LNS выполняется туннелирование по протоколу L2TP.

LAC туннелирует РРР-соединение к LNS, в результате чего пользова-тель получает доступ к локальной сети организации. Удаленному хосту могут быть предоставлены IP-адреса из LAN посредством NCP переговоров РРР. Управляющий домен в локальной сети может выполнить адресацию, аутентификацию, авторизацию и аккаунтинг (АААА) как если бы пользователь непосредственно соединился с NAS.

LAC-клиент (хост, на котором выполняется L2TP-протокол) может также выполнять туннелирование к LAN без использования отдельного LAC. В этом случае хост, с установленным ПО LAC-клиента, также должен иметь соединение с интернетом. Затем создается виртуальное РРР-соединение, и ПО локального L2TP LAC-клиента создает туннель к LNS. Как и в предыдущем случае адресацию, аутентификацию, авторизацию и аккаунтинг (АААА) выполняет управляющий домен из LAN.

Типы сообщений

В протоколе L2TP существует два типа сообщений: управляющие сообщения и сообщения данных. Управляющие сообщения используются для установления, поддержки и очистки туннелей и вызовов. Сообщения дан-ных используются для инкапсуляции РРР-кадров, передающихся по туннелю. Управляющие сообщения используют надежный канал, гарантирующий доставку. Для сообщений данных при потере пакета повторная передача не используется.

Стек протоколов при передаче РРР по L2TP


Рис. 6.2.  Стек протоколов при передаче РРР по L2TP

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

Формат заголовка L2TP

L2TP-пакеты управляющего канала и канала данных имеют одинаковый формат заголовка. Поля Length, Ns и Nr являются обязательными и должны присутствовать во всех управляющих сообщениях.

Заголовок L2TP-сообщения


Рис. 6.3.  Заголовок L2TP-сообщения

Формат L2TP-сообщения


Рис. 6.4.  Формат L2TP-сообщения

Бит T (Type) определяет тип сообщения. 0 – сообщение данных, 1 – управляющее сообщение.

Если бит L (Length) равен 1, то поле Length присутствует. Этот бит должен быть установлен в 1 для управляющих сообщений.

Если установлен бит S (Sequence), то поля Ns и Nr присутствуют. Бит S установлен в управляющих сообщениях.

Если установлен бит O (Offset), то поле Offset Size присутствует. В управляющих сообщениях данный бит установлен в ноль.

Если установлен бит P (Priority), то данное сообщение должно посылаться с большим приоритетом. Например, LCP-сообщения Echo Request, которые используются для проверки жизнеспособности связи, должно посылаться с этим установленным битом. Этот бит используется только для сообщений данных. В управляющих сообщениях он установлен в ноль.

Версия должна быть установлена в 2. Если версия установлена в 1, то это означает совместимость с протоколом L2F, т.е. L2F-пакеты и L2TP-пакеты могут посылаться вперемешку.

Tunnel ID определяет идентификатор управляющего соединения. L2TP-туннели именуются идентификаторами, которые имеют только локальное значение. Это означает, что один и тот же туннель имеет различные Tunnel ID на разных концах. Tunnel ID в сообщении указан для стороны получателя, а не для стороны отправителя. Tunnel ID выбираются, и их значениями обмениваются при создании туннеля.

Session ID определяет идентификатор сессии внутри туннеля. L2TP-сессии именуются идентификаторами, которые имеют только локальное значение. Это означает, что одна и та же сессия имеет разные значения Session ID на разных концах. Session ID в сообщении указано для стороны получателя, а не для стороны отправителя. Session ID выбираются, и их значениями обмениваются при создании сессии.

Ns указывает последовательный номер сообщения данных или управляющего сообщения.

Nr указывает последовательный номер следующего управляющего сообщения. Таким образом, Nr установлен в Ns последнего полученного сообщения плюс один (по модулю 216). В сообщениях данных Nr игнорируется.

Поле Offset Size, если присутствует, указывает, с какого байта после L2TP-заголовка начинаются данные.

Типы управляющих сообщений

В целях расширяемости и интераберабельности в L2TP используется унифицированный метод представления типов сообщений. Это представление обозначается AVP (Attribute-Value Pair).

Message Type AVP определяет тип посылаемого управляющего сообщения, т.е. тех сообщений, у которых установлен бит Т.

Для поддержки управляющего соединения используются следующие сообщения:

  1. SCCRQ Start-Control-Connection-Request
  2. SCCRP Start-Control-Connection-Replay
  3. SCCCN Start-Control-Connection-Connection
  4. STOPCCN Stop-Control-Connection-Notification
  5. HELLO Hello

    Для поддержки вызова используются следующие сообщения:

  6. OCRQ Outgoing-Call-Request
  7. OCRP Outgoing-Call-Reply
  8. OCCN Outgoing-Call-Connected
  9. ICRQ Incoming-Call-Request
  10. ICRP Incoming-Call-Reply
  11. ICCN Incoming-Call-Connected
  12. CDN Call-Disconnect-Notify

    Для отчета об ошибках используется сообщение:

  13. WEN WAN-Error-Notify

    Для управления РРР-сессией используется сообщение:

  14. SLI Set-Link-Info

Формат AVP

Формат AVP


Рис. 6.5.  Формат AVP

Первые шесть битов описывают общие атрибуты AVP.

Mandatory (M) бит: управляет реакцией на получение неизвестного AVP. Если бит установлен в AVP, который получатель не может распознать, то сессия, связанная с этим сообщением, завершается. Если сообще-ние связано с туннелем, то закрывается туннель и все сессии внутри него. Если бит М не установлен, то нераспознанный AVP игнорируется. Управляющее сообщение продолжает обрабатываться как если бы AVP не присутствовал.

Hidden (H) бит: указывает на скрытие данных в поле значения атрибута AVP. Это используется, чтобы избежать передачи чувствительных данных, таких как пароли пользователей, в явном виде в AVP. Далее рассмотрим процедуры, выполняющиеся для скрытия AVP.

Length: количество битов в данном AVP. Длина = 6 + длина поля Value в байтах. Длина самого этого поля равна 10 битам, что допускает максимально 1023 байтов данных в одном AVP. Минимальное значение в этом поле равно 6, что означает, что поле Value отсутствует.

Обязательные AVP

Получение неизвестного AVP с установленным битом М приводит к завершению сессии или туннеля, с которым этот AVP связан. Таким образом, бит М устанавливается только в AVP, которые абсолютно критичны для корректного функционирования сессии или туннеля.

Сокрытие значений атрибутов AVP

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

Бит Н должен быть установлен только в том случае, если между LAC и LNS существует общий секрет. Разделяемый секрет является тем же самым секретом, который используется для аутентификации туннеля. Если бит Н установлен в каком-либо AVP в данном управляющем сообщении, в сообщении должен также присутствовать Random Vector AVP, который дол-жен предшествовать первому AVP с установленным битом Н.

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

Исходный AVP


Рис. 6.6.  Исходный AVP

Длина значения исходного атрибута: это длина значения исходного атрибута, которое будет скрыто. Это необходимо для определения исходной длины значения атрибута, которая будет потеряна после добавления значений.

Значение исходного атрибута: значение атрибута, которое будет скрыто.

Добавление: случайные добавляемые октеты, используемые для скрытия исходной длины атрибута.

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

Далее вычисляется хэш-код MD5 для следующего значения:

2 октета номера атрибута + разделяемый секрет + случайный вектор произвольной длины

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

Затем выполняется XOR значения хэша MD5 и первых 16 октетов (или меньше) значения AVP, который требуется скрыть. Результат помещается в поле значения атрибута Hidden AVP. Если Hidden AVP меньше, чем 16 октет, то перед выполнение XOR оно добавляется до 16 октетов.

Если Hidden AVP длиннее 16 октетов, то вычисляется второе значение MD5 для конкатенации разделяемого секрета и следующими 16 октетами Hidden AVP.

Данная операция повторяется необходимое число раз.

Обзор существующих AVP

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

AVP, используемые во всех управляющих сообщениях

Message Type (все сообщения)

Определяет управляющее сообщение и контекст, в котором используются последующие AVP. Этот AVP является первым в сообщении, непосредственно следуя за заголовком управляющего сообщения.

Бит Mandatory (M) в Message Type AVP имеет специальное значение. Он указывает, что сам AVP должен игнорироваться, если не распознается. Он также определяет, что само управляющее сообщение должно игнорироваться. Таким образом, если бит М установлен в Message Type AVP, и Message Type не известен, то туннель уничтожается. Если бит М не установлен, то неизвестный тип сообщения может игнорироваться.

Random Vector (все сообщения)

Random Vector AVP используется для обеспечения возможности скрытия значений некоторых AVP. Этот случайный вектор будет использоваться при вычислении хэш-кода MD5 для скрытых значений.

В сообщение может быть несколько Random Vector AVP. Данный AVP посылается до первого AVP с установленным битом H.

Бит М в данном AVP установлен, AVP не должен быть скрыт.

Коды результата и коды ошибок

Result Code (CDN, STOPCCN)

Result Code AVP указывает причину завершения управляющего канала или сессии. Данный AVP не должен быть скрыт, бит М должен быть установлен.

В сообщении STOPCCN определены следующие коды результата:

  1. -Общий запрос на освобождение управляющего соединения.
  2. -Общая ошибка – в Error Code указана причина.
  3. -Управляющий канал уже существует.
  4. -Запрашивающая сторона не авторизована устанавливать управляющий канал.
  5. -Версия протокола не поддерживается получателем. В Error Code указана максимальная поддерживаемая версия.
  6. -Запрашивающая сторона остановлена.
  7. -Ошибка машины конечных состояний.

В сообщении CDN определены следующие коды результата:

  1. -Разрыв соединения из-за потери несущей.
  2. -Разрыв соединения из-за причины, указанной в коде ошибки.
  3. -Разрыв соединения из-за административных причин.
  4. -Сбой вызова из-за временного отсутствия необходимых усло-вий.
  5. -Сбой вызова из-за постоянного отсутствия необходимых усло-вий.
  6. -Недействительный получатель.
  7. -Сбой вызова из-за отсутствия несущей.
  8. -Сбой вызова из-за того, что сигнал занят.
  9. -Сбой вызова из-за потери тонального набора.
  10. -Вызов не был установлен в течение времени, отведенного LAC.
  11. -Вызов был установлен, но не обработан требуемым образом.

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

  1. -Не существует управляющего соединения для данной пары LAC-LNS.
  2. -Неправильная длина.
  3. -Одно из значений полей выходит за допустимый диапазон или зарезервированное поле имеет ненулевое значение.
  4. -Недостаточно ресурсов для выполнения данной операции.
  5. -Session ID является недействительным в данном контексте.
  6. -На стороне LAC произошла общая ошибка, специфичная для данного производителя.
  7. -Следует попытаться заново установить соединение. Если LAC известны другие возможные LNS, он должен попытаться соединиться с ними. Это может использоваться для того, чтобы поведение LAC зависело от политики LNS.
  8. -Сессия или туннель удалены из-за получения неизвестного AVP с установленным битом М.

AVP, используемые в управляющих соединениях

Protocol Version (SCCRP, SCCRQ)

Значение 2 указывает на протокол L2TP.

Framing Capabilities (SCCRP, SCCRQ)

AVP указывает противоположной стороне тип обработки: синхронная или асинхронная. Противоположная сторона не должна делать запрос входящего или исходящего вызова со значением Framing Type AVP, которое не соответствует полученному при установлении управляющего соединения. Попытки сделать это приведут к тому, что вызов будет сброшен.

Данный AVP может быть скрыт. Бит М для данного AVP всегда установлен.

Bearer Capabilities (SCCRP, SCCRQ)

Bearer Capabilities AVP указывает противоположной стороне типы устройств аппаратных интерфейсов, а именно, поддерживается ли аналоговый и цифровой доступ.

LNS не должен в исходящем вызове указывать значение в Bear Capabilities AVP, которое не соответствует тому, которое он получил от LAC при установлении управляющего соединения. Попытка сделать это приведет к тому, что вызов будет сброшен.

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

Данный AVP может быть скрыт, бит М не установлен.

Tie Breaker (SCCRQ)

Tie Breaker AVP говорит о том, что отправитель хочет, чтобы существовал единственный туннель между данной парой LAC-LNS.

Host Name (SCCRP, SCCRQ)

Host Name AVP указывает имя LAC или LNS, чаще всего это DNS-имя.

Assigned Tunnel ID (SCCRP, SCCRQ, STOPCCN)

Assigned Tunnel ID AVP указывает идентификатор, связанный с данным туннелем отправителем. Данное значение используется для мультиплексирования и демультиплексирования нескольких туннелей между LNS и LAC. Противоположная сторона размещает данное значение в заголовке Tunnel ID во всех управляющих сообщениях и сообщениях данных, которые передаются по этому туннелю. Перед тем, как получить Assigned Tunnel ID AVP от противоположной стороны, данной стороне посылаются управляющие сообщения со значением Assigned Tunnel ID, равным нулю.

В управляющем сообщении STOPCCN Assigned Tunnel ID AVP имеет тоже самое значение, что и в первый раз посланный Assigned Tunnel ID AVP, что позволяет противоположной стороне определить соответствующий туннель, даже если STOPCCN послан до того, как получен Assigned Tunnel ID AVP.

Данный AVP может быть скрыт. Бит М должен быть установлен.

Receive Window Size (SCCRQ, SCCRP)

Receive Window Size AVP определяет размер окна получателя.

Challenge (SCCRP, SCCRQ)

Challenge AVP говорит о том, что противоположная сторона хочет выполнить аутентификацию с использованием СНАР-механизма.

Данный AVP может быть скрыт. Бит М для данного AVP всегда установлен.

Challenge Response (SCCCN, SCCRP)

Response AVP передает ответ на полученный запрос.

Данный AVP всегда присутствует в SCCRP или SCCCN, если ранее был получен запрос в SCCRQ или SCCRP.

Данный AVP может быть скрыт. Бит М должен быть установлен.

Операции протокола

Установка туннелирования для РРР-сессии состоит из двух шагов:

  1. Установление управляющего соединения для туннеля.
  2. Установление сессии, которая запускается при входящих и исходящих вызовах.

Туннель и управляющее соединение должны быть установлены до инициализации входящего или исходящего вызова. L2TP-сессия должна быть установлена до того, как L2TP начнет туннелировать РРР-кадры. Че-рез единственный туннель может существовать несколько сессий, несколь-ко туннелей может быть создано между одними и теми же LAC и LNS.

Туннелирование РРР


Рис. 6.7.  Туннелирование РРР

Установление управляющего соединения

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

Установление управляющего соединения начинается с обмена следующими сообщениями:

Установление управляющего соединения


Рис. 6.8.  Установление управляющего соединения

ZLB ACK посылается, если в очереди нет сообщений.

Пример трафика при установлении соединения


Рис. 6.9.  Пример трафика при установлении соединения

Аутентификация туннеля

L2TP выполняет простую, не обязательную, СНАР-подобную аутентификацию туннеля при установлении управляющего соединения. Если LAC или LNS хочет аутентифицировать другого участника, в сообщение SCCRQ или SCCRP включается Challenge AVP. Если Challenge AVP получено, то Challenge Response AVP должен быть послан в следующем SCCRP или SCCRN соответственно. Если ответ не соответствует ожидаемому, установление туннеля должно быть сброшено.

Аутентификация выполняется с помощью разделяемого между LAC и LNS секрета. Тот же самый секрет используется для сокрытия AVP.

Установление сессии

После успешного установления управляющего соединения могут создаваться отдельные сессии. Каждая сессия соответствует одному потоку РРР между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является направленным от LAC к LNS. LAC запрашивает сессию для входящего вызова, LNS отвечает.

Установление входящего вызова

Для установления сессии используется обмен тремя сообщениями. Далее приведена типичная последовательность сообщений:

Установление входящего вызова


Рис. 6.10.  Установление входящего вызова

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

Установление исходящего вызова

Для установления сессии используется обмен тремя сообщениями. Далее приведена типичная последовательность сообщений:

становление исходящего вызова


Рис. 6.11.  становление исходящего вызова

ZLB ACK посылается, если больше нет сообщений в очереди к проти-воположной стороне.

Перенаправление РРР-кадров

После того, как завершено установление туннеля, РРР-кадры из удаленной системы получаются LAC, выполняются необходимые действия (удаление CRC, выполнение фрагментирования и т.п.), выполняется инкап-суляция в L2TP и перенаправление в соответствующий туннель. LNS получает L2TP-пакет, обрабатывает инкапсулированный РРР-кадр как если бы он был получен на локальном РРР-интерфейсе.

Отправитель сообщения, связанного с конкретной сессией и туннелем, размещает Session ID и Tunnel ID (указанные противоположной стороной) в заголовке Session ID и Tunnel ID для всех исходящих сообщений. Таким образом, РРР-кадры мультиплексируются в единственный туннель между LNS и LAC. В туннеле может существовать несколько сессий.

Нулевые значения Session ID и Tunnel ID используются для установления новой сессии.

Использование последовательных номеров в канале данных

Последовательные номера, содержащиеся в L2TP-заголовке, обяза-тельны для управляющих сообщений и не обязательны для сообщений данных. Они используются для обеспечения надежности транспорта управляющих сообщений и дополнительно могут обеспечивать подсчет сообщений данных. Каждый участник поддерживает отдельные последовательные номера для управляющего соединения и каждой отдельной сессии данных внутри туннеля.

В отличие от управляющего L2TP-канала канал данных L2TP не использует последовательные номера для повторной передачи потерянных сообщений данных. Сообщения данных могут использовать последовательные номера для определения потерянных пакетов или восстановления исходной последовательности пакетов, если при пересылке нарушена последовательность. LAC может потребовать, чтобы последовательные номера присутствовали в сообщениях данных, используя Sequencing Required AVP. Если данный AVP присутствует при установке сессии, последовательные номера должны указываться во всех сообщениях. Если данный AVP не присутствует, наличием последовательных номеров управляет LNS. Наличие или отсутствие последовательных номеров определяется посылкой сообщения с последовательным номеров в любое время в течение времени жизни сессии. Таким образом, если LAC получает сообще-ние данных без последовательного номера, он должен не посылать после-довательные номера во всех следующих исходящих сообщениях данных.

LNS может инициализировать отключение использования последовательных номеров в любой момент в течение сессии. Рекомендуется, чтобы в соединениях, в которых может происходить переупорядочение или потеря пакетов, последовательные номера всегда устанавливались при инициа-лизации РРР и отключались только в том случае, если такой риск считается приемлемым. Например, если РРР-сессия туннелируется без использования каких-либо протоколов сжатия или шифрования с поддержкой состояния, а обеспечивается просто доставка IP (как определяется установленным РРР NCP), то LNS должен отключить использование последовательных номеров, так как для IP допустимо потеря и переупорядочивание дейтаграмм.

Keepalive (Hello)

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

Завершение сессии

Завершение сессии может инициализироваться и LAC, и LNS, и состоит в посылке управляющего сообщения CDN. После того, как последняя сессия завершена, управляющее соединение может быть удалено. Типичный пример обмена сообщениями в этом случае следующий:

Завершение сессии


Рис. 6.12.  Завершение сессии

Завершение управляющего соединения

Завершение управляющего соединения может инициироваться и LAC, и LNS. Оно состоит в посылке единственного управляющего сообщения STOPCCN. Получатель STOPCCN должен послать ZLB ACK для подтверждения получения сообщения и поддержания состояния управляющего соединения, если ZLB ACK будет потерян. Типичный обмен сообщениями следующий:

Завершение управляющего соединения


Рис. 6.13.  Завершение управляющего соединения

Надежная доставка управляющих сообщений

L2TP обеспечивает надежную доставку всех управляющих сообщений. Для этого используются поля Nr и Ns в заголовке управляющего сообщения. Функции более высокого уровня в L2TP не занимаются повтором или переупорядочиванием управляющих сообщений. Каждая сторона поддерживает отдельные последовательные номера для каждого конца туннеля.

Последовательные номера управляющих сообщений возрастают на единицу. Исключением являются только ZLB-сообщений.

Номер последнего полученного сообщения передается противоположной стороне в поле Nr.

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

В каждом туннеле поддерживается очередь управляющих сообщений, которые должны быть переданы противоположной стороне. Сообщение в начале очереди посылается с текущим значением Ns и хранится до тех пор, пока противоположная сторона не подтвердит получение сообщения в поле Nr. Если подтверждение не получено в течение определенного периода времени (по умолчанию 1 секунда), сообщение передается повторно. Повторное сообщение содержит то же самое значение Ns, но значение Nr должно быть изменено на последовательный номер следующего ожидаемого сообщения.

Интервал между следующими повторными передачами должен возрастать экспоненциально. Таким образом, если первая повторная передача происходит через 1 секунду, то следующая повторная передача должна произойти через 2 секунды, затем через 4 секунды и т.д. Если противоположная сторона не отвечает после нескольких повторных передач (по умолчанию 5), то туннель и все сессии закрываются.

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

Для повторной передачи управляющего сообщения используется механизм скользящего окна, аналогичный тому, который используется в ТСР.

Протокол управляющего соединения

Для установления и поддержки L2TP-туннеля используются следующие сообщения управляющего соединения.

Start-Control-Connection-Request (SCCRQ)

Управляющее сообщение SCCRQ используется для инициализации туннеля между LNS и LAC. Оно посылается либо LAC, либо LNS для установления туннеля.

В SCCRQ должны быть следующие AVP:

•	Message Type AVP
•	Protocol Version
•	Host Name
•	Framing Capabilities
•	Assinged Tunnel ID 

Установление управляющего соединения


Рис. 6.14.  Установление управляющего соединения

Start-Control-Connection-Reply (SCCRP)

Управляющее сообщение SCCRP посылается в ответ на получение SCCRQ сообщения. SCCRP используется для указания того, что SCCRQ получено, и установление туннеля должно продолжаться.

Start-Control-Connection-Connected (SCCCN)

Управляющее сообщение SCCCN посылается в ответ на SCCRP. Оно завершает процесс установления туннеля.

Завершение установления управляющего соединения


Рис. 6.15.  Завершение установления управляющего соединения

Stop-Control-Connection-Notification (STOPCCN)

Управляющее сообщение STOPCCN посылается либо LAC, либо LNS для информирования противоположной стороны о том, что туннель завершается, и управляющее соединение должно быть закрыто. Кроме того, все управляющие сессии должны быть неявно очищены (без посылки каких-либо управляющих сообщений). Причина данного запроса указана в Result Code AVP. На данное сообщение нет явного ответа, только неявное подтверждение на транспортном уровне, что получено управляющее сообщение.

Hello

Сообщение Hello периодически посылается любым из участников для подтверждения жизнеспособности ("keepalive") туннеля.

Надежность доставки этого сообщения гарантируется лежащим ниже транспортом.

Сообщения Hello являются глобальными для туннеля. Session ID в сообщении Hello установлено в 0.

Incoming-Call-Request (ICRQ)

Управляющее сообщение ICRQ посылается от LAC к LNS, когда определен входящий вызов. Это первое из трех сообщений, которые используются для установления сессии в L2TP-туннеле.

ICRQ используется для указания того, что для данного вызова устанавливается сессия между LAC и LNS и предоставляет LNS-параметры сессии. LAC может отложить ответ на вызов до тех пор, пока он не получит ICRQ от LNS, указывающее, что сессия должна быть установлена. Данный механизм позволяет LNS получать информацию о вызове до определения того, нужно ли на него отвечать или нет. В качестве альтернативы LAC может ответить на вызов, начать переговоры об LCP и РРР-аутентификации и использовать информацию, полученную для выбора LNS. В этом случае при получении сообщения ICRP на вызов уже будет дан ответ. LAC просто игнорирует шаги "индикация вызова" и "ответ вызова".

Incoming-Call-Reply (ICRP)

Управляющее сообщение ICRP посылается от LNS к LAC в ответ на получение сообщения ICRQ. Это второе из трех сообщений, используемых для установления сессий в L2TP-туннеле.

ICRP используется для указания того, что ICRQ было успешным и для того, чтобы LAC ответил на вызов, если он еще не сделал этого. Это также позволяет LNS указать необходимые параметры L2TP-сессии.

Incoming-Call-Connection (ICCN)

Управляющее сообщение ICCN посылается от LAC к LNS в ответ на получение сообщения ICRР. Это третье из трех сообщений, используемых для установления сессий в L2TP-туннеле.

ICCN используется для указания того, что ICRP получено, на вызов был дан ответ, и что L2TP-сессия находится в состоянии "установлено". Оно также предоставляет LNS дополнительную информацию об используемых параметрах, которые еще могли быть не доступны при посылке сообщения ICRQ.

Outgoing-Call-Request (OCRQ)

Управляющее сообщение OCRQ посылается от LNS к LAC для указания того, что исходящий вызов от LAC установлен. Это первое из трех сообщений, используемых для установления сессии в L2TP-туннеле.

OCRQ используется для указания того, что для данного вызова сессия между LNS и LAC установлена.

LNS при установлении туннеля получает от LAC Bearer Capabilities AVP, чтобы запросить исходящий вызов к данному LAC.

Outgoing-Call-Reply (OCRP)

Управляющее сообщение OCRP посылается от LAC к LNS в ответ на получение сообщения OCRQ. Это второе из трех сообщений, используемых для установления сессии в L2TP-туннеле.

OCRP используется для указания того, что LAC пытается установить исходящий вызов, и возвращает соответствующие параметры.

Outgoing-Call-Connection (OCCN)

Управляющее сообщение OCCN посылается от LAC к LNS после OCRP и после того, как исходящий вызов завершен. Это заключительное сообщение из трех сообщений, используемых для установления сессии в L2TP-туннеле.

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

Call-Disconnect-Notify (CDN)

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

WAN-Error-Notify (WEN)

Управляющее сообщение WEN посылается от LAC к LNS для указания об условиях ошибки WAN (условиях, которые произошли на интерфейсе, поддерживающим РРР).

Set-Link-Info (SLI)

Управляющее сообщение SLI посылается от LNS к LAC для установления РРР-опций. Эти опции могут быть изменены в течение всего времени жизни соединения, тем самым LAC имеет возможность изменить свою информацию и поведение РРР-сессии.

Состояния управляющего соединения

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

Рассмотрим операции, выполняемые различными функциями управля-ющего соединения L2TP и сообщения, которые при этом используются.

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

Установление управляющего соединения

Состояниями, связанными с LNS или LAC для установленного управляющего соединения, являются:

Таблица 6.1.
Состояние Комментарий
Пустое Начальное состояние как инициатора, так и получателя. Инициатор передает SCCRQ, получатель остается в пустом состоянии, пока не получит SCCRQ.
Wait-ctl-reply Инициатор проверяет, не запрошено ли других соединений от той же самой противоположной стороны. В этом случае обрабатывает возникшую коллизию. При получении SCCRP он проверяет совместимость версий и переходит в состояние "установлено". Если версия не поддерживается, то посылается STOPCCN и закрывается туннель.
Wait-ctl-conn Состояние, при котором ожидается SCCCN; при получении проверяется ответ. Туннель либо устанавливается, либо закрывается, если не проходит аутентификация.
Установлено Установленное соединение может быть завершено либо в результате локальной причины, либо при получении Stop-Control-Connection-Notification. В случае локального завершения инициатор должен послать Stop-Control-Connection-Notification и очистить туннель. Если инициатор получает Stop-Control-Connection-Notification, он также должен очистить туннель.

Входящие вызовы

Сообщение Incoming-Call-Request создается LAC, когда определен входящий вызов (это может быть не только звонок в телефонной линии, но и инициализация ТСР-соединения, если удаленная система подсоединена через интернет). LAC выбирает идентификатор сессии и серийный номер и определяет тип вызова. ISDN-вызов должен указываться как цифровой. Могут также указываться вызываемый номер, вызвавший номер и подадрес, если эта информация доступна.

После того, как LAC посылает Incoming-Call-Request, он ждет ответ от LNS, но не обязательно должен быть ответный вызов от LNS к LAC. LNS может не принимать вызов, если:

Если LNS решает принимать вызов, он отвечает Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается соеди-нить вызов. Завершающее сообщение от LAC к LNS указывает, что состоя-ния вызова как для LAC, так и для LNS должны перейти в установленное состояние. Если вызов завершается до того, как LNS может принять его, LAC посылает Call-Disconnect-Notify для указания этого условия.

Когда звонящий клиент вешает трубку, вызов очищается обычным образом, и LAC посылает Call-Disconnect-Notify сообщение. Если LNS хочет очистить вызов, он посылает Call-Disconnect-Notify сообщение и очищает свою сессию.

Состояния входящего вызова LAC

Таблица 6.2.
Состояние Событие Действие Новое состояние
Пустое Звонок по несущей или определение входящего соединения, в зависимости от используемого типа сети Инициализация локального открытия туннеля Wait-tunnel
Пустое Получение ICCN, ICRP, CDN Очистка Пустое
Wait-tunnel Сброс несущей или локальный запрос закрытия Очистка Пустое
Wait-tunnel Открытие туннеля Посылка ICRQ Wait-reply
Wait-reply Получение ICRP, принимаемо Посылка ICCN Установлено
Wait-reply Получение ICRP, не принимаемо Посылка CDN, очистка Пустое
Wait-reply Получение ICRQ Посылка CDN, очистка Пустое
Wait-reply Получение CDN, ICCN Очистка Пустое
Wait-reply Локальный запрос закрытия или сброс несущей Посылка CDN, очистка Пустое
Установлено Получение CDN Очистка Пустое
Установлено Получение ICRQ, ICRP, ICCN Посылка CDN, очистка Пустое
Установлено Сброс несущей или локальный запрос закрытия Посылка CDN, очистка Пустое

Состояниями, связанными с LAC для входящих вызовов являются:

Таблица 6.3.
Состояние Комментарий
ПустоеLAC определяет входящий вызов на одном из своих интерфейсов. Обычно это означает звонок по аналоговой линии или ISDN, или установление начального соединения по Ethernet. LAC инициирует установление туннеля и переходит в ждущее состояние для подтверждения существования туннеля.
Wait-tunnel В этом состоянии сессия либо ждет открытия управляющего соединения, либо проверки, что туннель уже открыт. После проверки, что туннель уже открыт можно обмениваться управляющими сообщениями. Первым из них должно быть Incoming-Call-Request.
Wait-reply LAC получает либо CDN сообщение, указывающее, что LNS не может принять вызов, после чего переходит в пустое состояние. Или LAC получает Incoming-Call-Reply сообщение, указывающее, что вызов принимается, и LAC посылает Incoming-Call-Connected сообщение и переходит в установленное состояние.
Установлено Данные передаются по туннелю. Вызов может быть сброшен в результате следующих событий: Событие на интерфейсе, на котором установлено соединение: LAC посылает Call-Disconnect-Notify сообщение. Получение Call-Disconnect-Notify сообщения: LAC очищает ресурсы и разрывает соединение. Локальная причина: LAC посылает Call-Disconnect-Notify сообщение.

Состояния входящего вызова LNS

Таблица 6.4.
Состояние Событие Действие Новое состояние
Пустое Получение ICRQ, принимаемо Посылка ICRP Wait-connect
Пустое Получение ICRQ, не принимаемо Посылка CDN, очистка Пустое
Пустое Получение ICRP Посылка CDN, очистка Пустое
Пустое Получение ICCN Очистка Пустое
Wait-connect Получение ICCN, принимаемо Подготовка данных Установлено
Wait-connect Получение ICCN, не принимаемо Посылка CDN, очистка Пустое
Wait-connect Получение ICRQ, ICRP Посылка CDN, очистка Пустое
Пустое, wait-connect, установлено Получение CDN Очистка Пустое
Wait-connect, установлено Локальный запрос закрытия Посылка CDN, очистка Пустое
Установлено Получение ICRQ, ICRP, ICCN Посылка CDN, очистка Пустое

Состояниями, связанными с LNS для входящих вызовов, являются:

Таблица 6.5.
Состояние Комментарий
Пустое Получено Incoming-Call-Request сообщение. Если запрос не принимаем, то обратно к LAC посылается Call-Disconnect-Notify. LNS остается в пустом состоянии. Если Incoming-Call-Request сообщение принимаемо, то посылается Imcoming-Call-Reply. Сессия переходит в состояние wait-connect.
Wait-connect Если сессия уже установлена с LAC, LAC посылает Incoming-Call-Connect сообщение к LNS, который после этого переходит в состояние "установлено". LAC может послать Call-Disconnect-Notify для определения того, что входящий вызов не отсоединен.
Установлено Сессия завершается либо при получении Call-Disconnect-Notify сообщения от LAC, либо посылкой Call-Disconnect-Notify. Происходит очистка на обоих концах, не зависимо от того, кто был инициатором.

Исходящие вызовы

Исходящие вызовы инициируются LNS и требуют от LAC принять вызов. Для исходящих вызовов существует три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, указывая номер телефона звонящего, подадрес и другие параметры. Номер телефона указывается всегда, не зависимо от типа сети, для обеспечения интероперабельности с наследуемы-ми приложениями. LAC отвечает на Outgoing-Call-Request сообщением Outgoing-Call-Reply после того, как определит, что существуют возможности принять вызов, и вызов разрешен администратором. После того, как исходящий вызов соединен, LAC посылает Outgoing-Call-Connected сообщение к LNS, указывая конечный результат вызова.

Состояния исходящего вызова LAC

Таблица 6.6.
Состояние Событие Действие Новое состояние
Пустое Получение OCRQ, принимаемо Посылка OCRP, открытие несущей Wait-cs-answer
Пустое Получение OCRQ, не принимаемо Посылка CDN, очистка Пустое
Пустое Получение OCRP Посылка CDN, очистка Пустое
Пустое Получение OCCN, CDN Очистка Пустое
Wait-cs-answer Ответ несущей, определение кадров Посылка OCCN Установлено
Wait-cs-answer Сбой несущей Посылка CDN, очистка Пустое
Wait-cs-answer Получение OCRQ, OCRP, OCCN Посылка CDN, очистка Пустое
Установлено Получение OCRQ, OCRP, OCCN Посылка CDN, очистка Пустое
Wait-cs-answer, установлено Получение CDN Очистка Пустое
Установлено Сброс несущей, локальный запрос закрытия Посылка CDN, очистка Пустое

Состояниями, связанными с LAC для исходящих вызовов, являются:

Таблица 6.7.
Состояние Комментарий
Пустое Если получен Outgoing-Call-Request с указанием ошибки, ответом является Call-Disconnect-Notify. В противном случае отводятся ресурсы для физического канала и посылается Outgoing-Call-Reply. Отводятся ресурсы для исходящего вызова, и LAC переходит в состояние wait-cs-answer.
Wait-cs-answer Если вызов не выполнен или истек таймер ожидания выполнения вызова, посылается Call-Disconnect-Notify с указанием соответствующей ошибки. LAC переходит в пустое состояние. Если соединение на данной стороне установлено и определены кадры, посылается Outgoing-Call-Connected, указывающее на успешное завершение установления соединения. LAC переходит в состояние "установлено".
Установлено Если LAC получил Call-Disconnect-Notify, телекоммуникационный вызов должен быть обработан с помощью соответствующих механизмов и сессия очищена. Если вызов сброшен клиентом или вызывающим интерфейсом, к LNS посылается сообщение Call-Disconnect-Notify. После посылке этого сообщения отправитель Call-Disconnect-Notify переходит в пустое состояние.

Состояния исходящего вызова LNS

Таблица 6.8.
Состояние Событие Действие Новое состояние
Пустое Локальный запрос открытия Инициациализация локального открытия туннеля Wait-tunnel
Пустое Получение OCCN, OCRP, CDN Очистка Пустое
Wait-tunnel Открытие туннеля Посылка OCRQ Wait-reply
Wait-reply Получение OCRP, принимаемо Нет Wait-connect
Wait-reply Получение OCRP, не принимаемо Посылка CDN, очистка Пустое
Wait-reply Получение OCCN, OCRQ Посылка CDN, очистка Пустое
Wait-connect Получение OCCN Нет Установлено
Wait-connect Получение OCRQ, OCRP Посылка CDN, очистка Пустое
Пустое, wait-reply, wait-connect, установлено Получение CDN Очистка Пустое
Установлено Получение OCRQ, OCRP, OCCN Посылка CDN, очистка Пустое
Wait-reply, wait-connect, установлено Локальный запрос закрытия Посылка CDN, очистка Пустое
Wait-tunnel Локальный запрос закрытия Очистка Пустое

Состояниями, связанными с LNS для исходящего вызова, являются:

Таблица 6.9.
Состояние Комментарий
Пустое, wait-tunnel При инициации исходящего вызова во-первых создается туннель, а также состояниями входящего вызова LAC становятся пустое и wait-tunnel. После того, как туннель установлен, к LAC посылается Outgoing-Call-Request сообщение, и сессия переходит в состояние wait-reply.
Wait-reply Если полученоCall-Disconnect-Notify, то это означает, что произошла ошибка, сессия очищается и возвращается в пустое состояние. Если получено Outgoing-Call-Reply, то это означает, что происходит вызов, и сессия переходит в состояние wait-connect.
Wait-connect Если получен Call-Disconnect-Notify, вызов сбрасывается; сессия очищается и возвращается в пустое состояние. Если получен Outgoing-Call-Connected, то вызов считается успешным, и в сессии можно обмениваться данными.
Установлено Если получен Call-Disconnect-Notify, вызов завершается по причине, указанной в кодах результата. Сессия переходит в пустое состояние. Если LNS решает завершить сессию, он посылает Call-Disconnect-Notify к LAC, затем очищает сессию и переводит ее в пустое состояние.

Завершение туннеля

Туннель завершается, когда любой из участников посылает Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать в течение определенного периода времени подтверждения перед тем, как удалить управляющую информацию, связанную с туннелем. Получатель данного уведомления должен послать подтверждение и удалить соответствующую управляющую информацию.

Выполнение L2TP поверх UDP/IP

Протокол L2TP является самодостаточным и может функционировать в различных средах. Тем не менее необходимо знать некоторые детали, связанные со средой.

L2TP использует UDP-порт 1701. Весь L2TP-пакет, включая содержимое и L2TP-заголовок, посылается в UDP-дейтаграмме. Инициатор L2TP-туннеля выбирает доступный UDP-порт источника (который может и отличаться от 1701) и посылает пакет получателю на порт 1701. Получатель выбирает свободный порт в своей системе (который может и отличаться от 1701) и посылает ответ инициатору на его UDP-порт. После того, как адре-са и порты инициатора и получателя установлены, они остаются постоянными с течение всего времени жизни канала.

Считается, что, так как получатель может выбрать произвольный порт источника (в отличие от порта назначения в пакете, инициирующем туннель, который должен быть 1701), это может вызвать проблемы, связанные с прохождением NAT.

Также может иметь место фрагментация IP. В протоколе L2TP ничего не делается для оптимизации этого. LAC может использовать LCP для ве-дения переговоров о конкретном значении MRU, которое может быть оптимизировано для окружения LAC и согласовано со значением MTU в пути, по которому пересылаются L2TP-пакеты.

Задание MTU для L2TP-пакетов


Рис. 6.16.  Задание MTU для L2TP-пакетов

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

Порт 1701 используется как L2F-, так и L2TP-пакетами. Эти пакеты отличаются значением поля версии.

Для РРР-клиентов, использующих L2TP-over-UDP/IP туннель, РРР-канал имеет характеристики, которые дают возможность переупорядочивать или молча отбрасывать пакеты. Первый вариант может привести к тому, что не смогут использоваться не-IP-протоколы, передаваемые по РРР. Второй вариант может привести к тому, что не смогут использоваться протоколы, в которых ошибки определяются на уровне пакетов, такие как сжатие заголовка ТСР. Правильная последовательность может обеспечиваться последовательными номерами в сообщениях данных L2TP, если протокол, передаваемый по РРР-туннелю, не поддерживает переупорядочивание.

Возможность молча отбрасывать пакеты является наиболее проблематичной для некоторых протоколов. Если в РРР включена надежная доставка, то в протоколах более высокого уровня не будет потерь пакетов. Если в L2TP используются последовательные номера, то L2TP может определить потерю пакета. В случае LNS оба стека, и РРР, и L2TP присутствуют в LNS, и потеря пакета может быть обнаружена, если пакет получен с ошибкой контрольной суммы. Если стеки LAC и РРР не присутствуют одновременно, то эта технология также может использоваться.

Обсуждение безопасности

L2TP имеет несколько проблем, связанных с безопасностью.

Безопасность конечной точки туннеля

Конечные точки туннеля могут дополнительно выполнять аутентификацию друг друга при установлении туннеля. Характеристики этой аутентификации такие же, как у СНАР, т.е. аутентификация защищена от replay-атак и от атак, связанных с подделкой, при установлении туннеля. Данный механизм не предполагает никакой аутентификации после того, как туннель установлен. Это приводит к тому, что достаточно просто вставить пакеты в поток после того, как выполнена аутентификация конечных точек туннеля.

Для выполнения аутентификации LAC и LNS должны разделять общий секрет. Так как используется единственный секрет, AVP, аутентифицирующие туннель, содержат различные значения полей CHAP ID, используемые для вычисления дайджеста, чтобы гарантировать защиту от replay-атак.

Безопасность на уровне пакетов

Для обеспечения безопасности L2TP требуется, чтобы нижележащий транспорт мог предоставлять сервисы шифрования, целостности и аутентификации для всего L2TP-трафика. Этот безопасный транспорт оперирует со всем L2TP-пакетом и функционально не зависит от РРР и протокола, который доставляется по РРР. Таким образом, L2TP предоставляет сервисы конфиденциальности, целостности и аутентификации L2TP-пакетов между конечными точками туннеля (LAC и LNS), но не с шифрованием на уровне канала и обеспечением конфиденциальности трафика между физическими конечными точками.

End-to-end безопасность

Обеспечение защиты потока L2TP-пакетов на транспортном уровне означает безопасность данных, которые туннелируются РРР-пакетами, от LAC к LNS. Это не означает end-to-end безопасности между взаимодействующими хостами или приложениями.

L2TP и IPSec

При выполнении поверх IP IPSec обеспечивает безопасность на уровне пакетов с помощью ESP или АН. Все управляющие пакеты и пакеты данных L2TP, относящиеся к конкретному туннелю, являются для IPSec однородными UDP/IP пакетами.

В дополнение к транспортной безопасности на уровне IP в IPSec определен режим, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на уровне пакетов, предоставляемая туннельным режимом IPSec, и безопасность, обеспечиваемая L2TP совместно с IPSec, имеют эквивалентные характеристики.

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

Протокол РРТР

Протоколы L2TP и РРТР имеют много общего. Протокол L2TP был разработан на основе протоколов L2F и РРТР.

Одно из основных различий состоит в том, что протокол РРТР использует протокол GRE для пересылки РРР-пакетов. Для управляющего соеди-нения РРТР используется протокол ТСР.

Установление РРТР-соединения


Рис. 6.17.  Установление РРТР-соединения

Завершение установления РРТР-соединения


Рис. 6.18.  Завершение установления РРТР-соединения

Протокол PPPoE

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

Этот способ может использоваться для открытия РРР-сессий с несколькими получателями. Данный способ используется в различных технологиях удаленного доступа, когда провайдеры доступа хотят поддерживать сессию, связанную с РРР.

Обзор

Современные технологии доступа предназначены для нескольких конфликтующих друг с другом целей. Желательно установить соединение с несколькими хостами через одно и то же устройство доступа. Также необ-ходимо обеспечить управление доступом и возможности биллинга способом, аналогичным dial-up сервисам, использующим РРР. Во многих технологиях доступа наиболее эффективным является использование Ethernet для подсоединения нескольких хостов через одно и то же устройство доступа. Кроме того, желательно максимально снизить стоимость такого устройства и минимизировать необходимость конфигурирования.

РРРоЕ предоставляет возможность подсоединять к сети хосты через единственное устройство, которое обеспечивает доступ к удаленному Access Concentrator (NAC). При таком подходе каждый хост использует свой собственный РРР-канал, а пользователь имеет простой интерфейс. Управление доступом, биллинг и предоставляемые типы сервисов могут определяться на уровне пользователя.

Типичная топология сети при использовании РРРоЕ


Рис. 6.19.  Типичная топология сети при использовании РРРоЕ

Для предоставления соединения точка-точка по Ethernet каждая РРР-сессия должна знать Ethernet-адрес удаленной стороны, а также установить уникальный идентификатор сессии. В РРРоЕ определен протокол обнаружения, который выполняет эти задачи.

РРРоЕ имеет две стадии: стадия обнаружения (Discovery) и стадия РРР-сессии. Когда хост хочет установить РРРоЕ-сессию, он должен во-первых выполнить стадию Discovery для определения Ethernet МАС-адреса противоположной стороны и установить РРРоЕ SESSION_ID. Хотя РРР определяет взаимодействие типа точка-точка, Discovery наследует клиент-серверное взаимодействие. В процессе обнаружения Хост (клиент) определяет Access Concentrator (сервер). В зависимости от сетевой тополо-гии может быть несколько Access Concentrator, с которыми может взаимо-действовать Хост. Стадия Discovery позволяет Хосту обнаружить все Access Concentrator и выбрать один из них. При успешном завершении ста-дии Discovery как Хост, так и выбранный Access Concentrator обладают информацией, которую они будут использовать для создания своего собственного соединения точка-точка по сети Ethernet.

Стадия Discovery не поддерживает состояние до тех пор, пока не установлена РРР-сессия. После установления РРР-сессии как Хост, так и Access Concentrator выделяют ресурсы для виртуального РРР-интерфейса.

Содержимое пакетов

Пакеты имеют следующий формат.

Формат РРРоЕ-пакетов.


Рис. 6.20.  Формат РРРоЕ-пакетов.

Поле DESTINATION_ADDR содержит либо единственный Ethernet-адрес получателя, либо широковещательный Ethernet-адрес (0xffffffff). Для пакетов Discovery значением является либо единственный, либо широковещательный адрес. Для трафика РРР-сессии данное поле должно содержать адрес противоположной стороны.

Поле SOURCE_ADDR должно содержать Ethernet МАС-адрес источника.

Поле ETHER_TYPE определяет либо стадию Discovery, либо стадию РРР-сессии.

Стадия Discovery

На стадии Discovery существует четыре шага. После завершения данной стадии оба участника знают PPPoE SESSION_ID и Ethernet-адрес противоположной стороны, которые уникально определяют РРРоЕ-сессию. Шаги включают отправку Хостом широковещательного пакета Initiation, и получение от одного или более NAC пакета Offer. Затем Хост посылает одноадресный пакет Session Request, и выбранный NAC отвечает пакетом Confirmation. После получения Хостом пакета Confirmation, он начинает стадию установления РРР-сессии.

Содержимое РРРоЕ состоит из нуля или более атрибутов, которые в данном случае называются тегами (TAG). TAG являетсятройкой TLV (type-length-value).

1. Пакет PPPoE Active Discovery Initiation (PADI)

Хост посылает пакет PADI с широковещательным адресом, установленным в поле DESTINATION_ADDR.

2. Пакет PPPoE Active Discovery Offer (PADO)

При получении пакета PADI NAC отвечает пакетом PADO. Поле DESTINATION_ADDR содержит адрес Хоста, который послал пакет PADI. Пакет PADO должен содержать AC-Name TAG с именем NAC.

3. Пакет PPPoE Active Discovery Request (PADR)

Так как пакет PADI является широковещательным, Хост может получить более одного пакета PADI, из которых он должен выбрать один. Выбор может быть основан на AC-Name или предлагаемых сервисах. Затем Хост посылает пакет PADR к NAC, который он выбрал. Поле DESTINATION_ADDR установленов Ethernet-адресполучателя.

4. Пакет PPPoE Active Discovery Session-confirmation (PADS)

Когда NAC получает пакет PADS, он обрабатывает его и начинает РРР-сессию. Он создает уникальный SESSION_ID для данной РРРоЕ-сессии и возвращает пакет PADS Хосту.

5. Пакет PPPoE Active Discovery Termination (PADT)

Данный пакет может быть послан в любое время, после того, как сессия установлена, для указания того, что РРРоЕ-сессия завершается. Он может быть послан как Хостом, так и NAC.

При получении PADT никакой РРР-трафик не должен посылаться в рамках данной сессии. После посылки или получения PADT не должны посылаться даже обычные пакеты завершения РРР. РРР противоположной стороны может использовать сам протокол РРР для завершения РРРоЕ-сессии, но PADT может использоваться и тогда, когда РРР не используется.

Стадия РРР-сессии

После того, как РРРоЕ-сессия началась, РРР-данные посылаются как вложенные данные. Все Ethernet-пакеты являются одноадресными. SESSION_ID не изменяется для данной РРРоЕ-сессии и определяется на стадии обнаружения. Содержимым РРРоЕ является РРР-кадр. Кадр начинается с Protocol-ID PPP.

Не должны вестись переговоры о максимальном возможном блоке (Maximum-Receive-Unit - MRU), размер которого больше 1492. Так как максимальный размер содержимого Ethernet 1500 байтов, РРРоЕ-заголовок равен 6 байтам, и Protocol ID PPP равен 2 байтам, то РРР MTU не может быть больше, чем 1492.

Обычно NAC посылает Echo-Request пакеты к Хосту для определения состояния сессии. В противном случае, если Хост завершает сессию без отправления Terminate-Request пакета, NAC не имеет возможности определить, что сессия завершилась.

Когда LCP завершается, и Хост, и NAC перестают использовать данную сессию. Если Хост хочет начать другую РРР-сессию, он должен заново повторить стадию Discovery РРРоЕ.

Лекция 8. Соединение сетей протоколом L2TP, аутентификация с использованием общего секрета

Цель

Соединить два межсетевых экрана VPN с использованием протокола L2TP.Топология сети аналогична топологии VPN/IPSec.

Топология сети



Между интерфейсами wan1 на МЭ 1и МЭ 2 требуется поднять VPN/L2TP.

Описание практической работы

Создать статическую маршрутизацию и политики доступа, которые разрешают доступ между локальными сетями, расположенными за межсетевыми экранами. При этом трафик между МЭ 1 и МЭ 2 проходит по VPN/L2TP.

Межсетевой Экран 1

Межсетевой Экран 1 является клиентом, т.е. в его конфигурации следует указать имя пользователя и пароль.

L2TP-Интерфейс

Веб-интерфейс:

Interfaces → PPTP/L2TP Clients → Add → PPTP/L2TP Client

На вкладке General указать туннелирующий протокол L2TP, адрес конечной точки и сеть, расположенную за туннелем.

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



На вкладке Security указать параметры РРР-аутентификации и РРР-шифрования.



Если на вкладке Dial-on-demand установлен флаг Enable Dial-on-demand, то туннель будет установлен при появлении активности на стороне клиента и будет удален, если в течение указанного в параметре Idle timeout не было активности либо с обеих сторон, либо с одной из сторон, в зависимости от выбранной опции Activity sensing. Если флаг Enable Dial-on-demand не установлен, то туннель будет поднят всегда.



Если на вкладке Advanced установлен флаг Automatically add a route for this interface using the given remote network, то в таблицу маршрутизации main автоматически будет добавлен маршрут с указанной метрикой.



Команднаястрока:

add Interface L2TPClient l2tp_client Network=remote/rem_lan RemoteEndpoint=wan2/wan2_gw Username=l2tp_u Password=qwerty TunnelProtocol=L2TP

Правила фильтрования

Разрешим трафик от сети, расположенной за межсетевым экраном, выполняющим роль L2TP-клиента, к сети, расположенной за межсетевым экраном, выполняющим роль L2TP-сервера.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: l2tp
Rules → IP Rules → l2tp → Add



Командная строка:

add IPRuleFolder Name=l2tp
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=l2tp_int DestinationNetwork=remote/rem_lan Service=all_services Name=l2tp_out

Если требуется, чтобы у удаленного пользователя IP-адрес назначался L2TP-Сервером, то на стороне L2TP-Клиента в Правилах фильтрования указывается правило NAT.

На стороне клиента следует задать тот же пул IP-адресов, который задан на стороне сервера для L2TP-клиента.

Межсетевой Экран 2

Межсетевой Экран 2 является сервером, т.е. на нем надо создать не только интерфейс L2TP, но и БД учетных записей пользователей.

Объекты Адресной Книги

Создать пул IP-адресов.

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: l2tp
Object → Address Book → l2tp → Add



Командная строка:

add Address AddressFolder l2tp
cc Address AddressFolder l2tp
add IP4Address l2tp_pool Address=192.168.3.25-192.168.3.29

IP-адреса из этого пула будут выдаваться L2TP-клиенту, т.е. L2TP-интерфейсу на МЭ 1:



L2TP-Интерфейс

Веб-интерфейс:

Interfaces → PPTP/L2TP Servers → Add → PPTP/L2TP server

На вкладке General указываются параметры туннеля.



На вкладке РРР Parameters указываются параметры РРР-шифрования и пул IP-адресов, из которого будут выдаваться IP-адреса клиенту.



Командная строка:

add Interface L2TPServer l2tp_server Interface=wan2 IP=lan/lan_ip ServerIP=wan2/wan2_ip IPPool=l2tp/l2tp_pool TunnelProtocol=L2TP

Правила фильтрования

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: l2tp
Rules → IP Rules → l2tp → Add



Командная строка:

add IPRuleFolder Name=l2tp
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=l2tp_server SourceNetwork=remote/rem_lan DestinationInterface=lan DestinationNetwork=lan/lan_net Service=all_services Name=l2tp_in

Если у удаленного пользователя IP-адрес назначался L2TP-Сервером, то в Правилах фильтрования следует указать вместо удаленной сети пул выделяемых IP-адресов.

Аутентификация на уровне пользователя

Создать локальную базу данных пользователей.

Веб-интерфейс:

User Authentication → Local User Databases → Add → Local User Database

На вкладке General указать имя базы данных.



На вкладке Users добавить учетные записи пользователей.



Командная строка:

add LocalUserDatabase l2tp_ua
add User olga Password=qwerty AutoAddRouteNet=remote/rem_lan

Создать правило аутентификации пользователей.

Веб-интерфейс:

User Authentication → User Authentication Rules → Add
	Name: l2tp_rules

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



На вкладке Authentication Options указать имя локальной базы данных пользователей.



На вкладке Agent Options указать параметры РРР-аутентификации.



Командная строка:

add UserAuthRule AuthSource=Local Interface=l2tp_server LocalUserDB=l2tp_ua OriginatorIP=wan2/wan2_gw Agent=PPP TerminatorIP=wan2/wan2_ip Name=l2tp_rules

Проверка конфигурации

Выполнить команду ping.



На МЭ 2 в Статусах аутентификации пользователей должна появиться запись с именем пользователя, указанного в параметрах L2TP-клиента на противоположной стороне туннеля.



Дамп сетевого трафика на интерфейсе wan1 должен содержать команды протокола L2TP.



Лекция 9. Семейство протоколов IPSec

Назначение семейства протоколов IPSec

Рассмотрим архитектуру семейства протоколов IPSec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP для протоколов IPv4 и IPv6. Рассмотрим серви-сы безопасности, предоставляемые протоколами IPSec, и использование этих протоколов в сетях ТСР/IP.

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

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

IPSec может быть реализован как в ОС, так и в маршрутизаторе или межсетевом экране.

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

Перечислим основные задачи протоколов IPSec:

  1. Обеспечение криптографической защиты на уровне IP для протоколов IPv4 и IPv6, а именно обеспечение конфиденци-альности и целостности данных и целостности некоторой по-следовательности дейтаграмм.
  2. Обеспечение прозрачности для IP-трафика, для которого не требуется использование протоколов IPSec.
  3. Обеспечение расширяемости, т.е. возможности добавлять но-вые наборы алгоритмов без изменения самого протокола.

IPSec предназначен для безопасного взаимодействия с использованием криптографии для протоколов IPv4 и IPv6. Сервисы безопасности включают управление доступом, целостность и конфиденциальность данных и защиту от replay-атак, которая обеспечивается гарантированием целостности некоторой последовательности дейтаграмм. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP-протокола и протоколов более высокого уровня.

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

Рассмотрим выполнение протоколов IPSec, основные компоненты системы и их взаимодействие для обеспечения сервисов безопасности.

IPSec выполняется на хосте (Host – H) или шлюзе безопасности (Security Gateway – SG), обеспечивая защиту IP-трафика. Термин "шлюз безопасности" используется для обозначения маршрутизатора, который реализует IPsec-протоколы.

Защита основана на требованиях, определенных в базе данных политики безопасности (Security Policy Database - SPD), устанавливаемой и поддерживаемой администратором. В общем случае пакеты обрабатываются одним из трех способов, основанных на информации IP-заголовка и транспортного уровня в соответствии с записями в SPD. Каждый пакет либо отбрасывается, либо пропускается без обработки, либо обрабатывается в соответствии с записью SPD для данного пакета.

Возможные способы реализации IPSec

Существует несколько способов реализации IPSec на хосте или совместно с маршрутизатором или межсетевым экраном (для создания шлюза безопасности).

  1. нтеграция IPSec в конкретную реализацию протокола IP. Это требует доступа к исходному коду IP и делается как на хостах, так и на шлюзах безопасности.
  2. "Bump-in-the-stack" (BITS) реализации, когда IPSec реализован "внизу" существующей реализации стека IP-протоколов, встраивая свою реализацию между стандартной реализацией IP-протоколов и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном случае не требуется. Данный подход обычно реализуется на хостах, когда IPSec реализован в виде подключаемой библиотеки.
  3. Использование внешнего криптопроцессора. Обычно это называется "Bump-in-the-wire" (BITW) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITW-устройства являются IP-адресуемыми.

Протоколы защиты трафика и понятие безопасной ассоциации

Предоставляемые IPSec сервисы по защите трафика реализуются с помощью двух протоколов обеспечения безопасного трафика: Authentication Header (AH) и Encapsulating Security Payload (ESP).

Для защиты трафика в IPSec определены следующие протоколы:

  1. Протокол Encapsulating Security Payload (ESP) обеспечивает конфиденциальность и целостность протоколов, расположенных выше в стеке протоколов и дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм.
  2. Протокол Authentication Header (AH) обеспечивает целостность протоколов, расположенных выше в стеке протоколов и целостность отдельных полей IP-заголовка, которые не изменяются при пересылке от отправителя к получателю, дополнительно может обеспечиваться анти-replay сервис, т.е. целостность некоторой последовательности дейтаграмм. В IPSec v2 реализация данного протокола не является обязательной.
  3. Параметры этих протоколов определяются в протоколе распределения ключей Internet Key Exchange (IKE).

С трафиком, безопасность которого обеспечивается IPSec, связано понятие безопасной ассоциации (Security Association – SA). SA содержит всю информацию, необходимую для выполнения различных сетевых сервисов безопасности.

SA представляет собой симплексное (однонаправленное) логическое соединение, создаваемое между двумя конечными точками, для обеспечения безопасности которых используется один из протоколов IPSec. ESP и АН передают трафик по SA. Весь трафик, передаваемый по SA, обрабатывается в соответствии с политикой безопасности, заданной на концах соединения.

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

SA определяет параметры сервисов безопасности, которые применяются к трафику. В обычном случае при двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется две SA (по одной на каждое направление).

Будем рассматривать SA только для одноадресных соединений.

Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим используется для создания VPN между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP-заголовка. В протоколе ESP транспортный ре-жим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае АН защита распространяется также и на отдельные части IP-заголовка.

Другим режимом SA является режим туннелирования. Если одним из концов соединения является шлюз безопасности, то по стандартам IPSec SA обязательно должна выполняться в туннельном режиме, но многие производители допускают в этом случае как туннельный, так и транспортный режимы. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае ping- или SNMP-команд, шлюз безопасности рассматривается как хост, и как правило используется транспортный режим. Два хоста могут при необходимости устанавливать туннельный режим.

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

Кратко подытожим:

  1. Хост может поддерживать оба режима, как транспортный, так и туннельный.
  2. Шлюз безопасности как правило использует только туннель-ный режим. Если он поддерживает транспортный режим, то этот режим как правило используется только тогда, когда без-опасный шлюз является получателем трафика, например, для управления сетью.

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

На каждом сетевом интерфейсе, поддерживающим IPSec, должны создаваться две базы данных: БД Политики Безопасности (SPD) и БД Безопасных Ассоциаций (Security Association Database – SAD). Первая определяет политики, которые применяются для обработки всего IP-трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Для обработки трафика определяется понятие Селектора, который задает множества значений полей протоколов более высокого уровня, используемых для определения соответствия записи в SPD конкретному трафику.

Для широкого использования IPSec требуется стандартный, масштабируемый протокол создания и управления SA. Таким протоколом является протокол Internet Key Exchange – IKE. Протокол состоит из двух фаз – фаза I и фаза II. Каждая фаза состоит из обмена несколькими сообщениями. Каждое сообщение в свою очередь состоит из нескольких содержимых (payload). В результате выполнения фазы I создается IKE SA. В результате выполнения фазы II создается одна или несколько ESP SA или AH SA.

Для описания форматов передаваемых сообщений используется стандарт, называемый "Безопасная Ассоциация Интернет и Протокол Управления Ключом - Internet Security Association and Key Management Protocol (ISAKMP)". ISAKMP определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA.

Понятие домена IPSec

Понятие домена IPSec (Domain of Interpretation - DOI) вводится для то-го, чтобы можно было сгруппировать относящиеся к IPSec протоколы, использующие IKE для ведения переговоров о SA. Протоколы безопасности, относящиеся к одному DOI-домену, выбирают протокол безопасности и криптографические преобразования из общего пространства имен и используют общие идентификаторы в протоколе создания SA. Они также одинаково интерпретирует данные, содержащиеся в различных сообщениях.

При описании домена определяются следующие понятия:

Все идентификаторы, используемые в IPSec, зарегистрированы в IANA. Все данные хранятся в сетевом порядке байтов.

Определение условий, при которых выполняется

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

Условие			Значение 
SIT_IDENTITY_ONLY	0х01
SIT_SECRECY		0x02
SIT_INTEGRETY		0x04

Условие SIT_IDENTITY_ONLY

Условие SIT_IDENTITY_ONLY указывает, что безопасная ассоциация определяется идентификационной информацией источника, которая находится в содержимом SA. Определены несколько типов идентификаций, пе-редаваемых в содержимом Identification, которое посылается в фазе I IKE.

Если Инициатор не поддерживает ни SIT_SECRECY, ни SIT_INTEGRETY, то метка DOI может не передаваться.

Пример поля Situation


Рис. 7.1.  Пример поля Situation

Условие SIT_SECRECY

Условие SIT_SECRECY указывает, что SA устанавливается в окружении, в котором требуется защита. Поле Situation содержит значение требуемого уровня чувствительности.

Если Получатель не поддерживает SIT_SECRECY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Условие SIT_INTEGRETY

Условие SIT_INTEGRETY указывает, что SA устанавливается в окружении, в котором требуется обеспечение целостности. Поле Situation содержит значение требуемого уровня целостности.

Если Получатель не поддерживает SIT_INTEGRETY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Возможные топологии IPSec

С помощью протоколов IPSec можно реализовать различные топологии VPN. Основные топологии позволяют создавать следующие VPN:

Приведем четыре варианта топологий VPN, создаваемых между хостами и шлюзами безопасности, которые реализуют IPSec. Введем следующие обозначения:

Таблица 7.1



Рассматриваемые ниже безопасные ассоциации могут использовать как АН-, так и ESP-протоколы. Режим (туннельный или транспортный) определяется характером конечных точек. Для Host - Host SA режим может быть как транспортным, так и туннельным. Для SG - SG SA режим скорее всего будет туннельным.

Вариант 1. Создание безопасного соединения между двумя хостами через открытую публичную сеть.

Топология сети: VPN между двумя хостами


Рис. 7.2.  Топология сети: VPN между двумя хостами

В данном случае между хостами может использоваться как транспортный, так и туннельный режим. Заголовки в пакете между Host 1 и Host 2 выглядят следующим образом:

. Вложенность заголовков при создании VPN между двумя хостами


Рис. 7.3.  . Вложенность заголовков при создании VPN между двумя хостами

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

В данной топологии маршрутизаторы (Rtr 1 и Rtr 2) не поддерживают IPSec, т.е. не являются шлюзами безопасности (SG), и не могут анализировать трафик, передаваемый междуHost 1 и Host 2. Если эти маршрутизаторы также выполняют функции межсетевого экрана, то они должны пропускать весь IPSec-трафик, как трафик управления SA, так и трафик протоколов АН или ESP.

Трафик между Host 1 и Host 2 защищен сервисами безопасности как в публичной сети, так и в обеих локальных сетях. IP-адреса хостов видны как в публичной сети, так и в обеих локальных сетях.

Вариант 2. Создание виртуальной частной сети между двумя удален-ными локальными сетями.

Топология сети: VPN между двумя локальными сетями


Рис. 7.4.  Топология сети: VPN между двумя локальными сетями

В этом случае как правило используется только туннельный режим. При этом заголовки в пакете между SG1 и SG2 будут выглядеть следующим образом:

Вложенность заголовков при создании VPN между двумя локальными сетями


Рис. 7.5.  Вложенность заголовков при создании VPN между двумя локальными сетями

В данной топологии хосты в локальных сетях не поддерживают IPSec, и, как следствие, трафик в локальных сетях не защищен от внутренних (insider) атак. Трафик в публичной сети защищен. IP-адреса хостов в локальной сети не видны в публичной сети.

Вариант 3. Создание безопасного соединения между двумя хостами с возможностью частичного анализа и фильтрования трафика на шлюзах безопасности.

Топология сети: VPN с возможностью анализа трафика на шлюзе безопасности


Рис. 7.6.  Топология сети: VPN с возможностью анализа трафика на шлюзе безопасности

Создаются две вложенные SA. Одна между хостами Host 1 и Host 2, другая между шлюзами безопасности SG 1 и SG 2. В этом случае трафик будет защищен как в публичной, так и в локальной сетях, и шлюзы безопасности смогут частично анализировать и фильтровать трафик, передаваемый в и из локальных сетей.

На шлюзах безопасности должен использоваться туннельный режим. На хостах правильнее использовать транспортный режим.

Вариант 4. Безопасное подключение удаленного пользователя к ло-кальной сети организации с возможностью частичного анализа и фильтро-вания трафика на шлюзе безопасности (рис. 7.7).

В этом случае создаются две вложенные SA: одна между удаленным хостом Host 1 и хостом в локальной сети Host 2 (SA 1), вторая между удаленным хостом Host 1 и шлюзом безопасности SG 2 (SA 2). В результате трафик защищен как в интернете (SA 2), так и в локальной сети (SA 1). Удаленный хост (Нost 1) использует интернет для достижения межсетевого экрана организации (SG 2) и затем получает доступ к некоторому хосту (Нost 2) в локальной сети. Между Нost 1 и SG 2 используется режим туннелирования. Для SA между SG 2 и Нost 2 возможен как транспортный, так и туннельный режимы.

Топология сети: защищенный доступ пользователя в локальную сеть


Рис. 7.7.  Топология сети: защищенный доступ пользователя в локальную сеть

В данной топологии защищаемая конечная точка (обычно портативный переносной компьютер) соединяется со своей корпоративной сетью через IPSec-туннель. Конечная точка использует данный туннель для доступа в корпоративную сеть, после этого трафик может туннелироваться через локальную сеть, чтобы защитить его и в локальной сети. В этом случае существует возможность фильтрования трафика корпоративным межсетевым экраном. Конечная точка должна иметь IP-адрес, известный межсетевому экрану, чтобы он мог пропускать пакеты через межсетевой экран и туннелировать их далее. Данный IP-адрес может быть статический или может задаваться динамически какой-либо из технологий, аналогичных DHCP. Для поддержки второго варианта существует механизм, дающий возможность Инициатору запрашивать IP-адрес, принадлежащий межсетевому экрану для использования с SA, создаваемой в локальной сети.

Другие топологии

Возможны также другие топологии. Например, возможно использова-ние совместно с IPSec других протоколов туннелирования, таких как GRE или L2TP.

Степень детализации управления трафиком

IPSec позволяет управлять детализацией, с которой предоставляется сервис безопасности. Например, можно создать единственный зашифрованный туннель между двумя локальными сетями, или для каждого ТСР- и UDP-соединения может быть создан отдельный зашифрованный туннель между парой хостов. IPSec позволяет указывать следующие параметры:

  1. Необходимый уровень детализации применяемой защиты. Следует заметить, что сильно детализированные SA обычно являются более уязвимыми для анализа трафика, чем слабо детализированные.

    Пример веб-интерфейса для указания степени детализации создания SA


    Рис. 7.8.  Пример веб-интерфейса для указания степени детализации создания SA

  2. Используемые алгоритмы в протоколах обеспечения безопасности IP-трафика.

    Пример веб-интерфейса для указания требуемых алгоритмов в протоколах защиты трафика


    Рис. 7.9.  Пример веб-интерфейса для указания требуемых алгоритмов в протоколах защиты трафика

  3. Используемые алгоритмы в протоколах управления SA.

    Пример веб-интерфейса для указания требуемых алгоритмов в протоколах управления SA


    Рис. 7.10.  Пример веб-интерфейса для указания требуемых алгоритмов в протоколах управления SA

Протокол ESP

Обзор

Протокол ESP разработан для обеспечения возможности использования нескольких сервисов безопасности в IPv4 и IPv6.

ESP-заголовок вставляется после IP-заголовка и перед заголовком протокола более высокого уровня (транспортный режим) или перед инкапсулированным IP-заголовком (туннельный режим).

ESP используется для обеспечения конфиденциальности, аутентификации данных, целостности соединения и анти-replay сервиса (обеспечение целостности некоторой последовательности дейтаграмм).

Формат пакета ESP

Заголовок протокола (IPv4, IPv6 или Extension), непосредственно предшествующий ESP, содержит значение 50 в поле Protocol (IPv4) или Next Header (IPv6, Extension).

Пример вложенности ESP-пакета


Рис. 7.11.  Пример вложенности ESP-пакета

Формат ESP-пакета


Рис. 7.12.  Формат ESP-пакета

Данные (Payload Data)

Payload Data является полем переменной длины, содержащим данные протокола, расположенного выше в стеке, который указан в поле Next Header. Длина данного поля равна целому числу байтов. Если алгоритм, используемый для шифрования, требует криптографически синхронизованных данных, например инициализационный вектор IV, то эти данные также содержатся в этом поле.

Добавление (Padding)

Использование поля Padding объясняется несколькими факторами.

Длина добавления (Pad Length)

Поле Pad Length указывает число байтов добавления, которые непосредственно следуют за ним.

Следующий заголовок (Next Header)

Next Header является 8-битовым полем, которое указывает тип данных, содержащихся в поле Payload Data, например, заголовок Extension в IPv6 или идентификатор протокола более высокого уровня. Значение данного поля выбирается из множества IP Protocol Number, определяемого IANA.

Аутентификационные данные (Authentication Data)

Authentication Data является полем переменной длины, содержащим значение проверки целостности (Integrity Check Value – ICV), вычисленное для ESP-пакета, за исключением самого поля Authentication Data. Длина поля определяется выбранным алгоритмом аутентификации. Поле Authentication Data является необязательным и включается в том случае, если используется сервис аутентификации.

Обработка трафика, выполняемая ESP

Рассмотрим расположение заголовка ESP относительно заголовков других протоколов.

Протокол ESP может использоваться в двух режимах: в транспортном режиме и туннельном. Первый режим применяется в основном для создания VPN между двумя хостами и обеспечивает защиту для протоколов более высокого уровня, но не для заголовка IP. Заметим, что в данном режиме для "bump-in-the-stack" и "bump-in-the-wire" реализаций может потребоваться реассемблирование входящих и исходящих IP-фрагментов.

В транспортном режиме ESP-заголовок расположен после IP-заголовка и перед заголовком протокола более высокого уровня, например, ТСР, UDP, ICMP и т.д. Следующие рисунки показывают добавление заголовков в транспортном режиме ESP для типичного IPv4 пакета.

Вложенность заголовков до применения ESP в транспортном режиме в IPv4


Рис. 7.13.  Вложенность заголовков до применения ESP в транспортном режиме в IPv4

Вложенность заголовков после применения ESP в транспортном режиме в IPv4


Рис. 7.14.  Вложенность заголовков после применения ESP в транспортном режиме в IPv4

В протоколе IPv6 ESP рассматривается как end-to-end содержимое, и таким образом оно должно появляться после hop-by-hop, routing и fragmentation заголовков расширения. Заголовки параметров назначе-ния могут появляться как до, так и после ESP заголовка, в зависимости от требуемой семантики. Однако, так как ESP защищает только поля после ESP-заголовка, обычно требуется размещение заголовков опций назначения после ESP-заголовка. Следующие рисунки иллюстрируют добавление заголовков в транспортном режиме ESP для типичного IPv6-пакета.

Вложенность заголовков до применения ESP в транспортном режиме в IPv6


Рис. 7.15.  Вложенность заголовков до применения ESP в транспортном режиме в IPv6

Вложенность заголовков после применения ESP в транспортном режиме в IPv6


Рис. 7.16.  Вложенность заголовков после применения ESP в транспортном режиме в IPv6

* - если присутствует, то может быть до ESP, после ESP или и так, и так.

Туннельный режим ESP может быть реализован как на хостах, так и на шлюзах безопасности. При использовании ESP на шлюзе безопасности для защиты транзитного трафика должен применяться туннельный режим. В туннельном режиме внутренний IP-заголовок содержит конечные адреса источника и получателя, а внешний IP-заголовок содержит IP-адреса шлю-зов безопасности. В туннельном режиме ESP защищает весь внутренний IP-пакет, включая весь внутренний IP-заголовок. Расположение ESP в тун-нельном режиме относительно внешнего IP-заголовка является тем же са-мым, что и для транспортного режима. Следующие рисунки иллюстрируют добавление заголовков в туннельном режиме ESP для типичных IPv4- и IPv6-пакетов.

Вложенность заголовков после применения ESP в туннельном режиме в IPv4


Рис. 7.17.  Вложенность заголовков после применения ESP в туннельном режиме в IPv4

Вложенность заголовков после применения ESP в туннельном режиме в IPv6


Рис. 7.18.  Вложенность заголовков после применения ESP в туннельном режиме в IPv6

Алгоритмы

Определены алгоритмы, обязательные для реализации. Кроме них дополнительно могут быть реализованы и другие алгоритмы.

1. Алгоритмы шифрования

Алгоритмы шифрования определяются при создании SA и применяются для шифрования данных, передаваемых по SA. В протоколе ESP используются симметричные алгоритмы шифрования. Так как IP-пакеты могут приходить в любом порядке, каждый пакет должен содержать всю инфор-мацию, необходимую Получателю для расшифрования. Эти данные, например инициализационный вектор (IV), могут передаваться явно в поле содержимого или они могут быть получены из заголовка пакета.

2. Алгоритмы аутентификации (обеспечения целостности)

Алгоритм аутентификации, используемый для вычисления Integrity Check Value (ICV), определяется при создании SA. Для вычислений точка-точка соответствующие алгоритмы аутентификации используют МАС с ключом, основанный на симметричных алгоритмах шифрования (например, DES) или на односторонних хэш-функциях (например, MD5 или SHA-1). Для многоадресных соединений односторонние хэш-функции используются вместе с асимметричными алгоритмами создания цифровой подписи.

Обработка исходящего пакета

В транспортном режиме Отправитель инкапсулирует информацию протокола верхнего уровня в ESP-заголовок и сохраняет без изменения IP-заголовок (и любые IP-заголовки расширения в протоколе IPv6). В туннельном режиме внешний и внутренний IP-заголовки могут по-разному соотноситься друг с другом.

1. Поиск подходящей SA

ESP применяется к исходящему пакету после того, как определено, какой SA принадлежит пакет.

2. Шифрование пакета

Отправитель выполняет следующие действия:

Первым выполняется шифрование, затем выполняется аутентификация (обеспечение целостности), поэтому поле Authentication Data не за-шифровано. Такой порядок обработки дает возможность Получателю быстро обнаружить и отбросить повторные или фиктивные пакеты, что потенциально снижает вероятность успешного выполнения DoS-атак. Это также допускает возможность параллельной обработки пакетов Получате-лем, например, расшифрование может выполняться одновременно с проверкой целостности. Заметим, что, так как Authentication Data не защищено шифрованием, для вычисления ICV должен применяться алгоритм обеспечения целостности с ключом.

3. Вычисление Sequence Number

Первый пакет, посылаемый по заново созданной SA, имеет Sequence Number, равный 1.

Если используется анти-replay сервис, отправитель проверяет, что значение счетчика не переполнилось перед созданием нового значения в поле Sequence Number. Другими словами, отправитель не должен посылать пакет по SA, если возникает переполнение Sequence Number.

Отправитель повторяет пакет, если он не получил уведомления о его получении. Если счетчик переполнился, отправитель должен установить новую SA и вычислить новые ключи.

4. Вычисление значения проверки целостности

Если для SA требуется обеспечение целостности, Отправитель вычисляет ICV для всего ESP-пакета, за исключением поля Authentication Data. Таким образом, для полей SPI, Sequence Number, Payload Data, Padding (если присутствует) и Next Header вычисляется ICV. Заметим, что последние четыре поля являются зашифрованными, так как шифрование выполняется до вычисления ICV.

Для некоторых алгоритмов обеспечения целостности строка байтов, для которой вычисляется ICV, должна быть кратна длине блока выбранного алгоритма. Если длина данной строки байтов не соответствует требуемой длине блока, то должно выполняться добавление в конец ESP-пакета (после поля Next Header) до вычисления ICV. Октеты добавления должны иметь нулевые значения. Длина блока (и, следовательно, длина добав-ления) определяются из спецификации алгоритма. Данное добавление не передается вместе с пакетом.

5. Фрагментация

После описанных выше ESP-преобразований при необходимости может выполняться фрагментация пакета. Таким образом, транспортный режим ESP применяется только к целым IP-дейтаграммам (не к фрагментам IP). Входящий IP-пакет, для которого должно выполняться ESP-преобразование, может сам быть фрагментирован маршрутизаторами, и таким образом фрагменты должны реассемблироваться перед ESP-преобразованием на стороне Получателя.

Для транспортного режима bump-in-the-stack и bump-in-the-wire реализации могут, во-первых, реассемблировать пакет, фрагментированный локальным IP-уровнем, затем применять IPSec и затем снова фрагментировать получившейся пакет.

Обработка входящего пакета

Реассемблирование

Если требуется реассемблирование, то оно выполняется до ESP-обработки.

Поиск подходящей SA

При получении пакета, содержащего ESP-заголовок, Получатель определяет подходящую однонаправленную SA, просматривая SAD. Для одноадресных SA это определяется на основе значения SPI в заголовке. В записи SAD указано, следует ли проверять последовательный номер. Также в записи SAD указаны алгоритмы и ключи, используемые для расшифрования.

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

Заметим, что трафик управления SA, такой как IKE-пакеты, не идентифицируются SPI.

Проверка последовательного номера

В основе анти-replay сервиса лежит проверка корректного значения последовательного номера. Получатель проверяет, что пакет содержит последовательный номер, который не является дубликатом последовательного номера другого пакета, полученного в данной SA. Такая проверка выполняется первой, после того как найдена соответствующая SA, чтобы как можно быстрее отбросить дублирующие пакеты.

Лекция 10. Соединение сетей протоколом IPSec в туннельном режиме, аутентификация с использованием общего секрета

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec. В этом случае необходимо использовать туннельный режим.

Топология сети



Между интерфейсами wan2 на МЭ 1и МЭ 2 требуется поднять VPN/IPSec.

Описание практической работы

Создать статическую маршрутизацию и политики доступа, которые разрешают доступ между удаленными локальными сетями. При этом трафик между МЭ 1 и МЭ 2 проходит по VPN/IPSec.

Межсетевой Экран 1

Аутентификационный Объект

Необходимо создать аутентификационный объект Pre-Shared Key.

Веб-интерфейс:

Object → Authentication Objects → Add → Pre-Shared Key



Командная строка:

add PSKforIPSec Type=ASCII PSKAscii=qwerty

IPSec-Интерфейс

Создать IPSec-интерфейс. Так как создается VPN-туннель между двумя локальными сетями, то необходим туннельный режим.

Веб-интерфейс:

Interfaces → IPsec → Add → IPsecTunnel

На вкладке General указать сети перед и за туннелем, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.



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

1. Статически создаваемый маршрут.

Если все остальные параметры оставить по умолчанию, то в таблице маршрутизации будет создан маршрут.



Командная строка:

add Interface IPsecTunnel 
ipsec_tunnel LocalNetwork=lan/lan_net RemoteNetwork=remote/rem_lan AuthMethod=PSK PSK=forIPSec IKEAlgorithms=Medium IPsecAlgorithms=Medium EncapsulationMode=Tunnel RemoteEndpoint=wan2/wan2_gw

2. Динамически создаваемый маршрут.

Веб-интерфейс:

Если инициатором начального установления туннеля всегда будет являться противоположная сторона, возможно динамически создавать маршрут. Для этого на вкладке Routing следует поставить флаг динамического добавления маршрута.



А на вкладке Advanced снять флаг добавления маршрута, чтобы в таблице маршрутизации при наличии IPSec-трафика не было двух одинаковых маршрутов.



Командная строка:

set Interface IPsecTunnel ipsec_tunnel 
AddRouteToRemoteNet=Yes AutoInterfaceNetworkRoute=No

В этом случае в таблице маршрутизации будет динамически создаваться маршрут.



Правила фильтрования

Определим правило, разрешающее исходящий трафик с локальной сети, расположенной за МЭ 1, на локальную сеть, расположенную за МЭ 2.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: ipsec_tunnel
Rules → IP Rules → ipsec_tunnel → Add



Командная строка:

add IPRuleFolder Name=ipsec_tunnel
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=ipsec_tunnel DestinationNetwork=remote/rem_lan Service=all_services Name=ipsec_out

Межсетевой Экран 2

Аутентификационный Объект

Необходимо создать аутентификационный объект Pre-Shared Key с тем же значением Shared Secret, что и на межсетевом экране 1.

Веб-интерфейс:

Object → Authentication Objects → Add → Pre-Shared Key



Командная строка:

add PSK forIPSec Type=ASCII PSKAscii=qwerty

IPSec-Интерфейс

Необходимо создать IPSec-интерфейс.

Веб-интерфейс:

Interfaces → IPsec → Add → IPsec Tunnel

На вкладке General указать сети перед и за туннелем, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.



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



А на вкладке Advanced снять флаг добавления маршрута (иначе в таблице маршрутизации при наличии IPSec-трафика будет два одинаковых маршрута, что не является ошибкой, но смысла не имеет).



Командная строка:

add Interface IPsecTunnel ipsec_tunnel LocalNetwork=lan/lan_net 
RemoteNetwork=remote/rem_lan AuthMethod=PSK PSK=forIPSec 
IKEAlgorithms=Medium IPsecAlgorithms=Medium 
EncapsulationMode=Tunnel RemoteEndpoint=wan2/wan2_gw

Правила фильтрования

Создаем правила фильтрования, разрешающие входящий трафик с удаленной локальной сети, приходящий на ipsec-туннель, к локальной сети, расположенной за МЭ 2.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: ipsec_tunnel
Rules → IP Rules → ipsec_tunnel → Add



Командная строка:

add IPRuleFolder Name=ipsec_tunnel
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=ipsec_tunnel SourceNetwork=remote/rem_lan 
DestinationInterface=lan DestinationNetwork=lan/lan_net Service=all_services Name=ipsec_in

Проверка конфигурации

1. На МЭ1 выполняем команду ping рабочей станции, располо-женной в удаленной локальной сети. В качестве интерфейса, с которого пакет будет отправлен, указывает lan.



2. На МЭ 1 проверяем наличие IKE SA и IPSec SA.





3. На МЭ 2 также проверяем наличие IKE SA и IPSec SA.

4. Можно также проверить наличие ISAKMP SA и ESP SA, сделав дамп трафика.



Лекция 11. Аутентификация по стандарту XAuth в протоколе IPSec

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec, используя туннельный ре-жим. Дополнительно выполнить аутентификацию на уровне пользователя по стандарту XAuth в Фазе II IKE (Quick Mode). БД пользовательских учет-ных записей хранится локально на МЭ 2. На МЭ 1 указывается имя пользователя и пароль.

Топология сети



Описание практической работы

Межсетевой Экран 1

IPSec-Интерфейс

В созданный ранее ipsec-интерфейс на вкладке XAuth добавить имя пользователя и пароль.

Веб-интерфейс:

Interfaces → IPsec → ipsec



Командная строка:

set Interface IPsecTunnel ipsec_tunnel XAuth=PassToPeerGateway XAuthUsername=olga XAuthPassword=qwerty

Межсетевой Экран 2

IPSec-Интерфейс

В созданный ранее ipsec-интерфейс на вкладке XAuth добавить требование аутентификации пользователя.

Веб-интерфейс:

Interfaces→IPsec→IPSec_tunnel



Командная строка:

set Interface IPsecTunnel ipsec_tunnel XAuth=RequiredForInbound

Аутентификация на уровне пользователя

Создать локальную БД пользователей и пользователя с тем же именем и паролем, которые были указаны на вкладке XAuth Межсетевого Экрана 1.

Веб-интерфейс:

User Authentication → Local User Databases → Add → Local User Database





Командная строка:

add LocalUserDatabase ipsec_users
add User olga Password=qwerty 

Создать правило аутентификации пользователей.

Веб-интерфейс:

User Authentication → User Authentication Rules → Add → User Authentication Rule

На вкладке General указать тип используемой базы данных, для како-го протокола используется аутентификация и IP-адрес удаленного физического интерфейса.



На вкладке Authentication Options указать локальную базу данных.



Командная строка:

add UserAuthRule AuthSource=Local OriginatorIP=wan2/wan2_gw LocalUserDB=ipsec_users Agent=XAuth Name=ipsec_rules

Проверка конфигурации

На МЭ 1 выполнить команду ikesnoop, которая позволяет отслеживать состояние IKE SA.



Выполнить команду ping на хосте, расположенный в удаленной локальной сети.



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



Проверить, что ikesnoop показывает наличие mode CFG и атрибутов XAuth.





При использовании аутентификации по стандарту XAuth инициатором создания соединения всегда должна быть аутентифицируемая сторона (в нашем случае МЭ 1). В этом случае Инициатор до выполнения Quick mode использует CFG mode для передачи имени пользователя и пароля (транзакции 4 и 5), и только после этого выполняется Quick mode (транзакции 6). Если инициатором установления соединения является аутенти-фицирующая сторона (в нашем случае МЭ 2), то после Main/Aggressive mode сразу начинает выполняться Quick mode, и аутентификации на уровне пользователя не происходит. В дальнейшем установленные таким образом SA могут использоваться аутентифицируемой стороной без выполнения IKE с CFG mode и, соответственно, без аутентификации пользователя. Для предотвращения этого на аутентифицирующей стороне не следует использовать правила фильтрования, разрешающие установление соединения с аутентифицирующей стороны.

Лекция 12. Политика безопасности

IPSec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP-трафика. Защита основана на требованиях, определенных в базе данных политики безопасности (SPD), которая создается администратором.

Для каждого пакета может быть выполнено одно из трех действий:

  1. Пакет отбрасывается.
  2. Пакет пропускается без изменения.
  3. Пакет обрабатывается сервисом IPSec, основываясь на соответствующей политике.

База данных политик безопасности (SPD)

Многие детали, связанные с обработкой IP-трафика в протоколах IPSec не являются предметом стандартизации. Тем не менее, для обеспечения интероперабильности IPSec некоторые внешние аспекты обработки стандартизованы. Рассмотрим общие принципы, на которых основана SPD.

SPD задается для каждого интерфейса, на котором необходима IPSec-обработка.

На хосте с поддержкой IPSec по крайней мере для одного сетевого ин-терфейса должна быть определена SPD. Шлюз безопасности всегда имеет по крайней мере два сетевых интерфейса, но сетевой интерфейс, подклю-ченный к локальной сети, может не поддерживать IPSec, поэтому для шлю-за безопасности также может требоваться только одна SPD. Однако если хост или шлюз безопасности имеет несколько сетевых интерфейсов, на которых будут использоваться протоколы IPSec, необходимо иметь отдельные SPD для каждого сетевого интерфейса.

Параметры SA определяются в SPD, которая описывает сервисы, при-меняемые к IP-дейтаграммам.

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

Шлюз безопасности часто обладает как функциональностями IPSec, так и функциональностями межсетевого экрана. Поэтому правила фильтрования могут указываться как для IPSec-трафика, так и для не-IPSec-трафика. В этом случае используются принципы, которые применяются при создании правил фильтрования межсетевого экрана:

  1. По умолчанию трафик запрещен.
  2. Правила упорядочены. Применяется первое правило в списке, параметрам которого соответствует пакет.

Каждая реализация IPSec имеет пользовательский интерфейс, который позволяет администратору задавать SPD, т.е. указывает обработку, применяемую к входящему или исходящему пакету. Для указания детализированности (гранулированности) обработки трафика возможно использование символа "*" в различных полях селектора, чтобы указать, что все пакеты для одного UDP- или ТСР-соединения соответствуют одной записи SPD.

SPD содержит упорядоченный список записей политики. Записи SPD указываются вместе с правилами межсетевого экрана.

Пример описания в SPD конечных точек IPSec


Рис. 8.1.  Пример описания в SPD конечных точек IPSec

Задание правил фильтрования для IPSec-трафика


Рис. 8.2.  Задание правил фильтрования для IPSec-трафика

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

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

Селектор на сеть:

Пример селектора на сеть


Рис. 8.3.  Пример селектора на сеть

Селектор на хост:

Пример селектора на хост


Рис. 8.4.  Пример селектора на хост

Селектор на порт (отдельное приложение):

Пример селектора на порт


Рис. 8.5.  Пример селектора на порт

Но при этом создается несколько SA:

SAD с несколькими SA между одними и теми же конечными точками


Рис. 8.6.  SAD с несколькими SA между одними и теми же конечными точками

SAD с несколькими SA между одними и теми же конечными точками


Рис. 8.7.  SAD с несколькими SA между одними и теми же конечными точками

База данных безопасной ассоциации (SAD)

База данных безопасной ассоциации (SAD)

В IPSec существует база данных безопасных ассоциаций, в которой каждая запись определяет параметры, связанные с установленной SA. Соответственно, каждая существующая SA имеет запись в SAD. Для исходящей обработки записи ссылаются на записи в SPD. Если при обработке очередного пакета обнаружено, что запись SPD не ссылается на SA в SAD, отсутствующая SA создается в SAD, и запись в SPD связывается с записью в SAD.

Следующие поля SAD используются для IPSec-обработки:

  1. Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в АН- или ESP-заголовках для исходящего трафика.
  2. Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызыватьсобытие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).
  3. Алгоритм обеспечения целостности, ключи и параметры.
  4. Алгоритм шифрования, ключи, режим, инициализационный вектор IV и т.д.
  5. Время жизни данной SA: интервал времени, после которого должна быть заменена SA на новую или старая SA должна быть завершена. Это может зависеть от времени существования SA или количества байтов, переданных по SA.

Способы аутентификации участников и распределение ключей

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

Распределение ключей вручную

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

Автоматическое создание SA и распределение ключей

Для обеспечения широкого использования IPSec требуется стандартный, масштабируемый протокол создания и управления SA. Такой протокол необходим для возможности автоматического создания SA.

Таким протоколом является протокол IKE.

Форматы сообщений в протоколе IKE

Основные понятия

В IKEv1 для описания форматов передаваемых сообщений используется стандарт, называемый "Безопасная ассоциация интернет и протокол управления ключом - Internet Security Association and Key Management Protocol (ISAKMP)". ISAKMP определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA.

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

В атрибутах SA, которые используются для определения параметров протоколов AH и ESP, как минимум, должны быть указаны способ аутентификации, криптографический алгоритм, режим алгоритма, длина ключа и инициализационный вектор (IV). Установление SA является частью протокола управления ключом.

Протокол IKE обеспечивает полную безопасность последующих обменов (Perfect Forward Secrecy - PFS). Это означает, что при компрометации одного ключа возможен только доступ к данным, защищенным этим одним ключом.

Транспортный протокол: IKE может быть реализован поверх UDP или поверх IP. Производители посылают и получают IKE-сообщения протокола, используя UDP-порт 500. Этот UDP-порт зарезервирован для IKE в IANA. Производители могут дополнительно поддерживать IKE поверх других транспортных протоколов или поверх IP.

В протоколе IKE определены следующие понятия:

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

Содержимое (Payload): Определены различные типы содержимого, которые используются в сообщениях протокола. В одном сообщении может быть послано несколько содержимых.

Тип обмена (Exchange Type): тип обмена определяет число сообщений в протоколе и типы содержимого, которые содержатся в каждом из этих сообщений. Определено стандартное множество типов обмена. При необходимости могут быть добавлены другие типы для поддержки дополнительных сервисов.

В IKE существует две фазы переговоров. Во время первой фазы два участника, которые называются IKE/ISAKMP-серверами, договариваются о том, как защищать дальнейший трафик управления SA, устанавливая IKE SA. Эта IKE SA затем используется для защиты создания требуемой SA.

Вторая фаза переговоров используется для установления SA для протокола АН или ESP. При этом во второй фазе может быть установлено несколько безопасных ассоциаций.

Хотя подход, основанный на двух фазах, является достаточно дорогостоящим в самых простых сценариях, во многих случаях он себя оправдывает.

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

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

Сервисы безопасности в протоколе IKE

Защита от DoS-атак

Защита от DoS-атак является одной из наиболее трудно решаемых задач. Обмены, в которых присутствуют операции с открытым ключом, интенсивно используют ЦП. Для защиты от DoS-атак, которые направлены на интенсивное использование вычислительных ресурсов, могут использоваться "Cookie" или Anti-Clogging Token (ACT). Использование таких Cookie может препятствовать некоторым попыткам DoS-атак, которые состоят в простом наводнении пакетами (flooding-атаки). Абсолютная защита от DoS-атак невозможна, но такие Cookie обеспечивают возможность более быстрого ее определения.

Следует заметить, что такие Cookie должны использоваться вместе с механизмом сбора мусора, так как атакующий может завалить сервер, используя пакеты с поддельными IP-адресами.

Защита от атак подделки одной из сторон

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

Защита от атак man-in-the-middle

Атаки man-in-the-middle могут состоять в перехвате, вставке, уничтожении и модификации сообщений, в отражении сообщений обратно отправителю, повторе старых сообщений и перенаправлении сообщений. Протокол IKE предотвращает все эти типы атак. Для всех сообщений IKE обеспечивается целостность и аутентификация источника, что предотвращает от возможности любых модификаций сообщений. Создание новых Cookie для каждого нового установления SA предотвращает атаки, которые состо-ят в повторе старых сообщений. Выполнение сильной аутентификации предотвращает установление SA с кем-либо, кроме требуемого участника.

Идентификация SA

Идентификация IKE SA отличается от идентификации ESP SA или AH SA. Для идентификации SA на разных этапах установления SA используются разные поля: два поля Cookie и поле Message ID в заголовке IKE используются для идентификации IKE SA на разных стадиях установления SA. Поле SPI, определяемое в содержимом Proposal, в дальнейшем используется для идентификации SA в протоколах ESP и АН.

В следующей таблице показано наличие перечисленных полей при установлении SA. "0" означает, что значение отсутствует, "X" означает, что значение присутствует, "NA" означает, что значение не используется в данной стадии установления SA.

Способы идентификации IKE SA в протоколе IKE


Рис. 8.8.  Способы идентификации IKE SA в протоколе IKE

В первом сообщении Инициатор указывает Initiator Cookie в заголовке IKE (см первую строчку таблицы).

Начальное сообщение с Cookie Инициатора


Рис. 8.9.  Начальное сообщение с Cookie Инициатора

Во втором сообщении Получатель включает поля Initiator и Responder Cookie в заголовок IKE (см вторую строчку таблицы).

Ответное сообщение с Cookie Инициатора и Получателя


Рис. 8.10.  Ответное сообщение с Cookie Инициатора и Получателя

Взаимодействующие стороны могут обмениваться дополнительными сообщениями в зависимости от типа обмена, используемого в первой фазе переговоров. В течение первой фазы переговоров Cookies Инициатора и Получателя включаются в заголовок IKE всех обменов и определяют IKE SA. Поле SPI в содержимом Proposal установлено в 0 или может содер-жать Сookie взаимодействующих участников.

После завершения I фазы Инициатор определяет Message ID для протоколов, которые будут выполняться в данной SA. Этот Message ID Инициатора указывается для каждого протокола.

Идентификация SA по Message ID в Quick Mode


Рис. 8.11.  Идентификация SA по Message ID в Quick Mode

SPI будут использоваться для идентификации SA только после завершения второй фазы переговоров (см шестую строчку таблицы).

Формат сообщений

Наличие и последовательность содержимых в сообщении определяется полем Exchange Type.

1. Формат заголовка ISAKMP/IKE

Сообщение IKE имеет фиксированный формат заголовка, за которым следует переменное число содержимых. Этот заголовок содержит информацию, необходимую для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.

В IKE-заголовке определены следующие поля:

2. Общий заголовок содержимого

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

Общий заголовок содержимого


Рис. 8.16.  Общий заголовок содержимого

Поля общего заголовка содержимого определяются следующим образом:

3. Атрибуты данных

Существует несколько случаев, когда должны быть переданы атрибуты данных. Примером этого являются атрибуты SA в содержимом Transform. Эти атрибуты данных не являются отдельным содержимым, а присутствуют в других содержимых. Формат атрибутов данных обеспечивает гибкость представления различных типов информации.

Атрибуты данных


Рис. 8.17.  Атрибуты данных

Поля атрибутов данных определяются следующим образом:

4. Содержимое SA

Содержимое SA используется для выбора алгоритмов, которые будут применяться для защиты трафика. Содержимым SA может быть несколько сообщений Proposal.

В содержимое SA также указано DOI и Situation, при котором ведутся переговоры.

Содержимое SA


Рис. 8.18.  Содержимое SA

5. Содержимое Proposal

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

Содержимое Proposal


Рис. 8.19.  Содержимое Proposal

Пример Proposal


Рис. 8.20.  Пример Proposal

Proposal # определяет номер Proposal для текущего содержимого.

Protocol-Id определяет идентификатор протокола. Примерами являются IKE, ESP, AH.

SPI Size - длина SPI. В случае протокола IKE пара Сookie Инициатора и Получателя из заголовка идентифицируют IKE, следовательно, SPI Size не имеет значения и может быть от нуля до 16.

# of Transforms определяет количество преобразований для Proposal. Каждое из них указано в содержимом Transform.

6. Содержимое Transform

Содержимое Transform состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности соединения. Transform также может содержать атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты определяются DOI.

Содержимое Transform


Рис. 8.21.  Содержимое Transform

7. Содержимое Key Exchange

Содержимое Key Exchange поддерживает различные технологии обмена ключа. Примерами обменов ключа являются обмен ключа Диффи-Хеллмана, расширенный обмен ключа Диффи-Хеллмана или обмен ключа на основе RSA.

Содержимое Key Exchange


Рис. 8.22.  Содержимое Key Exchange

8. Содержимое Identification

В содержимом Identification представлены идентификационные данные.

Содержимое Identification


Рис. 8.23.  Содержимое Identification

9. Содержимое Certificate

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

Содержимое Certificate


Рис. 8.24.  Содержимое Certificate

Certificate Encoding - данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data.

Certificate Data - конкретное представление данных сертификата. Тип сертификата определяется полем Certificate Encoding.

10. Содержимое Certificate Request

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

 Содержимое Certificate Request


Рис. 8.25.  Содержимое Certificate Request

Certificate Authority содержит список сертификационных центров, открытые ключи которых есть у принимающей стороны. Например, для сертификата Х.509 оно должно содержать DN CA, принимаемого Инициатором. Это должно помочь Получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос. Если требуемый корневой сертификационный центр не важен, данное поле отсутствует.

11. Содержимое Hash

Hash содержит данные, создаваемые хэш-функцией (определенной при установлении SA), которая вычисляется для некоторой части сообщения и/или состояния протокола. Данное содержимое может использоваться для проверки целостности данных в IKE-сообщении или для аутентификации участников протокола.

Содержимое Hash


Рис. 8.26.  Содержимое Hash

12. Содержимое Signature

Signature содержит данные, созданные функцией создания цифровой подписи (выбранной во время установления SA) для некоторой части сообщения и/или состояния протокола. Данное содержимое используется для аутентификации отправителя и проверки целостности данных в IKE-сообщении и может быть использовано для сервисов невозможности отказа.

 Содержимое Signature


Рис. 8.27.  Содержимое Signature

13. Содержимое Nonce

Nonce содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. Nonce могут передаваться как часть данных обмена ключа или как отдельное содержимое.

Содержимое Nonce


Рис. 8.28.  Содержимое Nonce

14. Содержимое Notification

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

 Содержимое Notification


Рис. 8.29.  Содержимое Notification

Notification, которые посылаются фазе I переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE. Идентификатором протокола в данном случае является IKE, значение SPI равно 0. Если Notification передается до обмена ключевой информацией, то оно не будет защищено.

Notification, которые передаются во время фазы II переговоров, идентифицируются парой Cookie Инициатора и Получателя в заголовке IKE, а также Message ID и SPI, если они определены на данной стадии протокола.

Protocol-Id определяет идентификатор протокола для данного уведомления. Примерами протокола являются IKE, ESP, AH.

SPI Size - длина SPI в октетах как определено в Protocol-Id. В случае IKE пара Cookie Инициатора и Получателя из заголовка IKE выполняют функции IKE SPI, следовательно, SPI Size не имеет значения и может быть от 0 до 16.

Notify Message Type определяет тип сообщения уведомления. Дополнительная информация размещается в поле Notification Data.

15. Содержимое Delete

Delete содержит идентификатор SA, которую Инициатор удаляет из своей SAD. Возможна посылка нескольких SPI в одном Delete, однако каждый SPI должен быть предназначен для того же самого протокола. Нескольких идентификаторов протоколов в Delete быть не может.

Содержимое Delete


Рис. 8.30.  Содержимое Delete

Удаление, которое относится к IKE SA, содержит в качестве идентификатора протокола IKE, в качестве SPI указываются Cookies Инициатора и Получателя из заголовка IKE. Удаление, которое выполняется для таких протоколов, как ESP или АН, будет содержать идентификатор этого протокола (т.е. ESP, AH), и SPI SA.

# of SPIs - количество SPI, содержащихся в Delete. Размер каждого SPI определяется полем SPI Size

Security Parameter Index - идентификаторы, определяющие удаляемые безопасные ассоциации.

Протокол IKE

Будем использовать следующие обозначения.

HDR – заголовок сообщения. Запись HDR* означает, что одержимое сообщения зашифровано.

SA – сообщение SA, которое содержит один или более Proposal. Инициатор посылает несколько Proposal, упорядоченных в соответствии со своим приоритетом. Получатель должен выбрать только один Proposal.

CKY-I и CKY-R есть Cookie Инициатора и Получателя соответственно.

gXi и gXr – открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно.

КЕ – сообщение обмена ключа, т.е. открытые значения, которыми обмениваются в алгоритме Диффи-Хеллмана.

Nx – сообщение Nonce; x может быть i или r для Инициатора и Получателя соответственно.

IDx – содержимое идентификации для х. Х может быть ii или ir для Инициатора и Получателя во время фазы I; или ui или ur для Инициатора и Получателя во время фазы II.

SIG – сообщение подписи. Подписываемые данные зависят от типа обмена.

CERT – сообщение, содержащее сертификат.

HASH (HASH(2)или HASH_I) – сообщение, содержащее хэш данных, которые зависят от способа аутентификации.

PRF (key, msg) – псевдослучайная функция. Чаще всего используется хэш-функция с ключом, результатом которой является значение, которое удовлетворяет требованиям к случайным числам. PRF используется как для получения ключа, так и для аутентификации участников при использовании аутентификации по общему секрету.

SKEYID – значение, полученное из секрета и известное только участникам обмена.

SKEYID_e – ключ, используемый для обеспечения конфиденциальности сообщений.

SKEYID_а – ключ, используемый для проверки целостности сообщений.

SKEYID_d – ключ, используемый для получения ключей для безопасных ассоциаций, создаваемых в фазе II, т.е. АН SA и ESP SA.

Обзор протокола

Протокол IKE имеет две фазы, в каждой из которых может быть выполнено несколько обменов.

В результате фазы I участники устанавливают защищенный канал, который называется IKE SA. В фазе I определено два режима: Main Mode и Aggressive Mode.

Фаза II начинается после установления IKE SA. Для второй фазы обмена определен режим Quick Mode.

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

Участники фазы I договариваются о следующих параметрах.

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

Группа Диффи-Хеллмана определяется по номеру.

Задание группы Диффи-Хеллмана


Рис. 8.31.  Задание группы Диффи-Хеллмана

Обмены

Существует два режима, используемых в фазе I: Main Mode и Aggressive Mode. В обоях случаях создается аутентифицированный ключевой материал, полученный из обмена открытыми значениями алгоритма Диффи-Хеллмана. В фазе II используется Quick Mode для создания нового материала ключа и ведения переговоров о AH SA или ESP SA.

Первым посылается сообщение SA.

Открытое значение Диффи-Хеллмана передается в содержимом КЕ в фазе I, оно может передаваться в фазе II обмена, если требуется PFS. Длина открытого значения Диффи-Хеллмана определяется в сообщении SA.

Main Mode обеспечивает защиту идентификаций. В первых двух сообщениях договариваются об используемых алгоритмах; в следующих двух сообщениях обмениваются открытыми значениями Диффи-Хеллмана и случайными значениями; последние два сообщения аутентифицируют обмен Диффи-Хеллмана. Метод аутентификации определяется при переговорах в первых сообщениях и влияет на последовательность сообщений.

В первых двух сообщениях Aggressive Mode договариваются об используемых алгоритмах, обмениваются открытыми значениями Диффи-Хеллмана, случайными значениями и идентификациями. Второе сообщение аутентифицирует Получателя. Третье сообщение аутентифицирует Инициатора.

Определено два метода аутентификации как для Main Mode, так и для Aggressive Mode - цифровая подпись и предварительно распределенный секрет.

Значение SKEYID для каждого метода аутентификации вычисляется по своему алгоритму.

Для подписей:

SKEYID = PRF (Ni | Nr, gxy)

Для предварительно распределенного секрета:

SKEYID = PRF (pre-shared-key, Ni | Nr)

Результатом как Main Mode, так и Aggressive Mode являются три ключа:

SKEYID_d = PRF (SKEYID, gxy | CKY-I | CKY-R|0)
SKEYID_a = PRF (SKEYID, SKEYID_d | gxy | CKY-I | CKY-R|1)
SKEYID_e = PRF (SKEYID, SKEYID_a | gxy | CKY-I | CKY-R|2)

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

Для проверки целостности обмена и аутентификации участников Инициатор вычисляет HASH_I, и Получатель создает HASH_R, где:

HASH_I = PRF (SKEYID, gXi | gXr | CKY-I | CKY-R |SAi|IDii)
HASH_R = PRF (SKEYID, gXr | gXi | CKY-R | CKY-I |SAi|IDir)

При аутентификации с помощью цифровых подписей HASH_I и HASH_R подписаны; при аутентификации предварительно распределенным секретом HASH_I и HASH_R непосредственно аутентифицируют обмен.

Метод аутентификации влияет на последовательность сообщений и использование сообщений в фазе I.

Фаза I с аутентификацией с помощью подписей

Последовательность сообщений в Main Mode с аутентификацией с помощью подписей следующая:

Main Mode с аутентификацией с помощью цифровых подписей


Рис. 8.32.  Main Mode с аутентификацией с помощью цифровых подписей

Последовательность сообщений в Aggressive Mode с аутентификацией с помощью подписей следующая:

Aggressive Mode с аутентификацией с помощью цифровых подписей


Рис. 8.33.  Aggressive Mode с аутентификацией с помощью цифровых подписей

В обоих режимах подписи SIG_I или SIG_R выполняются для HASH_I и HASH_R соответственно.

Фаза I с аутентификацией по предварительно распределенному секрету

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

Когда выполняется аутентификация по предварительно распределенному секрету, последовательность сообщений в Main Mode следующая:

Main Mode с аутентификацией по предварительно распределенному секрету


Рис. 8.34.  Main Mode с аутентификацией по предварительно распределенному секрету

В Aggressive Mode с аутентификацией по предварительно распределенному секрету последовательность сообщений следующая:

Aggressive Mode с аутентификацией по предварительно распределенному секрету


Рис. 8.35.  Aggressive Mode с аутентификацией по предварительно распределенному секрету

При использовании аутентификации по предварительно распределенному секрету в Main Mode ключ может идентифицироваться только по IP-адресу противоположной стороны, так как HASH_I вычисляется до того, как Инициатор получит IDir.

Фаза II – Quick Mode

Quick Mode сам по себе законченным обменом не является. Это означает, что он связан с фазой I обмена, так как использует ключи, вычисленные на фазе I. Сообщения, которыми обмениваются в Quick Mode, зашифрованы алгоритмами и ключами, определенными в фазе I, т.е. все сообщения, за исключением заголовка будут зашифрованы. Первое сообщение HASH проверяет, что соединение не сброшено и аутентифицирует участников.

Quick Mode выполняет переговоры об SA и обменивается Nonce, которые обеспечивают защиту от повторов. Nonce используются для создания нового материала ключа и предотвращения replay-атак, в результате которых могут быть созданы ложные SA. Можно произвести обмен дополнительным сообщением KE, чтобы для SA, созданной на фазе II, полностью обновить ключи.

Базовый Quick Mode (без содержимого KE) вычисляет ключи, из клю-чевого материала, созданного в фазе I. Считается, что это хуже, так как не обеспечивается PFS. При использовании дополнительного сообщения KE ключи полностью обновляются.

При Quick Mode последовательность сообщений следующая:

 Quick Mode


Рис. 8.36.  Quick Mode

HASH(1)вычисляется PRF для поля Message-ID (M-ID) из заголовка, присоединенного ко всему сообщению.

HASH(2)вычисляется аналогично HASH(1). Включение Nonce как Инициатора, так и Получателя в HASH(2)сделано для того, чтобы подтвердить жизнеспособность SA.

HASH (3) также вычисляется для доказательства жизнеспособности.

HASH(1) = PRF (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | Idcr ])
HASH(2) = PRF (SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDci | Idcr ])
HASH (3) = PRF (SKEYID_a, 0 | M-ID | Ni | Nr)

Если политика не требует PFS, т.е. обмен сообщениями KE не выполняется, то новый материал ключа вычисляется следующим образом:

KEYMAT = PRF (SKEYID_d, protocol | SPI | Ni | Nr)

Если PFS требуется, и участники обмениваются содержимым KE, то новый материал ключа вычисляется следующим образом:

KEYMAT = PRF (SKEYID_d, g (qm)xy | protocol | SPI | Ni | Nr)

Где g (qm)xy является разделяемым секретом из последнего обмена Диффи-Хеллмана, выполненного в Quick Mode.

Значения Protocol и SPI берутся из сообщения Proposal из Quick Mode.

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

KEYMAT = K1 | K2 | K3 | …

Где

K1 = PRF (SKEYID_d, [g (qm)xy | ] protocol | SPI |Ni| Nr)
K2 = PRF (SKEYID_d, K1 | [g (qm)xy |]protocol|SPI|Ni| Nr)
K3 = PRF (SKEYID_d, K2 | [g (qm)xy |]protocol|SPI|Ni| Nr)

В Quick Mode за один обмен можно договориться о создании нескольких SA:

Quick Mode с созданием нескольких SA


Рис. 8.37.  Quick Mode с созданием нескольких SA

Информационный обмен

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

Управляющие сообщения, которые относятся к IKE SA, должны быть посланы в IKE SA. Управляющие сообщения, которые относятся к ESP или АН SA, должны быть посланы под защитой IKE SA, под управлением которой они созданы.

Сообщения информационного обмена могут содержать несколько Notification, Delete и Configuration содержимых. Получатель запроса информационного обмена должен послать ответ, так как в противном случае Инициатор будет предполагать, что сообщение было потеряно, и будет повторять его.

Использование таймеров ретрансмиссии

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

IKE является надежным протоколом в том смысле, что Инициатор должен повторять запрос до тех пор, пока он не получит соответствующий ответ или он решит, что IKE SA упала, и он сбросит все состояния, связанные с ней и все дочерние SA для протоколов ESP и АН, созданные с использованием данной IKE SA.

Использование последовательных номеров для Message ID

Каждое сообщение IKE содержит в заголовке Message ID. Данный Message ID используется для идентификации сообщений в протоколе IKE.

Заметим, что Message ID криптографически защищен, и обеспечивается защита против повторных сообщений.

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

Синхронизация состояния и таймауты соединения

Состояния IKE SA и связанных с ней AH SA и ESP SA могут быть в любой момент потеряны. Это обычно происходит в случае останова или перезапуска конечной точки. Важно, что когда происходит сбой конечной точки или повторная инициализация ее состояния, то противоположная конечная точка должна иметь возможность определить эту ситуацию и не продолжать бессмысленную посылку пакетов по разрушенной SА.

Так как IKE разрабатывался для противодействия DoS-атакам, конечная точка не должна делать вывод о падении противоположной конечной точки, основываясь на какой-либо информации маршрутизации (например, ICMP-сообщениях) или IKE-сообщениях, которые были получены без криптографической защиты (например, Notify-сообщения, уведомляющие о проблемах неизвестных SPI). Конечная точка должна делать вывод, что другая конечная точка упала только тогда, когда она не получает ответа за определенный период на повторные попытки связаться или когда получено криптографически защищенное уведомление INITIAL_CONTACT по другой IKE SA для той же самой аутентифицированной идентификации. Конечная точка может подозревать, что на противоположной стороне произошел сбой, основываясь на информации маршрутизации, и инициировать запрос, который бы показал ей, что данная конечная точка жизнеспособна. Для проверки жизнеспособности другой стороны определено пустое INFORMATIONAL сообщение, которое (подобно всем IKE-запросам) требует подтверждения о получении. Если криптографически защищенное сообщение получено от другой стороны недавно, незащищенные уведомления могут игнорироваться. Производители могут ограничить темп, с которым они будут действовать, основываясь на незащищенных сообщениях.

Если существует только исходящий трафик по всем SA, связанным с IKE SA, то особенно важно подтверждение жизнеспособности другой ко-нечной точки, чтобы избежать появления черных дыр. Если не было полу-чено никаких криптографически защищенных сообщений по IKE SA или по любой ESP или AH SA в течение определенного периода времени, необходимо выполнить проверку жизнеспособности, чтобы избежать посылки сообщений прекратившему существование участнику. Получение свежего криптографически защищенного сообщения по IKE SA или по любой ESP или AH SA гарантирует жизнеспособность IKE SA или ESP и AH SA.

Лекция 13. Соединение сетей протоколом IPSec в транспортном режиме, аутентификация с использованием общего секрета

Цель

Обеспечить безопасность трафика только между двумя межсетевыми экранами. В этом случае следует поднять VPN с использованием семейства протоколов IPSec в транспортном режиме.

Топология сети



Топология аналогична топологии в предыдущей лабораторной работе. Между интерфейсами wan1 на МЭ 1и МЭ 2 требуется поднять VPN/IPSec в транспортном режиме.

Описание практической работы

Создать IPSec-туннель и политики доступа, которые разрешают доступ между межсетевыми экранами 1 и 2 по этому туннелю.

Межсетевой Экран 1

IPSec-Интерфейс

Создать IPSec-интерфейс в транспортном режиме.

Веб-интерфейс:

Interfaces → IPsec → Add → IPsecTunnel

На вкладке General указать конечные точки туннеля, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный в предыдущей лабораторной работе аутентификационный объект.

Командная строка:

add Interface IPsecTunnel 
ipsec LocalNetwork=wan2/wan2_ip 
RemoteNetwork=wan2/wan2_gw 
AuthMethod=PSK PSK=forIPSec 
IKEAlgorithms=Medium 
IPsecAlgorithms=Medium 
EncapsulationMode=Transport 
RemoteEndpoint=wan2/wan2_gw

Правила фильтрования

Определим правило, разрешающее исходящий трафик с МЭ 1 на МЭ 2.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: ipsec_trans
Rules → IP Rules → ipsec_trans



Команднаястрока:

add IPRuleFolder Name=ipsec_trans
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=wan2 SourceNetwork=wan2/wan2_ip DestinationInterface=ipsec_trans DestinationNetwork=wan2/wan2_gw Service=all_services Name=ipsec_out

Межсетевой Экран 2

IPSec-Интерфейс

Создать IPSec-интерфейс в транспортном режиме.

Веб-интерфейс:

Interfaces→IPsec→Add→IPsecTunnel

На вкладке General указать конечные точки туннеля, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный в предыдущей лабораторной работе аутентификационный объект.

Командная строка:

add Interface IPsecTunnel IPSec_trans 
LocalNetwork=wan2/wan2_ip 
RemoteNetwork=wan2/wan2_gw 
AuthMethod=PSK PSK=forIPSec IKEAlgorithms=Medium 
IPsecAlgorithms=Medium RemoteEndpoint=wan2/wan2_gw

Правила фильтрования

Определим правило, разрешающее входящий трафик с МЭ 1 на МЭ 2.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: ipsec_trans
Rules → IP Rules → ipsec_trans



Командная строка:

add IPRuleFolder Name=ipsec_trans
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=ipsec_trans SourceNetwork=wan2/wan2_gw DestinationInterface=core DestinationNetwork=wan2/wan2_ip Service=all_services Name=ipsec_in

Проверка конфигурации

Выполнить команду ikesnoop -on –verbose на МЭ 1.

Выполнить команду ping на МЭ 2.

Команда ikesnoop должна показать, что выполняется IPSec в транспортном режиме.



Лекция 14. Использование NAT в протоколе IPSec

Обзор

Вначале опишем изменения в фазе I IKE, необходимые для прохождения NAT. Это включает определение, поддерживает ли противоположная сторона прохождение NAT и определение, сколько преобразований NAT существует между участниками.

Далее опишем, какие следует вести переговоры в Quick Mode IKE об использовании UDP для инкапсуляции IPSec-пакетов. Также опишем, как при необходимости передавать исходные адреса отправителя и получателя противоположной стороне. Эти адреса используются в транспортном режиме для изменения TCP/IP контрольных сумм, чтобы они были правильными после преобразования NAT. (NAT не может сделать это, потому что контрольная сумма TCP/IP находится внутри UDP, инкапсулирующего IPSec-пакет.)

Базовым сценарием в данном документе является предположение, что Инициатор расположен за NA(P)T, а Получатель имеет фиксированный IP-адрес.

Фаза I

В фазе I выполняется определение поддержки прохождения NAT обоими участниками и определение того, что между участниками имело место преобразование NAT.

NAT может изменить UDP-порт источника в IKE-пакетах, поэтому Получатель должен уметь обрабатывать IKE-пакеты, чей порт источника отличается от 500. NAT не должен менять порт источника, если только один IPSec-хост расположен за NAT. Для первого IPSec-хоста NAT может оставить порт 500 и изменять номера портов только для последующих коммуникаций.

Получатель должен возвращать пакеты на адрес источника, указанный в пакете. Это означает, что Получатель, выполняющий повторные переговоры о ключах или посылающий оповещение Инициатору, должен посылать пакеты, используя тот же самый набор портов и IP-адресов, который использовался в последней IKE SA.

Например, когда Инициатор посылает пакет с портами источника и получателя 500, NAT может изменить их на порт источника 12312 и порт получателя 500. Получатель должен иметь возможность обработать пакет с портом источника 12312. Он должен ответить, указав в пакете порт источника 500 и порт получателя 12312. Затем NAT будет преобразовывать в данном пакете порт источника на 500 и порт получателя на 500.

Определение поддержки прохода NAT

Возможность прохождения NAT удаленным хостом определяется посредством обмена содержимыми ID производителя (VID). В первых двух сообщениях фазы I должно посылаться содержимое ID производителя для определения возможности прохождения NAT. Содержимым является хэш-код MD5, вычисленный для строки "RFC 3947".

Определение наличия NAT

В фазе I посылается содержимое NAT-D, которое не только определяет наличие NAT между двумя противоположными сторонами IKE, но и определяет, где находится NAT. Расположение NAT важно, так как поддержка инициируется участником, расположенным за NAT.

Для определения NAT между двумя хостами необходимо определить изменялись ли IP-адреса и порты при пересылке. Это делается посылкой в содержимом NAT-D хэшей IP-адресов и портов обоих участников друг другу. Если на обоих концах вычислены те же самые хэши, что и полученные в сообщениях NAT-D, то это означает, что между участниками нет NAT. Если хэши не совпадают, где-то была выполнена трансляция адреса или порта. Это означает, что для получения IPSec-пакетов необходимо выполнить прохождение NAT.

Если отправитель пакета не знает свой собственный IP-адрес (в случае нескольких интерфейсов может быть неизвестно, какой IP-адрес будет использоваться для маршрутизации пакета), отправитель может поместить в пакет несколько хэшей локальных IP-адресов в виде отдельных NAT-D со-держимых. В этом случае NAT присутствует тогда и только тогда, когда ни для одного из хэшей не найдено соответствие.

Содержимые NAT-D включаются в третий и четвертый пакеты Main Mode и второй и третий пакеты Aggressive Mode.

Хэш вычисляется для следующих значений:

HASH = HASH (CKY-I | CKY-R | IP | Port)

Первое содержимое NAT-D содержит IP-адрес и порт удаленной стороны, т.е. адрес получателя UDP-пакета. оставшиеся содержимые NAT-D содержат возможные IP-адреса и порты на локальной стороне, т.е. все возможные адреса источника UDP-пакета.

Если между участниками нет NAT, первое полученное содержимое NAT-D должно соответствовать одному из локальных содержимых NAT-D, а другое содержимое NAT-D должно соответствовать IP-адресу и порту удаленной стороны. Если первая проверка не проходит, т.е. первое содержимое NAT-D не соответствует ни одному локальному IP-адресу и порту, то это означает, что между участниками существует динамический NAT, и данная сторона должна начать посылать пакеты, учитывая наличие NAT.

CKY-I и CKY-R являются Cookie Инициатора и Получателя. Они добавлены в хэш, чтобы предотвратить атаки, связанные с заранее вычисленными IP-адресами и портами.

Приведем пример обменов фазы I с определением прохождения NAT в Main Mode с аутентификацией с помощью цифровых подписей.

Main Mode с аутентификацией с помощью цифровых подписей и определением наличия NAT


Рис. 9.1.  Main Mode с аутентификацией с помощью цифровых подписей и определением наличия NAT

Приведем пример обменов фазы I с определением прохождения NAT в Aggerissive Mode с аутентификацией с помощью цифровых подписей.

Aggressive Mode с аутентификацией с помощью цифровых под-писей и определением наличия NAT


Рис. 9.2.  Aggressive Mode с аутентификацией с помощью цифровых под-писей и определением наличия NAT

Символ "#" означает, что данные пакеты посылаются с измененным номером порта, если определено наличие NAT.

Изменение на новые порты

Преобразования NAT, которые знают о наличии IPSec, могут вызвать проблемы. Некоторые преобразования NAT не изменяют IKE-порт источника 500, даже если существует несколько клиентов позади NAT. Они могут также использовать IKE Cookies для пересылки пакетов нужному получателю за NAT вместо использования порта источника. Эти возможности обеспечивают определенную прозрачность NAT, в результате чего IKE трудно определить наличие NAT. Наилучшим подходом считается просто передавать IKE-трафик на порт 500 и по возможности избегать использова-ния NAT, которые могут учитывать наличие IPSec.

Рассмотрим случай, когда Инициатор расположен за NAT. Инициатор должен сразу же изменить порт на 4500 после того, как он определит наличие NAT, чтобы минимизировать проблемы, связанные с NAT, которые могут учитывать наличие IPSec.

В Main Mode Инициатор должен изменить порты при посылке содержимого ID, если между хостами есть NAT. Инициатор устанавливает оба UDP-порта (и источника, и получателя) в 4500. Кроме того, к IKE-данным добавляются с помощью UDP-инкапсуляции не-ESP маркеры, которые позволят доставить трафик получателю, расположенному за NAT.

Таким образом, IKE-пакет теперь выглядит следующим образом:

IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT,]SIG_I

В данном случае предполагается аутентификация с использованием цифровых подписей.

Когда Получатель получает данный пакет, он выполняет обычную об-работку различных содержимых. Если обработка завершается успешно, то Получатель должен изменить локальное состояние таким образом, чтобы все последующие пакеты (включая информационные уведомления) к про-тивоположной стороне использовали новый порт и возможно новый IP-адрес, полученные из входящего пакета. Обычно порт отличается, так как NAT отображает UDP (500, 500) на UDP (X, 500) и UDP (4500, 4500) на UDP (Y, 4500). IP-адрес редко отличается от изначально имеющегося IP-адреса. Получатель должен посылать всю последовательность IKE-пакетов, используя UDP (4500, Y).

Аналогично, если Получатель решает выполнить обновление ключей для фазы I SA, то переговоры об обновлении ключей должны начинаться с использованием порта 4500. В этом случае нет необходимости изменять что-то еще.

После того, как выполнено изменение порта, если какой-либо пакет получен на порт 500, то считается, что это старый пакет.

Приведем пример обмена фазы I с использованием прохождения NAT в Main Mode при аутентификации с использованием цифровых подписей и с изменением порта:

Main Mode с определением наличия NAT и изменением портов


Рис. 9.3.  Main Mode с определением наличия NAT и изменением портов

Пример SA с содержимом VID для прохождения NAT


Рис. 9.4.  Пример SA с содержимом VID для прохождения NAT

Пример обмена с содержимым NAT-D


Рис. 9.5.  Пример обмена с содержимым NAT-D

В Aggressive Mode последовательность аналогичная. После того, как определен NAT, Инициатор посылает

IPUDP (4500, 4500) <4 байта не-ESPмаркера>HDR*, [CERT,] NAT-D, SIG_I

Получатель выполняет обработку, аналогичную предыдущей, и, если она успешна, он должен изменить свои собственные IKE-порты. Получатель должен отвечать на все последующие IKE-пакеты, используя UDP (4500, Y).

Сообщения фазы I при прохождении NAT


Рис. 9.6.  Сообщения фазы I при прохождении NAT

Если включена поддержка прохождения NAT, порт содержимого ID как в Main, так и в Aggressive режимах должен быть установлен в 0.

В большинстве случаев для Получателя, расположенного позади NAT, NAT выполняет простое преобразование адреса 1:1. В этом случае Инициатор все еще продолжает изменять оба порта на 4500. Получатель использует алгоритм, описанный выше, хотя в этом случае Y будет равен 4500, так как никакого преобразования порта не происходит.

Изменение порта на другое значение может привести к необходимости использовать нестандартные способы определения используемых портов. Например, если Получатель расположен за NAT, преобразующим порты, и Инициатору необходимо установить соединение в первый раз, то Инициа-тор должен определить используемые порты, обычно соединяясь с некото-рым другим сервером. После того, как Инициатор выяснит, какие порты используются для прохождения NAT, обычно UDP (Z, 4500), он начинает использовать эти порты. Это аналогично случаю, когда Получатель начи-нает новые переговоры о ключах, при которых используемые порты уже известны, и никаких дополнительных обменов нет.

Quick Mode

После завершения фазы I оба участника знают, есть ли между ними NAT. Окончательное решение об использовании прохождения NAT при-нимается в Quick Mode. Об использовании прохождения NAT ведутся переговоры в содержимых SA Quick Mode. В Quick Mode оба участника так-же могут послать исходные адреса IPSec-пакетов (в случае транспортного режима), поэтому каждый может фиксировать поле контрольной суммы ТСР/IP после преобразования NAT.

Переговоры об инкапсуляции для обхода NAT

Для переговоров о прохождении NAT добавлено два новых инкапсулирующих режима:

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

Если между хостами есть NAT, то обычная транспортная или туннельная инкапсуляция не работает. В этом случае следует использовать UDP-инкапсуляцию.

Если между хостами нет NAT, то UDP-инкапсуляция не используется.

Также Инициатор не должен включать в свои предложения одновременно как обычный туннельный или транспортный режим, так и UDP-инкапсулирующий туннельный или транспортный режим.

Посылка исходных адресов отправителя и получателя

Для возможности изменения контрольных сумм ТСР обоим участникам может понадобиться знать исходные IP-адреса, которые использовались участниками при создании пакета.

Исходные IP-адреса посылаются в содержимом NAT-OA.

Инициатор <---------> NAT <---------> Получатель
^                        ^               ^
Iaddr           NatPub      Raddr

Инициатор расположен за NAT, который в свою очередь взаимодействует с публично доступным Получателем. Инициатор и Получатель име-ют IP-адреса Iaddr и Raddr. NAT имеет публичный IP-адрес NatPub.

Инициатор:

NAT-OAi = Iaddr
NAT-OAr = Raddr

Получатель:

NAT-OAi = NATPub
NAT-OAr = Raddr
Инициатор <---> NAT1 <---> NAT2 <---> Получатель
^           ^          ^           ^
Iaddr    Nat1Pub     Nat2Pub  Raddr

Здесь NAT2 "публикует" Nat2Pub в качестве адреса Получателя и перенаправляет весь трафик с данного адреса к Получателю.

Инициатор:

NAT-OAi = Iaddr
NAT-OAr = Nat2Pub

Получатель:

NAT-OAi = Nat1Pub
NAT-OAr = Raddr

В случае транспортного режима обе стороны должны посылать друг другу исходные адреса Инициатора и Получателя. В туннельном режиме обе стороны не должны посылать друг другу исходные адреса.

Содержимое NAT-OA посылается в первом и втором пакетах в Quick Mode. Инициатор должен послать содержимое, если он предложил UDP-инкапсулирующий транспортный режим, Получатель должен послать содержимое, если он выбрал UDP-инкапсулирующий режим. Возможна ситуация, когда Инициатор посылает NAT-OA содержимое, но предлагает и транспортный, и туннельный UDP-инкапсулирующий режимы. Если Получатель выбирает туннельный UDP-инкапсулирующий режим, то он не посылаетNAT-OA содержимое.

Пример Quick Mode, использующий NAT-OA содержимые:

Сообщения Quick Mode при прохождении NAT


Рис. 9.7.  Сообщения Quick Mode при прохождении NAT

Пример задания параметров прохождения NAT в транспортном режиме (часть 1)


Рис. 9.8.  Пример задания параметров прохождения NAT в транспортном режиме (часть 1)

Пример задания параметров прохождения NAT в транспортном режиме (2 часть)


Рис. 9.9.  Пример задания параметров прохождения NAT в транспортном режиме (2 часть)

Пример дампа трафика с инкапсулирующим режимом UDP Transport


Рис. 9.10.  Пример дампа трафика с инкапсулирующим режимом UDP Transport

Уведомления начального взаимодействия

IP-адрес и порт отправителя в уведомлении INITIAL-CONTACT для хоста, расположенного за NAT, не важны, так как NAT может изменить их, поэтому IP-адреса и номера портов не должны использоваться для определения того, какие IKE/IPSec SA следует удалять. Для этих целей следует использовать содержимое ID. Например, когда посылается INITIAL-CONTACT уведомление, то получившая его сторона должна удалить все SA, связанные с этим содержимым ID

Восстановление при истечении таймаута преобразования NAT

В некоторых случаях NAT решает удалить записи о сессиях, которые с точки зрения NAT больше не существуют (например, когда интервал подтверждения жизнеспособности SA превышен или когда NAT перезапускают). В этом случае для восстановления участники, которые не расположены за NAT, должны использовать последний действительный UDP-инкапсулирующий IKE- или IPsec-пакет от противоположной стороны, чтобы определить, какой IP-адрес и порт следует использовать. Хост позади динамического NAT не должен делать этого, так как в этом случае он может стать уязвимым для DoS-атаки, так как IP-адрес или порт другого хоста не изменился, если он не расположен за NAT.

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

Обсуждение безопасности

Аутентификационные механизмы, основанные на IP-адресах, не могут использоваться, если выполняется преобразование NAT. Аутентификация не может основываться на IP-адресах. Это означает, что аутентификация по pre-shared ключам не может использоваться в Main Mode без использования ключей, разделяемых всеми, расположенными за NAT. Использование групповых ключей создает большой риск, потому что позволяет любому из группы аутентифицироваться в качестве VPN-шлюза, после чего просматривать и модифицировать трафик всей группы.

Ни содержимое NAT-D, ни содержимое Vendor ID не аутентифициро-ваны ни в Main Mode, ни в Aggressive Mode. Это означает, что атакующий может удалить эти содержимые, модифицировать их или добавить. Это может привести к DoS-атакам. Вставляя пакеты NAT-D, атакующий может заставить обоих участников использовать UDP-инкапсулированные пакеты вместо простого туннельного или транспортного режимов.

Метод определения сбоя противоположной стороны IKE, основанный на наличии трафика

При взаимодействии по протоколам IKE и IPSec может возникнуть ситуация, когда между двумя участниками внезапно пропадает соединение. Такая ситуация возникает в результате проблем с маршрутизацией, переза-пуска одного из хостов и т.п. В этом случае часто не существует способа противоположной стороне определить потерю соединения. При этом SA могут существовать до тех пор, пока не истечет их время жизни. В результате этого образуется "черная дыра", в которую уходят пакеты. Часто тре-буется обнаружить черные дыры как можно скорее, чтобы обеспечить отказоустойчивость. Более того, часто необходимо определить черные дыры, чтобы предотвратить расходование лишних ресурсов.

Проблема определения падения противоположной стороны IKE реша-ется на стадии посылки Proposal, в которых указывается требование пе-риодической посылки сообщений HELLO/ACK, которые бы доказывали жизнеспособность противоположной стороны. Такая схема может быть как однонаправленной (только HELLO) или двунаправленной (пара HELLO/ACK). Часто используется термин "heartbeat" ("биение сердца") для однонаправленного сообщения проверки жизнеспособности, а термин "keepalive" используется для двунаправленных сообщений.

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

Производители могут реализовать свои собственные подходы для определения жизнеспособности противоположной стороны без необходимости посылки сообщений через определенные интервалы. Данная схема, называемая Dead Peer Detection (DPD), основана на IKE-сообщениях Notify, в которых запрашивается жизнеспособность противоположной стороны IKE.

Сначала объясним использование обмена IKE-сообщениями для определения жизнеспособности противоположной стороны. Затем рассмотрим разницу в подходах heartbeat и keepalive. И, наконец, опишем формат Предложения DPD, который используется в описанных подходах. В заключении рассмотрим возникающие проблемы безопасности.

Обмен периодическими сообщениями для доказательства жизнеспособности

Как уже отмечалось, часто бывает необходимо как можно скорее определить, что соединение с противоположной стороной потеряно. IKE не предоставляет способа выполнить это, кроме как ждать до тех пор, пока не истечет период обновления ключей. В большинстве случаев это неприем-лемо, поэтому необходим способ проверки состояния противоположной стороны. В этом случае обычно использует IKE Notify либо в двунаправленном обмене сообщениями "keepalive" (HELLO, затем ACK), либо в однонаправленной посылке сообщения "heartbeat" (только HELLO).

Сравнение keepalive и heartbeat

Keepalive

Рассмотрим схему keepalive, в которой каждой стороне требуется регулярное подтверждение жизнеспособности противоположной стороны. Обмен сообщениями происходит с использованием аутентифицированного сообщения Notify. Оба участника в фазе I согласовывают интервал, в течение которого посылаются сообщения, например, 10 секунд. Каждое сообщение HELLO служит доказательством жизнеспособности противоположной стороны. В свою очередь каждая из сторон должна подтвердить сообщениеHELLO. Если по истечении 10 секунд какая-либо из сторон не получила HELLO, она сама посылает сообщение HELLO, ожидая ACK от противоположной стороны в качестве доказательства жизнеспособности. При получении как HELLO, так и ACK таймер перезапускается.

Сценарий 1:

У участника А 10-секундный таймер истекает первым, и он посылает HELLO участнику В. В отвечает ACK

Сообщения в схеме keepalive


Рис. 9.11.  Сообщения в схеме keepalive

Сценарий 2:

У участника А таймер истекает первым, он посылает HELLO участнику В. Участник В не отвечает. Участник А может повторить передачу, если он предполагает, что первое HELLO потеряно. Данная ситуация описывает, как участник А определяет, что соединение с противоположной стороной потеряно.

Сообщения в схеме keepalive в случае сбоя на стороне участника В


Рис. 9.12.  Сообщения в схеме keepalive в случае сбоя на стороне участника В

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

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

Heartbeat

Рассмотрим схему доказательства жизнеспособности, состоящую из однонаправленных (без подтверждения) сообщений. Сторона, которая за-интересована в жизнеспособности противоположной стороны, должна полагаться на то, что противоположная сторона сама периодически будет посылать сообщения, демонстрирую свою жизнеспособность. В данной схеме обмен сообщениями может быть следующим:

Сценарий 3:

Участники А и В заинтересованы в жизнеспособности друг друга. Определение жизнеспособности каждым участником зависит от того, будет ли другой периодически посылать HELLO

Сообщения в схеме Heartbeat


Рис. 9.13.  Сообщения в схеме Heartbeat

Сценарий 4:

Определение сбоя противоположной стороны.

 Сообщения в схеме Heartbeat в случае сбоя на сто-роне участника В


Рис. 9.14.  Сообщения в схеме Heartbeat в случае сбоя на сто-роне участника В

Недостатком данной схемы является то, что предполагается, что противоположная сторона будет демонстрировать свою жизнеспособность. Но с другой стороны, участник В может никогда не интересоваться жизнеспособностью участника А. Тем не менее, если А интересуется жизнеспособностью В, В должен отдавать себе отчет в этом и поддерживать необходимую информацию о состоянии, периодически посылая HELLO к А. Недостаток данной схемы становится очевидным в сценарии удаленного доступа. Рассмотрим VPN-шлюз, на котором закан-чивается большое количество сессий (порядка 50 000 или более участников). Если какому-то участнику, требуется поддержка отказоустойчивости, то шлюз должен будет посылать HELLO-пакеты каждые 10 секунд. Такая схема плохо масштабируема, так как шлюз должен посылать 50 000 сообщений каждые несколько секунд.

В обеих схемах должны быть выполнены определенные переговоры, чтобы каждая сторона знала, как часто противоположная сторона предполагает получать сообщения HELLO. Это добавляет определенную слож-ность. Аналогично, необходимость периодически посылать сообщения (не зависимо от другого трафика IPSec/IKE) также добавляет вычислительную нагрузку на систему.

Протокол DPD

DPD позволяет ликвидировать недостатки схем keepalive и heartbeat введением определенной логики управления обменом сообщений. В частности, keepalive и heartbeat должны обязательно обмениваться HELLO через определенные интервалы времени. В отличие от этого при использовании DPD каждый участник в большей степени не зависит от другого. Участник может запрашивать доказательство жизнеспособности в тот момент, когда это ему необходимо, а не через фиксированный интервал времени. Такая асинхронность DPD-обменов позволяет посылать разное количество сообщений, чем достигается большая масштабируемость.

Веб-интерфейс для указания использования протокола DPD


Рис. 9.15.  Веб-интерфейс для указания использования протокола DPD

Рассмотрим взаимодействие двух DPD-участников А и В. Если между ними существует IPSec-трафик, то нет необходимости в регулярном доказательстве жизнеспособности. С другой стороны, если существует период простоя, в течение которого между ними нет обмена пакетами, то жизне-способность каждого участника может вызывать сомнения. Однако знание о жизнеспособности противоположной стороны необходимо только в том случае, если должен быть передан трафик. Например, если участник А должен послать IPSec-пакеты после определенного периода простоя, он должен быть уверен в жизнеспособности В. В этот момент участник А может инициировать DPD-обмен.

Кроме того, каждая сторона может иметь разные требования к определению жизнеспособности. Участнику А, например, может требоваться высокая отказоустойчивость, в то время как требования к ресурсам не столь жесткие. При использовании DPD каждая сторона может определить свою собственную "метрику волнения" - интервал, который определяет необходимость DPD-обмена. В данном примере участник А может определить DPD-интервал в 10 секунд. Затем, если сторона А посылает исходящий IPSec-трафик, но в течение 10 секунд происходит сбой при получении входящего трафика, она может инициировать DPD-обмен.

С другой стороны, участник В определяет DPD-интервал 5 минут. Если IPSec-сессия простаивает в течение 5 минут, то участник В может инициировать DPD-обмен, если в следующий момент он собирается послать IPSec-пакет к А.

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

DPD Vendor ID

Для указания возможностей DPD участник должен послать DPD Vendor ID. Оба участника IKE-сессии должны послать DPD Vendor ID перед тем, как начинать DPD-обмены. Формат DPD Vendor ID следующий:

Формат DPD Vendor ID


Рис. 9.16.  Формат DPD Vendor ID

Где

HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57} Сторона IKE должна послать Vendor ID, если она хочет выполнять DPD-обмены.

Обмены сообщениями

DPD-обмен является двунаправленным (HELLO/ACK) Notify-сообщением. Обмен определен следующим образом:

Сообщения протокола DPD


Рис. 9.17.  Сообщения протокола DPD

R-U-THERE сообщение соответствует HELLO, а R-U-THERE-ACK соответствует ACK. Оба сообщения являются просто содержимыми IKE Notify. Определены два новых типа Notify-сообщений IKE: R-U-THERE и R-U-THERE-ACK.

Участник, который послал DPD Vendor ID, должен ответить на запрос R-U-THERE. Участник должен отбрасывать незашифрованные R-U-THERE и R-U-THERE-ACK сообщения.

Формат сообщения NOTIFY (R-U-THERE / R-U-THERE-ACK)

Сообщение R-U-THERE имеет следующий формат:

Формат сообщения R-U-THERE


Рис. 9.18.  Формат сообщения R-U-THERE

Так как данное сообщение является IKE NOTIFY, то поля Next Payload, RESERVED и Payload Length должны быть установлены в соответствии с требованиями протокола IKE. Остальные поля установлены следующим образом:

Формат R-U-THERE-ACK тот же самый, за исключением того, что тип сообщения Notify есть R-U-THERE-ACK, и данные содержат последовательный номер, соответствующий полученному R-U-THERE сообщению.

Начало DPD-обмена

Вместо того, чтобы основываться на определенном временном интервале, в течение которого необходимо выполнить обмен сообщениями, предполагается, что R-U-THERE сообщения могут быть посланы в любое время. Участник IKE посылает R-U-THERE запрос противоположной стороне только в том случае, если его интересует жизнеспособность противо-положной стороны. С этой точки зрения, если существует регулярный трафик между участниками, то любая из сторон может использовать данный трафик как доказательство жизнеспособности противоположной стороны, и обоим участникам не следует инициировать DPD-обмен.

Участник хранит состояние данного DPD-обмена. Этого означает, что после того, как был послан R-U-THERE запрос, он ожидает получить ACK в ответе в течение определенного времени. Если не получен ACK, то переда-ется повторный запрос. После определенного количества повторных передач считается, что противоположная сторона не отвечает, и удаляются IPSec и IKE SA с противоположной стороной.

Возможные реализации

Так как жизнеспособность противоположной стороны запрашивается только тогда, когда отсутствует трафик, производители могут начинать отслеживать состояние только при отсутствии трафика. В этом случае жизнеспособность противоположной стороны важна только в том случае, если требуется посылать исходящий трафик. Чтобы сделать это, можно иниции-ровать DPD-обмен (т.е. послать R-U-THERE сообщение), если есть определенный период простоя, после которого требуется послать исходящий трафик. Кроме того, DPD-обмен может инициироваться, если был послан исходящий IPSec-трафик, но в ответ не были получены входящие IPSec-пакеты. Полный DPD-обмен (т.е. передать R-U-THERE и получить соответствующий R-U-THERE-ACK) служит доказательством жизнеспособности до тех пор, пока не начнется следующий период простоя.

Также, так как в DPD нет никакого обязательного интервала, этот "период простоя" (или "метрика волнения") зависит от реализации. Переговоры об этом значении, как правило, не ведутся.

Сравнение протокола DPD со схемами keepalive и heartbeat

Выигрыш в производительности, который дает DPD по сравнению с традиционными схемами keepalive и heartbeat, получается из-за того, что нет необходимости регулярно посылать сообщения. Реализация схемы keepalive требует одного таймера для сигнализации, когда следует посылать HELLO-сообщение, и одного таймера для отслеживания таймаута ACK от противоположной стороны, который также может являться таймером повторной передачи. В схеме heartbeat необходимо иметь один таймер для сигнализации о том, что следует ожидать HELLO от противоположной стороны. В отличие от этих схем, в схеме DPD необходимо хранить отметку времени, когда был получен последний трафик от противоположной стороны (что является началом "периода простоя"). После того, как было посла-но DPD R-U-THERE сообщение, необходимо иметь таймер, который будет сигнализировать о необходимости повторной передачи. Таким образом, уменьшается необходимость в поддержке состояния таймера, в результате чего улучшается масштабируемость. (Предполагается, что поддерживать отметку времени проще, чем таймер.)

Более того, так как DPD-обмен возникает только тогда, когда не получен трафик от противоположной стороны, количество IKE-сообщений, которые должны быть посланы и обработаны, уменьшается. Как следствие, масшабируемость DPD гораздо лучше, чем при использовании keepalive и heartbeat.

DPD поддерживает модель HELLO/ACK, существующую в keepalive, при этом обмен инициируется только тогда, когда участнику важна жизнеспособность противоположной стороны.

Защита от replay-атак и фальшивого доказательства жизнеспособности

1. Последовательный номер в DPD-сообщениях

Для защиты от replay-атак и фальшивого доказательства жизнеспособности в каждом R-U-THERE сообщении используется 32-битный последовательный номер. Получатель R-U-THERE сообщения должен послать R-U-THERE-ACK с тем же самым номером. При получении R-U-THERE-ACK сообщения проверяется правильность полученного последовательного номера.

Кроме того, отправители и R-U-THERE сообщения, иR-U-THERE-ACK сообщения проверяют корректность Cookies Инициатора и Получателя, которые указаны в поле SPI.

2. Выбор и поддержка последовательных номеров

Оба DPD-участника могут инициировать DPD-обмен, т.е. оба участника могут послать R-U-THERE сообщение. При этом каждый участник под-держивает свой собственный последовательный номер для R-U-THERE сообщений. Первое R-U-THERE сообщение, посланное в течение данной сессии, имеет случайно выбранный номер. Для предотвращения переполнения 32-битного значения старший бит установлен в ноль. В следующих R-U-THERE сообщениях последовательный номер возрастает на единицу. Последовательные номера могут быть выбраны заново при истечении IKE SA. Каждый участник также хранит последовательный номер R-U-THERE сообщения противоположной стороны.

Как правило, поддерживается окно принимаемых последовательных номеров.

Обсуждение безопасности

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

Хотя использование последовательных номеров требует поддержки состояния противоположной стороны, они также обеспечивают дополнительный способ защиты от некоторых replay-атак. Рассмотрим случай, когда участник А посылает участнику В действительное DPD R-U-THERE сообщение. Атакующий С может перехватить данное сообщение и послать несколько его копий. В расшифрует и обработает каждый пакет (не зависимо от того, используются ли последовательные номера или nonces). При использовании последовательных номеров В может определить, что пакеты являются повторами, так как их последовательные номера не возрастают. В этом случае В не будет создавать, шифровать и отправлять ACK. Если же используются nonces, то для предотвращения replay-атак В должен поддерживать список недавно полученных nonces.

Проблемы выполнения

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

Использование IPSec также увеличивает стоимость компонентов, осуществляющих пересылку и маршрутизацию, но не использующих IPSec. Это происходит из-за возрастания размера пакета в результате добавления заголовков АН и/или ESP, АН и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве случаев это возрастание не будет сильно влиять на производительность. Тем не менее, иногда такое влияние может быть большим, например, передача зашифрованного трафика по низкоскоростным каналам.

Лекция 15. Использование преобразования NAT в протоколе IPSec

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec (Лабораторная работа 10). В этом случае необходимо использовать туннельный режим. На МЭ 1 должен выполняться NAT.

Топология сети



Описание практической работы

Межсетевой Экран 1

IPSec-Интерфейс

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

Веб-интерфейс:







Командная строка:

set Interface IPsecTunnel ipsec_tunnel NATTraversal= AlwaysOn AddRouteToRemoteNet=No AutoInterfaceNetworkRoute=Yes

Правила фильтрования

Вместо Правила Allow следует указать правило NAT.



Межсетевой Экран 2

IPSec-Интерфейс

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

Проверка конфигурации

Выполнить команду ping и проанализировать передаваемый трафик.



Запишем дамп трафика в файлы и посмотрим его с помощью программы Wireshark.



На lan-интерфейсе трафик с измененным IP-адресом:



Лекция 16. Использование протокола DPD в протоколе IPSec

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec в туннельном режиме. До-полнительно МЭ1 и МЭ2 используют протокол DPD для проверки жизнеспособности друг друга.

Топология сети



Топология аналогична топологии в предыдущей лабораторной работе. Между интерфейсами wan2 на МЭ 1и МЭ 2 требуется поднять VPN/IPSec. Жизнеспособность противоположной стороны необходимо проверять по протоколу DPD.

Описание практической работы

Межсетевой Экран 1

IPSec-Интерфейс

Установить использование протокола DPD.

Веб-интерфейс:

Interfaces → IPsec → ipsec



Командная строка:

set Interface IPsecTunnel ipsec_tunnel DeadPeerDetection=Yes

Настройки протокола DPD указываются в дополнительных установках (Advanced Settings).





Межсетевой Экран 2

IPSec-Интерфейс

Если на МЭ 2 также необходима проверка жизнеспособности противо-положной стороны, то необходимо сделать аналогичные изменения в настройках IPSec-интерфейса.

Проверка конфигурации

Запишем дамп трафика в файлы и посмотрим его с помощью программы Wireshark



Лекция 17. Совместное использование протоколов L2TP и IPSec

Рассмотрим, как протокол L2TP может использовать IPSec для выполнения аутентификации туннеля, обеспечения конфиденциальности, целостности и защиты от replay-атак. Рассмотрим случаи как добровольного, так и принудительного туннелирования.

Обзор

L2TP является протоколом, который туннелирует РРР-трафик по раз-личным сетям (IP, ATM и т.п.). Так как протокол инкапсулирует РРР, L2TP использует РРР-аутентификацию, а также протоколы РРР управления шифрованием и сжатием. L2TP обеспечивает взаимную аутентификацию конечных точек туннеля.

IPSec является набором протоколов сетевого уровня, которые используются для обеспечения безопасного взаимодействия двух участников.

Рассмотрим возможность использования набора протоколов IPSec для обеспечения защиты L2TP-трафика по IP-сетям. Также рассмотрим совместное использование IPSec и L2TP.

Хотя L2TP в качестве транспорта не обязательно использует IP/UDP, в данном случае будем рассматривать только L2TP в IP-сетях.

Для описания совместного использования L2TP и IPSec будем использовать следующую терминологию.

Добровольное туннелирование. При добровольном туннелировании туннель создается пользователем, обычно посредством использования клиента туннелирования. В результате этого клиент будет посылать L2TP-пакеты к NAS, который затем будет пересылать их LNS. При добровольном туннелировании NAS не должен поддерживать L2TP, и LAC расположен на той же самой машине, что и клиент.

Обязательное туннелирование. При обязательном туннелировании туннель создается без какого-либо участия клиента, и клиенту не предоставляется никакого выбора. В результате этого клиент будет посылать РРР-пакеты к NAS/LAC, который затем будет инкапсулировать их в L2TP и туннелировать к LNS. При обязательном туннелировании NAS/LAC должен поддерживать L2TP.

Инициатор. Инициатором может быть LAC или LNS, это то устройство, которое посылает SCCRQ и получает SCCRP.

Получатель. Получателем может быть LAC или LNS, это то устройство, которое получает SCCRQ и отвечает SCCRP.

Примеры атак на протокол L2TP

Как управляющие пакеты, так и пакеты данных L2TP-протокола уязвимы для разного рода атак:

  1. Противник может узнать идентификаторы пользователей, просматривая пакеты данных.
  2. Противник может попытаться модифицировать пакеты (как управляющие, так и данных).
  3. Противник может попытаться встроиться в L2TP-туннель или РРР-соединение внутри туннеля, представившись одной из сторон.
  4. Противник может выполнить DoS-атаку, прерывая РРР-соединения или L2TP-туннели.
  5. Противник может попытаться внедриться в РРР-переговоры о параметрах шифрования, чтобы ослабить или удалить конфиденциальность. Противник может также попытаться внедриться в РРР LCP-переговоры об аутентификации, ослабив аутентификацию и получив после этого доступ к паролям пользователей.

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

Сам протокол L2TP, а также аутентификация в РРР-протоколе не удовлетворяют перечисленным требованиям безопасности. При аутентификации на уровне L2TP-туннеля обеспечивается взаимная аутентификация LAC и LNS при создании туннеля. Но защиты управляющего трафика и трафика данных на уровне пакетов нет. Это делает L2TP-туннель уязви-мым. РРР аутентифицирует клиента для LNS, но аутентификация, целост-ность и защита от replay-атак на уровне пакетов также отсутствует. РРР-шифрование обеспечивает конфиденциальность РРР-трафика, но не обес-печивает аутентификацию, целостность, защиту от replay-атак и управле-ние ключом. Кроме того, нет переговоров об используемых алгоритмах.

Управление ключом в протоколе L2TP отсутствует. Если требуется аутентификация туннеля, то необходимо распределять пароли для этого туннеля каким-то внешним по отношению к протоколу способом.

Для предотвращения этих атак следует использовать IPSec ESP для обеспечения безопасности как управляющих пакетов, так и пакетов данных L2TP. Обязательно должен поддерживаться транспортный режим, может также поддерживаться и туннельный режим. Если конфиденциальность не требуется (например, для трафика данных L2TP), то следует использовать NULL-шифрование в ESP.

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

Основные принципы совместного использования L2TP и IPSec

  1. Требуется обеспечить синхронное завершение L2TP-туннеля и SA, созданной в фазах I или II.

    Механизмы РРР и L2TP дают возможность завершения соединения как с уведомлением об этом противоположной стороны, так и без уведомления. В протоколе РРР LCP TermReq и TermAck обеспечивают завершение с уведомлением. Сообщения LCP keep-alive и hello L2TP-туннеля дают возможность определить, что произошло завершение без уведомления. Когда происходит завершение, приводящее к закрытию туннеля, используются механизмы управляющего соединения протокола L2TP. При удалении L2TP-туннеля любой из сторон SA, созданные в фазах I или II, которые используются L2TP-туннелем, также должны быть удалены.

  2. Проблемы, связанные с фрагментацией.

    Так как MTU по умолчанию для РРР-соединений равно 1500 байтам, возможна фрагментация при добавлении L2TP- и IPSec-заголовков в РРР-кадр. Одним из механизмов, который может использоваться для решения этой проблемы, может быть использование в РРР значения MTU для входящего / исходящего трафика, равного L2TP/IPSec туннелю минус накладные расходы, связанные с внешними заголовками. Это должно быть сдела-но после того, как L2TP-туннель был установлен, но перед тем, как нача-лись LCP-переговоры. Если значение MTU для входящего / исходящего трафика для туннеля меньше, чем значение MTU для РРР, то указывается новое значение. Это значение может также использоваться в качестве начального значения, предлагаемого для MTU в LCP ConfigReq.

    Если ICMP MTU получено в IPSec, то это значение должно храниться в SA. IPSec должен также уведомить об этом L2TP, чтобы новое значение MTU было указано в РРР-интерфейсе. Любое новое значение MTU, задава-емое для РРР-интерфейса, должно проверяться на соответствие этим ограничениям.

    Параметр MTU для протокола L2TP


    Рис. 10.1.  Параметр MTU для протокола L2TP

Детали IPSec-фильтрования для L2TP-защиты

Так как IKE/IPSec не знает о деталях приложения, которое он защищает, обычно не требуется никакой интеграции между приложением и IPSec-протоколом. Однако в протоколах, в которых возможно изменение номера порта при переговорах, выполняемых этим протоколом (как в случае L2TP), могут возникнуть проблемы при выполнении IKE. В спецификации протокола L2TP говорится, что производитель может динамически назначать UDP-порт источника. Новое значение порта посылается в SCCRP от Получателя к Инициатору.

Хотя текущая спецификация L2TP позволяет Получателю указывать новый IP-адрес в SCCRP, если требуется защита L2TP с использованием IPSec, обычно этого не делают. Для обеспечения возможности указывать новый IP-адрес при совместном использовании L2TP и IPSec, необходимо, чтобы при выборе Получателем нового IP-адреса, он посылал STOPCCN Инициатору с AVP Result Code, Error Code. Result Code должен быть установлен в 2 (General error), и Error Code должен быть установлен в 7 (Try Another).

Если Error Code установлен в 7, то должно посылаться дополнительное сообщение об ошибке, в котором содержится IP-адрес, который Получатель будет использовать в последующих обменах. Инициатор после обработки этих сообщений должен послать новый SCCRQ на новый IP-адрес. Данный подход уменьшает сложность, так как Инициатор всегда знает корректный IP-адрес противоположной стороны. Это также позволяет управляющему механизму L2TP привязать записи в базе данных поли-тик IPSec к одной и той же противоположной стороне.

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

  1. I фаза IKE-переговоров.

    В IKE при использовании аутентификации по предварительно распределенному секрету этот секрет должен быть указан на каждой стороне. При использовании Main Mode (который обеспечивает защиту идентификации) этот секрет должен быть связан с IP-адресом противоположной стороны. При использовании Aggresive Mode (который не обеспечивает защиту идентификации) предварительно распределенный секрет должен быть связан с одним из допустимых типов идентификаций, определенных в IPSec DOI.

    Идентификация участников по DNS-имени


    Рис. 10.2.  Идентификация участников по DNS-имени

    Если инициатор получает STOPCCN с AVP результата и кодом ошибки, установленным в Try Another, и в сообщении присутствует действительный IP-адрес, он может связать исходный предварительно распределенный секрет с новым IP-адресом, содержащимся в сообщении об ошибке.

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

  2. Переговоры II фазы IKE.

    В течение II фазы участники согласовывают, как будет защищен трафик IPSec-протоколов. Идентификации в Quick Mode являются комбинацией адресного пространства, протокола и номера порта.

    При обеспечении безопасности L2TP с использованием IPSec возможны следующие изменения портов и адресов Инициатора и Получателя:

    Таблица 10.1.
    Порт Инициатора Адрес Получателя Порт Получателя
    1701 Фиксированный 1701
    1701 Фиксированный Динамический
    1701 Динамический 1701
    1701 Динамический Динамический
    Динамический Фиксированный 1701
    Динамический Фиксированный Динамический
    Динамический Динамический 1701
    Динамический Динамический Динамический

    Наиболее общим случаем является последний в списке. В этом случае Инициатор выбирает новый номер порта, и Получатель выбирает новый адрес и новый номер порта. Поток L2TP-сообщений, который возникает в этом случае, следующий:

    →IKE фаза I и фаза II для защиты Initial SCCRQ
    SCCRQ 	→ (Фиксированный IP-адрес, Динамический порт Инициатора)
    ← STOPCCN (Получатель выбирает новый IP-адрес)
    → Новые переговоры IKE фаза I и фаза II для защиты нового SCCRQ
    SCCRQ 	→ (SCCRQ на новый IP-адрес Получателя)
    ← Новые переговоры IKE фаза II для изменения номера порта Получателя
    ← SCCRP (Получатель выбирает новый номер порта)
    SCCCN 	→ (Завершение установления L2TP-туннеля)
    

    Хотя обычно Инициатор и Получатель динамически не изменяют пор-ты, безопасность L2TP должна также обеспечиваться при использовании таких приложений, как балансировка нагрузки и гарантирование качества (QoS). Это может потребовать изменения порта и IP-адреса при установлении L2TP-туннеля.

    Для поддержки наиболее общего случая в L2TP и IPSec должны быть разработаны механизмы, которые позволяют L2TP вставлять свои записи в БД IPSec. Данная технология может быть использована любым приложением, которое изменяет порты и которому требуется безопасность с использованием IPSec.

    Не требуется, чтобы Получатель поддерживал возможность изменять свой IP-адрес и порт. Тем не менее Инициатор должен позволять Получателю изменить свой порт и IP-адрес.

    Терминология, используемая для задания параметров фильтрования:

    Таблица 10.2.
    I-PortНомер UDP-порта, который Инициатор выбирает для инициализации и получения L2TP-трафика. Это может быть статический порт, такой как 1701, или временный порт, связанный с сокетом.
    R-Port Номер UDP-порта, который Получатель выбирает для инициализации и получения L2TP-трафика. Это может быть порт 1701 или временный порт, связанный с сокетом. Это номер порта, который Получатель будет использовать после получения начального SCCRQ.
    R-IPAddr1 IP-адрес, который Получатель слушает при получении начального SCCRQ. Если Получатель не изменил IP-адрес на новый, данный адрес будет использоваться всем последующим L2TP-трафиком.
    R-IPAddr2 IP-адрес, который Получатель выбрал после получения SCCRQ. Этот адрес используется для того, чтобы послать SCCRQ, и весь последующий трафик L2TP-туннеля будет посылаться с данного адреса и получаться на него.
    R-IPAddr IP-адрес, который Получатель использует для посылки и получения L2TP-пакетов. Это либо исходное значение R-IPAddr1, либо новое значение R-IPAddr2.
    I-IPAddr IP-адрес, который Инициатор использует для взаимодействия по L2TP-туннелю.
    Any-Addr Наличие Any-Addr говорит о том, что IKE должен допускать любой одиночный адрес, предложенный в качестве ID в фазе II переговоров. Данный одиночный адрес может рассматриваться как единственный IP-адрес или IP-адрес с маской, установленной в 255.255.255.255.
    Any-Port Наличие Any-Port говорит о том, что IKE должен допускать любое значение номера порта.

    Записи в политике IPSec, которые будут определены далее, перечислены от наибольшего приоритета к наименьшему.

Начальные записи в политике, необходимые для защиты SCCRQ

Добавление начальных записей на стороне Инициатора и Получателя необходимо для защиты SCCRQ, посылаемого Инициатором для открытия L2TP-туннеля. Как Инициатор, так и Получатель должны либо быть заранее сконфигурированы с этими дополнительными записями, либо в L2TP должен быть определен метод добавления этой информации в БД политик IPSec. В любом случае данные записи должны быть определены до того, как будет послано первое сообщение об установке L2TP-туннеля.

Записи на стороне Получателя:

Таблица 10.3.
Записи на стороне Получателя:
Для исходящего трафикаНет. Они должны быть динамически созданы IKE при успешном завершении фазы II.
Записи на стороне Инициатора:
Для исходящего трафикаfrom I-IPAddrto R-IPAddr1UDPsrc I-Portdst 1701
Для входящего трафикаfrom R-IPAddr1to I-IPAddr UDP src 1701 dst I-Port
from R-IPAddr1 to I-IPAddr UDP src Any-Port dstI-Port

Если Инициатор использует динамические порты, то L2TP должен вставить записи в БД политик IPSec после того, как стал известен номер порта источника. Если Инициатор использует фиксированный порт 1701, эти записи могут быть определены статически.

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

Если на фазе II все еще нет SA для защиты SCCRQ, посылка SCCRQ Инициатором должна привести к тому, что IKE установит необходимые SA для защиты данного пакета. В качестве альтернативы L2TP может запросить IKE установить SA. Если по какой-то причине SA не может быть установлена, пакет должен быть отброшен.

Номера портов в ID Quick Mode, посылаемые Инициатором, должны содержать номера портов, используемые для идентификации UDP-сокета. Номера портов будут либо I-Port/1701, либо 1701/1701 для начального SCCRQ. ID Quick Mode, посылаемые Инициатором, являются подмножеством первой записи для входящего трафика на стороне Получателя. В результате этого после завершения обмена Quick Mode IKE должен вставить определенный набор записей в БД политик IPSec и связать этот набор записей с SA фазы II, установленной между участниками. Эти записи должны существовать до тех пор, пока существует L2TP-туннель. Новый набор записей на стороне Получателя будет:

Таблица 10.4.
Записи на стороне Получателя:
Для исходящего трафикаfrom R-IPAddr1 to I-IPAddr UDP src 1701 dst I-Port
Для входящего трафикаfrom I-IPAddr1 to R-IPAddr11 UDP 1src I-Port1 dst 17011
from Any-Addr to R-IPAddr1 UDP src Any-Port dst 1701

Между L2TP и IPSec должны существовать такие механизмы, чтобы L2TP мог не передавать повторно SCCRQ, если SA уже установлена.

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

SCCRQ должно посылаться от Инициатора к Получателю только после того, как SA фазы II между участниками установлена.

Если Получатель не использует новый IP-адрес или порт, то установление L2TP-туннеля может быть продолжено.

Получатель выбрал новый IP-адрес

Опишем процесс, который выполняется, если Получатель решает ис-пользовать новый IP-адрес. После получения SCCRQ и перед отправлением SCCRP у Получателя существует единственная возможность изменить свой IP-адрес.

Новый адрес, который выбирает Получатель, должен быть указан в AVP Result и Error Code в STOPCCN сообщении. Сообщение STOPCCN посылается на тот же самый адрес и UDP-порт, которые Инициатор ис-пользовал для посылки SCCRQ. Данное сообщение будет защищено начальными SA, установленными для защиты SCCRQ.

При получении STOPCCN Инициатор должен извлечь IP-адрес и вста-вить новый набор записей в БД политик IPSec. Если используется аутентификация по предварительно распределенному секрету, L2TP может запросить IKE связать новый IP-адрес с этим секретом, который использовался для исходного IP-адреса.

Так как IP-адрес Получателя был изменен, то между участниками должны быть установлены новые SA фазы I и II до того, как будет послано новое SCCRQ.

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

Таблица 10.5.
Записи на стороне Инициатора:
Для исходящего трафикаfrom I-IPAddr to R-IPAddr2 UDP src I-Port dst 1701
Для входящего трафикаfrom R-IPAddr2 to I-IPAddr UDP src 1701 dst I-Port
from R-IPAddr2 to I-IPAddr UDP srcAny-Port dstI-Port

После того, как II фаза IKE завершится, новый набор записей у Полу-чателя будет следующим:

Таблица 10.6.
Записи на стороне Получателя:
Для исходящего трафикаfrom R-IPAddr2 to I-IPAddr UDP src 1701 dst I-Port
from Any-Addr to R-IPAddr1 UDP src Any-Port dst 1701

Если Получатель не изменил номер порта, то установка L2TP-туннеля может быть завершена.

Получатель выбрал новый номер порта

Получатель может решить использовать новый UDP-порт источника для трафика L2TP-туннеля. Это решение должно быть принято до посылки SCCRP. Если выбран новый номер порта, то L2TP должен вставить новые записи в БД политик IPSec. Получатель должен начать с Инициатором новую II фазу переговоров IKE.

Заключительный набор записей у Инициатора и Получателя следующий:

Таблица 10.6.
Записи на стороне Инициатора:
Для исходящего трафикаfrom I-IPAddr to R-IPAddr UDP src I-Port dst R-Port
from I-IPAddr to R-IPAddr UDP src I-Port dst 1701
Для входящего трафикаfrom R-IPAddr to I-IPAddr UDP src R-Port dst I-Port
from R-IPAddrto I-IPAddrUDP src 1701dst I-Port
from R-IPAddr to I-IPAddr UDP srcAny-Port dstI-Port

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

Таблица 10.7.
Записи на стороне Получателя:
Для исходящего трафикаfromR-IPAddr to I-IPAddr UDP srcR-Port dstI-Port
fromR-IPAddrto I-IPAddrUDPsrc1701dstI-Port
Для входящего трафикаfromI-IPAddrto R-IPAddr UDP srcI-Port dstR-Port
fromI-IPAddrto R-IPAddrUDPsrcI-Port dst 1701
fromAny-Addrto R-IPAddr1UDP srcAny-Port dst 1701

После того, как переговоры завершены, посылается SCCRP, и установление L2TP-туннеля может быть завершено. После того, как L2TP-туннель установлен, любые оставшиеся SA и связанные с ними записи могут быть удалены.

Обсуждение топологий шлюз-шлюз и исходящего канала L2TP

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

Таблица 10.8.
Для входящего трафика from Any-Addr to R-IPAddr1 UDP srcAny-Port dst 1701

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

Обсуждение безопасности

  1. Различия между IKE- и РРР-аутентификацией

    Во время переговоров IPSec IKE должен быть выбран метод аутентификации. В дополнение к IKE-аутентификации L2TP-протокол использует методы РРР-аутентификации. Обсудим проблемы, связанные с аутентификацией.

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

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

    Другое различие состоит в том, что идентификация, предоставляемая РРР, является идентификацией на уровне пользователя, а идентификация, предоставляемая IKE, является идентификацией на уровне компьютера.

    Так как только идентификация компьютера проверяется на уровне пакетов, то не существует способа проверить, что только аутентифицированный РРР-пользователь использует туннель. ПО IPSec, обеспечивающее аутентификацию на уровне компьютера, обычно не имеет возможности сегрегации трафика на уровне различных пользователей данного компьютера. Как следствие, если используется аутентификация на уровне компьютера, то после открытия L2TP/IPSec туннеля любой пользователь в многопользовательской среде обычно имеет возможность посылать трафик по туннелю.

    Если ПО IPSec поддерживает аутентификацию на уровне пользователя, то эту проблему можно решить. В этом случае идентификация пользователя, вставленная в IKE, будет проверяться для каждого пакета. Для того, чтобы обеспечить сегрегацию трафика между пользователями, если используется аутентификация на уровне пользователя, клиент должен гарантировать, что по L2TP-туннелю посылается только трафик определенного пользователя.

  2. Аутентификация по сертификатам в IKE

    Если в IKE выбрана аутентификация с помощью сертификатов Х.509, то считается, что в LNS для запроса сертификата клиента в IKE будет использоваться специальное содержимое CERP. В LNS может присутствовать несколько CERP, если несколько сертификационных центров являются доверенными, т.е. сконфигурированы в политике аутентификации IPSec IKE.

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

    LNS может динамически назначать порты источника и получателя только в том случае, если об этом договорились в IKE.

  3. Сравнение аутентификации в IKE по сертификатам пользователя и компьютера

    Сертификаты, предоставляемые L2TP-клиентом для переговоров IKE, могут быть выпущены кака для компьютера, так и для пользователя. Когда используется аутентификация на уровне компьютера, сертификат компьютера обычно хранится в LAC или LNS. Когда используется сертификат пользователя, он может храниться как в компьютере, так и на смарт-карте.

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

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

  4. Использование аутентификации по общему секрету

    Использование аутентификации по общему секрету в Main Mode IKE уязвимо для атак "man-in-the-middle", когда этот секрет используется для получения удаленного доступа. В Main Mode использование SKEYID_e необходимо до получения идентификации. Следовательно, выбор разделяемого ключа может быть сделан только на основании информации, содержащейся в IP-заголовке. Однако в случае удаленного доступа обычно IP-адрес назначается динамически, поэтому часто бывает невозможно определить требуемый разделяемый ключ, основываясь только на IP-адресе.

    Таким образом, когда в сценариях удаленного доступа используется аутентификация по общему секрету, один и тот же секрет используется группой пользователей. В такой ситуации невозможна ни идентификация сервера, ни идентификация клиента в I фазе IKE; возможно только доказать, что оба участника являются членами группы, которые знают разделя-емый секрет. Это допускает ситуацию, когда кто-либо может получить доступ к разделяемому секрету группы и выполнить атаку "man-in-the-middle".

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

    В результате этого, если используется Main Mode с разделяемыми секретами и если РРР не выполняет взаимную аутентификацию, то сервер не аутентифицирован. Это дает возможность поддельному серверу получить доступ к групповому разделяемому секрету для успешной подделки под LNS и провести словарную атаку на такие наследуемые методы аутентификации как СНАР. Такая атака может потенциально компрометировать достаточно большое количество паролей. Подобная уязвимость существует в некоторых реализациях туннельного режима IPSec.

    Чтобы избежать подобной проблемы, производители L2TP/IPSec не должны использовать групповой разделяемый секрет для IKE-аутентификации в LNS. Разделяемый ключ IKE должен быть защищен аналогично тому, как защищены пароли пользователей, используемые в L2TP.

  5. Безопасное взаимодействии IPSec и РРР

    Когда L2TP защищен с помощью IPSec, доступны сервисы безопасности как РРР, так и IPSec. Какие сервисы будут использоваться, зависит от того, является ли туннель обязательным или добровольным. Проанализируем сценарии обязательного и добровольного туннелирования.

    Будем предполагать, что как клиенты, так и сервера L2TP могут устанавливать и получать свойства IPSec SA, а также влиять на сервисы безопасности IPSec, о которых ведутся переговоры. Более того, будем предполагать, что клиенты и серверы L2TP могут влиять на процесс переговоров относительно РРР-шифрования и сжатия.

    Обязательное туннелирование

    В случае обязательного туннеля клиент посылает РРР-кадры к LAC и обычно не знает, что кадры туннелируются или что какие-либо сервисы безопасности имеют место между LAC и LNS. LNS получает пакет данных, который содержит РРР-кадр, инкапсулированный в L2TP, который сам в свою очередь инкапсулирован в IP-пакет. Получая свойства SA, установ-ленной между LNS и LAC, LNS может иметь информацию о сервисах без-опасности, которые установлены между ним самим и LAC. Таким образом, в случае обязательного туннелирования клиент и LNS имеют не одинаковые знания о сервисах безопасности, установленных между ними.

    Так как LNS может узнать, имеется ли конфиденциальность, целостность, аутентификация и защита от replay-атак между ним и LAC, он может использовать эти знания для модификации своего поведения при переговорах РРР ЕСР и ССР. Предположим, что политика конфиденциальности LNS может быть описана одним из следующих терминов: "Требуется шифрование", "Допустимо шифрование" и "Запрещено шифрование". Если сервисы конфиденциальности IPSec имеют место, то LNS устанавливает политику "Запрещено шифрование". Это не тоже самое, что просто отключить РРР-шифрование и сжатие, так как в этом случае окончательное решение зависит от политики клиента.

    Так как клиент не знает о сервисах безопасности, используемых между LAC и LNS, и так как для соединения между клиентом и LAC также могут требоваться сервисы безопасности, клиент обычно использует РРР-шифрование между ним и LNS.

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

    В результате этого LAC может вести переговоры с LNS для ESP с нулевым шифрованием, а LNS может обеспечивать защиту от replay-атак. Это гарантирует, что сервисы конфиденциальности и сжатия не будут дублироваться между LAC и LNS.

    Добровольное туннелирование

    В случае добровольного туннелирования клиент посылает L2TP-пакеты к NАS, который затем их маршрутизирует к LNS. В случае dial-up эти L2TP-пакеты будет инкапсулированы в IP и РРР. В этом случае клиент знает сервисы безопасности между ним и LNS. Он также знает о сервисах РРР-шифрования и сжатия, о которых были переговоры между ним и NAS.

    Так как LNS имеет возможность узнать, используется ли конфиденциальность, аутентификация, проверка целостности и защита от replay-атак между ним и клиентом, он может использовать эту информацию для модификации переговоров РРР ЕСР и ССР. Если установлена IPSec-конфиденциальность, то LNS может считать, что директива "Требуется шифрование" установлена, и не обязательно использовать РРР-шифрование и сжатие. Обычно LNS не требует, чтобы РРР-шифрование и сжатие были выключены, предоставляя решение об этом принимать клиенту.

Лекция 18. Соединение сетей протоколом GRE/IPSec в транспортном режиме

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec. VPN с использованием IPSec будем создавать в транспортном режиме. Для туннеля между двумя локальными сетями будет использовать протокол GRE.

Топология сети аналогична топологии VPN/IPSec.

Топология сети



Описание практической работы

Межсетевой Экран 1

Аутентификационный Объект

Используем аутентификационный объект Pre-Shared Key, созданный в предыдущей лабораторной работе.

Объекты Адресной Книги

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: gre
Object → Address Book → gre → Add



Командная строка:

add Address AddressFolder gre
cc Address AddressFolder gre
add IP4Address gre_ip Address=192.168.35.10

GRE- и IPSec-Интерфейсы

Создать GRE-Интерфейс.

Веб-интерфейс:

Interfaces → GRE → Add → GRE Tunnel



Командная строка:

add Interface GRETunnel gre Network=remote/rem_lan IP=gre/gre_ip RemoteEndpoint=wan2/wan2_gw

Создать IPSec-интерфейс. Так как туннель между двумя локальными сетями создается с помощью протокола GRE, то для протокола IPSec следует использовать транспортный режим.

Веб-интерфейс:

Interfaces → IPsec → Add → IPsecTunnel

На вкладке General указать сети перед и за туннелем, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.

Командная строка:

add Interface IPsecTunnel ipsec_gre LocalNetwork=wan2/wan2_ip RemoteNetwork=wan2/wan2_gw AuthMethod=PSK PSK=forIPSec 
IKEAlgorithms=Medium IPsecAlgorithms=Medium EncapsulationMode=Transport RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты к сетям через интерфейсы wan1, gre и ipsec.



Правила фильтрования

Правила фильтрования достаточно задать для GRE-интерфейса.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre_ipsec
Rules → IP Rules → gre → Add



Командная строка:

add IPRuleFolder Name=gre_ipsec
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan SourceNet-work=lan/lan_net DestinationInterface=gre DestinationNet-work=remote/rem_lan Service=all_services Name=gre_out

Межсетевой Экран 2

Аутентификационный Объект

Используем аутентификационный объект Pre-Shared Key, созданный в Лабораторной работе 9.

Объекты Адресной Книги

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: gre
Object → Address Book → gre → Add



Командная строка:

add Address AddressFolder gre
cc Address AddressFolder gre
add IP4Address gre_ip Address=192.168.35.20

GRE- и IPSec-Интерфейсы

Создать GRE-Интерфейс.

Веб-интерфейс:

Interfaces → GRE → Add → GRE Tunnel



Командная строка:

add Interface GRETunnel gre Network=remote/rem_lan 
IP=gre/gre_ip RemoteEndpoint=wan2/wan2_gw

Создать IPSec-интерфейс. Так как создается туннель между двумя локальными сетями создается с помощью протокола GRE, то для протокола IPSec следует использовать транспортный режим.

Веб-интерфейс:

Interfaces → IPsec → Add → IPsecTunnel

На вкладке General указать сети перед и за туннелем, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.

Командная строка:

add Interface IPsecTunnel ipsec_gre LocalNetwork=wan2/wan2_ip RemoteNetwork=wan2/wan2_gw AuthMethod=PSK PSK=forIPSec 
IKEAlgorithms=Medium IPsecAlgorithms=Medium EncapsulationMode=Transport RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты к сетям через интерфейсы wan1,gre и ipsec.



Правила фильтрования

Правила фильтрования достаточно задать для GRE-интерфейса.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: gre_ipsec
Rules → IP Rules → gre_ipsec → Add



Команднаястрока:

Add IPRuleFolderName=gre_ipsec
cc IPRuleFolder <N folder>
Add IPRule Action=Allow SourceInterface=gre 
SourceNetwork=remote/rem_lan DestinationInterface=lan 
DestinationNetwork=lan/lan_net Service=all_services Name=gre_in

Проверка конфигурации

На Сервере 1 выполним команду ping.



Получим дамп трафика аналогично тому, как это делалось в предыдущих лабораторных работах.

На интерфейсе wan1 видим следующий трафик:



После обмена IKE-содержимыми трафик зашифрован, на интерфейсе wan1 он не виден.

На интерфейсе ipsec видим следующий трафик:



Между интерфейсами ipsec поднят GRE-туннель.

Лекция 19. Соединение сетей протоколом L2TP/IPSec в транспортном режиме

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec. VPN с использованием IPSec будем создавать в транспортном режиме. Для туннеля между двумя локальными сетями будет использовать протокол L2TP.

Топология сети аналогична топологии VPN/IPSec.

Топология сети



Описание практической работы

Межсетевой Экран 1

Аутентификационный Объект

Используем аутентификационный объект Pre-Shared Key, созданный в предыдущей лабораторной работе.

L2TP- и IPSec-Интерфейсы

Создать L2TP-интерфейс аутентифицируемой стороны туннеля.

Веб-интерфейс

Interfaces → PPTP/L2TPClients → Add → PPTP/L2TPClient

На вкладке General указать туннелирующий протокол, адрес конеч-ной точки и сеть, расположенную за туннелем.

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



На вкладке Security следует отключить всё шифрование, так как шифрование трафика будет выполнять протокол IPSec.



Командная строка

add Interface L2TPClient l2tp_client Network=remote/rem_lan RemoteEndpoint=wan2/wan2_gw Username=l2tp_u 
Password=qwerty TunnelProtocol=L2TP MPPENone=No MPPERC4128=No MPPERC440=No MPPERC456=No

Создать IPSec-интерфейс.

Веб-интерфейс

Interfaces → IPsec → Add → IPsec Tunnel

На вкладке General указать конечные точки туннеля, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.

Командная строка

add Interface IPsecTunnel IPSec_l2tp 
LocalNetwork=wan2/wan2_ip RemoteNetwork=wan2/wan2_gw 
AuthMethod=PSK PSK=ipsec_psk 
IKEAlgorithms=Medium IPsecAlgorithms=Medium 
EncapsulationMode=Transport RemoteEndpoint=wan2/wan2_gw

Статическая маршрутизация

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



Правила фильтрования

Правила фильтрования достаточно задать для L2TP-интерфейса. Пра-вило должно разрешать исходящий трафик с lan-интерфейса на созданный L2TP-интерфейс.

Веб-интерфейс

Rules → IP Rules → Add → IP Rule Folder
	Name: ipsec_l2tp
Rules → IP Rules → ipsec_l2tp → Add



Командная строка

add IPRuleFolder Name=ipsec_l2tp
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=l2tp_client DestinationNetwork=remote/rem_lan Service=all_services Name=ipsec_l2tp_in

Межсетевой Экран 2

Аутентификационный Объект

Используем аутентификационный объект Pre-Shared Key, созданный в предыдущей лабораторной работе.

Объекты Адресной Книги

Создать пул IP-адресов.

Веб-интерфейс

Object → Address Book → Add → Address Folder
	Name: l2tp
Object → Address Book → l2tp → Add



Командная строка

add Address AddressFolder l2tp
cc Address AddressFolder l2tp
add IP4Address l2tp_pool Address=192.168.3.25-192.168.3.29

IP-адреса из этого пула будут выдаваться l2tp-клиенту.

L2TP- и IPSec-Интерфейсы

Создать IPSec-интерфейс.

Веб-интерфейс

Interfaces → IPsec → Add → IPsec Tunnel

На вкладке General указать конечные точки туннеля, а также режим выполнения IPSec и используемые наборы алгоритмов для IPSec и IKE.



На вкладке Authentication указать созданный аутентификационный объект.

Командная строка

add Interface IPsecTunnel IPSec_l2tp LocalNetwork=wan2/wan2_ip RemoteNetwork=wan2/wan2_gw AuthMethod=PSK PSK=ipsec_psk IKEAlgorithms=Medium 
IPsecAlgorithms=Medium EncapsulationMode=Transport 
RemoteEndpoint=wan2/wan2_gw

Создать L2TP-интерфейс, который будет аутентифицировать противо-положную сторону туннеля.

Веб-интерфейс

Interfaces → PPTP/L2TP Servers → Add → PPTP/L2TP server

На вкладке General указываются параметры туннеля. В качестве ин-терфейса указывается ipsec.



На вкладке РРР Parameters снять параметры РРР-шифрования и ука-зать пул IP-адресов, из которого будут выдаваться IP-адреса клиенту.



Командная строка

add Interface L2TPServer l2tp_server Interface=ipsec_l2tp IP=lan/lan_ip 
ServerIP=wan2/wan2_ip IPPool=l2tp/l2tp_pool TunnelProtocol=L2TP 
MPPENone=No MPPERC4128=No MPPERC440=No MPPERC456=No

Статическая маршрутизация

В таблице маршрутизации должны быть маршруты к сетям через интерфейсы wan1 и ipsec. Маршрут через интерфейс l2tp будет добавлен динамически.



Правила фильтрования

Правила фильтрования достаточно задать для L2TP-интерфейса.

Веб-интерфейс:

Rules → IP Rules → Add → IP Rule Folder
	Name: l2tp
Rules → IP Rules → l2tp → Add



Командная строка

add IPRuleFolder Name=ipsec_l2tp
cc IPRuleFolder <N folder>
add IPRule Action=Allow SourceInterface=l2tp_server SourceNetwork=remote/rem_lan DestinationInterface=lan DestinationNetwork=lan/lan_net Service=all_services Name=ipsec_l2tp_in

Аутентификация на уровне пользователя

Создать локальную базу данных пользователей.

Веб-интерфейс:

User Authentication → Local User Databases → Add → Local User Database

На вкладке General указать имя базы данных.



На вкладке Users добавить учетные записи пользователей.



Командная строка

add LocalUserDatabase l2tp_ua
add User olga Password=qwerty AutoAddRouteNet=remote/rem_lan

Создать правило аутентификации пользователей.

Веб-интерфейс:

User Authentication → User Authentication Rules → Add
	Name: l2tp_rules

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



На вкладке Authentication Options указать имя локальной базы данных пользователей.



На вкладке Agent Options указать параметры РРР-аутентификации.



Командная строка

add UserAuthRule AuthSource=Local Interface=l2tp_server 
LocalUserDB=l2tp_ua OriginatorIP=wan2/wan2_gw Agent=PPP 
TerminatorIP=wan2/wan2_ip Name=l2tp_rules

Проверка конфигурации

На рабочей станции, расположенной в локальной сети за межсетевым экраном 1, выполним команду ping.



Получим дамп трафика аналогично тому, как это делалось в предыдущих лабораторных работах.

На интерфейсе wan2 видим IPSec-трафик.



На интерфейсе IPSec_l2tp видим L2TP-трафик.



На интерфейсе l2tp_server видим ICMP-трафик.

Лекция 20. Соединение двух сетей протоколом L2TP/IPSec в транспортном режиме, для одной из локальных сетей используется NAT

Цель

Соединить две сети, расположенные за межсетевыми экранами, VPN с использованием семейства протоколов IPSec. VPN с использованием IPSec будем создавать в транспортном режиме. Для туннеля между двумя ло-кальными сетями будет использовать протокол L2TP. Локальная сеть, рас-положенная за L2TP-клиентом, используется NAT.

Топология сети аналогична топологии VPN/IPSec.

Топология



Описание практической работы

Межсетевой Экран 1

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

L2TP- и IPSec-Интерфейсы

NAT выполняется для L2TP-адресов. Поддержка NAT для IPSec не требуется



Правила фильтрования

В Правилах фильтрования вместо действия Allow следует указать действие NAT.



Межсетевой Экран 2

L2TP- и IPSec-Интерфейсы

NAT выполняется для L2TP-адресов. Поддержка NATдля IPSec не требуется.



Правила фильтрования

В Правилах фильтрования вместо сети remote_lan следует указать пул IP-адресов, из которого выделяется IP-адрес противоположной стороне L2TP-туннеля.

Веб-интерфейс:

Rules→IPRules→l2tp



Командная строка

set IPRule 1 DestinationNetwork=l2tp/l2tp_pool

Аутентификация на уровне пользователя

В описании параметров пользователя вместо сети remote_lan следует указать пул IP-адресов, из которого выделяется IP-адрес противоположной стороне L2TP-туннеля.



Проверка конфигурации

На рабочей станции, расположенной за межсетевым экраном 1, выполним команду ping.



Получим дамп трафика аналогично тому, как это делалось в предыдущих лабораторных работах.

На интерфейсе wan2 видим IPSec-трафик.



На интерфейсе IPSec_l2tp видим L2TP-трафик.



На интерфейсе l2tp_server видим ICMP-трафик.

IP-адрес источника в ICMP-запросе принадлежит пулу IP-адресов, указанному для L2TP-клиента.



Лекция 21. Протокол SSL/TLS

Обзор

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

Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет TLS иметь обратную совместимость с SSL 3.0.

Перечислим задачи протокола SSL/TLS в порядке их приоритета:

  1. Криптографическая безопасность: SSL/TLS должен использоваться для установления криптографически безопасного соединения между двумя участниками.
  2. Интероперабельность: независимые разработчики должны иметь возможность создавать приложения, которые будут взаимодействовать по протоколу SSL/TLS, что позволит устанавливать безопасные соединения.
  3. Расширяемость: SSL/TLS определяет общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования. Это избавляет от необходимости создавать новый протокол для использования новых алгоритмов, что сопряжено с опасностью появления новых слабых мест, и исключает необходимость полностью реализовывать новую библиотеку криптографических алгоритмов.
  4. Относительная эффективность: криптографические операции интенсивно используют ЦП, особенно операции с открытым ключом. Для уменьшения вычислительной нагрузки вводится понятие сессии, в рамках которой может быть создано несколько ТСР-соединений. SSL/TLS позволяет кэшировать параметры сессии для уменьшения количества выполняемых криптографических операций при установлении соединения. Это снижает нагрузку как на ЦП, так и на трафик.

Протокол состоит из двух уровней. Нижним уровнем, расположенным выше некоторого надежного протокола (а именно, протокола ТСР) является протокол Записи. Протокол Записи обеспечивает безопасность соединения, которая основана на следующих двух свойствах:

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

Протокол Рукопожатия обеспечивает безопасность соединения, которая основана на следующих свойствах:

  1. Участники аутентифицированы с использованием криптографии с открытым ключом (т.е. с использованием алгоритмов RSA, DSS и т.д.). Эта аутентификация может быть необязательной, но обычно требуется по крайней мере для сервера.
  2. Переговоры о разделяемом секрете безопасны, т.е. этот общий секрет невозможно подсмотреть.
  3. Переговоры о разделяемом секрете надежны, если выполнена аутентификация хотя бы одной из сторон. В таком случае ата-кующий, расположенный в середине соединения, не может модифицировать передаваемый секрет незаметно для участ-ников соединения.

Одно из преимуществ TLS состоит в том, что он независим от при-кладного протокола.

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

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

Протокол Записи

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

Выше протокола Записи могут располагаться следующие протоколы: протокол Рукопожатия, Аlert-протокол, протокол изменения шифрования и прикладной протокол, безопасность которого обеспечивается.

Состояния соединения

В протоколе вводится понятие состояния соединения, которое определяет параметры выполнения протокола Записи. Такими параметрами являются алгоритм сжатия, алгоритм шифрования и МАС-алгоритм, а также параметры этих алгоритмов, т.е. секреты МАС, ключи алгоритма шифрования и инициализационные вектора. Для каждого направления (соответственно чтение или запись) параметры соединения могут различаться. Существует четыре состояния соединения: текущие состояния чтения и записи и ожидаемые состояния чтения и записи. Параметры безопасности для ожидаемых состояний устанавливаются протоколом Рукопожатия, а протокол изменения шифрования делает ожидаемое состояние текущим, в результате чего соответствующие параметры текущего состояния сбрасываются и заменяются параметрами ожидаемого состояния. Параметры ожидаемого состояния инициализируется пустыми значениями. Вначале текущее состояние всегда определяется без использования шифрования, сжатия и МАС.

Определены следующие параметры состояния:

Таблица 11.1.
Конец соединения Каждый участник является либо "клиентом", либо "сервером"
Алгоритм симметричного шифрования Алгоритм, используемый для симметричного шифрования, и его параметры – длина ключа алгоритма, длина блока алгоритма, ключ шифрования, инициализационный вектор (IV) и др.
МАС алгоритм Алгоритм, используемый для проверки целостности сообщения, секрет МАС.
Алгоритм сжатия Алгоритм, используемый для сжатия данных.
Мастер-секрет 48-байтный секрет, разделяемый обоими участниками соединения.
Случайное число клиента SecurityParameters.client_random 32-байтное значение, создаваемое клиентом в протоколе Рукопожатия.
Случайное число сервера SecurityParameters.server_random 32-байтное значение, создаваемое сервером в протоколе Рукопожатия.
Последовательный номер Каждое состояние соединения содержит последовательный номер, который вычисляется независимо для состояний чтения и записи. Последовательный номер должен устанавливаться в ноль при инициализации состояния. Последовательные номера не могут быть больше 264 - 1. Последовательный номер возрастает после создания очередной записи.

Из мастер-секрета создаются шесть ключей:

Ключи client write используются сервером, когда он получает сообщения и клиентом, когда тот посылает их. Ключи server write используются сервером, когда он посылает сообщения и клиентом, когда он получает их. После того как параметры безопасности установлены и ключи созданы, ожидаемые состояния соединения делаются текущими.

Вычисление ключей

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

НМАС и псевдослучайная функция

Для обеспечения целостности используется НМАС с хэш-функциями MD5 и SHA-1, обозначаемыми как HMAC_MD5 (secret,data) и HMAC_SHA (secret, data).

В алгоритме определена псевдослучайная функция PRF, которая расширяет секрет до нужной длины для создания всех необходимых ключей. Эта функция получает в качестве входа секрет, "зерно" (seed - значение, которое с одной стороны является случайным, а с другой стороны не явля-ется секретным, т.е. может стать известно оппоненту) и стандартное значение, и создает выход требуемой длины.

Сначала определяется функция расширения данных P_hash (secret, data), которая использует хэш-функцию для расширения секрета до нужной длины следующим образом:

P_hash (secret, seed) = HMAC_hash (secret, A(1) || seed) || 
HMAC_hash (secret, A(2) || seed) ||
HMAC_hash (secret, A(3) || seed) ||

А (i) определяется следующим образом:

А (0) = seed
A (i) = HMAC_hash (secret, A (i - 1))

P_hash может иметь столько итераций, сколько необходимо для создания данных требуемой длины. Например, если P_SHA-1 используется для создания 64 байтов данных, то количество итераций должно быть равно 4, при этом будет создано 80 байтов данных; последние 16 байтов заключительной итерации будут отброшены, чтобы оставить только 64 байта выходных данных.

Для получения ключевого материала нужной длины секрет, вычисленный в протоколе Рукопожатия, делится на две половины, одна половина используется для создания данных с помощью P_MD5, а другая - для созда-ния данных с помощью P_SHA-1.

PRF определяется как результат сложения по модулю 2 результатов выполнения P_MD5 и P_SHA-1.

PRF (secret, label, seed) = P_MD5 (S1, label + seed) ⊕ 
P_SHA-1 (S2, label + seed)

Label является фиксированной текстовой строкой.

Заметим, что поскольку MD5 создает 16-байтные значения, а SHA-1 создает 20-байтные значения, то количество итераций каждой из функций будет разным. Например, для создания 80-байтного значения необходимо выполнить 5 итераций P_MD5 и 4 итерации P_SHA-1.

Для создания ключей вычисляется следующее значение:

key_block = PRF (SecurityParameters.master_secret,
"key expansion",  
SecurityParameters.server_random + SecurityParame-ters.client_random)

Количество итерация в PRF определяется суммарной длиной ключей. Затем key_block разбивается на блоки для получения требуемых ключей.

Протокол Рукопожатия

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

В результате выполнения протокола Рукопожатия будут созданы следующие элементы сессии:

Таблица 11.1.
Идентификатор сессииПроизвольная последовательность байтов, выбираемая сервером для идентификации активного или возобновляемого состояния сессии.
Сертификат участника Х.509 v3 сертификат участника. Этот элемент может быть нулевым.
Метод сжатия Алгоритм, используемый для сжатия данных перед шифрованием.
Набор алгоритмов Алгоритм симметричного шифрования данных (например, NULL, DES, AES и т.д.), МАС-алгоритм (такой как MD5 или SHA-1) и параметры этих алгоритмов.
Мастер-секрет 48-байтный секрет, разделяемый клиентом и сервером.
Возобновляемо Флаг, определяющий, может ли данная сессия использоваться для создания нового ТСР-соединения.

Протокол изменения шифрования

Протокол состоит из единственного сообщения, которое зашифровано и сжато, как определено в текущем состоянии соединения.

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

Alert-протокол

Одним из протоколов, выполняющихся выше протокола Записи, является протокол Аlert. Содержимым протокола является либо фатальное, либо предупреждающее сообщение. Фатальное сообщение должно приводить к немедленному разрыву данного ТСР-соединения. В этом случае другие соединения, соответствующие данной сессии, могут быть продолжены, но идентификатор сессии должен быть помечен как недействительный для предотвращения использования данной сессии для установления новых соединений. Подобно другим сообщениям, сообщения Alert зашифрованы и сжаты, как определено в текущем состоянии соединения.

Протокол Рукопожатия

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

Протокол Рукопожатия состоит из следующих шагов:

  1. Обмен сообщениями Hello для согласования алгоритмов, обмена случайными значениями и проверки возобновляемости сессии.
  2. Обмен необходимыми криптографическими параметрами, которые позволяют клиенту и серверу согласовать премастер-секрет.
  3. Обмен сертификатами и криптографической информацией, которая позволяет клиенту и серверу аутентифицировать друг друга.
  4. Предоставление параметров безопасности на уровень Записи.
  5. Возможность клиенту и серверу проверить, что они вычислили одни и те же параметры безопасности и что Рукопожатие произошло без вмешательства злоумышленника.

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

Клиент посылает сообщение ClientHello, на которое сервер должен ответить сообщением ServerHello или фатальной ошибкой и разрывом соединения. ClientHello и ServerHello используются для определения максимального уровня безопасности между клиентом и сервером. Client Hello и Server Hello устанавливают следующие атрибуты: Protocol Version, Session ID, Cipher Suite и Compression Method. Дополнительно создаются и передаются два случайных значения: ClientHello.random и ServerHello.random.

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

После сообщений Hello сервер посылает сертификат, с помощью которого клиент выполняет аутентификацию сервера. Дополнительно может быть послано сообщение обмена ключа сервера, если сервер не имеет сертификата или его сертификат может использоваться только для проверки подписи. Если сервер аутентифицирован, он может запросить сертификат клиента, если того требует установленная политика безопасности на стороне сервера. После этого сервер посылает сообщение Server Hello Done, указывающее на то, что фаза Hello-сообщений рукопожатия завершена. Затем сервер ждет ответа клиента. Если сервер послал сообщение запроса сертификата, клиент должен послать сообщение Certificate. После этого посылается сообщение обмена ключа клиента. Содержимое этого сообщения зависит от выбранного алгоритма выработки общего секрета. Если клиент посылал свой сертификат, то он посылает сообщение, содержащее цифровую подпись для проверки всех сообщений Рукопожатия.

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

Последовательность сообщений при полном Рукопожатии


Рис. 11.1.  Последовательность сообщений при полном Рукопожатии

Когда клиент и сервер решают возобновить предыдущую сессию или дублировать существующую (вместо того чтобы вести новые переговоры о параметрах безопасности), выполняется так называемое сокращенное рукопожатие:

Поток сообщений при сокращенном Рукопожатии

Последовательность сообщений при сокращенном Рукопожатии


Рис. 11.2.  Последовательность сообщений при сокращенном Рукопожатии

Следует заметить, что, так как Session ID передается без шифрования и обеспечения целостности, он не содержит конфиденциальную информацию. Содержимое всего Рукопожатия, включая Session ID, защищено Finished-сообщениями, которыми участники обмениваются в конце рукопожатия.

Список Cipher Suite, передаваемый от клиента серверу в сообщении Client Hello, содержит перечень криптографических алгоритмов, поддерживаемых клиентом, упорядоченный по предпочтениям клиента. Сервер выбирает по одному алгоритму из каждой категории, который он поддерживает. Если такого алгоритма не существует, сервер возвращает фатальный Alert и закрывает соединение.

После посылки сообщения Client Hello клиент ждет сообщения Server Hello. Любое другое сообщение, возвращаемое сервером, за исключением Hello Request, трактуется как фатальная ошибка.

Сервер посылает Server Hello в ответ на сообщение Client Hello, для того чтобы выбрать конкретный набор алгоритмов. Если для какого-то типа алгоритмов клиент и сервер не имеют одинакового алгоритма, ТСР-соединение будет сброшено.

Сообщение Certificate (сервера)

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

Тип сертификата должен соответствовать выбранному алгоритму обмена ключа. Обычно это сертификат X.509v3. Он должен содержать ключ, который соответствует методу обмена ключа.

Сообщение сервера обмена ключа посылается сервером только тогда, когда сообщение Server Certificate (если оно послано) не содержит достаточно данных для того, чтобы клиент мог осуществить обмен премастер-секретом.

Данное сообщение передает криптографическую информацию, которая позволяет клиенту передавать премастер-секрет: премастер-секрет шифруется либо открытым ключом RSA, либо открытым ключом Диффи-Хеллмана.

Сообщение Certificate Request

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

Сообщение Server Hello Done

Сообщение Server Hello Done посылается сервером как признак окончания фазы Server Hello.

Сообщение Certificate (клиента)

Это первое сообщение, которое клиент посылает после получения сообщения Server Hello Done. Оно посылается только в том случае, если сервер запросил аутентификацию клиента.

Сообщение Client Key Exchange

Данное сообщение посылается клиентом всегда. Оно следует сразу за сообщением Client Certificate, если оно посылалось. В противном случае это первое сообщение, посланное клиентом после получения сообщения Server Hello Done.

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

Проверка целостности с помощью сертификата клиента

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

Сообщение Finished

Сообщение Finished всегда посылается непосредственно после сообщения Сhange Сipher Spec для проверки успешного выполнения обмена ключа и процессов аутентификации. Сообщение Change Cipher Spec должно быть получено после остальных сообщений Рукопожатия и перед Finished-сообщением.

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

Вычисление мастер-секрета

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

master_secret = PRF(pre_master_secret, "master se-cret",ClientHello.random+ServerHello.random)       [0..47]

Длина мастер-секрета всегда равна 48 байтам. Длина премастер-секрета изменяется в зависимости от метода обмена ключа.

Добавление дополнительных возможностей в протокол

Рассмотрим расширения, которые позволяют добавлять новые функциональности в SSL/TLS. Рассмотрим общие механизмы расширений для протокола Рукопожатия и конкретные расширения, используемые для добавления новых возможностей.

Сейчас SSL/TLS используется в самых разных окружениях, возможности которых не учитывались при разработке протокола. Данные расширения разработаны для того, чтобы SSL/TLS мог максимально эффективно функционировать в новых окружениях, такие, например, как беспроводные сети.

Беспроводные окружения часто имеют ряд ограничений, обычно отсутствующих в других окружениях. Эти окружения могут иметь ограничения на полосу пропускания, на вычислительные мощности клиента, на объем памяти и т.п.

Данные расширения предназначены для обеспечения следующих возможностей:

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

Описываемые расширения могут использоваться клиентами и серверами, поддерживающими версию TLS 1.0. Расширения поддерживают обратную совместимость – это означает, что клиенты версии TLS 1.0, которые поддерживают расширения, могут общаться с серверами TLS 1.0, не поддерживающими расширения, и наоборот.

Обратная совместимость достигается следующим образом.

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

В качестве имени сервера как правило, поддерживается только DNS-имя.

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

Переговоры о максимальной длине фрагмента

Прежняя версия SSL/TLS указывает, что максимальная длина незашифрованного фрагмента равна 214 байт. Для некоторых клиентов может требоваться использовать меньшую длину фрагмента из-за ограничений памяти или ограничений полосы пропускания.

Сервер, получивший расширенный Client Hello с расширением Max Fragment Length, может принять эту длину и включить расширение Max Fragment Length в Server Hello.

После того, как стороны успешно договорились о максимальной длине фрагмента, отличной от 214, клиент и сервер должны немедленно начать фрагментировать сообщения (включая сообщения Рукопожатия), чтобы гарантировать, что не посылаются сегменты большей длины, чем та, о ко-торой договорились.

Новая длина применяется в течение всей сессии, включая возобновляемые сессии.

URL сертификат клиента

SSL/TLS требует, чтобы при выполнении аутентификации клиента сертификаты клиента посылались серверу в протоколе Рукопожатия. Для клиентов, имеющих ограничения на память, существует возможность посылать URL сертификата вместо самих сертификатов, чтобы они могли не хранить свои сертификаты и тем самым не занимать память.

Для ведения переговоров о посылке серверу URL сертификата клиенты могут включать расширение типа Client Certificate Url в Client Hello.

Сервер, получивший расширенный Client Hello, содержащий расширение Client Certificate Url, может указать, что имеет возможность принимать URL сертификата, указывая расширение типа Client Certificate Url в Server Hello.

Указание доверенного СА

Клиенты, которые имеют ограниченную память, могут хранить только небольшое количество сертификатов корневых СА. В этом случае они могут указать серверу, какими корневыми сертификатами они владеют.

Для этого клиенты могут включить расширение типа Trusted Ca Keys в Client Hello. Поле Extension Data данного расширения должно содержать Trusted Authorities.

Урезанный НМАС

В настоящий момент набор шифрования использует в качестве МАС НМАС либо с MD5, либо с SHA-1 для аутентификации соединений уровня записи. Результат вычисления хэш-функции используется в качестве значения МАС. Однако в некоторых ограниченных окружениях может оказаться желательным использовать 80-битные значения МАС.

Для того чтобы вести переговоры об использовании 80-битного урезанного МАС, клиенты могут включить расширение Truncated Hmac в расширенный Client Hello.

При получении расширенногоHello, содержащего расширение Truncated Hmac, сервер может согласиться использовать урезанный МАС, включая расширения Truncated Hmac с пустым Extension Data в расширенный Server Hello.

Запрос статуса сертификата

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

Лекция 22. Аутентификация доступа к ресурсам с использованием браузера

Цель

Выполнить аутентификацию локальных пользователей при доступе к ресурсам, расположенным в DMZ. Для доступа к этим ресурсам использу-ется браузер. Межсетевой экран выполняет аутентификацию, используя либо Basic-аутентификацию протокола НТТР, либо аутентификацию с по-мощью HTML-формы, которая задана в настройках самого межсетевого экрана.

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

Можно отредактировать существующую HTML-форму или создать собственную.

Веб-интерфейс:

Object → HTTP Banner Files → Add
	Name: userAuth





Командная строка

1. Переписать файл FormLogin из каталога

HTTPAuthBanners/userAuth/.pscp.exe
admin@<IP-адрес>:HTTPAuthBanners/userAuth/FormLogin FormLogin

2. Отредактировать его редактором.

3. Переписать отредактированный файл в тот же каталог.

Топология сети



Описание практической работы

Правила аутентификации пользователей

1. Создание локальной базы данных пользователей.

Веб-интерфейс:

User Authentication → Local User Databases → Add
	Name: web_auth



User Authentication → Local User Databases → web_auth
Users → Add

Командная строка

add LocalUserDatabase web_auth
cc LocalUserDatabase web_auth

При использовании идентификатора пользователя:



Командная строка

add User olga Password=qwerty

При использовании в правилах аутентификации идентификатора группы вместо идентификатора пользователя следует указать группу, в которую входит данный пользователь:



Командная строка

add User olga Password=qwerty Groups=web_user

2. Создание правила аутентификации пользователей.

Веб-интерфейс:

User Authentication → User Authentication Rules → Add
	Name: web_auth







Командная строка

add UserAuthRule Interface=lan AuthSource=Local 
LocalUserDB=web_auth OriginatorIP=lan/lan_net 
LoginType=HTMLForm HTTPBanners=userAuth Name=web_auth Agent=HTTP

3. Создание объекта в Адресной Книге с адресами локальной се-ти и требованием аутентификации пользователей.

Веб-интерфейс:

Object → Address Book → web_auth → Add
	Name: lan_auth



На вкладке User Authentication указать идентификатор пользователя:



Командная строка

cc Address AddressFolder web_auth
add IP4Address lan_auth Address=192.168.1.0/24 UserAuthGroups=olga

Использование идентификатора группы:



Командная строка

cc Address AddressFolder local_lan
add IP4Address lan_auth Address=192.168.12.0/24 UserAuthGroups=web_user

Правила фильтрования

a) Правило, разрешающее доступ к веб-серверу аутентифицированным пользователям.

Веб-интерфейс:

Rules → IP Rules → web_auth → Add
	Name: http_auth
Rules → IP Rules → web_auth → http_auth



Командная строка

cc IPRuleFolder <N Folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_auth DestinationInterface=dmz DestinationNetwork=dmz/web_server Service=http Name=http_auth

b) Правило, перенаправляющее неаутентифицированных пользо-вателей на межсетевой экран для прохождения аутентификации.

Веб-интерфейс:

Rules → IP Rules → web_auth → Add
	Name: http_sat
Rules → IP Rules → web_auth → http_sat





Командная строка

cc IPRuleFolder <N Folder>
add IPRule Action=SAT SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=dmz DestinationNetwork=dmz/web_server Service=http SATTranslateToIP=lan/lan_ip SATAllToOne=Yes Name=http_sat

c) Правило, разрешающее трафик для выполнения аутентификации пользователей.

Веб-интерфейс:

Rules → IP Rules → local_nets → Add
	Name: http_auth
Rules → IP Rules → local_nets → http_auth



Командная строка

cc IPRuleFolder <NFolder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net DestinationInterface=dmz DestinationNetwork=dmz/web_server Service=http Name=http

Правило, разрешающее трафик к интерфейсу core для доступа к форме аутентификации пользователей.

Веб-интерфейс:

Rules → IP Rules → local_nets → Add
	Name: http_core
Rules → IP Rules → local_nets → http_core



Командная строка

cc IPRuleFolder <N Folder>
add IPRule Action=Allow SourceInterface=lan SourceNetwork=lan/lan_net 
DestinationInterface=core DestinationNetwork=dmz/web_server Service=http Name=http_core

Проверка конфигурации

Используем браузер, в качестве адреса указываем IP-адрес веб-сервера, после чего попадаем на созданную html-страницу.



Проверяем статус аутентифицированных пользователей.



Лекция 23. Аутентификация и хранение учетных записей

Описание лекции

Топология сети

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

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

Как правило, при большом числе пользователей идентификационные и аутентификационные данные хранятся на отдельном сервере. Это позволяет освободить межсетевой экран от необходимости хранить большие объемы идентификационных и аутентификационных данных. Доступ к серверу, на котором хранятся идентификационные и аутентификационные данные, как правило, осуществляется либо по протоколу RADIUS, либо по прото-колу LDAP (рис. 12.1).

Будем предполагать, что сеть имеет следующую топологию.

  1. Пользователю, который вошел на удаленный хост, требуется доступ к серверу, который расположен либо в LAN, либо в DMZ.
  2. Между двумя межсетевыми экранами выполняется один из протоколов VPN, для которого необходима аутентификация пользователя, получающего доступ в локальную сеть или DMZ. В нашем случае аутентификационная информация ука-зывается на МЭ1.
  3. Вся аутентификационная и авторизационная информация хра-нится либо на сервере RADIUS, либо на сервере LDAP.

Топология сети при использовании сервера идентификации


Рис. 12.1.  Топология сети при использовании сервера идентификации

Протокол RADIUS

Основные понятия

Конечная цель – предоставить аутентифицированный и авторизованный доступ пользователю с удаленного хоста к серверу, расположенному в LAN или DMZ. Между МЭ1 и МЭ2 выполняется один из протоколов VPN. Учетные записи пользователей хранятся на сервере RADIUS. Идентифика-ционная и аутентификационная информация указывается на удаленной точке туннеля. Запрос аутентификации и используемый сервер, на котором хранятся идентификационные и аутентификационные данные, указываются на локальной стороне туннеля. При успешной аутентификации пользователю с удаленного хоста предоставляется доступ к серверу, расположенному в LAN или DMZ.

Взаимодействующими сторонами в протоколе RADIUS (Remote Au-thentication Dial In User Service) являются:

Сервер RADIUS– сервер, выполняющий аутентификацию, авторизацию и хранение учетных записей (аккаунтинг). В английском варианте Authentication, Authorization и Accounting – ААА. RADIUS предоставляет сервисы ААА для NAS.

Сервер Сетевого Доступа (Network Access Server – NAS)– устройство, которое предоставляет удаленным пользователям доступ в сеть и является клиентом для сервера RADIUS.

Аутентификация, авторизация и аккаунтинг выполняются для удаленной стороны туннеля, в нашем случае для учетной записи, указанной в конфигурации МЭ1.

Основные принципы функционирования RADIUS:

  1. Клиент-серверная модель функционирования. NAS функционирует как клиент RADIUS. Он пересылает пользовательскую аутентификационную информацию серверу RADIUS и затем выполняет действия в соответствии с полученным ответом.

    Сервер RADIUS получает запрос от NAS, аутентифицирует пользователя и затем возвращает NAS всю необходимую для предоставления сервиса информацию.

    Сервер RADIUS может функционировать как прокси-клиент для других серверов RADIUS или аутентификационных серверов других типов.

  2. Обеспечение сетевой безопасности. Транзакции между NAS и сервером RADIUS аутентифицированы с помощью общего секрета, который никогда не посылается по сети. Кроме того, все пользовательские пароли посылаются между NAS и серве-ром RADIUS в защищенном виде, что исключает возможность просмотра.

    Задание секрета между NAS и сервером RADIUS на стороне NAS


    Рис. 12.2.  Задание секрета между NAS и сервером RADIUS на стороне NAS

    Задание секрета между NAS и сервером RADIUS на стороне сервера RADIUS


    Рис. 12.3.  Задание секрета между NAS и сервером RADIUS на стороне сервера RADIUS

    Защищенность пользовательского пароля при пересылке между NAS и сервером RADIUS


    Рис. 12.4.  Защищенность пользовательского пароля при пересылке между NAS и сервером RADIUS

  3. Гибкие аутентификационные механизмы. RADIUS сервер может поддерживать различные способы аутентификации пользователей. Если используются имя пользователя и пароль, то поддерживаются такие способы аутентификации, как РРР РАР, СНАР и MS-CHAP.

    Параметры РРР-аутентификации на стороне NAS


    Рис. 12.5.  Параметры РРР-аутентификации на стороне NAS

    Параметры РРР-аутентификации на стороне сервера RADIUS


    Рис. 12.6.  Параметры РРР-аутентификации на стороне сервера RADIUS

  4. Расширяемый протокол. Все транзакции состоят из троек значений переменной длины (Атрибут – Длина – Значение). Могут быть добавлены новые атрибуты без изменения существующих реализаций протокола.

В протоколе RADIUS все данные передаются в элементах, которые называются атрибутами.

Атрибуты RADIUS используются для передачи:

Атрибут может быть определен в спецификации протокола RADIUS, и в этом случае говорят, что он является стандартным и принадлежит стандартному пространству имен, либо может быть определен производителем, в этом случае говорят, что он принадлежит пространству имен производи-теля и являются Vendor-Specific Attributes (VSA).

Такие атрибуты определяются производителем и указываются в поле String.

Значение каждого атрибута принадлежит определенному типу данных. В отличие от протокола SNMP в RADIUS нет формального языка определения данных.

Типы данных могут быть "базовые" и "комплексные". Базовые типы данных используют один из существующих типов данных RADIUS, которые могут содержаться в стандартном атрибуте или VSA-атрибуте.

Пример атрибутов RADIUS


Рис. 12.7.  Пример атрибутов RADIUS

Типы данных

В RADIUS определены следующие базовые типы данных:

Следующие типы данных определены как "комплексные":

Пространство имен производителя

Пространство имен производителя обозначается как VSA. При этом Vendor-Id определяет конкретного производителя, а поле String определяет уникальный тип атрибута для данного производителя.

Принципы функционирования RADIUS

Функционирование RADIUS основано на следующих принципах:

Хотя производители серверов RADIUS и могут поддерживать состояние, в самом протоколе RADIUS понятие состояния не определено. Однако определенная информация может передаваться от одной транзакции к другой с помощью атрибута State.

В спецификации RADIUS определены атрибуты, содержащие конфиденциальную информацию (например, пароли). Такие атрибуты не пересылаются в запросе и не возвращаются в ответе в открытом виде. Кроме того, аутентификационный механизм связывает вместе последовательность пакетов Access-Request / Access-Challenge в одной аутентификационной сессии с помощью атрибута State.

Протокол RADIUS является протоколом типа запрос-ответ, выполняющимся между клиентом и сервером RADIUS. Один пакет запроса требует в ответ по крайней мере один пакет, который посылается на IP-адрес и порт клиента.

Длина пакета RADIUS не может быть больше 4096 байтов (октетов).

Даже если длина пакета меньше, чем 4096 байтов, она может быть больше, чем Path MTU (PMTU). Любой пакет, длина которого больше, чем PMTU, будет фрагментирован, что может привести к сложности прохожде-ния межсетевых экранов, которые отбрасывают фрагментированные пакеты. Если приходится использовать фрагментированные пакеты, то необхо-димо тщательное тестирование корректного прохождения всех межсетевых экранов и устройств, которые могут отбрасывать фрагментированные пакеты. Некоторые устройства не могут передавать фрагментированные UDP-пакеты, затрудняя развертывание RADIUS в сети с такими устройствами. Рекомендуется следить за тем, чтобы сообщения RADIUS были как можно более маленькими.

Если необходимо передавать пакеты большей длины, чем 4096 байтов, то используется один из следующих подходов:

  1. Использование последовательности пакетов. При аутентификации и авторизации может быть использована последовательность Access-Request / Access-Response пакетов.
  2. Использование имен, а не значений. Если в атрибуте указана политика, которая заранее известна NAS, то может быть передано имя политики, а не сама политика.
  3. Использование технологий пакетизации и технологий определения максимального PMTU (RFC 4821).

Аутентификация RADIUS

Последовательность пакетов

Последовательность пакетов при выполнении аутентификации


Рис. 12.8.  Последовательность пакетов при выполнении аутентификации

Пользователь предоставляет NAS аутентификационную информацию, после этого NAS использует протокол RADIUS для аутентификации данного пользователя. Эта аутентификационная информация может предоставляться в виде настраиваемого приглашения для входа, когда от пользователя требуется ввести имя и пароль. Либо может использовать такой протокол, как РРР, в котором существуют аутентификационные пакеты для пересылки данной информации.

Задание аутентификационных данных пользователя на противоположной NAS стороне туннеля


Рис. 12.9.  Задание аутентификационных данных пользователя на противоположной NAS стороне туннеля

После того, как NAS получил эту информацию, он может выполнить аутентификацию пользователя на сервере RADIUS. Для того чтобы сделать это, NAS создает запрос Access-Request, содержащий в качестве атрибутов имя пользователя, пароль, идентификатор и тип порта NAS, к которому пользователь хочет получить доступ. Если присутствует пароль, то используется метод его скрытия, основанный на алгоритме хэширования MD5.

Пересылка аутентификационных данных пользователя по туннелю между NAS и противоположной стороной туннеля


Рис. 12.10.  Пересылка аутентификационных данных пользователя по туннелю между NAS и противоположной стороной туннеля

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

Некоторые атрибуты могут быть включены в сообщение несколько раз. Результат такого включения зависит от атрибута.

Если есть несколько атрибутов одного и того же типа, то прокси-серверы не должны изменять их упорядоченность. Порядок атрибутов разных типов прокси-серверами может быть изменен. Поведение RADIUS-сервера и клиента никак не зависит от упорядоченности атрибутов разных типов. Не требуется, чтобы атрибуты одного и того же типа были расположены рядом друг с другом.

Пересылка аутентификационных данных между NAS и сервером RADIUS


Рис. 12.11.  Пересылка аутентификационных данных между NAS и сервером RADIUS

Access-Request передается по сети серверу RADIUS. Если в течение определенного времени ответ не получен, то запрос повторяется. Клиент может также направить запросы к альтернативному серверу или нескольким серверам в случае, если первичный сервер выключен или не доступен. Альтернативный сервер может использоваться либо после определенного числа неудачных попыток обращения к первичному серверу, либо по круговому алгоритму.

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

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

Указание параметров аутентификации на стороне сервера RADIUS


Рис. 12.12.  Указание параметров аутентификации на стороне сервера RADIUS

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

Если в запросе Access-Request есть какие-либо атрибуты Proxy-State, они должны быть скопированы без каких-либо изменений и в том же порядке в пакет ответа. Остальные атрибуты могут быть расположены до, после и даже между Proxy-State атрибутами.

Если какое-либо из условий не выполнено, сервер RADIUS посылает Access-Reject ответ, который говорит о том, что аутентификация не выполнена и запрос пользователя на вход отвергается. Сервер может также включить в Access-Reject текстовое сообщение, которое будет показано пользователю. Никаких других атрибутов, за исключением Proxy-State, в Access-Reject не передается.

Пример сообщения Access-Reject при отсутствии у пользователя или NAS требуемых аутентификационных данных


Рис. 12.13.  Пример сообщения Access-Reject при отсутствии у пользователя или NAS требуемых аутентификационных данных

Если все условия выполнены, и RADIUS-серверу требуется получить дополнительные ответы от пользователя, RADIUS-сервер посылает Access-Challenge ответ. Он может включить текстовое сообщение, которое будет показано пользователю, и может включать атрибут State.

Если NAS получил Access-Challenge и поддерживает Запрос / Ответ, он может показать текстовое сообщение, если оно есть, и затем выдать приглашение пользователю для ввода ответа. Затем клиент передает свой исходный Access-Request с новым ID запроса и с атрибутом User-Password и атрибутом State из Access-Challenge, если они были там указаны.

В ответе не может быть больше одного экземпляра атрибута State. На это сообщение сервер может ответить новым Access-Request, указав в нем либо Access-Request, либо Access-Reject, либо другой Access-Challenge.

Если все условия выполнены, в ответ Access-Request помещается список конфигурационных значений. Эти значения включают тип сервиса (например, SLIP, PPP, Login User) и все необходимые значения для получения требуемого сервиса. Для SLIP и РРР это может включать такие значения, как IP-адрес, маска подсети, MTU, алгоритм сжатия и идентификаторы требуемых фильтров пакетов. Могут быть также указаны требуемый протокол и хост.

Пример сообщения Access-Request при выполнении аутентификации


Рис. 12.14.  Пример сообщения Access-Request при выполнении аутентификации

Вызов / Ответ

При аутентификации Вызов/Ответ (Challenge/Response) пользователь получает заранее неизвестное число запросов, на которые он должен дать ответ. Для создания корректного ответа пользователь должен иметь либо специальные устройства, такие как смарт-карты, либо ПО, которое создает ответ. Если у пользователя нет соответствующего устройства или в ПО не установлено корректное значение секрета, пользователь считается неавторизованным.

Пакет Access-Challenge обычно содержит Reply-Message, которое показывается пользователю, например, числовое значение, которое никогда не повторяется.

Затем пользователь вводит это случайное число в смарт-карту или программу, которая вычисляет ответ. Пользователь вводит этот ответ, и NAS пересылает его на сервер RADIUS во втором Access-Request. Если ответ правильный, сервер RADIUS возвращает Access-Request, в противном случае возвращает Access-Reject.

Пример:

Пример последовательности пакетов при Challenge/Response


Рис. 12.15.  Пример последовательности пакетов при Challenge/Response

NAS посылает пакет Access-Request к серверу RADIUS с атрибутами NAS-Identifier, NAS-Port, User-Name, User-Password (который может быть фиксированной строкой типа "challenge" и игнорироваться). Сервер посылает обратно пакет Access-Challenge с атрибутами State, Reply-Message и строкой "Challenge 12345678, введите ваш ответ", которую NAS показывает пользователю. NAS выдает приглашение пользователю для ответа и посылает полученный ответ в новом пакете Access-Request к серверу (с новым ID), содержащий атрибуты NAS-Identifier, NAS-Port, User-Name, User-Password. В этом случае ответ, который только что ввел пользователь, защищен. Этот ответ содержит тот же самый атрибут State, который был указан в Access-Challenge. После этого сервер присылает обратно либо пакет Access-Request, либо пакет Access-Reject.

Интероперабельность с РАР и СНАР

При использовании РАР NAS получает РАР ID и пароль и посылает их в пакете Access-Request в качестве атрибутов User-Name и User-Password. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol=PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.

При использовании СНАР NAS создает случайный вызов (желательно 16 октетов) и посылает его пользователю, который возвращает СНАР-ответ вместе с атрибутами CHAP ID и СНАР Username. Затем NAS посылает пакет Access-Request к серверу RADIUS со значением СНАР Username в атрибуте User-Name и со значением СНАР ID и СНАР-ответом в атрибуте CHAP-Password. Случайный вызов либо может быть включен в атрибут CHAP-Challenge, либо, если его длина больше 16 октетов, он может быть помещен в поле Request Authenticator в пакете Access-Request. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.

Если сервер RADIUS не может выполнить необходимую проверку, он возвращает Access-Reject. Например, при использовании СНАР требуется, чтобы пароль пользователя был доступен серверу в незашифрованном виде для того, чтобы он мог хэшировать его вместе с вызовом и сравнить с тем, что получил в качестве СНАР-ответа. Если пароль не доступен серверу RADIUS в незашифрованном виде, то он посылает клиенту Access-Reject.

Использование прокси-сервера

Топология сети при использовании прокси-сервера RADIUS


Рис. 12.16.  Топология сети при использовании прокси-сервера RADIUS

При использовании RADIUS-прокси один RADIUS-сервер получает запрос на аутентификацию (или аккаунтинг) от RADIUS-клиента (такого как NAS), перенаправляет запрос к удаленному RADIUS-серверу, получает ответ от него и посылает этот ответ клиенту, возможно с изменениями, от-ражающими локальную административную политику. RADIUS-прокси чаще всего используется при роуминге. В этом случае для предоставления доступа несколько административных единиц должны аутентифицировать пользователей друг друга.

NAS посылает свой запрос на доступ к перенаправляющему серверу, который перенаправляет этот запрос на удаленный сервер. Удаленный сервер присылает ответ (Access-Request, Access-Reject или Access-Challenge) обратно перенаправляющему серверу, который посылает его к NAS. Атрибут User-Name может содержать идентификатор сетевого доступа (например, userID, переданный клиентом при РРР-аутентификации). Выбор сервера, которому следует перенаправить запрос, основывается на аутентификационной области (realm). Аутентификационная область может быть частью области идентификатора сетевого доступа ("области имени"). Выбор сервера, которому пересылается запрос, может быть основан и на каком-то другом критерии.

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

Следующий сценарий иллюстрирует взаимодействие между RADIUS-прокси, NAS и удаленным RADIUS-сервером:

  1. NAS посылает запрос на доступ перенаправляющему серверу.
  2. Перенаправляющий сервер отправляет запрос на доступ к удаленному серверу.
  3. Удаленный сервер присылает сообщения Access-Request, Access-Reject или Access-Challenge обратно перенаправляющему серверу. В нашем случае предположим, что посылается Access-Request.
  4. Перенаправляющий сервер посылает сообщение Access-Request к NAS.

Перенаправляющий сервер должен рассматривать все атрибуты Proxy-State в пакете как неструктурированные данные. Его действия не должны зависеть от содержимого Proxy-State атрибутов, которые были добавлены предыдущими серверами.

Если в запросе, полученном от клиента, существуют какие-либо атрибуты Proxy-State , перенаправляющий сервер должен включить эти атрибуты Proxy-State в ответ клиенту. Перенаправляющий сервер может как включать, так и не включать Proxy-State атрибуты в запрос доступа при перенаправлении запроса. Если перенаправляющий сервер не включил Proxy-State атрибуты в перенаправленный запрос доступа, он должен присоединить их к ответу перед тем, как посылать ответ обратно клиенту.

Рассмотрим каждый шаг более детально.

  1. NAS посылает свой запрос на доступ перенаправляющему серверу. Перенаправляющий сервер проверяет User-Password, если он есть, используя общий секрет с NAS. Если в пакете присутствует атрибут CHAP-Password и нет атрибута CHAP-Challenge, перенаправляющий сервер не должен изменять атрибут Request-Authenticator или должен копировать его в атрибут CHAP-Challenge. Перенаправляющий сервер может добавить в пакет не более одного атрибута Proxy-State. Если он добавляет атрибут Proxy-State, то он должен быть добавлен после всех остальных атрибутов Proxy-State, которые уже есть в пакете. Перенаправляющий сервер не изменяет последовательность атрибутов одного и того же типа, включая атрибуты Proxy-State.
  2. Перенаправляющий сервер обеспечивает конфиденциальность User-Password, если он присутствует. Для защиты от replay-атак используется секрет, который он разделяет с удаленным сервером. Перенаправляющий сервер может добавить значение Identifier, после чего перенаправляет запрос на доступ к удаленному серверу.
  3. Удаленный сервер (если он является конечным получателем) проверяет пользователя, используя User-Password, CHAP-Password или какой-либо другой метод, и возвращает обрат-но перенаправляющему серверу ответ Access-Request, Access-Reject или Access-Challenge. Предположим, что посылается Access-Request. Удаленный сервер должен копировать, не модифицируя, все атрибуты Proxy-State (и только их) из запроса на доступ в пакет ответа.
  4. Перенаправляющий сервер проверяет аутентификатор в ответе, используя секрет, который он разделяет с удаленным сервером, и молча отбрасывает пакет, если он не проходит проверку. Если пакет успешно проходит проверку, то перенаправ-ляющий сервер удаляет последний атрибут Proxy-State (если он был присоединен), обеспечивает целостность аутентификатора ответа, используя секрет, который он разделяет с NAS, и посылает Access-Request к NAS.

Перенаправляющему серверу может понадобиться изменить атрибуты для реализации локальной политики. Но при этом перенаправляющий сервер не должен изменять имеющиеся в пакете атрибуты Proxy-State, State или Class.

Производители перенаправляющих серверов определяют значения, которые они готовы принимать в качестве значения атрибута Service-Type. Это может повлиять на передачу значения Service-Type от NAS в проксируемом пакете Access-Request. Могут также существовать механизмы, которые блокируют определенные типы сервисов.

Причина использования UDP

Часто возникает вопрос, почему в качестве транспорта сообщений RADIUS используется UDP, а не ТСР. UDP был выбран исключительно по техническим причинам.

Существуют определенные проблемы, в результате которых UDP становится более предпочтительным транспортным протоколом. RADIUS является протоколом, основанным на транзакциях, который обладает следующими характеристиками:

  1. Если запрос к первичному аутентификационному серверу выполняется со сбоем, должен быть сделан запрос к вторичному серверу. Для выполнения этого требования копия запроса должна храниться в стеке протоколов выше транспортного уровня, чтобы иметь возможность выполнить альтернативную передачу. Это также означает, что требуется таймер повторной передачи.
  2. Требования к задержкам по времени для данного протокола существенно отличаются от тех, которые обеспечиваются в протоколе ТСР.

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

    С другой стороны пользователя нельзя заставлять ждать завершения аутентификации несколько минут. Следовательно, надежная доставка ТСР-данных в течение двух минут не нужна. Быстрее использовать альтернативный сервер, который может предоставить доступ.

  3. Протокол не поддерживает состояния, поэтому естественнее использовать UDP.

    И клиент, и сервер могут завершить соединение, любая из сторон может выполнить перезапуск всей системы. При этом обычно не возникает проблем, связанных с необходимостью определения потерянного соединения, которые имеют место в протоколе ТСР. Код может быть просто написан с учетом обработки аномальных событий. В самом протоколе UDP полностью отсутствует какая-либо специальная обработка при потере соединения. И клиент, и сервер могут использовать данное UDP-соединение только один раз.

  4. Использование UDP упрощает реализацию сервера.

В ранних реализациях RADIUS сервер состоял из единственной нити. Это означало, что одновременно мог получаться, обрабатываться и возвращаться единственный запрос. Это за-медляло обработку в тех случаях, когда используемым механизмам безопасности требовалось много времени. Также могла переполниться очередь запросов на сервер, если сотням людей ежеминутно требовалась аутентификация. Очевидным решением этой проблемы является реализация сервера с использованием нескольких нитей. Сделать это значительно проще, используя UDP. Каждый процесс обрабатывал отдельный запрос и отвечал клиенту NAS простым UDP-пакетом.

Это не является панацеей от всех бед. При использовании UDP на прикладном уровне требуется помнить о проблемах, которые автоматически решаются в ТСР, например управлением таймерами повторных передач.

Использование повторных передач

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

Если сервер изменил содержимое атрибута User-Password (или любого другого атрибута), то он должен создать новый аутентификатор запроса и, следовательно, новый ID.

Если NAS повторяет запрос к тому же самому серверу, и атрибуты не изменились, следует использовать тот же самый аутентификатор запроса, ID и порт источника. Если какой-либо атрибут изменился, необходимо использовать новые аутентификатор запроса и ID.

NAS может использовать один и тот же ID для всех серверов или может для каждого сервера использовать отдельный ID.

Проверка жизнеспособности сервера

Некоторые производителя посылают тестовые запросы для проверки жизнеспособности сервера. Это не самая лучшая практика, так как увели-чивается трафик и уменьшается масштабируемость, без предоставления при этом никакой дополнительной информации. Так как запрос RADIUS содержится в единственной дейтаграмме, можно вместо этого просто выполнить команду ping.

Для мониторинга RADIUS-сервера следует использовать протокол SNMP.

Формат пакета аутентификации

В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1812.

При создании ответа порты отправителя и получателя меняются местами.

Формат RADIUS-пакета аутентификации


Рис. 12.17.  Формат RADIUS-пакета аутентификации

Поле Code

Поле Code состоит из одного октета и определяет тип RADIUS-пакета. Если получен пакет с недействительным значением поля Code, то пакет молча (без ответа) отбрасывается. В поле Code могут быть указаны следующие значения:

1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server
13	Status-Client

Поле Identifier

Поле Identifier состоит из одного октета и предназначено для сопоставления пар запросов и ответов. RADIUS-сервер может определить дубликат запроса, если запрос имеет IP-адрес источника, UDP-порт источника и значения поля Identifier, что и у уже полученного запроса.

Поле Length

Поле Length состоит из двух октетов. Оно содержит длину пакета, состоящего из полей Code, Identifier, Length, Authenticator и Attribute.

Поле Authenticator

Поле Authenticator состоит из 16 октетов. Это значение используется для определения повторных ответов от RADIUS-сервера и используется в алгоритме скрытия пароля.

Аутентификатор запроса

В пакете Access-Request значение Authenticator состоит из 16-октетного случайного числа, называемого аутентификатор запроса. Значение должно быть случайным. Хотя протокол RADIUS и не может защитить от встраивания поддельной информации в аутентифицированную сессию с помощью активной атаки man-in-the-middle, создание случайного значения в качестве аутентификатора защищает от большого числа активных атак, связанных с аутентификацией.

NAS и RADIUS-сервер разделяют общий секрет. Выполняется конкатенация этого секрета и аутентификатора запроса, результат подается на вход хэш-функции MD5, которая создает 16-октетное значение дайджеста. Затем выполняется операция XOR полученного значения и пароля, введен-ного пользователем, и результат помещается в атрибут User-Password в пакете Access-Request.

Аутентификатор ответа

Значение поля Authenticator в пакетах Access-Request, Access-Reject и Access-Challenge называется аутентификатором ответа и содержит хэш-значение MD5, вычисленное для RADIUS-пакета, начиная с поля Code и включая поля Identifier, Length, Request Authenticator из пакета Access-Request, Attributes из ответа, за которыми следует разделяемый секрет.

MD5 (Code+ID+Length+RequestAuth+Attributes+Secret)

где "+" означает конкатенацию.

Вопросы администрирования

Секрет (пароль, разделяемый клиентом и RADIUS-сервером) должен быть такой длины, чтобы его трудно было перебрать. Считается, что его длина должна быть по крайней мере 16 октетов.

Перенаправляющий прокси может изменить содержимое пакета, а именно он может добавить атрибут Proxy-State. Когда прокси возвращает ответ, он должен удалить свой атрибут Proxy-State, если тот был добавлен. Proxy-State всегда добавляется после других атрибутов Proxy-State, но никаких других предположений относительно его расположения в списке атрибутов не делается. Так как ответы Access-Request и Access-Reject аутентифицированы как часть содержимого всего пакета, удаление атрибута Proxy-State делает недействительным аутентификатор пакета, поэтому прокси заново вычисляет аутентификатор.

Сообщение Access-Request

Пакеты Access-Request посылаются RADIUS-серверу и содержат информацию, используемую для определения разрешен ли пользователю доступ к данному NAS и какие сервисы доступны для данного пользователя.

Пакет Access-Request должен содержать атрибут User-Name. Он также должен содержать атрибуты NAS-IP-Address или NAS-Identifier.

Пакет Access-Request должен содержать либо атрибут User-Password, либо атрибут CHAP-Password, либо атрибут State. Пакет Access-Request не должен содержать одновременно и User-Password, и CHAP-Password. Возможно также добавление других типов аутентификационной информации и атрибутов, которые будут использоваться в пакете Access-Request вместо атрибутов User-Password или CHAP-Password.

Пакет Access-Request может содержать атрибут NAS-Port или NAS-Port-Type, а также дополнительные атрибуты, но при этом не требуется, чтобы сервер их как-то учитывал при создании ответа.

Если присутствует атрибут User-Password, он должен быть скрыт с использованием хэш-функции MD5.

Сообщение Access-Request

Пакеты Access-Request посылаются RADIUS-сервером и содержат информацию, необходимую для предоставления сервиса пользователю. Если все значения атрибута Attribute в Access-Request корректные, то RADIUS-сервер должен передать пакет с полем Code, установленным в 2 (Access-Request).

В пакете Access-Request поле Identifier должно соответствовать отправленному в Access-Request.

Сообщение Access-Reject

Если какое-либо значение Attributes не является допустимым, то RADIUS-сервер передает ответ с полем Code, установленным в 3 (Access-Reject). Он может включить один или несколько атрибутов Reply-Massage с текстовым сообщением, которое NAS может показать пользователю.

Сообщение Access-Challenge

Если RADIUS-сервер считает, что пользователю необходимо послать вызов, требующий ответа, то он отвечает пакетом с полем Code, установленным в 11 (Access-Challenge).

Поле Attribute может содержать один или несколько атрибутов Reply-Message или единственный атрибут State, либо не содержать ничего из перечисленного. Могут также быть включены следующие атрибуты: Vendor-Specific, Idle-Timeout, Session-Timeout и Proxy-State. Никакие другие атрибуты не должны включаться в Access-Challenge.

В полученном пакете Access-Challenge поле Identifier должно соответствовать тому, которое было указано в отправленном NAS Access-Request.

Если NAS не поддерживает обмен сообщениями Вызов/Ответ, он должен считать, что Access-Challenge соответствует Access-Reject.

Если NAS поддерживает обмен сообщениями Вызов/Ответ, то получение корректного ответа Access-Challenge означает, что должен быть послан новый запрос Access-Request. NAS может показать пользователю текстовое сообщение и выдать приглашение для ввода ответа. Затем он посылает исходный Access-Request с новым ID запроса и аутентификатором запроса, с атрибутом User-Password, в котором содержится ответ пользователя (в скрытом виде), а также в него добавляется атрибут State из Access-Challenge, если он там был. В Access-Request может присутствовать не более одного атрибута State.

NAS, поддерживающий РАР, может перенаправить Reply-Message клиенту и получить РАР-ответ, который затем он может использовать в качестве ответа пользователя. Если NAS это не поддерживает, он должен трактовать Access-Challenge как Access-Reject.

Атрибуты аутентификации

Атрибуты имеют следующий формат:

Формат атрибутов RADIUS


Рис. 12.18.  Формат атрибутов RADIUS

Поле Type

Поле Type имеет длину один октет. Возможные типы стандартизованы и перечислены в соответствующих RFC. Как RADIUS-сервер, так и клиент могут игнорировать атрибуты, тип которых они не знают.

Основные типы атрибутов следующие:


1	User-Name
2	User-Password
3	CHAP-Password
4	NAS-IP-Address
5	NAS-Port
6	Service-Type
7	Framed-Protocol
8	Framed-IP-Address
9	Framed-IP-Netmask
10	
11	
12	Framed-MTU
13	Framed-Compression
14	Logon-IP-Host
15	Login-Service
16	Login-TCP-Port
17	
18	Reply-Message
19	Callback-Number
20	Callback-Id
21	
22	Framed-Route
23	Framed-IPX-Network
24	State
25	Class
26	Vendor-Specific
27	Session-Timeout
28	Idle-Timeout
29	Termination-Action
30	Called-Station-Id
31	Calling-Station-Id
32	NAS-Identifier
33	Proxy-State
34	-59  
60	CHAP-Challenge
61	NAS-Port-Type
62	Port-Limit
63	Login-LAT-Port

Атрибут User-Name

Атрибут содержит имя аутентифицируемого пользователя. Он обязательно указывается в пакетах Access-Request.

Он может быть послан в пакете Access-Request, в этом случае клиент должен использовать это имя во всех пакетах Accounting-Request данной сессии. Если в Access-Request включен ServiceType=Rlogin и атрибут User-Name, NAS может использовать возвращаемое значение User-Name при выполнении сервиса Rlogin в UNIX-системах. Значением атрибута может быть текст, идентификатор сетевого доступа или DN прото-кола LDAP.

Атрибут User-Password

В данном атрибуте указывается пароль аутентифицируемого пользователя или введенная пользователем информация при получении пакета Access-Challenge. Атрибут используется только в пакетах Access-Request.

Пароль передается в скрытом виде. Первым делом к паролю добавляются символы заполнения, чтобы длина пароля стала кратной 16 октетам. Затем используется хэш-функция MD5, на вход которой подаются разделяемый секрет и аутентификатор запроса. Затем выполняется операция XOR этого значения с первыми 16 октетами пароля, полученное значение помещается в первые 16 октет поля String атрибута User-Password.

Если пароль длиннее 16 символов, второй раз используется хэш-функция MD5, на вход которой подается разделяемый секрет, за которым следует результат первого XOR. После этого выполняется XOR результата второго использования MD5 и вторых 16 октетов пароля. При необходимости данная операция повторяется нужное число раз.

Обозначим разделяемый секрет – S, псевдослучайный 128-битный аутентификатор запроса – RA. 16-октетные части пароля – р1, р2 и т.д.

b1 = MD5 (S + RA)		c(1) = p1 xor b1
b2 = MD5 (S + c(1))		c(2) = p2 xor b2
String содержит с(1) + с(2) +  ….., 
где + обозначает конкатенацию.

Атрибут СНАР-Password

В данном атрибуте указывается ответ на запрос, предоставленный протоколом СНАР, в ответ на Вызов (Challenge). Атрибут используется только в пакетах Access-Request.

Значение Вызова СНАР берется из атрибута CHAP-Challenge, если он присутствует в пакете, в противном случае используется поле Аутентификатора запроса.

Атрибут NAS-IP-Address

Данный атрибут определяет IP-адрес NAS, который запросил аутентификацию пользователя. Этот IP-адрес должен быть уникальным у данного RADIUS-сервера. NAS-IP-Address используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать либо NAS-IP-Address, либо NAS-Identifier.

Заметим, что NAS-IP-Address не должен использоваться для выбора разделяемого секрета, который используется для аутентификации запроса. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.

Атрибут NAS-Port

Атрибут определяет номер физического порта NAS, который аутентифицирует пользователя. Атрибут используется только в пакетах Access-Request. Заметим, что это порт физического соединения NAS, а не ТСР или UDP номер порта. В пакете Access-Request должен присутствовать либо NAS-Port, либо NAS-Port-Type.

Атрибут Service-Type

Данный атрибут определяет тип сервиса, который запросил пользователь, или тип сервиса, который будет предоставлен. Он может использоваться в пакетах Access-Request и Access-Accept. Не требуется, чтобы NAS мог реализовывать все типы сервисов, неизвестные или не поддерживаемые сервисы игнорируются и должны рассматриваться как Access-Reject.

Следующие типы сервисов могут использоваться в Access-Request. При использовании в Access-Request они могут рассматриваться как подсказка RADIUS-серверу какой тип сервиса требуется пользователю. Но при этом не требуется, чтобы сервер следовал этой подсказке.

Таблица 12.1.
Login Пользователь должен войти на хост.
Framed Для соединения с пользователем должен использоваться такой протокол, как РРР или SLIP.
Callback Login Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего пользователь должен быть снова подсоединен к хосту.
Callback Framed Пользователь должен быть отсоединен, затем должен быть сделан обратный вызов, после чего должен начать выполняться такой протокол, как РРР или SLIP.
Outbound Пользователю должен быть предоставлен доступ к внешним устройствам.
Administrative Пользователю должен быть предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды.
NAS prompt Пользователю должно быть выдано приглашение для ввода непривилегированных команд NAS.
Authenticate Only Требуется только аутентификация, в Access-Request не должно возвращаться никакой авторизационной информации (обычно используется прокси-серверами, а не самим NAS).
Callback NAS Prompt Пользователь отсоединяется, осуществляется обратный вызов и пользователю выдается приглашение для выполнения непривилегированных команд NAS.
Call Check Используется NAS в пакете Access-Request для указания того, что вызов был получен, и что в ответ на вызов RADIUS-сервер должен послать сообщение Access-Accept или Access-Reject, обычно основываясь на атрибутах Called-Station-Id или Calling-Station-Id. Рекомендуется, чтобы Access-Request использовал Calling-Station-Id в качестве значения User-Name.
Callback Administrative Пользователь должен быть отсоединен, выполнен обратный вызов, затем предоставлен доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды.

Атрибут Framed-Protocol

Атрибут указывает внешний протокол, который используется для получения доступа. Может использоваться в пакетах Access-Request и Access-Accept.

Атрибут Framed-IP-Address

Данный атрибут определяет IP-адрес, который должен быть выдан пользователю. Атрибут может быть указан в пакетах Access-Accept. Он также может быть указан в пакете Access-Request в качестве предпочтительного IP-адреса, но сервер не обязан следовать этому указанию.

Атрибут Framed-IP-Netmask

Данный атрибут определяет IP-маску, которая будет сконфигурирована для пользователя при доступе в сеть. Атрибут может использоваться в пакетах Access-Accept. Он может также использоваться в пакете Access-Request для указания предпочтений NAS серверу, но сервер не обязан следовать этому.

Атрибут Framed-MTU

Данный атрибут определяет MTU, который будет сконфигурирован для пользователя, если об этом значении не ведутся переговоры каким-либо другим способом, например в РРР. Атрибут может использоваться в Access-Accept пакетах. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.

Атрибут Framed-Compression

Данный атрибут определяет протокол сжатия. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.

Может быть послано несколько атрибутов, определяющих протокол сжатия. За использование корректного протокола сжатия отвечает NAS.

Атрибут Login-IP-Host

Данный атрибут определяет систему, к которой должен подсоединиться пользователь, если используется атрибут Login-Service. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.

Атрибут Login-Service

Данный атрибут указывает сервис, который будет использоваться при соединении пользователя с хостом. Он может использоваться только в пакетах Acces-Accept.

Атрибут Login-TCP-Port

Данный атрибут определяет ТСР-порт, с которым будет устанавливать соединение пользователь, если присутствует атрибут Login-Service. Используется только в пакетах Access-Request.

Атрибут Reply-Message

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

Если используется в пакете Access-Challenge, может содержать диалоговое сообщение, которое выдается пользователю для ввода ответа.

Если в сообщении содержится несколько Reply-Message, то они показываются в том же порядке, в каком расположены в пакете.

Атрибут Callback-Number

Атрибут определяет строку, которая будет использоваться при обратном вызове. Атрибут может использоваться в пакетах Access-Accept. Он может быть указан в пакете Access-Request для указания серверу предпочтений, но сервер не обязан этому следовать.

Атрибут Callback-Id

Данный атрибут определяет имя, которое будет использовано при обратном вызове и которое должно будет интерпретироваться NAS. Атрибут может использоваться в Access-Accept пакетах.

Атрибут Framed-Route

Данный атрибут предоставляет информацию маршрутизации, которая будет сконфигурирована для пользователя NAS. Атрибут используется в пакете Access-Accept, и может появиться там несколько раз.

Атрибут State

Атрибут посылается сервером клиенту в сообщении Access-Challenge и должен быть отправлен без изменения обратно клиентом серверу в новом Access-Request, который является ответом на запрос.

Данный атрибут может быть послан сервером клиенту в сообщении Access-Accept, в котором должен быть также атрибут Termination-Action со значением RADIUS-Request. Если NAS выполняет Termination-Action, посылая новый Access-Request при завершении текущей сессии, он должен включить без изменения атрибут State в этот Access-Request.

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

Атрибут Class

Данный атрибут посылается сервером клиенту в Access-Accept, и должен отправляется без изменения клиентом серверу, хранящему учетные записи (аккаунтинг) как часть Accounting-Request пакета, если используется аккаунтинг. Клиент не должен интерпретировать данный атрибут локально.

Атрибут Vendor-Specific

Данный атрибут позволяет производителям поддерживать свои собственные атрибуты. Данный атрибут не должен влиять на операции протокола RADIUS.

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

Атрибут Session-Timeout

Данный атрибут устанавливает максимальное время (в секундах) перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.

Атрибут Idle-Timeout

Данный атрибут устанавливает максимально допустимое число секунд простоя соединения перед тем, как завершить сессию или ожидание ответа. Атрибут может быть послан сервером клиенту в Access-Accept или Access-Challenge.

Атрибут Termination-Action

Данный атрибут определяет действие, которое должен выполнить NAS при завершении определенного сервиса. Используется только в пакетах Access-Accept.

Атрибут Called-Station-Id

Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, который использовал пользователь. Заметим, что это может отличаться от номера телефона, с которого пришел вызов. Данный атрибут используется только в пакетах Access-Request.

Атрибут Calling-Station-Id

Данный атрибут позволяет NAS послать в пакете Access-Request номер телефона, с которого пришел вызов. Атрибут используется только в пакетах Access-Request.

Атрибут NAS-Identifier

Данный атрибут содержит строку, идентифицирующую NAS, который создал исходный Access-Request. Атрибут используется только в пакетах Access-Request. Либо NAS-IP-Address, либо NAS-Identifier должен присутствовать в пакете Access-Request.

Заметим, что NAS-Identifier не должен использоваться для выбора разделяемого секрета, аутентифицирующего запрос. Для выбора разделяемого секрета должен использоваться IP-адрес источника пакета Access-Request.

Атрибут Proxy-State

Данный атрибут может быть послан прокси-сервером другому серверу при перенаправлении Access-Request. Атрибут должен быть возвращен без изменения в Access-Accept, Access-Reject или Access-Challenge. Когда прокси-сервер получает ответ на свой запрос, он должен удалить свой собственный Proxy-State (последний Proxy-State в пакете) перед тем, как перенаправить ответ к NAS.

Если атрибут Proxy-State добавляется в пакет, то он должен быть добавлен после всех имеющихся атрибутов Proxy-State.

Содержимое всех других атрибутов Proxy-State, отличных от добавляемого, должно рассматриваться как неформатированные данные и не должно влиять на операции протокола.

Использование атрибута Proxy-State зависит от протокола.

Атрибут CHAP-Challenge

Данный атрибут содержит CHAP Challenge, посылаемый NAS. Он используется только в Access-Request пакетах.

Если значение вызова СНАР имеет длину в 16 октетов, то оно может быть размещено в поле аутентификатора запроса, а не в данном атрибуте.

Атрибут NAS-Port-Type

Данный атрибут определяет тип физического порта NAS, с которого выполняется аутентификация пользователя. Атрибут может использоваться вместо или в дополнение к атрибуту NAS-Port. Данный атрибут используется только в Access-Request пакетах. Если NAS различает свои порты, то в пакете Access-Request должен присутствовать либо атрибут NAS-Port, либо атрибут NAS-Port-Type, либо оба эти атрибута.

Атрибут Port-Limit

Данный атрибут устанавливает максимальное количество портов, которое может предоставить NAS своим пользователям. Атрибут может быть послан сервером клиенту в пакете Access-Accept. Предполагается, что он будет использоваться вместе с многоканальным РРР или в аналогичной технологии. Он также может быть послан NAS к серверу в качестве предпочтения, какое количество портов может использоваться, но сервер может игнорировать это.

Атрибуты RADIUS, специфичные для ПО Microsoft

Рассмотрим атрибуты, которые могут быть переданы в одном или более атрибутах RADIUS, тип которых есть Vendor-Specific. В одном Vendor-Specific атрибуте могут быть переданы несколько атрибутов; в этом случае эти атрибуты пакетируются в виде последовательности троек Vendor-Type/Vendor-Length/Value, которые следуют за начальными полями Type, Length и Vendor-Id. Поле Vendor-ID должно быть установлено в десятичное значение 311 (Microsoft).

Атрибуты для поддержки MS-CHAP V1

Microsoft разработала протокол MS-CHAP для аутентификации удаленных рабочих станций Windows, обеспечивая функциональность, аналогичную той, к которой привыкли пользователи сети. Где это возможно, MS-CHAP аналогичен стандартному СНАР. Основная разница в следующем:

Атрибуты RADIUS отражают эти отличия.

Атрибут MS-CHAP-Challenge

Данный атрибут содержит вызов, посылаемый NAS к пользователю MS-CHAP. Он может использоваться в пакетах Access-Request и Access-Challenge.

Атрибут MS-CHAP-Response

Данный атрибут содержит ответ, передаваемый пользователем в ответ на вызов. Атрибут используется только в пакетах Access-Request.

Атрибут MS-CHAP-Domain

Атрибут MS-CHAP-Domain определяет Window-домен, в котором пользователь был аутентифицирован. Данный атрибут может быть включен в пакеты Access-Accept и Accounting-Request.

Атрибут MS-CHAP-Error

Атрибут MS-CHAP-Error содержит информацию об ошибке, относящуюся к предыдущему MS-CHAP-обмену. Данный атрибут может использоваться в обменах как MS-CHAP-V1, так и MS-CHAP-V2. Данный атрибут используется только в пакетах Access-Reject.

Атрибут MS-CHAP-CPW-1

Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут может использоваться только в пакетах Access-Request и должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP не меньше 2.

Атрибут MS-CHAP-CPW-2

Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут используется только в пакетах Access-Request, и включается только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль истек, и версия MS-CHAP равна 2.

Атрибут MS-CHAP-LM-Enc-PW

Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, пароль разделяется на несколько частей и передается в нескольких атрибутах. В атрибут включается последовательный номер (2 октета), чтобы обеспечить возможность правильной сборки фрагментов пароля.

Атрибут используется только в пакетах Access-Request совместно с атрибутом MS-CHAP-CPW-2. Атрибут должен включаться только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия MS-CHAP равна 2 или более.

Атрибут MS-CHAP-NT-Enc-PW

Данный атрибут содержит новый пароль Windows, скрытый с помощью хэша старого пароля Windows. Скрытый пароль Windows имеет длину 516 октетов; так как это длиннее, чем максимальная длина RADIUS-атрибута, то пароль разделяется на несколько частей и передается в нескольких атрибутах. Последовательный номер включается в атрибут, чтобы обеспечить сборку фрагментов пароля.

Данный атрибут используется только в пакете Access-Request совместно с атрибутами MS-CHAP-CPW-2 и MS-CHAP-CPW. Он включает только в том случае, если атрибут MS-CHAP-Error был включен в непосредственно предшествующий пакет Access-Reject, поле String атрибута MS-CHAP-Error указывает, что пароль пользователя истек, и версия протокола MS-СНАР равна 2 или более.

Атрибуты для поддержки MS-CHAP V2

Рассмотрим RADIUS-атрибуты, необходимые для поддержки второй версии протокола MS-CHAP. Протокол MS-CHAP-V2 аналогичен, но не совместим с протоколом MS-CHAP-V1. Некоторые поля удалены или используются по-другому. Протокол MS-CHAP-V2 максимально согласован как с протоколом MS-CHAP-V1, так и со стандартным протоколом СНАР.

Кратко различия между протоколами MS-CHAP-V2 и MS-CHAP-V1 следующие:

Соответствующие атрибуты отражают эти различия.

Атрибут MS-CHAP2-Response

Данный атрибут содержит ответ, предоставленный противоположной стороной. Атрибут используется только в пакетах Access-Accept.

Атрибут MS-CHAP2-Success

Данный атрибут содержит ответ длиной 42 октета. Данная строка содержит поле Message из пакета Success, который посылался от NAS к противоположной стороне. Данный атрибут используется только в пакетах Access-Accept.

Атрибут MS-CHAP2-CPW

Данный атрибут позволяет пользователю изменить свой пароль, если он истек. Данный атрибут используется только совместно с атрибутом MS-CHAP-NT-Enc-PW2в пакетах Access-Request и включен только если в непосредственно предшествующий пакет Access-Reject был включен атрибут MS-CHAP-Error, указывающий, что пароль пользователя истек, и версия MS-CHAP равна 3.

Атрибуты для поддержки МРРЕ

Рассмотрим атрибуты, разработанные для поддержки протокола Microsoft Point-to-Point Encryption (MPPE). Протокол МРРЕ обеспечивает способ передачи РРР-пакетов в зашифрованном виде. В протоколе МРРЕ для шифрования используется алгоритм RC4. Могут вестись переговоры о длине ключа сессии для инициализации таблиц шифрования.

Атрибут MS-CHAP-MPPE-Keys

Атрибут MS-CHAP-MPPE-Keys содержит два ключа сессии, которые будут использоваться в протоколе МРРЕ. Данный атрибут включается только в пакеты Access-Accept.

Атрибут MS-MPPE-Send-Key

Атрибут MS-MPPE-Send-Key содержит ключ сессии, который будет использоваться в протоколе МРРЕ. Считается, что этот ключ используется для шифрования пакетов, посылаемых от NAS к удаленному хосту. Данный атрибут включается только в пакеты Access-Accept.

Атрибут MS-MPPE-Recv-Key

Атрибут MS-MPPE-Recv-Key содержит ключ сессии, который будет использоваться в протоколе МРРЕ. Считается, что данный ключ используется для шифрования пакетов, получаемых NAS от противоположной стороны. Данный атрибут включается только в пакеты Access-Accept.

Атрибут MS-MPPE-Encryption-Policy

Атрибут MS-MPPE-Encryption-Policy используется для указания того, что шифрование требуется или нет. Если поле Policy равно 1 (Encryption-Allowed), то может использоваться любой из типов шифрования, указанный в атрибуте MS-MPPE-Encryption-Types, или не использоваться ни один. Если поле Policy равно 2 (Encrypted-Required), то любой из типов шифрования, указанный в атрибуте MS-MPPE-Encrypted-Types, может использоваться, но по крайней мере один должен использоваться.

Атрибут MS-MPPE-Encryption-Types

Атрибут MS-MPPE-Encryption-Types используется для указания типов шифрования, которые могут использоваться в протоколе МРРЕ. Атрибут является 4-х октетным целым, которое интерпретируется как строка битов.

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

Таблица 12.1.
RequestAccept Reject Challenge Атрибут
0-10-1 0 0 User-Name
0-1 0 0 0 User-Password
0-1 0 0 0 CHAP-Password
0-1 0 0 0 NAS-IP-Address
0-1 0 0 0 NAS-Port
0-1 0-1 0 0 Service-Type
0-1 0-1 0 0 Framed-Protocol
0-1 0-1 0 0 Framed-IP-Address
0-1 0-1 0 0 Framed-IP-Netmask
0 0-1 0 0 Framed-Routing
0 0+ 0 0 Filter-Id
0-1 0-1 0 0 Framed-MTU
0+ 0+ 0 0 Framed-Compression
0+ 0+ 0 0 Login-IP-Host
0 0-1 0 0 Login-Service
0 0-1 0 0 Login-TCP-Port
0 0+ 0+ 0+ Reply-Message
0-1 0-1 0 0 Callback-Number
0 0-1 0 0 Callback-Id
0 0+ 0 0 Framed-Route
0-1 0-1 0 0-1 State
0 0+ 0 0 Class
0+ 0+ 0 0+ Vendor-Specific
0 0-1 0 0-1 Session-Timeout
0 0-1 0 0-1 Idle-Timeout
0 0-1 0 0 Termination-Action
0-1 0 0 0 Called-Station-Id
0-1 0 0 0 Calling-Station-Id
0-1 0 0 0 NAS-Identifier
0+ 0+ 0+ 0+ Proxy-State
0-1 0 0 0 CHAP-Challenge
0-1 0 0 0 NAS-Port-Type
0-1 0-1 0 0 Port-Limit

Access-Request должен содержать либо User-Password, либо CHAP-Password, либо State. Access-Request не может одновременно содержать как User-Password, так и CHAP-Password.

Access-Request должен содержать либо NAS-IP-Address, либо NAS-Identifier, либо и то, и другое.

Обсуждение безопасности

Каждый RADIUS-сервер имеет базу данных, в которой хранятся имена пользователей и аутентификационная информация ("секреты"). Не предпо-лагается, что отдельный пользователь может быть аутентифицирован не-сколькими способами. Аутентификация несколькими способами может быть уязвима, если атакующий попытается заставить использовать наиболее слабый метод.

К паролям и другим секретам доступ должен быть максимально ограничен.

Аккаунтинг RADIUS

Рассмотрим использование протокола RADIUS для доставки информации об учетных записях от NAS к серверу учетных записей RADIUS.

Последовательность пакетов

Последовательность пакетов при выполнении аккаунтинга


Рис. 12.19.  Последовательность пакетов при выполнении аккаунтинга

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

Пример первого пакета Accounting Start RADIUS


Рис. 12.20.  Пример первого пакета Accounting Start RADIUS

Затем этот сервер присылает подтверждение, что пакет был получен.

После завершения получения сервиса NAS создает пакет Accounting Stop, в котором описан тип полученного сервиса и возможно различная статистическая информация, такая как затраченное время, количество входящего и исходящего трафика. Этот пакет посылается к серверу аккаунтинга RADIUS, который присылает подтверждение, что пакет был получен.

Клиент посылает пакеты Accounting-Request до тех пор, пока не получит тем или иным способом подтверждения. После того, как клиент не получил подтверждения в течение определенного времени, он может перенаправить запрос альтернативному серверу.

Сервер аккаунтинга RADIUS может делать запросы другим серверам, в этом случае он действует как клиент.

Использование прокси-сервера

Аккаунтинг прокси функционирует аналогично аутентификационному прокси.

Топология сети при использовании прокси-сервера RADIUS


Рис. 12.21.  Топология сети при использовании прокси-сервера RADIUS

Перенаправляющий сервер не должен модифицировать существующие в пакете атрибуты Proxy-State и Class.

Формат пакета аккаунтинга

Формат пакета аккаунтинга аналогичен формату пакета аутентификации, значения полей другие. В UDP инкапсулируется ровно один RADIUS-пакет. Порт получателя – 1813.

При создании ответа порты отправителя и получателя меняются местами.

Формат RADIUS-пакета аккаунтинга


Рис. 12.22.  Формат RADIUS-пакета аккаунтинга

Поле Code

Поле Code состоит из одного октета и определяет тип RADIUS-пакета. Если получен пакет с недействительным значением поля Code, то пакет молча (без отправления ответа) отбрасывается. В поле Code могут быть указаны следующие значения:

4 Accounting-Request
5 Accounting-Response

Поле Identifier

Поле Identifier состоит из одного октета и предназначено для того, чтобы можно было сопоставить пары запросов и ответов. RADIUS-сервер может определить дубликат запроса, если запрос имеет IP-адрес источника, UDP-порт источника и Identifier, что и у уже полученного запроса.

Поле Length

Поле Length состоит из двух октетов. Оно содержит длину пакета, включая поля Code, Identifier, Length, Authenticator и Attribute.

Поле Authenticator

Поле Authenticator состоит из 16 октетов. Это значение используется для определения повторов ответов от RADIUS-сервера и используется в алгоритме скрытия пароля.

Аутентификатор запроса

В пакетах Accounting-Request значение Authenticator является 16-октетным значением MD5, называемым аутентификатором запроса.

NAS и аккаунтинг сервер RADIUS разделяют секрет. Поле аутентификатора запроса содержит результат вычисления MD5 над следующими значениями: Code + Identifier + Length + 16 октетов нулей + атрибуты запроса + разделяемый секрет.

Заметим, что аутентификатор запроса в Accounting-Request может вычисляться другим способом, чем аутентификатор запроса в Access-Request, потому что в Accounting-Request нет атрибута User-Password.

Аутентификатор ответа

Поле Authenticator в пакете Accounting-Response называется аутентификатором ответа и содержит результат вычисления MD5 над следующими значениями:

Code + Identifier + Length + аутентификатор запроса из пакета Accounting-Request + атрибуты ответа, если есть, + разделяемый секрет. 
Полученные 16 октетов записываются в поле Authenticator пакета Accounting-Response.

Поле Attributes

В поле Attributes могут быть включена атрибуты разных типов. Атрибуты некоторых типов могут быть включены несколько раз. В этом случае порядок атрибутов одного и того же типа фиксирован.

Типы пакетов

Тип пакета RADIUS определяется полем Code.

Пакет Accounting-Request

Пакеты Accounting-Request посылаются от клиента (обычно NAS или прокси) к аккаунтинг-серверу RADIUS и содержат информацию, используемую для авторизации доступа к сервису, предоставляемого пользователю. Клиент передает RADIUS-пакет с полем Code, установленным в 4 (Accounting-Request).

При получении Accounting-Request сервер должен передать ответ Accounting-Response, если он успешно записал пакет аккаунтинга, и не должен передавать никакого ответа, если произошел сбой при записи пакета аккаунтинга.

Любой атрибут, который используется в пакетах Access-Request и Access-Accept, может использоваться и в пакете Accounting-Request, за исключением следующих атрибутов, которые не должны присутствовать в пакетах Accounting-Request: User-Password, CHAP-Password, Reply-Message, State. В пакете Accounting-Request должен присутствовать атрибуты либо NAS-IP-Address, либо NAS-Identifier. Пакет должен содержать NAS-Port, или NAS-Port-Type, или оба атрибута, если только в сервисе не определен порт, или NAS не различает свои порты.

Если пакет Accounting-Request содержит Framed-IP-Address, то атрибут должен содержать IP-адрес пользователя. Если Access-Request использует специальные значения для Framed-IP-Address, которые означают, что NAS должен назначить IP-адрес пользователю или вести о нем переговоры, то Framed-IP-Address (если есть) в Accounting-Request должен содержать реальный IP-адрес, который назначен или о котором договорились.

Пакет Accounting-Response

Пакеты Accounting-Response посылаются сервером RADIUS клиенту как подтверждение того, что Accounting-Request был получен и успешно записан. Если Accounting-Request был успешно записан, то аккаунинг сервер должен передать пакет с полем Code, установленным в 5 (Accounting-Response). При получении Accounting-Response клиент проверяет, что поле Identifier соответствует отправленному в запросе. Аутентификатор ответа должен содержать корректное значение. Недействительный пакет молча отбрасывается.

Атрибуты аккаунтинга

Атрибуты отражают детали аутентификации, авторизации и аккаунтинга в запросе и ответе.

Некоторые атрибуты могут быть включены несколько раз. Результат такого включения зависит от атрибута.

Атрибуты имеют следующий формат.

Формат RADIUS-атрибутов


Рис. 12.23.  Формат RADIUS-атрибутов

Поле Type

Поле Type имеет длину один октет. Основные типы атрибутов следующие:

40	Acct-Status-Type
41	Acct-Delay-Time
42	Acct-Input-Octets
43	Acct-Output-Octets
44	Acct-Session-Id
45	Acct-Authentic
46	Acct-Session-Time
47	Acct-Input-Packets
48	Acct-Output-Packets
49	Acct-Terminate-Cause
50	Acct-Multi-Session-Id
51	Acct-Link-Count

Поле Length

Поле Length имеет длину один октет и определяет длину данного атрибута, включая поля Type, Length и Value. Если в Accounting-Request получен атрибут с неправильным значением поля Length, то весь пакет отбрасывается.

Поле Value

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

Атрибут Acct-Status-Type

Атрибут указывает, маркирует ли данный пакет Accounting-Request начало пользовательского сервиса (Start) или конец (Stop).

Он может использоваться клиентом для маркировки начала аккаунтинга (например, после перезагрузки), указав специальное значение атрибута Accounting-On и пометив конец аккаунтинга (например, перед плановым перезапуском) специальным значением атрибута Accounting-Off.

Атрибут Acct-Delay-Time

Атрибут указывает сколько секунд клиент пытается послать данную запись, и может вычитаться из времени получения сервером пакета Accounting-Request, т.е. время передачи по сети будет игнорироваться.

Атрибут Acct-Input-Octets

Атрибут определяет, сколько октетов было получено с порта, на котором был предоставлен сервис, и может присутствовать только в пакетах Accounting-Request, в которых Acct-Status-Type установлен в Stop.

Атрибут Acct-Output-Octets

Атрибут определяет, сколько октетов было послано на порт, на котором выполняется данный сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.

Атрибут Acct-Session-Id

Атрибут содержит уникальный идентификатор, который используется для нахождения соответствующих пар старт- и стоп-записей в лог-файле. Старт- и стоп-записи для данной сессии должны иметь один и тот же Acct-Session-Id. Пакет Access-Request может содержать атрибут Acct-Session-Id. Если он содержит этот атрибут, то NAS должен использовать тот же самый Acct-Session-Id во всех пакетах Accounting-Request, относящихся к данной сессии.

Атрибут Acct-Authentic

Атрибут может быть включен в пакет Accounting-Request для указания того, был ли пользователь аутентифицирован самим NAS или использовался протокол RADIUS или другой протокол удаленной аутентификации. Для пользователей, которые получили сервис без выполнения аутентификации, не должны создаваться записи аккаунтинга.

Атрибут Acct-Session-Time

Атрибут указывает, сколько секунд пользователь получал сервис, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.

Атрибут Acct-Input-Packets

Атрибут указывает, сколько пакетов было получено с порта в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.

Атрибут Acct-Output-Packets

Атрибут указывает, сколько пакетов было послано на порт в течение использования данного сервиса пользователем, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.

Атрибут Acct-Terminate-Cause

Атрибут указывает, как сессия была завершена, и может присутствовать только в пакетах Accounting-Request, в которых атрибут Acct-Status-Type установлен в Stop.

Атрибут Acct-Multi-Session-Id

Данный атрибут является уникальным Accounting ID, что позволяет легко объединить в лог-файле несколько взаимосвязанных сессий. Каждая сессия имеет уникальный атрибут Acct-Session-Id, но взаимосвязанные сессии имеют один и тот же атрибут Acct-Link-Count.

Атрибут Acct-Link-Count

Атрибут содержит количество взаимосвязанных (с помощью атрибута Acct-Link-Count) сессий. NAS может включить атрибут Acct-Link-Count в любой пакет Accounting-Request, который связан с несколькими сессиями.

Это дает возможность аккаунтинг-серверу объединить все записи в логах, относящиеся к взаимосвязанным сессиям.

Лекция 24. Использование локальной БД для хранения учетных записей

Цель

Учетные записи пользователей хранятся в локальной базе данных.

Топология сети



Описание практической работы

Межсетевой Экран 1

1. Создаем локальную базу данных.

Веб-интерфейс:

User Authentication → Local User Databases → Add
	Name: l2tp_users



Командная строка

add LocalUserDatabase l2tp_users

2. Создаем учетные записи пользователей.

Веб-интерфейс:

User Authentication → Local User Databases →l2tp_users
Users → Add



Командная строка

add Userl2tp_u Password=qwerty AutoAddRouteNet=remote/rem_lan

3. Создаем правило аутентификации пользователей.

Веб-интерфейс:

User Authentication → User Authentication Rules → Add

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



На вкладке Authentication Options указать имя локальной базы данных пользователей.



На вкладке Agent Options указать параметры РРР-аутентификации.



Командная строка

add UserAuthRule AuthSource=Local Interface=l2tp_server LocalUserDB=l2tp_users 
OriginatorIP=wan2/wan2_gw Agent=PPP TerminatorIP=wan2/wan2_ip Name=l2tp_rules 

Лекция 25. Использование сервера RADIUS для хранения учетных записей

Цель

Учетные записи пользователей хранятся на отдельном сервере, доступ к которому выполняется по протоколу RADIUS.

Топология сети



Описание практической работы

Сервер радиус

На Windows Server 2008 добавить роль Network Policy and Access Services.



В качестве RADIUS-клиента указать IP-адрес МЭ 2.



В свойствах указать тот же самый разделяемый секрет, что на NAS.



Создать политику запроса соединения (ConnectionRequestPolicies), в которой указать атрибуты RADIUS, присылаемые NAS.



Могут быть добавлены различные условия аутентификации NAS.

Эта информация должна присылаться NAS при запросе доступа.

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

1. В политиках запроса соединения (Connection Request Policies) можно указать имя пользователя, задаваемое на аутентифици-руемой стороне туннеля.





2. В политиках сети (Network Policies) перечислить группы, чле-нам которых разрешен доступ.

На сервере RADIUS:



В данном примере члены группы l2tp_group могут быть указаны на аутентифицируемой стороне туннеля.

Roles → Active Directory Users and Computers → Users → l2tp_group



На аутентифицируемой стороне туннеля указывается имя пользователя:

Interfaces → PPTP/L2TP Clients



На стороне NAS проверяется, что аутентификация выполнена:

Status → User Authentication



NAS

Объекты Адресной Книги

Создать объекты, описывающие IP-адреса RADIUS-серверов аутентификации и авторизации.

Веб-интерфейс:

Object → Address Book → Add → Address Folder
	Name: radius
Object → Address Book → radius → Add



Командная строка:

add Address AddressFolder radius
cc Address AddressFolder radius
add IP4Address radius_ip Address=192.168.2.121

Ссылка на RADIUS-сервера

Создать ссылку на внешнюю базу данных пользователей, в которой указывается тот же пароль, что и на сервере RADIUS.

Веб-интерфейс:

User Authentication → External User Databases → Add → RADIUS Server



Командная строка:

add RadiusServer radius_server_auth IPAddress=radius/radius_IP SharedSecret=qwerty

Создать ссылку на сервер хранения учетных записей RADIUS, в кото-рой указывается тот же пароль, что и на сервере RADIUS.

Веб-интерфейс:

User Authentication → Accounting Servers → Add → RADIUS Server



Командная строка

add RadiusAccounting radius_server_ac IPAddress=radius/radius_IP SharedSecret=qwerty

Правила аутентификации

Указать правила аутентификации.

Веб-интерфейс:

User Authentication Rules → Add User Authentication Rule



В качестве интерфейса указать интерфейс l2tp_server. В качестве исходного IP-адреса указать IP-адрес противоположной точки туннеля. В качестве IP-адреса завершения (Terminator IP) указать IP-адрес на локальной стороне.

На вкладке Authentication Options выбрать созданный RADIUS-Сервер.



На вкладке Accounting выбрать созданный RADIUS-Сервер.



На вкладке Agent Options указать параметры РРР-шифрования.



Командная строка

add UserAuthRuleAuth Source=RADIUS Interface=l2tp OriginatorIP=wan1/wan1_gwFW2 RadiusServers=W2K8_radius 
Agent=PPP TerminatorIP=wan1/wan1_ipFW2 
AccountingServers=W2K8_radius Name=l2tp_radius 

Лекция 26. Протокол LDAP

Введение

ITU (International Telecommunication Union) разработал серию рекомендаций для создания так называемого сервиса Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о различных объектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base - DIB). Информация включает имя объекта, а также различные атрибуты, характеризующие этот объект. Данные рекомендации носят название стандарта Х.500.

Для доступа к объектам этой распределенной базы данных был разработан Протокол Доступа к Каталогу (Directory Access Protocol – DAP).

LDAP (Lightweight Directory Access Protocol) предоставляет большинство возможностей DAP при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.

Однако не существует взаимно однозначного соответствия между операциями протокола LDAP и операциями протокола DAP стандарта Х.500.

LDAP - это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.

Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.

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

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

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

Запись идентифицируется глобально уникальным именем (Distinguished Name – DN) – подобно имени домена в структуре DNS.

Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS.

Преимущества LDAP

Основные причины роста популярности LDAP связаны с тем, что:

Сравнение LDAP и базы данных

Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:

Принципы развертывания серверов LDAP

При развертывании серверов LDAP необходимо выполнить следующие задачи:

Основные характеристики LDAP

Основными характеристиками LDAP, которые определяют его свойства, являются:

Способ хранения и доступа к информации

Рассмотрим информационную модель Каталога LDAP.

Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Инфор-мация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу, используя клиентское ПО. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.

DIB содержит следующие типы информации:

  1. Пользовательская информация - информация, предоставляемая пользователям и, быть может, изменяемая ими.
  2. Административная и функциональная информация - информация, используемая для администрирования и/или функционирования Каталога.

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

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

Запись Каталога – это поименованный набор информации. Она являет-ся основной единицей информации, хранящейся в Каталоге. Существует несколько видов записей Каталога.

Запись содержит информацию о конкретном объекте. Запись типа Alias (Псевдоним) обеспечивает способ альтернативного именования того же самого объекта.

Множество записей имеет иерархическую структуру дерева, которая называется Информационное Дерево Каталога – Directory Information Tree (DIT).

Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и alias-записи.

Информационное дерево Каталога

DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.

Дуги между вершинами определяют отношения между записями. Если существует дуга от Х к Y, то запись Х является родителем Y, и Y непосредственно подчиняется Х. Вышестоящими записями являются записи непосредственного родителя и его родителей. Подчиненными записями являются все записи, непосредственно подчиненные данной, и все их подчиненные.

Пример дерева Каталога:

Пример дерева Каталога


Рис. 13.1.  Пример дерева Каталога

В данном случае dc=msu и dc=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.

Способ именования

LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:

Принципы именования следующие:

Относительные уникальные имена

Относительное уникальное имя (Relative Distinguished Name – RDN) является совокупностью некоторого множества записей.

Значения записей RDN должно быть уникальным среди всех непосред-ственных подчиненных вышестоящей записи.

Полные уникальные имена

Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет узел в дереве.

Приведем примеры DN:

Примеры DN


Рис. 13.2.  Примеры DN

В LDAPv3 для представления уникального имени (DN) используется строка UTF-8.

Самым левым элементом является последний элемент в дереве. Далее через запятую перечисляются элементы более высоких уровней.

Уникальные имена имеют две части.

В приведенном выше примере RDN есть CN=olga

Базовое уникальное имя есть CN=Users,DC=olga,DC=oit,DC=cmc,DC=msu,DC=ru

Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.

Запись LDAP

Вся информация в LDAP хранится в записях.

Основные свойства записи:

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

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

Два значения атрибута считаются эквивалентными, если эти значения одинаковые в соответствии с правилами эквивалентности для данного типа атрибута. Если для типа атрибута не определено правило эквивалентности, то два значения два значения этого атрибута считаются эквивалентными, если они одинаковые с учетом чувствительности к регистру.

Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они не чувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.

Атрибуты

Атрибут состоит из имени атрибута и одного или более значений дан-ного атрибута.

Примеры имен атрибутов:

uid		User id
cn		Common Name
sn		Surname
l		Расположение (Location)
ou		Организационная единица
o		Организация
dc		Контроллер Домена
st		Штат
c		Страна

Каждое значение атрибута должно быть уникальным, т.е. дублирова-ние не допускается.

Примеры атрибутов LDAP


Рис. 13.3.  Примеры атрибутов LDAP

Описания атрибута

Описание атрибута состоит из типа атрибута и возможно нескольких параметров атрибута.

Пример синтаксиса атрибутов LDAP


Рис. 13.4.  Пример синтаксиса атрибутов LDAP

Типы атрибутов

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

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

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

Каждый тип атрибута определяется идентификатором объекта (OID) и возможно одним или несколькими короткими именами (дескрипторами).

Значение атрибута

Значения атрибута должно соответствовать синтаксису, определенному для атрибута.

Когда атрибут используется в качестве имени записи, в RDN присутствует единственное значение данного атрибута. Это значение должно быть уникальным.

Схема

Схема Каталога предназначена для:

Схема содержит следующую информацию:

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

Схема Каталога состоит из следующего множества определений:

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

b) Определение классов объектов, описывающих множество обязательных и необязательных атрибутов.

c) Определение правил соответствия.

d) Определение синтаксиса, описывающего используемые правила представления.

Описываемые в Схеме определения


Рис. 13.5.  Описываемые в Схеме определения

Класс объекта

Класс объекта группирует объекты, которые имеют общие характери-стики. Классы определяют необходимые и допустимые атрибуты.

Записи могут состоять из объектов нескольких классов. Необходимые и допустимые атрибуты записи являются объединением атрибутов каждого класса, из объектов которого состоит запись.

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

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

Каждый класс объекта может быть одним из трех видов: абстрактный (Abstract), структурный (Structural) или вспомогательный (Auxiliary).

Каждый класс объекта идентифицируется своим идентификатором объекта (OID) и возможно одним или более именем.

Абстрактные классы объектов

Абстрактный (Abstract) класс объекта описывает основные характеристики, которыми должны обладать классы объектов, которые являются наследниками абстрактного класса.

Существует специальный класс, называемый top – все структурные и абстрактные классы являются его расширением. Для данного класса необходимым атрибутом является только objectClass. Это гарантирует, что все записи имеют атрибут objectClass.

Абстрактные классы не могут происходить от структурных или вспомогательных классов объектов.

Все структурные классы объектов получены от абстрактного класса top. Вспомогательные классы необязательно получены от top.

Записи могут иметь объекты только структурных и вспомогательных классов.

Структурные классы объектов

Структурный класс является подклассом абстрактного класса top.

Структурные классы не могут быть подклассом вспомогательных классов.

Вспомогательные классы объектов

Объекты вспомогательных классов (Auxiliary) используются для описания дополнительных характеристик записей. Обычно они применяются для расширения множества необходимых и допустимых атрибутов записи.

Объекты вспомогательных классов не могут принадлежать подклассам структурных классов.

Запись может иметь любое количество объектов вспомогательных классов.

Множество объектов вспомогательных классов, которые принадлежат записи, может со временем изменяться.

Наследование классов объектов

Наследование классов объектов обладает следующими свойствами:

Правила синтаксиса

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

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

Правила соответствия

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

LDIF

LDIF (LDAP Data Interchange Format) является форматом обмена данными и обладает следующими свойствами:

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

Распределенное множество серверов LDAP

Протокол LDAP предполагает, что существует один или несколько серверов, которые совместно предоставляют доступ к Информационному Дереву Каталога (DIT).

Пример распределенного множества серверов LDAP


Рис. 13.6.  Пример распределенного множества серверов LDAP

Каждый сервер содержит определенное поддерево DIT.

Разработка топологии

Дерево Каталога может быть распределено по нескольким физическим серверам.

Использование распределенной топологии обеспечивает:

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

Распределенная структура Каталогов во многом аналогична распределенной структуре серверов DNS.

Ссылки (Referral)

Для реализации распределенной топологии LDAP-Сервер может содержать ссылки (referral) на другие LDAP-серверы. Эти ссылки используются в операциях поиска, что обеспечивает клиенту возможность получения информации от нескольких серверов.

Взаимодействие серверов LDAP


Рис. 13.7.  Взаимодействие серверов LDAP

Рассмотрим последовательность запросов при поиске клиентом информации в Каталоге.

  1. Клиент запрашивает информацию у Сервера 1.
  2. Сервер 1 возвращает ссылку на Сервер 2.
  3. Клиент повторно посылает запрос на Сервер 2.
  4. Сервер 2 возвращает информацию Клиенту.

Код результата поиска может указывать, что сервер, с которым осуществляется соединение, не содержит целевой записи. В этом случае сервер присылает ссылку на другой сервер в поле referral. Это поле содержит одну или несколько ссылок на один или несколько серверов или сервисов, которые могут быть доступны по протоколу LDAP или по другим протоколам. Такие ссылки могут быть возвращены в ответе для любого запроса операции (исключая операции unbind и abandon, которые не имеют ответа). По крайней мере один URL должен быть указан в поле referral.

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

В URL для протокола LDAP содержится DN, который указывает имя объекта. Если DN в ответе присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, а если DN в ответе отсутствует, клиент будет использовать то же самое имя, что и в начальном запросе. Некоторые серверы (например, участвующие в распределенном индексировании) могут указать в ссылке различные фильтры для операции поиска. Если фильтр в URL присутствует, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, если фильтр отсутствует, клиент должен использовать тот же фильтр, который он использовал ранее для данного запроса. Другие аспекты нового запроса могут быть как теми же самыми, так и отличаться от запроса, в результате которого была получена ссылка.

Имя корневого контекста

Имя корневого контекста является записью верхнего уровня для каждого сервера. Некоторые серверы могут иметь несколько имен корневого контекста.

LDAP-Сервер предоставляет информацию об имени корневого контекста в атрибуте baseDN.

Определение baseDN сервера


Рис. 13.8.  Определение baseDN сервера

Корневой контекст является набором атрибутов, который зависит от конкретного сервера. Значения этих атрибутов можно получить, выполнив поиск объекта с фильтром (objectClass=*).

Описание протокола

Основные свойства протокола LDAP:

Для обеспечения расширяемости клиенты и серверы должны игнорировать те элементы, чьи теги они не распознали.

Клиент указывает версию, которую он использует как часть запроса bind. Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны передавать данный атрибут.

Параметр baseDN (Base Object) на стороне клиента


Рис. 13.9.  Параметр baseDN (Base Object) на стороне клиента

В протоколе LDAP определены следующие операции:

bindRequest
bindResponse
unbindRequest   
searchRequest
searchResEntry
searchResDone
searchResRef
modifyRequest
modifyResponse
addRequest
addResponse
delRequest
delResponse
modDNRequest
modDNResponse
compareRequest
compareResponse
abandonRequest
extendedReq
extendedResp

Все сообщения протокола имеют общий конверт, содержащий поля, необходимые всем операциям протокола. В настоящий момент общими полями являются только MessageID и, возможно, controls.

Пример сообщения searchRequest


Рис. 13.10.  Пример сообщения searchRequest

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

Ответы сервера содержат значение MessageID из соответствующего запроса.

Control представляет собой способ указать дополнительную информацию в LDAP-сообщении. Control только изменяет семантику сообщения, к которому он присоединен.

Результат выполнения операции возвращается в поле resultCode, которое может принимать следующие значения:

Success				(0) 
operationsError			(1) 
protocolError			(2) 
timeLimitExceeded		(3) 
sizeLimitExceeded		(4) 
compareFalse			(5) 
compareTrue			(6) 
authMethodNotSupported		(7) 
strongAuthRequired		(8) 
referral				(10) 
adminLimitExceeded		(11) 
unavailableCriticalExtension	(12)
confidentialityRequired		(13) 
saslBindInProgress		(14) 
noSuchAttribute			(16) 
undefinedAttributeType		(17) 
inappropriateMatching		(18) 
constraintViolation		(19) 
attributeOrValueExists	(20) 
invalidAttributeSyntax	(21) 
- 22-31 неиспользуются -- 
noSuchObject			(32) 
aliasProblem			(33) 
invalidDNSyntax			(34) 
-- 35 зарезервировано для неопределенного isLeaf -- 
aliasDereferencingProblem	(36) 
- 37-47 неиспользуются -- 
inappropriateAuthentication	(48) 
invalidCredentials		(49) 
insufficientAccessRights 	(50) 
busy				(51) 
unavailable			(52) 
unwillingToPerform		(53) 
loopDetect				(54) 
- 55-63 неиспользуются -- 
namingViolation			(64) 
objectClassViolation		(65) 
notAllowedOnNonLeaf			(66) 
notAllowedOnRDN				(67) 
entryAlreadyExists			(68) 
objectClassModsProhibited		(69) 
- 70 reserved for CLDAP -- 
affectsMultipleDSAs			(71) 
- 72-79 не используются -- 
other			       (80)

Коды результата являются расширяемыми.

Операции протокола LDAP

В протоколе определено 9 операций:

Типичные переговоры LDAP


Рис. 13.11.  Типичные переговоры LDAP

Операция Bind

Операция Bind передает аутентификационную информацию от клиента к серверу.

Пример сообщения bindRequest


Рис. 13.12.  Пример сообщения bindRequest

Параметрами запроса Bind являются:

Ответ Bind определяется следующим образом.

Пример сообщения bindResponse


Рис. 13.13.  Пример сообщения bindResponse

BindResponce содержит статус запроса клиента на аутентификацию.

Если доступ разрешен, то resultCode будет Success, в противном случае он должен содержать OperationError или другую индикацию неудачной аутентификации. Если сервер не поддерживает требуемую клиенту версию протокола, он должен установить resultCode в protocolError.

Операция Unbind

Назначение операции Unbind состоит в завершении сессии протокола.

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

Операция Search

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

Сообщение Search Request имеет следующие параметры:

baseObject - LDAPDN, 
scope 
baseObject 		(0), 
singleLevel 		(1), 
wholeSubtree 		(2) , 
derefAliases 
neverDerefAliases 	(0), 
derefInSearching 	(1), 
derefFindingBaseObj 	(2), 
derefAlways 		(3) }, 
sizeLimit 	INTEGER (0 .. maxInt), 
timeLimit 	INTEGER (0 .. maxInt), 
typesOnly 	BOOLEAN, 
filter 	Filter, 
attributes 	AttributeDescriptionList 

Filter ::= CHOICE { 
and			[0] SET SIZE (1..MAX) OF Filter, 
or			[1] SET SIZE (1..MAX) OF Filter, 
not			[2] Filter, 
equalityMatch		[3] AttributeValueAssertion, 
substrings		[4] SubstringFilter, 
greaterOrEqual	[5] AttributeValueAssertion, 
lessOrEqual		[6] AttributeValueAssertion, 
present		[7] AttributeDescription, 
approxMatch		[8] AttributeValueAssertion, 
extensibleMatch 	[9] MatchingRuleAssertion 
} 
SubstringFilter ::= SEQUENCE { 
type	AttributeDescription, 
-- по крайней мере один должен присутствовать, 
-- initial и final могут быть указаны только один раз
substrings	SEQUENCE OF CHOICE { 
 initial	[0] AssertionValue, 
 any		[1] AssertionValue, 
	final	[2] AssertionValue } 
} 
MatchingRuleAssertion ::= SEQUENCE { 
matchingRule	[1] MatchingRuleId OPTIONAL, 
type		[2] AttributeDescription OPTIONAL, 
matchValue		[3] AssertionValue, 
dnAttributes	[4] BOOLEAN DEFAULT FALSE 
} 

Перечислим параметры Search Request:

Следует заметить, что если запрошены все пользовательские атрибуты, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены.

Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в Search Responses, которые являются LDAP-сообщениями, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.

SearchResultEntry::= SEQUENCE { 
objectName	LDAPDN, 
attributes	PartialAttributeList 
} 
PartialAttributeList ::= SEQUENCE OF SEQUENCE { 
type	AttributeDescription, 
vals		SET OF AttributeValue 
} 
-- следуетзаметить, что PartialAttributeList может
-- иметь ноль элементов (если ни один из атрибутов затре-бованной записи 
-- не может быть возвращен) и что множество vals  
-- может также иметь ноль элементов (если запрошены только типы или 
-- все значения были исключены из результата) 
SearchResultReference::= [APPLICATION 19] SEQUENCE OF LDAPURL 
-- по крайней мере один элемент LDAPURL должен присут-ствовать 
SearchResultDone ::= [APPLICATION 5] LDAPResult 

После получения Search Request сервер будет выполнять необходимый поиск в DIT.

Сервер может возвращать как найденные записи (SearchResultEntry), так и ссылки на другие серверы для продолжения поиска (SearchResultReference).

Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.

Пример запроса searchRequest


Рис. 13.17.  Пример запроса searchRequest

Пример ответа searchResEntry


Рис. 13.18.  Пример ответа searchResEntry

Операция Modify

Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify имеет следующие параметры:

object	LDAPDN, 
modification
operation
add		(0), 
delete		(1), 
replace	(2) }, 
modification	AttributeTypeAndValues } 
AttributeTypeAndValues ::= SEQUENCE { 
type	AttributeDescription, 
vals	SET OF AttributeValue
} 

Перечислимпараметрызапроса Modify:

Результат изменения, которое пытался выполнить сервер при получении Modify Request, возвращается в Modify Response.

При получении Modify Request сервер выполняет необходимые изменения в DIT.

Сервер возвращает клиенту единственный Modify Response, указывающий либо на успешное завершение изменения DIT, либо на причину неудачного завершения. Заметим, что в силу требования атомарности применения списка изменений в Modify Request, клиент может считать, что ни одно изменение DIT не выполнено, если полученный Modify Response указывает на какую-либо ошибку, и что все запрошенные изменения про-шли успешно, если Modify Response указывает на успешное завершение операции изменения.

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

Операция Add

Операция Add позволяет клиенту запросить добавление записи в Каталог. Add Request имеет следующие параметры:

entry	LDAPDN, 
attributes	AttributeList 
AttributeList ::= SEQUENCE OF SEQUENCE { 
type	AttributeDescription, 
vals	SET OF AttributeValue 

Параметрами Add Request являются:

Запись, указанная в поле entry в AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example,DC=NET, но запись DC=Example, DC=NET не существует, а запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.

Операция Delete

Операция Delete позволяет клиенту запросить удаление записи из Каталога.

Сообщение Delete Request состоит из DN удаляемой записи. Заметим, что сервер не переходит по aliases, и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.

Результат операции удаления, выполненной сервером при получении сообщения Delete Request, возвращается в сообщении Delete Response.

Операция Modify DN

Операция Modify DN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. Сообщение Modify DN Request имеет следующие параметры:

entry		LDAPDN, 
newrdn		RelativeLDAPDN, 
deleteoldrdn	BOOLEAN, 
newSuperior	[0] LDAPDNOPTIONAL

Параметрами Modify DN Request являются:

Результат попытки изменения имени сервером при получении сообщения Modify DN Request возвращается в сообщении Modify DN Response.

Например, если запись, указанная в параметре entry, была cn=OlgaLaponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция завершится с кодом ошибки entryAlreadyExists.

Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.

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

Операция Compare

Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. Compare Request имеет следующие параметры:

entry	LDAPDN, 
ava	AttributeValueAssertion

Перечислим параметры CompareRequest:

Результат сравнения, выполненного сервером при получении Compare Request, возвращается в Compare Response.

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

Заметим, что управление доступом может быть организовано таким образом, чтобы значения некоторых атрибутов (таких как userPassword) сравнивались или запрашивались другими способами.

Операция Abandon

Операция Abandon предоставляет возможность создания запроса на прерывание сервером выполняющейся операции.

MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от идентификатора более ранней операции, для которой был выполнен Abandon.

Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в Abandon Request. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполнив новую операцию bind.

Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, модификации) определяется сервером.

В том случае, если сервер получил Abandon Request для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.

Клиенты не должны несколько раз посылать запросы Abandon для одной и той же операции, но должны обрабатывать полученные результаты прерванных операций (так как они могли быть уже переданы после полу-чения Abandon и не могли быть прерваны).

Серверы сбрасывают запросы Abandon для тех MessageID, которые они не распознали, для операций, которые не могут быть прерваны, и для операций, которые уже прерваны.

Дополнительные операции

В версию 3 LDAP добавлен расширенный механизм, позволяющий определять дополнительные операции для сервисов, которые ранее не были доступны в протоколе LDAP, например для операций цифровой подписи.

Расширенная операция позволяет клиенту делать запросы и получать ответы с предопределенными синтаксисом и семантикой. Каждый запрос должен иметь уникальный OBJECT IDENTIFIER.

requestName	LDAPOID,  
requestValue	OCTET STRING OPTIONAL

requestName есть OBJECT IDENTIFIER операции requestValue содержит информацию в том виде, в котором она определена в операции. Данная информация инкапсулирована в строку октетов.

Сервер отвечает LDAPMessage, содержащим ExtendedResponse.

COMPONENTS OF LDAPResult, 
ResponseName	LDAPOID OPTIONAL, 
Response		OCTET STRING OPTIONAL 

Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.

Лекция 27. Использование сервера LDAP/MS AD для хранения учетных записей

Цель

Учетные записи пользователей хранятся в MS AD сервере.

Топология сети



Описание практической работы

1. Создать AD с DNS-именем olga.oit.cmc.msu.ru



2. На межсетевом экране создать внешнюю базу данных пользо-вателей. DNS-имя MS Active Directory указывается при созда-нии этой базы данных.

Веб-интерфейс:

User Authentication → External User Databases → Add → LDAP Server



В поле Base Object DNS-имя указано в формате DN, в поле Domain Name в формате DNS.

3. В AD создать контейнер хранения учетных записей удаленных пользователей.



Или использовать существующий контейнер, например, Users:



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



4. В выбранном контейнере создать пользователя, в нашем случае создается пользователь l2tp_user в контейнере l2tp.



5. Имя этого пользователя указывается на противоположной сто-роне туннеля (в нашем случае на стороне L2TP-клиента).

Веб-интерфейс:

Interfaces → PPTP/L2TPClients → Add → PPTP/L2TPClient



6. Имя пользователя в AD является значением атрибута sAMAccountName.



7. Имя этого атрибута указывается в поле Name Attribute в параметрах создания внешней базы данных пользователей на межсетевом экране.



8. Аутентификация противоположной стороны туннеля (в нашем случае L2TP-клиента) выполняется по значению поля, имя которого указано в поле Password Attribute в параметрах со-здания внешней базы данных пользователей на межсетевом экране.



9. Тип этого поля должен быть Text.



10. Значение поля указывается в AD.



11. И на противоположной стороне туннеля (в нашем случае L2TP-клиента) в качестве значения пароля.



К AD посылается следующий запрос:



Ответ от AD следующий:



Значение поля description, которое является паролем пользователя, передается в открытом виде. Следовательно, канал между межсетевым экраном и AD должен быть защищен.

Дополнения


Литература