Неформальное изложение возможностей Kerberos

Система Kerberos предназначена для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты — пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание своего секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен) знать секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

Система Kerberos представляет собой надежную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.

Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило — клиент) посылает Kerberos'у запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает две порции информации: так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его (билета) содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание своего секретного ключа. Значит, клиент — именно тот субъект, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) — они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи — вопрос отдельный.

Проиллюстрируем описанную процедуру Рис. 1 .

Изложенный вариант 1 — крайне упрощенная версия реальной процедуры проверки подлинности. Прежде всего, необходимо уточнить структуру пересылаемых запросов и возвращаемых ответов. И билет, и вторая порция информации, предоставляемая со стороны Kerberos, содержат случайный ключ, пригодный для шифрования сообщений, пересылаемых между клиентом и сервером. Этот ключ называется сеансовым и представляет собой общую секретную информацию, разделяемую C и S. Появление подобной общей информации и возможность организации конфиденциального взаимодействия — важный побочный продукт аутентификации средствами Kerberos.

Билет, который выдает Kerberos, имеет ограниченный срок годности. Естественно распространить этот срок и на сеансовый ключ. Когда срок годности истекает, необходимо проведение повторной проверки подлинности. Продолжительность стандартного срока годности зависит от политики безопасности, проводимой организацией. Типичный срок годности — 8 часов.

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

Далее, необходимо защитить информацию, пересылаемую по сети, от воспроизведения. Если этого не сделать, злоумышленник сможет послать серверу дубликаты билета и дополнительной информации и успешно выдать себя за "второго C". Стандартный способ защиты от воспроизведения — включение в нее временных штампов и/или так называемых одноразовых номеров, позволяющих удостовериться в "свежести" сообщений и в их неповторяемости (и, более того, в целостности последовательности сообщений). Одноразовые номера позволяют также ассоциировать ответы с предыдущими запросами.

Отобразим упомянутые уточнения на новом рисунке ( Рис. 2 ).

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

Порции информации в сообщениях 3 и 4, шифруемые сеансовыми ключами, называют аутентификаторами. Они позволяют убедиться в подлинности предъявившего их субъекта. В дальнейшем аутентификатор клиента мы будем обозначать Ac, аутентификатор сервера — As.

Вариант 2 гораздо практичнее варианта 1, однако и он нуждается в уточнении. Естественно предположить, что клиенту понадобятся услуги нескольких серверов. Соответственно, чтобы доказать свою подлинность, клиенту придется несколько раз повторять диалог с Kerberos и использовать свой секретный ключ. К сожалению, долго держать наготове секретный ключ опасно — его могут украсть. Чтобы справиться с указанной проблемой, сервер Kerberos "раздваивается" на сервер начальной аутентификации (AS — Authentication Server) и сервер выдачи билетов (TGS — Ticket Granting Server). Клиент запрашивает у AS по схеме, изображенной на Рис. 2 , билет к TGS ("билет на получение билетов", "билет на билеты" — TGT, Ticket-Granting Ticket). TGT содержит сеансовый ключ для засекречивания общения между клиентом и сервером выдачи билетов. Билеты к другим серверам клиент получает у TGS на основании "билета на билеты".

В результате схема получения доступа к серверу приобретает вид, изображенный на Рис. 3 .

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

Любопытно отметить, что AS, вопреки своему названию, не проверяет подлинности обратившихся к нему субъектов. Билет на билеты может получить кто угодно, в том числе и злоумышленник, но воспользоваться этим билетом он сможет, только если знает секретный ключ субъекта, от имени которого он выступает. Отметим также, что если для программных субъектов (клиентов и серверов) способ хранения секретного ключа не определен, то для пользователей специфицируется алгоритм преобразования пароля в ключ. Иными словами, пользователю достаточно помнить только свой пароль.

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

Чтобы субъекты из разных областей управления могли общаться друг с другом, между областями должно быть заключено соглашение, а серверы Kerberos должны обменяться секретными ключами. (Ключи могут быть разными для различных общающихся пар серверов Kerberos.) Поскольку между областями управления Kerberos существуют стандартные иерархические отношения, каждой области достаточно заключить соглашение и обменяться ключами с родителем и всеми потомками. В принципе возможно заключение соглашения между двумя произвольными областями, субъекты которых активно общаются друг с другом. Рис. 4 иллюстрирует отношения между областями управления.

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

В более общем случае клиенту придется пройти через несколько промежуточных серверов выдачи билетов. Впрочем, поскольку глубина вложенности областей управления обычно невелика (3 — 4), не должен быть длинным и путь до удаленного сервера.

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

На реализацию и использование Kerberos можно смотреть с разных точек зрения. Пользователь видит Kerberos как набор команд (например, kinit — начало Kerberos-сеанса, kdestroy - разрушение Kerberos-билетов и окончание сеанса, klist — выдача текущего списка билетов, kpasswd — смена Kerberos-пароля и т.п.) или не видит его вообще, если соответствующие вызовы встроены в утилиты и команды операционной системы, такие как login, logout, passwd.

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

С точки зрения системного администратора Kerberos — это набор административных средств конфигурирования, регистрации субъектов, работы с базой данных секретных ключей.

В последующих разделах Kerberos рассматривается более формально. Основой изложения является официальный документ сообщества Internet — RFC 1510 "The Kerberos Network Authentication Service (V5)".

От чего защищает и от чего не защищает Kerberos	Содержание	Флаги, используемые в билетах