Аутентификация по протоколу 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 домена «Запад», зашифрованный с междоменным ключом, общим для доменов «Штаб-квартира» и «Запад».

3.    Клиент обращается в службу KDC домена «Запад» с просьбой о билете на доступ к серверу домена «Запад».

Служба KDC домена «Запад» направляет клиенту билет на доступ к нужному серверу.

Подпротоколы

Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и билета TGT. Он называется Authentication Service Exchange (обмен со службой аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен со службой выдачи билетов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового билета доступа к службам.

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

Подпротокол AS Exchange

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

После этого клиент посылает в службу аутентификации центра KDC запрос KRB_AS_REQ (Kerberos Authentication Service Request – запрос к службе аутентификации Kerberos). Первая часть его сообщения содержит идентификатор пользователя, то есть Алисы, а также имя службы, для которой ей нужно удостоверение, то есть службы выдачи билетов. Во второй же части указываются данные предварительной аутентификации (pre-authentication data), которые подтверждают, что Алиса знает пароль. Обычно в качестве таких данных используется метка времени, зашифрованная с долговременным ключом Алисы, хотя Kerberos допускает и другие виды предаутентификационных данных.

Рис. 5. Подпротокол AS Exchange

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

После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи билетов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в билет TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует билет TGT с собственным долговременным ключом и, наконец, включает зашифрованный сеансовый ключ регистрации вместе с билетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply – ответ службы аутентификации Kerberos), который направляет клиенту.

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

Подпротокол TGS Exchange

Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request – запрос к службе выдачи билетов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, билет TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен билет.

Рис. 6. Подпротокол TGS Exchange

Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа расшифровывает билет TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из билета TGT регистрационные данные Алисы и генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в билет, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply – ответ службы выдачи билетов Kerberos) и направляется на ее рабочую станцию.

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

Подпротокол 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, поэтому к ним нужно присмотреться как можно ближе.

Что такое билет

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

Таблица 1. Поля билета

Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Длина поля – 32 разряда, однако для администратора Kerberos интерес представляют только 9 флагов билета.

Таблица 2. Флаги билета

Какие данные из билета известны клиенту

Клиенту необходимо знать часть информации, содержащейся как в обычных билетах, так и в билетах TGT, чтобы управлять своей кэш-памятью удостоверений. Возвращая билет и сеансовый ключ в рамках подпротоколов AS Exchange или TGS Exchange, служба KDC упаковывает клиентскую копию сеансового ключа в структуру данных, где уже могут быть заполнены поля flags, authtime, starttime, endtime и renew-till. Вся эта структура шифруется с помощью ключа клиента, включается в пакет KRB_AS_REP или KRB_TGS_REP и возвращается на рабочую станцию клиента.

Как служба KDC ограничивает срок действия билета

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

Запрашивая в центре KDC билет для доступа к службе, клиент может указать конкретное время начала его действия. Если этого не сделано или заданное время уже минуло, центр KDC указывает в поле starttime текущее время.

Но независимо от того, указал клиент время начала действия билета или нет, запрос обязательно должен содержать время прекращения срока его действия. Получив такой запрос, служба KDC рассчитывает значение поля endtime. Для этого она суммирует наибольший срок действия билета, предусмотренный политикой Kerberos, со значением поля starttime, а затем сравнивает полученный результат со временем прекращения действия билета, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.

Что происходит после истечения срока действия билета

О скором истечении срока действия сеансового билета или билета TGT служба KDC не уведомляет клиента. Не следит она и за транзакциями с клиентом, если не считать краткосрочных записей, главная цель которых – предотвратить повторное использование перехваченных пакетов.

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

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

Обновляемые билеты TGT

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

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

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

Делегирование аутентификации

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

Для решения этой проблемы в протоколе Kerberos имеется специальный механизм – так называемое делегирование аутентификации. По существу, в такой ситуации клиент поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный сервер имеет право представлять клиента. Такой подход напоминает концепцию имперсонации (concept of impersonation) Windows 2000.

Делегирование аутентификации возможно двумя способами. Во-первых, клиент может получить билет на подключение к серверу высшего уровня, а затем передать его ближайшему серверу. Билеты, полученные таким способом – клиентом для ближайшего сервера – называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная трудность: чтобы получить представительский билет, клиенту нужно знать имя сервера высшего уровня. Решить проблему помогает второй способ делегирования аутентификации. Здесь клиент передает на ближайший к нему сервер свой билет TGT, который тот по мере необходимости использует для запроса собственных билетов. Билеты TGT, полученные таким образом, то есть, по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC, зависит от политики Kerberos.

Представительские билеты

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

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

Передаваемые билеты

Клиент, который намерен делегировать свои права на получение билета для доступа к серверу высшего уровня, должен запросить у службы KDC передаваемый билет TGT. Это делается с помощью подпротокола AS Exchange. В запрос обязательно включается имя сервера, который будет представлять клиента. Если политика Kerberos допускает использование передаваемых билетов, служба KDC генерирует билет TGT на доступ данного клиента к серверу высшего уровня, выставляет в нем флаг FORWARDABLE и в таком виде направляет клиенту. Клиент, в свою очередь, пересылает полученный билет TGT тому серверу, с которым работает непосредственно.

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