ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.12.2023
Просмотров: 44
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Схема переадресации запросов может быть порядочно усложнена в таких сетях, где развернуто более двух доменов. Казалось бы, всё просто, в теории центр KDC каждого домена может наладить связь с каждым центром KDC других доменов, договорившись каждым о б использовании индивидуального междоменного ключа. Однако не сложно представить насколько количество и сложность таких связей возрастет и на сколько сложно будет выстроенно управление ими. Kerberos имеет решение и для этой проблемы: клиент каждого домена можует получить доступ к серверу другого домена через один и более промежуточный сервер, каждый из которых выдаст ему мандат переадресации.
Для более наглядного описания обратимся к уже известным нам доменам «Москва» и «Воронеж», а так же добавим третий домен «Арвендейл». В центре KDC домена «Москва» отсутствует междоменной ключ для KDC домена «Саратов», но центры распределения ключей обоих доменов уже установили связь с доменом «Арвендейл». Когда клиентской машине из домена «Москва» понадобится сервер из домена «Саратов», её запрос будет пару раз переадресован. Во-первых, клиент сначала обратится в центр KDC своего домена, далее пакет попадет на промежуточный сервер «Арвендейл», а уже затем пакет направляется в KDC домена «Саратов», которому известен сеансовый ключ нужного сервера, то есть выходит, что клиент посылает сеансовый мандат три раза в три разные службы KDC. Пошагово вышеописанный процесс выглядит так:
-
Пользователь-клиент запрашивает у центра распределения ключей домена «Москва» мандат на доступ к службе сервера «Воронеж». Служба KDC «Московоского» домена возвращает клиенту мандат переадресации в KDC домена «Арвендейл», зашифрованный общим для доменов «Москва» и «Арвендейл» междоменным ключом. -
Клиент направляет запрос в службу KDC домена «Арвендейл» с вопросом о выдаче сеансового мандата на доступ к серверу домена «Саратов». Центр распределения ключей домена «Арвендейл» возвращает клиенту мандат переадресации в KDC домена «Воронеж», зашифрованный междоменным ключом, общим для доменов «Арвендейл» и «Саратов» -
В итоге клиент обращается в KDC домена «Воронеж» с запросом на сеансовый мандат для доступа к серверу, находящемуся в зоне ответственности этого домена. Центр Воронеж» отправляет в адрес клиента сеансовый мандат на доступ к нужному серверу.
1.8. Подпротоколы Kerberos
1.8.1 AS Exchange
Далее будет уместно разобрать три существующих подпротокола протокола Kerberos. Первый из них применяется центром распределения ключей для отправки клиенту сеансового ключа регистрации и TGT мандата. Называется он Authentication Service Exchange (обменный сервис аутентификации), так же допустимо применение в сокращенной форме – AS Exchange. Следующий, второй подпротокол использующийся для отправки служебных сеансовых ключей и сеансовых ключей самого центра KDC называется Ticket-Granting Service Exchange (служба обмена мандатами). Последний, третий подпротокол, Client/server Exchange (клиент-серверный обмен) нужен клиенту для пересылки сеансового мандата доступа к сервисам.
Для лучшего понимания схемы взаимодейтсвия подпротоколов следует обратиться к нашим старым знакомым в следуещем качестве: Елена– пользователь сети, а Стив – сервер.
Рисунок 5. -AS Exchange подпротокол.
Центр KDC получая запрос KRB_AS_REQ, ищет в своей базе данных соответствующий учетной записи Елена её долговременный ключ, расшифровавыет с помощью него блок данных предварительной аутентификации и проверяет метку времени, хранящуяся в нем. При успешной провереке, служба KDC делает закономерный вывод, что информация в блоке предварительной аутентификации была зашифрована долговременным ключом Елена, что значит это информация поступила от клиента, имя которого содержится в первой части блока. После успешной проверки личности Алёны, центр распределения ключей формирует удостоверение, подтверждающее, что клиентская программа протокола Kerberos на её машине имеет право направить запрос в службу выдачи мандатов. Этот процесс состоит из двух шагов:
-
Центром KDC формирует сеансовый ключ регистрации и шифрует его с помощью долговременного ключа Елена. -
Центр формирует TGT мандат включая туда еще одну копию сеансового ключа регистрации, данные авторизации Елена. Вместе с этой информацией KDC шифрует TGT мандат своим долговременным ключом. Затем зашифрованный сеансовый ключ регистрации вместе с TGT мандатом собирается в пакет Kerberos Authentication Service Reply (KRB_AS_REP) – ответ службы аутентификации Kerberos, который отправляется клиенту.
Получив это сообщение, клиент применяет свой долговременный ключ
для расшифровки сеансового ключа регистрации и помещает его в свою кэш-память удостоверений вместе с так же извлеченным TGT мандатом.
1.8.2 TGS Exchange
Клиентская программа Kerberos, установленная на машине Елена, посылает запрос на получение удостоверения на доступ к службе на сервере Артем в виде сообщения KRB_TGS_REQ (Kerberos Ticket-Granting service request - запрос к сервису выдачи мандатов Kerberos) в адрес KDC. В этом сообщении заключена информация об имени пользователя, аутентификатор, зашифрованный сеансовым ключом регистрации Алёны, TGT мандат, полученный при взаимодействии по подпротоколу AS Exchange, а так же имя службы, к которой запрашивается доступ.
Рисунок 6. Подпротокол TGS Exchange
Получив блок информации KRB_TGS_REQ, центр дистрибуции ключей используя свой секретный ключ расшифровывает TGT мандат и достает из него сеансовый ключ регистрации Елена, который в свою очередь используется для расшифровки аутентификатора Елена. При успешной проверке её аутентификатора, центр KDC извлекает из TGT мандата регистрацинные данные Елена и создает сеансовый ключ общий для клиента Елена и сервера Артем. Первую копию этого сгенерированного ключа KDC шифрует сеансовым ключом регистрации Алёны, а другую копию вместе с информацией об авторизации Елена помещает в сеансовый мандат, который шифрует долговременным ключом сервера Артем. После этих манипуляций блок информации который и является по сути удостоверением Елена включается в пакет KRB_TGS_REP (Kerberos Ticket-Grating Service Reply – ответ службы выдачи мандатов Kerberos) и отправляется обратно на рабочую станцию Алёны. Служба Kerberos на компьютере Елена получив этот пакет, расшифровывает его своим сеансовым ключом регистрации и получает таким образом сеансовый ключ доступа к запрашиваемой службе и помещает его в свою кэш-память удостоверений, извлекаемый далее сеансовый мандат на доступ к службе так же сохраняется в кэш-памяти.
1.8.3 CS Exchange
Сервис Kerberos, установленный на клиентской машине Елена посылает запрос к серверу Артем, для чего направляет сообщение KRB_AP_REQ (Kerberos Application Request – запрос уровня приложений Kerberos). Это сообщение сообщение представляет собой аутентификатор Алёны, зашифрованный сеансовым ключом для сервера Артем, мандат, полученный посредством протокола TGS Exchange, а так же флаг, свидетельствующий о желании клиента произвести процесс взаимной аутентификации, причем наличие или отсутствие данного флага определяется общей конфигурацией Kerberos, по умолчанию он устанавливается без участия пользователя и без каких-либо дополнительных запросов.
Рисунок.7. - Подпротокол CS Exchange
Сервер Артем, приняв сообщение KRB_AP_REQ, расшифровывает мандат и получает из него данные авторизации Елена и сеансовый ключ, которым далее расшифровывает аутентификатор Елена. При условии, что метка времени, содержащаяся в аунтификаторе, успешно проходит проверку, то сервер проверяет наличие флага взаимной аутентификации. При его обнаружении, Артем шифрует поле времени из аутентификатора Елена сеансовым ключом, полученным ранее, включает полученный результат в блок данных KRB_AP_REP (Kerberos Application Reply – ответ уровня приложений Kerberos) и отправляет его обратно на машину Елена. Клиент Kerberos рабочей машины Елена получив пакет KRB_AP_REP расшифровывает аутентификатор Артем при помощи сеансового ключа и сравнивает извлеченную метку времени с исходной, которую направляла в первом запросе. При их совпадении делается вывод, что линк установлен с искомой службой, и можно приступать к совместной работе.
Глава 2 Содержимое мандатов. Иные механизмы аутентификации. Уязвимости.
2.1 Мандаты в деталях
В общем и целом мы достаточно хорошо поняли для чего нужны эти самые сеансовые мандаты, теперь же пришло время рассмотреть их более подрбно, в разрезе. Наиболее полно структура сеансового мандата описана в документе RFC 1510, в рамках данной работы мы рассмотрим структуру полей содержащихся в мандате, флаги, время жизни, для чего это нужно и какие из этих данных становятся известны пользователю. В таблице 1 представлена структура сеансового мандата и различные сообщения зашифрованные в нем.
Таблица 1 – Структура мандата
| Название поля | Описание |
| | В первых трёх полях содержится «несекретная» информация, пересылаемая открытым текстом и, соответственно, не подвергаемая процедуре шифрования. Эти поля необходимы клиенту для управления мандатами, хранящимися в кэш-памяти. |
| | |
| | |
| tkt-vno | Версия мандата (номер версии формата мандата). Для актуальной версии протокола Kerberos за номером 5 в этом поле указывается цифра 5. |
| Realm | Название домена, где был создан мандат. Центр распределения ключей генерирует мандаты только для серверов и клиентов «родной» области, поэтому в этом поле фактически указывается имя области «домена» где расположен сервер с развернутым на нем KDC. |
| Sname | Имя сервере для которого сгенерирован мандат |
| Flags | Флаги мандата |
| Key | Сеансовый ключ |
| Crealm | Клиентский домен |
| Cname | Называние клиента |
| Transited | Список доменов с развернутым сервером Kerberos, с помощью которых осуществлялась аутентификация клиента, которому выдан мандат. Иначе, основываясь на самом названии – список транзитных областей (доменов). |
| Authtime | Время первичной аутентификации клиента. Это поля заполняется в момент генерации центром KDC TGT мандата и в дальнейшем при генерации мандатов на основе TGT временная метка из поля authtime TGT мандата копируется в поле authtime генерируемого мандата. |
| Starttime | Время вступления мандата в силу. |
| Endtime | Время окончания срока действия мандата. |
| renew-till | Необязательное поле. Максимальное значение поля endtime, задаваемое флагом RENEWABLE. |
| Caddr | Не обязательное поле. Здесь указывается один или несколько адресов, из которых может использоваться этот мандат. При отсутствии информации в этом поле мандатом можно воспользоваться из любого адреса. |
| Authorization-data | Необязательное поле. Атрибуты, определяющие привилегии клиента, интерпретируемые службой к которой клиент обратился. |