Сервер аутентификации Kerberos

Флаги, используемые в билетах
Начальные билеты
Негодные билеты
Обновляемые билеты
Предварительные билеты
Доверенности
Билеты с правом передачи
Форматы данных в системе Kerberos

Обмен с сервером начальной аутентификации
Обмен с сервером выдачи билетов
Аутентификационный обмен клиент/сервер
Защищенные сообщения
Конфиденциальные сообщения
Пересылка удостоверений

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

} 

• authenticator-vno - номер версии формата аутентификатора (5);
• crealm и cname - то же, что и для билета;
• cksum - контрольная сумма прикладных данных, передаваемых серверу;
• cusec - микросекундная часть временного штампа клиента;
• ctime - основная часть временного штампа клиента;
• subkey - выбранный клиентом ключ для защиты конкретного сеанса связи. Если это поле не задано, будет использоваться сеансовый ключ;
• seq-number - начальный номер последовательности сообщений. Механизм номеров используется для контроля целостности последовательности и, в частности, для защиты от дублирования. Начальный номер рекомендуется выбирать случайным образом, а последующие номера не использовать дважды даже в разных сеансах;
• authorization-data - то же, что и для билета (позволяет уточнить информацию, переданную в билете).

Типы пересылаемых сообщений

Обмен с сервером начальной аутентификации

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