ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.12.2023
Просмотров: 42
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Рисунок 1.- Механизм взаимной аутентификации
Теперь, когда ясен механизм простой взаимной аутентификации вроде того, что описан выше, мы сталкиваемся со следующей проблемой. В примере со Артемом и Еленой не упомянуто место, в котором они договариваются о секретном ключе для своей переписки. Нет, конечно люди могут встретиться где-нибудь в парке и обсудить все детали, но в сетевой картине договариваются машины. В дальнейшем мы будем под Еленой подразумевать клиентскую программу, а под Артемом сетевую службу на сервере. При подобном раскладе очевидно, что клиентская программа и серверная служба сами по себе встретится не могут, тем более если у Елены-клиента есть задача посылать сообщения на несколько серверов появляется еще одна проблема – для каждого из них придется обзавестись отдельным секретным ключом. Да и Артем - серверу потребуется столько ключей, сколько у него клиентов. То есть если каждой клиентской программе для поддержания связи с каждой сетевой службой требуются уникальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то задача обмена ключами становится достаточно острой проблемой. Эту проблему как раз-таки и решает рассматриваемый нами протокол Kerberos.
Из самого названия протокола понятно, что он задуман для решения проблемы управления ключами. Персонаж греческой мифологии Цербер – это огромный трёхголовый пёс, охраняющий врата в царство мёртвых. Проводя аналогию можно увидеть соответствие трех голов Цербера трём участкам безопасной связи: клиент, сервер и доверенный посредник. Роль посредника между ними играет центр распределения ключей Key Distribution Center, далее KDC, который в контексте данной работы, будучи установленным на отдельной машине является сервером аутентификации Kerberos (Цербер) для отдельного домена.
KDC являет собой специальную службу, запущенную на физически защищенном сервере, где она ведет базу данных с информацией по учётным записям всех главных абонентов безопасности (security principal) своей области ответственности. Под областью ответственности в сетях Windows 2000 и выше подразумевается домен, в дальнейшем, для удобства мы будем использовать этот термин. В базе данных KDC по мимо данных о каждом абоненте безопасности хранится и криптографический ключ, известный только абоненту и службе KDC.
Этот ключ называется долговременным и используется для установления связи между пользователем системы безопасности и центра распределения ключей. Чаще всего при реализации протокола Kerberos долговременные ключи генерируются на основе пароля пользователя. Когда клиенту требуется обратиться к серверу, он сначала направляет запрос в KDC, который в свою очередь направляет каждому участнику предстоящего сеанса связи копии уникального сеансового ключа (session key), с коротким периодом действия. Назначение такого ключа в проведении аутентификации клиента и сервера. Копия ключа, направляемая на сервер шифруется при помощи долговременного ключа этого сервера, а направляемая клиенту соответственно с помощью долговременного ключа клиента.
Рисунок 2.- Теоретическое управление ключами
В теории, для работы в качестве доверенного посредника KDC достаточно направлять сеансовые ключи как показано выше – непосредственно абонентам безопасности. Однако же на практие реализовать такую простую схему очень ресурсозатрано и как следствие очень сложно. В этом случае, серверу пришлось бы хранить свою копию сеансового ключа в памяти до попытки клиента связаться с ним. Причем сервер обслуживает множество клиентов, поэтому ему придется хранить ключи всех клиентов, которые могут связаться с ним. При таких условиях функция управления ключами перетянет на себя значительную часть вычислительной мощности сервера, что в свою очередь ограничивает возможность масштабирования сети. Так же следует принять во внимания возможные коллизии при прохождении сетевого траффика: вполне возможно, что запрос от клиента, получившего сеансовый пароль, поступит на сервер раньше, чем сеансовый ключ от KDC, тем самым сервер будет вынужден ждать с ответом, пока не получит свою копию ключа, что еще больше нагружает сервер. Поэтому при реализации протокола Kerberos используется иная схема управления ключами – с помощью сеансовых мандатов.
1.5. Сеансовые мандаты
При формировании ответа на запрос клиента, который намерен подключиться к удаленному серверу, служба KDC фактически направляет обе копии сеансового ключа (клиента и сервера) клиенту, причем сеансовый ключ клиента шифруется при помощи долговременного ключа клиента, а сеансовый ключ сервера вместе с информацией о клиенте формируется в блок данных, называющийся сеансовый мандат. Далее сеансовый мандат целиком шифруется с помощью долговременного ключа сервера, который как мы помним знаю лишь сервер и служба KDC.Таким образом обязанность обработки сеансового мандата, возлагается на клиента, который должен доставить его на сервер.
Рисунок 3. - Схема аутентификации с использованием сеансового мандата.
Следует отметить, что в данном случае функции центра распределения ключей ограничиваются генерацией сеансового мандата и службе KDC более нет нужды отслеживать статусы доставки сообщений соответствующим адресатам. В случае же если какое-либо из сообщений попадет не по адресату, - ничего страшного не случится, так как расшифровать клиентскую копию сеансового ключа может только тот, кто владеет долговременным ключом клиента, а расшифровать сеансовый мандат способен тот только тот, кто владеет долговременным ключом сервера. Итак, получив ответ от KDС, клиентская машина извлекает из полученного блока сеансовый мандат и свою копию сеансового ключа, который помещает в безопасное хранилище в области оперативной памяти. В момент возникновения необходимости связаться с сервером, клиент посылает ему блок информации состоящий из сеансового мандата, который зашифрован долговременным ключом этого сервера и клиентского аутентификатора, зашифрованного с помощью сеансового ключа, полученного от KDC при первоначальном обращении к нему. Собственно, сам сеансовый мандат в комплексе с аутентификатором и является удостоверением, по которому сервер доподлинно определяет «личность» обратившегося к нему клиента.
Рисунок 4. - Взаимная аутентификация клиент-сервер.
Далее сервер, получив блок информации удостоверяющий «личность» клиента, расшифровывает содержимое сеансового мандата и получает свой сеансовый ключ, который использует для расшифровки аутентификатора клиента. При условии, что все проходит нормально, сервер делает вывод, что удостоверение клиента было выданно доверенным посредником, то есть службой KDC. При этом клиент может потребовать у сервера провести взаимную аутентификацию. В таком случае сервер при помощи своей копии сеансового ключа зашифровывает метку времени из клиентского аутентификатора и пересылает её клиенту в качестве собственного аутентификатора.
Используя такую схему связи с использованием сеансовых мандатов, сервере не нужно хранить сеансовые ключи для связи с клиентами, они хранятся в специальной кэш-памяти удостоверений (credetntials cache) клиентской машины, что является несомненным приемуществом. Сервре же, получив от клиента мандат, получает, расшифровав его, свою копию сеансового ключа. При миновании надобности в этом ключе, сервер попросту может стереть его из своей памяти.
Другое, немаловажное приемущество, заключается в том, что у клиента отпадает необходимость в обращении к центру KDC перед каждой попыткой соединения с с конкретным сервером. Сеансовый мандаты используются многократно. Для нивелирования угрозы хищения устанавливается срок жизни мандата, который установливается KDC взависимости от настроек политики Kerberos для каждого отдельного домена в сети, в самой структуре данных мандата. Стандартным сроком жизни мандата является период не больше восьми часов, то есть стандартная продолжительность сеанса работы в сети, примерно равная рабочему дню.
1.6 Мандат на выдачу мандатов
Ранее отмечалось, что обычно долговременный ключ пользователя создается на основе его пароля. Когда Елена проходит регистрацию, клиент клиент Kerberos, установленные у неё на машине, обрабатывает её пароль с помощью функции хэширования, при помощи одного из алгоритмов DES-CBC-MD5 или других. В результате на выходе получаем криптографический ключ. В KDC получившейся долговременный ключ Елена хранится в базе данных с учетными данными пользователей. Получая запрос от клиента, KDC заглядывает в свою базу данных и находит в ней учетную запись нужного пользователя, в нашем примере Елена, далее извлекая соответствующий пользователю долговременный ключ.
Процесс вычисления одной копии ключа по пользовательскому паролю и извлечения другой его копии из базы данных выполняется единожды за сеанс, при первом входе пользователя в сеть. После получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos на машине пользователя запрашивает сеансовый мандат и сеансовый ключ, котырые впоследствии и используются во все последующих транзакциях с KDC в течении текущего сеанса работы в сети. Для установления первичного сеанса связи с KDC, при первом обращении KDC отвечает специальным сеансовым мандатом, так называемый мандат на выдачу мандатов (ticket-granting ticket), или TGT мандат. Как и обычный сеансовый мандат, TGT имеет копию сеансового ключа для связи службы с клиентом (KDC-клиент). Манндат TGT шифруется при помощи долговременного ключа центра KDC, а клиентская копия сеансового ключа посредством долговременного ключа пользователя. Ответ от KDC на первоначальный запрос клиента, расшифровывается и из него извлекается клиентская копия сеансового ключа с использованием своего долговременного ключа пользователя из своей кэш-памяти. Как правило, после этого долговременный ключ, полученный из пользовательского пароля можно удалить из памяти, так как он больше не нужен, потому что вся последующая связь центра KDC с клиентом будет шифроваться с помощью сеансового ключа. Как и все остальные сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT или до момента выхода пользователя из системы. В связи с этим такой ключ называется сеансовым ключом регистрации (logon session key). Сам по себе мандат TGT почти ничем не отличается от обычного. Перед обращением к той или иной службе, клиент сначала обращается к своей кэш-памяти удостоверений и ищет там сеансовый мандат для этой конкретнйо службы. При его отсутствии, клиент находит там же TGT мандат, извлекает оттуда сеансовый ключ регистрации, компонует с его помощью аутентификатор, который высылает вместе с TGT обратно в центр KDC, причем одновременно с этим высылается запрос на сеансовый мандат для нужнуго сервера и службы. По факту выходит, что организации защищенного доступа к KDC не имеет отличий от организации такого доступа к любому другому серверу домена, ведь требуемой набор остается тем же: аутентификатор, сеансовый ключи и мандат (в случае с KDC – мандат TGT). Со стороны же KDC, TGT мандаты позволяют ускорить обработку запросов на получение мандатов. Центр KDC обращается к долговременному ключу пользователя лишь однажды, когда предоставляет клиенту мандат TGT, во всех дальнейших транзакциях с этим клиентом центр распределения ключей расшифровывает мандаты TGT при помощи своего долговременного ключа и извлекает из него сеансовый ключ регистрации, который и используется для проверки аутентификатора клиента.
1.7 Аутентификация за пределами домена
Функция центра распределения ключей можно разделить на две группы, а именно: служба выдачи мандатов, которая генерирует сеансовые мандатыи и служба выдачи TGT мандатов. Такое разделение позволяет использовать рассматриваемый протокол за пределами основного домена, то есть клиентская машина, получившая TGT мандат из центра распределения ключей одного домена получает возможность воспользоваться им для получения сеансовых мандатов в KDC другого домена.
Для описания приципа междоменной аутентификации для примера рассмотрим простую сеть в составе двух доментов «Москва» и «Воронеж».
Допустим, что администраторы этих двух доменов являются сотрудниками одной фирмы или существует иная веская причина требующая уравнять в правах доступа пользователей одного домена с другогим доменом. В любом случае наладить аутентификацию между доменами будет не трудной, для этого следует договориться о едином междоменном ключе, который в Windows 2000, например, генерируется автоматически, когда между доменами устанавливаются доверительные отношения). В момент создания ключа, служба выдачи мандатов каждого домена регистрируется в KDC другого домена в роли главного абонента безопасности, после этого служба KDC, а именно служба выдачи мандатов каждого из доменов начинает рассматривать службу выдачи мандатов второго домена в качестве еще одной своей службы. В результате клиент, прошедший аутентификацию и получивший определенные права в системе, получает и возможность запрашивать и получать сеансовые мандаты для неё.
Далее рассмотрим процесс при котором пользователь с учетной записью в домене «Москва» запрашивает доступ с службе из домена «Воронеж». Клиент Kerberos на машине пользователя направляет запрос в KDC своего домена, где просит выдать сеансовый мандат на сервер расположенный в другом домене. Центр KDC, аточнее её служба выдачи мандатов проверяет свою базу данных абонентов безопасности и видит, что такого сервере среди абонентов нет, поэтому служба отправляет клиенту не сеансовый мандат, а мандат переадресации (referal ticket),который из себя представляет TGT мандат зашифрованный междоменным ключом, общим для центров KDC доменов «Москва» и «Воронеж». Клиент же, по получении этого мандата переадресации, использует его для подготовки следующего запроса на на сеансовый мандат. Отличие в том, что в этот раз запрос направляется в KDC того домена, где находится абонентская запись искомого сервера, в нашем случае домена «Саратов». Его служба выдачи мандатов принимает попытку расшифровать TGT мандат из домена «Москва» при помощи своей копии междоменного ключа, при успехе этой попытки, KDC домена «Саратов» отправляет обратившемуся клиенту сеансовый мандат для доступа к соответствующей службе своего домена.