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

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

Рисунок.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.

Таблица 1 - Структура билета и различных сообщений Kerberos

Название поля	Описание
	Первые три поля билета не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления билетами, хранящимися в кэш-памяти.
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	Атрибуты привилегий клиента. Поле необязательное. Его содержимое Kerberos не обрабатывает - оно интерпретируется службой.

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

Таблица 2 - Флаги билета Kerberos

Флаг	Описание
FORWARDABLE	Указывает, что на основании данного билета TGT служба выдачи билетов может генерировать новый билет TGT с другим сетевым адресом (поле имеется только в билетах TGT).
FORWARDED	Указывает на то, что данный билет TGT был переадресован или генерирован на основе другого билета TGT, прошедшего переадресацию.
PROXY	Указывает на то, что сетевой адрес в данном билете отличается от адреса, приведенного в билете TGT, на основании которого он выдан.
RENEWABLE	Используется в сочетании с полями endtime и renew-till, разрешая периодическое обновление службой KDC билетов с повышенным срока действия.
INITIAL	Указывает, что данный билет является билетом выдачи билетов (поле имеется только в билетах TGT).

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

Клиенту необходимо знать часть информации, содержащейся как в обычных билетах, так и в билетах 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 и заменяет сеансовый ключ.