Рисунок 1 - Взаимная аутентификация (Алиса-Боб)

Управление ключами

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

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) - персонаж классической греческой мифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет врата подземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center или, сокращенно, KDC

KDC представляет собой службу, работающую на физически защищенном сервере. Она ведет базу данных с информацией об учетных записях всех главных абонентов безопасности (security principal) своей области (области Kerberos в сетях Windows 2000 соответствует домен, поэтому в дальнейшем мы будем применять именно этот привычный термин). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Данный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.

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

Рисунок.2. Управление ключами (в теории)

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

Сеансовые билеты

В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис.3. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа клиента, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового билета (session ticket). Затем сеансовый билет целиком шифруется с помощью долговременного ключа сервера, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку билета, несущего в себе зашифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.

Рисунок.3. Управление ключами (на практике)

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

Рисунок.4. Взаимная аутентификация (клиент-сервер)

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

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

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

Билеты на выдачу билетов

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

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

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

На запрос пользователя KDCотвечает специальным сеансовым билетом для самого себя, так называемый билет на выдачу билетов (ticket-granting ticket), или билет TGT. Как и обычный сеансовый билет, TGT содержит копию сеансового ключа для связи службы (в данном случае - KDC) с клиентом. В сообщение с билетом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Билет TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа - с помощью долговременного ключа пользователя.

Получив ответ службы KDC на свой первоначальный запрос, клиент расшифровывает свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия билета TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key). С точки зрения клиента, билет TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент, прежде всего, обращается в кэш-память удостоверений и достает оттуда сеансовый билет для этой службы. Если его нет, он начинает искать в этой же кэш-памяти билет TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с TGT высылает в KDC. Одновременно туда направляется запрос на сеансовый билет для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена - она требует сеансового ключа, аутентификатора и билета (в данном случае TGT). С точки же зрения службы KDC, билеты TGT позволяют ускорить обработку запросов на получение билетов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный билет TGT. Во всех последующих транзакциях с этим клиентом центр KDC расшифровывает билеты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента.

Аутентификация за пределами домена

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

Чтобы лучше понять принцип междоменной аутентификации, рассмотрим для начала простейшую сеть, содержащую всего два домена - "Восток" и "Запад". Предположим, что администраторы этих доменов являются сотрудниками одной организации или у них есть какие-либо другие веские причины уравнять пользователей второго домена со своими собственными. В любом из этих случаев наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения). Как только ключ создан, служба выдачи билетов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи билетов каждого из доменов начинает рассматривать службу выдачи билетов второго домена, как еще одну свою службу. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать сеансовые билеты для нее.

А теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене "Восток" запрашивает доступ к серверу из домена "Запад". Прежде всего, клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи билетов своего домена, в котором просит выдать сеансовый билет для доступа на нужный сервер. Служба выдачи билетов домена "Восток" проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый билет переадресации (referral ticket), который представляет собой TGT, зашифрованный с помощью междоменного ключа, общего для служб KDCдоменов "Восток" и "Запад". Получив билет переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи билетов того домена, где находится учетная запись нужного сервера, то есть, домена "Запад". Его служба выдачи билетов пытается расшифровать билет переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDCнаправляет клиенту сеансовый билет на доступ к соответствующему серверу своего домена.

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

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

1. Клиент запрашивает у службы KDC домена "Восток" билет на доступ к серверу домена "Запад". Служба KDC домена "Восток" направляет клиенту билет переадресации в службу KDC домена "Штаб-квартира", зашифрованный с междоменным ключом, общим для доменов "Восток" и "Штаб-квартира".

2. Клиент обращается в службу KDC домена "Штаб-квартира" с просьбой о билете на доступ к серверу домена "Запад". Служба KDC домена "Штаб-квартира" направляет клиенту билет переадресации в службу KDC домена "Запад", зашифрованный с междоменным ключом, общим для доменов "Штаб-квартира" и "Запад".