http://www.osp.ru/os/1996/01/178793/
Идентификация и проверка подлинности пользователей или аутентификация - основное средство защиты информационных систем от постороннего вмешательства. В соответствии с технологией клиент/сервер, организация такой защиты заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. На сегодняшний день на роль фактического стандарта сервера аутентификации претендует Kerberos, продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем - концерн OSF, например, сделал Kerberos частью своей распределенной компьютерной среды (DCE).
Под идентификацией обычно понимается процедура, посредством которой пользователь или процесс сообщает сведения о себе. Проверка подлинности, или аутентификация - это процедура проверки достоверности предъявленных данных. Современные информационные системы представляют собой совокупность разнородных и реализованных на различных аппаратно-программных платформах, территориально разнесенных компонентов. Как правило, большинству пользователей требуется доступ ко многим сервисам, предоставляемым системами. В то же время ни им, ни системным администраторам не хочется размножать регистрационную информацию и особым образом входить в каждый сервер.
Выход из этой ситуации заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. Выделение особого сервера аутентификации позволяет реализовать собственные прикладные комплексы со своей системой понятий, но со стандартной процедурой проверки подлинности, что существенно облегчает управление правами доступа пользователей. Kerberos, а точнее, его версия, реализованная в MIT, является свободно распространяемым программным продуктом, доступным в исходных текстах, за исключением криптографических компонентов. Таким образом, в руках разработчиков прикладных систем и лиц, отвечающих за информационную безопасность, оказывается не "черный", а "прозрачный ящик", функционирующий понятным и проверяемым образом и доступный для "подгонки" с учетом нужд конкретной организации.
Неформальное изложение возможностей Kerberos
Система Kerberos предназначена для решения следующей задачи. Имеется открытая, незащищенная сеть, в узлах которой сосредоточены субъекты - пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Стобы субъект C мог доказать свою подлинность субъекту S, без которой последний не станет обслуживать C, он должен не только назвать себя, но и продемонстрировать знание своего секретного ключа. Субъект C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта - доступна для пассивного и активного прослушивания, а, во-вторых, потому, что S не знает и не должен знать секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.
Система Kerberos представляет собой третью сторону, которой доверяют все, владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.
Стобы с помощью Kerberos получить доступ к серверу S клиент C посылает запрос, содержащий сведения о себе и о требуемой услуге. В ответ Kerberos возвращает две порции информации: так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, переданной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные - ведь содержимое билета никому, кроме сервера и Kerberos, недоступно, и продемонстрировал знание своего секретного ключа. Значит, клиент - именно тот субъект, за кого себя выдает. Обратим внимание, что секретные ключи в процессе проверки подлинности не передавались по сети даже в зашифрованном виде - они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи - вопрос отдельный. Проиллюстрируем описанную процедуру на рис. 1.
Рисунок 1.
Проверка сервером S подлинности клиента C (вариант 1) (Здесь c и s - сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 - дополнительная (по отношению к билету) информация, Tc.s - билет для клиента C на обслуживание у сервера S, Kc и Ks - секретные ключи клиента и сервера, {info}K - информация info, зашифрованная ключом K.)
Приведенный вариант 1 является крайне упрощенной версией реальной процедуры проверки подлинности. Прежде всего, необходимо уточнить структуру пересылаемых запросов и возвращаемых ответов. И билет, и вторая порция информации, предоставляемая со стороны Kerberos, содержат случайный ключ, пригодный для шифрования сообщений, пересылаемых между клиентом и сервером. Этот ключ называется сеансовым и представляет собой общую секретную информацию, разделяемую C и S. Появление подобной общей информации и возможность организации конфиденциального взаимодействия - важный побочный продукт аутентификации средствами Kerberos.
Билет, который выдает Kerberos, имеет ограниченный срок годности. Естественно распространить этот срок и на сеансовый ключ. Когда срок годности истекает, необходимо проведение повторной проверки подлинности. Продолжительность стандартного срока годности зависит от политики безопасности, проводимой организацией. Типичный срок годности - 8 часов.
Вполне вероятно, что клиент C захочет убедиться в подлинности обслуживающего его сервера S. Стобы это было возможным, клиент шифрует дополнительную информацию, передаваемую серверу, с помощью сеансового ключа. Сервер может узнать сеансовый ключ, только расшифровав билет. Если это случится и сервер вернет клиенту свидетельство того, что он сумел прочитать дополнительную информацию, C вправе считать подлинность сервера S установленной.
Далее, необходимо защитить информацию, пересылаемую по сети, от воспроизведения. Если этого не сделать, злоумышленник сможет послать серверу дубликаты билета и дополнительной информации и успешно выдать себя за "второго C". Стандартный способ защиты от воспроизведения - включение в нее временных штампов или так называемых одноразовых номеров, позволяющих удостовериться в "свежести" сообщений и в их неповторяемости, а также в целостности последовательности сообщений. Одноразовые номера позволяют также ассоциировать ответы с предыдущими запросами. Отобразим упомянутые уточнения на рис. 2.
Рисунок 2.
Взаимная проверка клиентом C и сервером S подлинности друг друга (вариант 2) (Здесь timeexp - срок годности билета, n - одноразовый номер, Kc.s - сеансовый ключ, ts - временной штамп, ck - контрольная сумма).
Отдельного пояснения заслуживает обозначение 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.
Рисунок 3.
Взаимная проверка клиентом C и сервером S подлинности друг друга (вариант 3) (Здесь Ac - аутентификатор клиента).
Таким образом, секретный ключ нужен клиенту только на короткое время для получения "билета на билеты" - в дальнейшем используется сеансовый ключ, разделяемый клиентом и сервером при выдаче билетов. Компрометация сеансового ключа, имеющего ограниченный срок годности, - вещь существенно менее опасная, чем раскрытие секретного ключа.
Любопытно отметить, что AS, вопреки своему названию, не проверяет подлинности обратившихся к нему субъектов. Билет на билеты может получить кто угодно, в том числе и злоумышленник, но воспользоваться этим билетом он сможет, только если знает секретный ключ субъекта, от имени которого он выступает. Отметим также, что если для программных субъектов - клиентов и серверов - способ хранения секретного ключа не определен, то для пользователей специфицируется алгоритм преобразования пароля в ключ. Иными словами, пользователю достаточно помнить только свой пароль.
Каждый сервер Kerberos обслуживает определенную область управления. До сих пор рассматривался случай, когда клиент и сервер находились в пределах одной области и взаимодействовали посредством локального Kerberos. Важно разобрать ситуацию, когда клиент и сервер зарегистрированы в разных областях.
Стобы субъекты из разных областей управления могли общаться друг с другом, между областями должно быть заключено соглашение, а серверы Kerberos должны обменяться секретными ключами. Ключи могут быть разными для различных общающихся пар серверов Kerberos. Поскольку между областями управления Kerberos существуют стандартные иерархические отношения, каждой области достаточно заключить соглашение и обменяться ключами с родителем и всеми потомками. В принципе возможно заключение соглашения между двумя произвольными областями, субъекты которых активно общаются друг с другом. На рис. 4 приведена схема организации отношения между областями управления.
Рисунок 4.
Отношения между областями управления Kerberos.
При наличии договорных отношений локальный сервер выдачи билетов может выдать билет к удаленному TGS, который, в свою очередь, выдаст билет к удаленному серверу. В таком случае последовательность обмена сообщениями будет иметь вид как на рис. 5.
Рисунок 5.
Взаимная проверка клиентом C и удаленным сервером S-rem подлинности друг друга (вариант 4).
В более общем случае клиенту придется пройти через несколько промежуточных серверов выдачи билетов. Впрочем, поскольку глубина вложенности областей управления обычно невелика (3 - 4), не должен быть длинным и путь до удаленного сервера.
Такова идейная основа механизма аутентификации, принятого в Kerberos. Следует отметить, что, помимо изложенных, сервер Kerberos предоставляет еще много дополнительных возможностей. Так, на самом деле срок годности билета задается как пара: время начала и окончания его действия. В результате можно получать билеты "на потом", например, для пакетных заданий, выполняющихся ночью. Далее, имеется механизм билетов с правом передачи, что позволяет серверам выполнять определенные действия от имени обратившихся к ним клиентов, например серверу печати осуществлять доступ к файлам пользователя.
На реализацию и использование Kerberos можно смотреть с разных точек зрения. Пользователь видит Kerberos как набор команд, например, kinit - начало Kerberos-сеанса, kdectroy - разрушение 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
Kerberos предоставляет средства проверки подлинности субъектов, работающих в незащищенной сети - сети, не исключающей возможности перехвата, модификации и пополнения пересылаемой информации. Kerberos не полагается на средства аутентификации, реализованные в операционных системах сетевых компьютеров, на подлинность сетевых адресов, на физическую защищенность сетевых компьютеров, кроме тех, на которых он сам работает. С точки зрения реализации Kerberos - это один или несколько серверов проверки подлинности, функционирующих на физически защищенных компьютерах. Серверы поддерживают базу данных субъектов и их секретных ключей.
- отказов в обслуживании. Отражение подобных атак, как и реакция на "нормальные" отказы возлагается на пользователей и администраторов.
- кражи секретных ключей. Субъекты должны сами заботиться о секретности своих ключей.
- угадывания паролей. Плохо выбранный пароль может не устоять против подбора с помощью словаря, вычисления по паролю секретного ключа с последующей попыткой расшифровать полученную от Kerberos информацию. Соответствующим образом измененная программа ввода пользовательского пароля - "троянский конь" позволит злоумышленнику узнать пароли многих пользователей. Таким образом, Kerberos все же предполагает некоторый уровень защищенности обслуживаемых компьютеров.
- повторного использования идентификаторов субъектов. В принципе возможна ситуация, когда новый субъект Kerberos получит тот же идентификатор, что был у ранее выбывшего субъекта. Возможно, что этот идентификатор остался в списках управления доступом какой-либо системы в сети. В таком случае новый субъект унаследует права доступа выбывшего.
- рассогласования часов на компьютерах. Kerberos полагается на приблизительную согласованность часов сетевых компьютеров. Подобное предположение упрощает обнаружение воспроизведения, дублирования информации. Допустимая погрешность часов может устанавливаться индивидуально для каждого сервера. Если синхронизация часов выполняется сетевыми средствами, соответствующий протокол должен сам заботиться о безопасности.
Kerberos не защищает от:
ОСНОВНЫЕ ПОНЯТИЯ KERBEROS
Авторизация - процесс определения правомочности использования клиентом определенной услуги, перечня доступных объектов, а также разрешенных видов доступа.
Аутентификатор - запись, содержащая информацию, про которую можно доказать, что она была недавно сгенерирована с использованием сеансового ключа, известного только клиенту и серверу.
Аутентификационный заголовок - запись, содержащая билет и удостоверение. Эта запись будет представлена серверу в процессе проверки подлинности.
Аутентификационный маршрут - последовательность промежуточных областей управления, пересекаемых в процессе проверки подлинности субъектов из разных областей.
Аутентификация, проверка подлинности - проверка того, что субъект является тем, за кого он себя выдает.
Билет - запись, помогающая клиенту доказать серверу свою подлинность. Билет содержит сведения о клиенте, сеансовый ключ, временной штамп и другую информацию. На билете ставится печать с помощью секретного ключа сервера. Билет действителен только вместе со свежим аутентификатором.
Билет на билеты (Ticket-Granting Ticket, TGT) - билет к серверу выдачи билетов (Ticket-Granting Server, TGS), позволяющий получать билеты к другим серверам.
Доверенность - документ, дающий предъявителю право на доступ к определенным объектам или услугам. В системе Kerberos это может быть билет, использование которого ограничено содержимым поля авторизации. К билету должен прилагаться сеансовый ключ.
Идентификатор субъекта - имя, используемое для уникальной идентификации субъекта.
Клиент - процесс, использующий сетевые сервисы от имени пользователя. Отметим, что в некоторых случаях сервер сам может являться клиентом некоторого другого сервера, например, сервер печати может пользоваться услугами файлового сервера.
Обычный текст - исходные данные для функции шифрования или результат функции расшифровки. Расшифровка преобразует шифрованный текст в обычный.
Печать - средство, позволяющее так зашифровать запись, содержащую несколько полей, что замена отдельных полей станет невозможна без знания ключа шифрования - иначе подмена будет обнаружена.
Сеансовый ключ - временный ключ шифрования, используемый двумя субъектами. Время жизни такого ключа ограничено одним сеансом работы в системе.
Секретный ключ - ключ шифрования, разделяемый субъектом и KDC и используемый длительное время. В случае, когда субъектом является пользователь, секретный ключ вычисляется по паролю.
Сервер - субъект, предоставляющий ресурсы сетевым клиентам.
Сервис - ресурс, предоставляемый сетевым клиентам. Зачастую может поддерживаться несколькими серверами, например, сервис удаленных файлов.
Субсеансовый ключ - временный ключ шифрования, используемый двумя субъектами. Обмен субсеансовыми ключами защищается посредством сеансовых ключей. Время жизни субсеансового ключа ограничено одним сеансом общения между субъектами.
Субъект - пользователь, клиент или сервер, имеющий уникальное имя и участвующий в сетевом общении.
Удостоверение - совокупность билета и секретного сеансового ключа, необходимого для успешного использования билета в процессе проверки подлинности.
Центр распределения билетов (Key Distribution Center, KDC) - сетевой сервис, предоставляющий билеты и временные сеансовые ключи, или конкретный сервер, оказывающий данную услугу, или хост - компьютер, на котором функционирует этот сервер. KDC обслуживает запросы и на начальный билет, а соответствующий компонент иногда называют сервером начальной аутентификации - Authentication Server, AS, и на билеты к конкретным серверам - этот компонент именуют сервером выдачи билетов - TGS.
Цербер (Kerberos) - не только мифологический трехголовый пес, охранявший подземное царство, но и название сервиса проверки подлинности для проекта Афина (Массачусетский технологический институт), протокол, используемый этим сервисом, а также программная реализация сервиса аутентификации.
Шифрованный текст - результат функции шифрования. Шифрование преобразует обычный текст в шифрованный.
Флаги, используемые в билетах
Каждый Kerberos-билет содержит набор флагов. Большинство из них запрашивается клиентом перед получением билета. Некоторые флаги Kerberos сам автоматические устанавливает и сбрасывает. Рассмотрение флагов и способов их использования позволяет в полном объеме продемонстрировать аутентификационные возможности сервера Kerberos.
Начальные билеты
Флаг INITIAL указывает на то, что билет выдан сервером начальной аутентификации (AS). Серверы приложений, которым нужно знать секретный ключ пользователя (пример - программа изменения пароля), могут принимать билеты только с установленным флагом INITIAL как свидетельство недавнего использования именно секретного, а не сеансового, ключа. Два дополнительных флага, PRE-AUTHENT и HW-AUTHENT, могут нести дополнительную информацию о начальной аутентификации, независимо от того, кто выдал данный билет - AS или TGS.
Негодные билеты
Флаг INVALID свидетельствует о том, что билет негоден. Серверы приложений должны отвергать билеты с этим флагом. Обычно флагом INVALID помечаются предварительные билеты, предназначенные для использования в будущем. Чтобы предварительный билет стал годным, его нужно зарегистрировать, направив в TGS запрос с опцией VALIDATE. Регистрация пройдет успешно только после наступления начального времени годности билета. Процедура регистрации позволяет выявлять и отвергать украденные предварительные билеты.
Обновляемые билеты
Билеты с длительным сроком годности удобны, но небезопасны, поскольку кража содержащейся в них информации открывает злоумышленнику доступ к соответствующим серверам также на длительное время. С другой стороны, использование краткосрочных билетов заставляет постоянно обращаться к секретному ключу, что представляет еще большую опасность.
Обновляемые билеты позволяют смягчить последствия кражи информации. Они имеют два срока годности - промежуточный и окончательный. Клиент должен периодически, до момента окончания промежуточного срока, представлять обновляемый билет в TGS с опцией RENEW. В ответ TGS возвращает новый билет с другим сеансовым ключом и более поздним промежуточным сроком годности. Все остальные поля переносятся из старого билета без изменений. Подобная периодическая перерегистрация в принципе позволяет TGS выявлять украденные билеты и уничтожать их. В результате потенциальное время жизни нелегальных билетов уменьшается.
Обычно флаг RENEWABLE интерпретируется только TGS, однако некоторые особенно осторожные серверы могут отвергать билеты с этим флагом. Флаг RENEWABLE устанавливается в билете лишь по явному запросу клиента к серверу начальной аутентификации (AS).
Предварительные билеты
Иногда нужны билеты, которые будут использоваться спустя довольно долгое время после выдачи. Например, от момента порождения пакетного задания до начала выполнения может проходить несколько часов. Поскольку держать годные билеты в пакетной очереди рискованно, Kerberos предлагает механизм предварительных билетов, получаемых в момент порождения задания, но "дремлющих" до момента активации и перерегистрации в TGS. Если в промежутке стало известно о краже билета, TGS откажет в перерегистрации.
Флаг MAY-POSTDATE обычно интерпретируется только TGS в "билетах на билеты" и устанавливается лишь по явному запросу клиента к серверу начальной аутентификации (AS). По "билету на билеты" с флагом MAY-POSTDATE TGS выдает билет к серверу с флагом POSTDATED. Сервер может проверить, как давно был выдан предварительный билет и, возможно, отказать клиенту в обслуживании. Более того, билет с флагом POSTDATED первоначально содержит и флаг INVALID, так что клиент перед использованием должен перерегистрировать билет в TGS.
Доверенности
Когда возникает необходимость позволить серверу выполнить некоторые действия от имени клиента, например, получить доступ к файлам для их печати, то можно воспользоваться имеющимся в Kerberos механизмом доверенностей.
Флаг PROXIABLE, установленный в "билете на билеты" (это происходит по умолчанию), дает право TGS выдать новый билет (но не "билет на билеты") с другим сетевым адресом. В новом билете устанавливается флаг PROXY. Клиент может передать серверу новый билет в качестве доверенности.
Чтобы затруднить использование украденных удостоверений, Kerberos-билеты обычно разрешается использовать только субъектам с сетевыми адресами, явно указанными в билете. В принципе сетевые адреса в билете можно не указывать, но это не рекомендуется. Вот почему клиент должен передать серверу доверенность - билет с сетевым адресом сервера.
Билеты с правом передачи
Билеты с правом передачи позволяют развить механизм доверенностей и передавать серверу права на совершение любых действий от имени клиента. Подобное сильнодействующее средство полезно, например, когда пользователь, войдя в удаленную систему, хочет, чтобы проверка подлинности проходила так же, как и в случае локального входа.
Флаг FORWARDABLE трактуется почти так же, как PROXIABLE, однако дает право на получение новых "билетов на билеты" с другими сетевыми адресами и устанавливается лишь по явному запросу пользователя к серверу начальной аутентификации (AS) при получении первоначального "билета на билеты". В принципе пользователь может получить новый "билет на билеты" с другими сетевыми адресами и без флага FORWARDABLE, обратившись непосредственно к AS, но тогда ему придется вводить свой пароль.
Флаг FORWARDED устанавливается в новом билете по явному запросу пользователя, когда он представляет TGS билет с флагом FORWARDABLE, задает опцию FORWARDED и указывает новый список сетевых адресов. Флаг FORWARDED наследуется при выдаче новых билетов.
Форматы данных в системе Kerberos
Опишем форматы двух важнейших объектов системы Kerberos - билета и аутентификатора. Описание дается в нотации ASN.1. Понимание этих форматов позволит лучше прочувствовать тонкости механизма аутентификации.
Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER,
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
Шифруемая секретным ключом сервера часть билета имеет следующий вид:
EncTicketPart ::= [APPLICATION 3] SEQUENCE{ flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses
OPTIONAL,
authorization-data [10]
AuthorizationData
OPTIONAL
}
Поясним смысл компонентов билета:
- tkt-vno - номер версии формата билета. Данный документ описывает версию 5;
- realm - область управления, выдавшая билет, и, одновременно, область, содержащая сервер;
- sname - имя сервера, к которому выдан данный билет;
- enc-part - зашифрованная часть билета;
- flags - битовая шкала флагов;
- key - сеансовый ключ, выданный Kerberos для связи между клиентом и сервером;
- crealm - область управления, в которой зарегистрирован клиент, и, одновременно, область, в которой происходила начальная проверка подлинности;
- cname - имя клиента;
- transited - список промежуточных областей управления, участвовавших в аутентификации клиента;
- authtime - время выдачи первоначального билета, "наследником" которого является данный билет. Осторожные серверы могут отвергать билеты, основанные на слишком давней аутентификации;
- starttime - время, отмечающее начало срока годности билета. Если данное поле не задано, используется значение authtime;
- endtime - время, отмечающее окончание срока годности билета. В принципе конкретные серверы могут устанавливать свои, более жесткие, ограничения на время жизни билета;
- renew-till - время, после которого даже обновляемый билет становится негодным;
- caddr - список сетевых адресов, откуда билет может быть использован. Если список пуст, билет можно использовать откуда угодно. Данный список затрудняет применение злоумышленником украденного билета;
- authorization-data - авторизационная информация, передаваемая владельцем билета серверу приложений. Предполагается, что это поле содержит имена обслуживаемых объектов и права доступа к ним. Поле authorization-data позволяет выдать доверенность на совершение определенных действий. Например, клиент, желающий напечатать файл, может передать серверу печати доверенность на чтение файла. Содержательная трактовка поля авторизации находится вне компетенции Kerberos.
Аутентификатор шифруется сеансовым ключом, копия которого находится в билете и позволяет выбрать "настоящий сеансовый ключ" для обслуживания конкретного сеанса связи между клиентом и сервером.
Authenticator ::= [APPLICATION 2] SEQUENCE{ authenticator-vno [0] INTEGER,
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] INTEGER,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] INTEGER OPTIONAL,
authorization-data [8] AuthorizationData
OPTIONAL
}
Типы пересылаемых сообщений
Обмен с сервером начальной аутентификации
Общение с сервером начальной аутентификации (таблица 1) обычно инициируется клиентом, желающим получить удостоверение к определенному серверу, но не имеющим пока других удостоверений. Для шифровки и расшифровки используется секретный ключ клиента. Как правило, данный обмен происходит при входе в систему, для получения удостоверения к серверу выдачи билетов. Кроме того, общение с сервером начальной аутентификации используется для получения удостоверения к серверам, требующим знания именно секретного ключа (пример - сервер смены пароля).
В своем запросе (KRB_AS_REQ) клиент посылает открытым текстом свое имя и имя сервера, к которому он хочет получить удостоверение. Ответ, KRB_AS_REP, содержит билет, который клиент должен будет представить серверу, и сеансовый ключ для совместного использования клиентом и сервером. Билет шифруется секретным ключом сервера, сеансовый ключ и дополнительная информация - секретным ключом клиента. Сообщение KRB_AS_REP содержит данные, позволяющие связать его с предыдущим запросом (KRB_AS_REQ) и обнаружить дублирование сообщений. В случае какой-либо ошибки возвращается сообщение KRB_ERROR, которое не шифруется.
Сервер аутентификации не делает попыток убедиться в подлинности обратившегося к нему субъекта - он просто возвращает информацию, воспользоваться которой может лишь тот, кто знает секретный ключ субъекта.
Обмен с сервером выдачи билетов
Обмен между клиентом и сервером выдачи билетов (таблица 2) инициируется клиентом, когда тот хочет получить удостоверение к определенному серверу, возможно, зарегистрированному в удаленной области управления, обновить или зарегистрировать существующий билет или получить билет с доверенностью. В первом случае клиент должен располагать предварительно полученным от сервера начальной аутентификации билетом к TGS. Формат сообщений при обмене с сервером выдачи билетов почти тот же, что и для сервера начальной аутентификации. Основное отличие состоит в том, что для шифровки и расшифровки используется сеансовый ключ.
Запрос (KRB_TGS_REQ) состоит из информации, подтверждающей подлинность клиента, и заявки на удостоверение. Ответ (KRB_TGS_REP) содержит запрашиваемое удостоверение, зашифрованное сеансовым ключом, и данные, позволяющие обнаружить дублирование сообщений и связать ответ с запросом.
Аутентификационный обмен клиент/сервер
Данный обмен (таблица 3) используется сетевыми приложениями для взаимной проверки подлинности. Клиент должен располагать предварительно полученным удостоверением к серверу. Клиент передает серверу билет, аутентификатор зашифрованный сеансовым ключом и некоторую дополнительную учетную информацию. Если требуется ответ, то сервер возвращает только аутентификатор, зашифрованный тем же сеансовым ключом.
Защищенные сообщения
Сообщения типа KRB_SAFE могут использоваться партнерами по общению, желающими контролировать целостность передаваемой информации. Контроль целостности достигается за счет включения в сообщение криптографической контрольной суммы. Используется последний субсеансовый или сеансовый ключ.
Конфиденциальные сообщения
Сообщения типа KRB_PRIV могут использоваться партнерами по общению, желающими защитить данные от нелегального прочтения и контролировать их целостность. Цель достигается криптографическими методами.
Пересылка удостоверений
Сообщения типа KRB_CRED используются для пересылки удостоверений с одного хоста на другой. В сообщение входят билет и зашифрованные данные, содержащие сеансовый ключ и другую ассоциированную с билетом информацию.
База данных Kerberos
Сервер Kerberos должен иметь доступ к базе данных, содержащей идентификаторы и секретные ключи субъектов. Записи в этой базе должны содержать по крайней мере информацию, представленную в таблице 4.
Секретные ключи субъектов могут шифроваться "мастер-ключом" Kerberos.
Когда секретный ключ сервера изменяется нормальным образом - не в результате компрометации старого ключа, то старый ключ следует сохранять до тех пор, пока остаются годными билеты, выданные с его помощью. Таким образом, возможна ситуация, когда один субъект имеет несколько активных ключей. Информация, шифруемая секретным ключом, всегда помечается версией примененного ключа, иначе правильная расшифровка может стать невозможной.
Субъекту с несколькими активными ключами соответствует несколько записей в базе данных Kerberos. При выдаче билетов и в процессе начальной аутентификации всегда используется самый свежий ключ, имеющий максимальный номер версии.
В реализации Kerberos в рамках проекта Афина записи базы данных содержали следующие дополнительные поля, представленные в таблице 5.
Битовая шкала атрибутов может задавать характеристики билетов, допустимые для данного субъекта, или влиять на процесс преобразования пароля в секретный ключ.
Если политика безопасности, проводимая организацией, требует более детальной отчетности, то в записи базы данных Kerberos могут быть включены поля, помогающие отследить все операции с билетами. Правда, при этом следует учитывать необходимость частых изменений базы, что может быть нежелательным и по соображениям эффективности, и по соображениям безопасности. Также возможно, но нежелательно использование внешней по отношению к Kerberos базы данных, например, службы имен сетевой операционной системы.
Заключение
Популярность системы Kerberos довольно быстро растет, а вместе с ней растет и число предложений, направленных на развитие Kerberos. Эти предложения можно разбить на две основные группы:
стандартизация программного интерфейса как часть процесса выработки более общего прикладного программного интерфейса безопасности, затрагивающего не только аутентификацию;
стандартизация использования в процедуре начальной аутентификации одноразовых паролей и/или асимметричных методов шифрования.
Можно надеяться, что доступность системы Kerberos и гласность процедуры стандартизации сделают аутентификационный сервис еще более надежным и гибким.
АО "Инфосистемы Джет" niva@jet.msk.su
16.01.1996г
Комментариев нет:
Отправить комментарий