Безопасное сетевое взаимодействие (часть 1)

Флаги билета

Поле флагов, введенное в билеты в версии 5, поддерживает расширенную функциональность по сравнению с версией 4. Рассмотрим флаги, которые могут быть определены в билете (см. таб. 20.1).

Флаг INITIAL определяет, что данный билет получен от AS , а не от TGS . Когда клиент требует билет, гарантирующий сервис, от TGS , он предоставляет билет, гарантирующий билет, полученный от AS . В версии 4 это был способ, в конечном счете, получить билет, гарантирующий сервис. Версия 5 предоставляет дополнительную возможность, чтобы клиент мог получить билет, гарантирующий сервис, непосредственно от AS . Это применяется в таких, например, случаях, когда сервер изменения пароля хочет убедиться, что пароль клиента был только что проверен.

Флаг PRE-AUTHENT, если установлен, определяет, что когда AS получит первоначальный запрос (сообщение 1), он аутентифицирует клиента, прежде чем выдать билет. Строгая форма этой предаутентификации остается неспецифицированной. Например, реализация MIT версии 5 имеет предаутентификацию в виде зашифрованной отметки времени. В этом случае клиентский модуль посылает AS предаутентификационный блок, содержащий случайное число, номер версии и отметку времени и зашифрованный с использованием пароля пользователя. AS расшифровывает блок и посылает билет, гарантирующий билет, если отметка времени находится в допустимом диапазоне. Другая возможность применения данного флага состоит в использовании смарт-карт, создаваемых с постоянно меняющимся паролем, который включается в предаутентификационное сообщение. Пароли, создаваемые картой, могут быть основаны на пользовательских паролях, но затем быть преобразованы смарт-картой так, чтобы в действительности использовались одноразовые пароли. Это предотвращает атаки, основанные на легко вскрываемых паролях. Если используется смарт-карта или аналогичное устройство, это определяется флагом HW-AUTHENT.

Когда билет имеет долгое время жизни, существует опасность его кражи и последующего использования оппонентом в допустимый период. Если используется короткое время жизни для уменьшения подобной угрозы, то может возникнуть потребность в получении новых билетов. В случае билета, гарантирующего билет, клиент может хранить секретный ключ пользователя, который не подвержен риску, или повторно запрашивать у пользователя пароль. Компромисс состоит в использовании возобновляемых билетов. Билет с установленным флагом RENEWABLE включает два срока истечения: один для данного билета и один является самым поздним допустимым значением для истекаемого времени. Если новое время находится в пределах самого позднего допустимого значения, TGS может выдать новый билет с новым временем сессии и определить время его истечения. Преимущество данного механизма состоит в том, что TGS может отказаться обновлять билет, помечая его как украденный.

Клиент может выдать запрос на предоставление AS билета, гарантирующего билет, с установленным флагом MAY-POSTDATE. Клиент может затем использовать этот билет для запроса билета от TGS с установленными флагами POSTDATED и INVALID. Впоследствии клиент может подать подтверждение на просроченный билет, чтобы сделать его действительным. Эта схема может использоваться для выполнения долгих пакетных заданий на сервере, который периодически требует билет. Клиент может один раз получить некоторое число билетов для данной сессии с несколькими значениями времени. Все, кроме первого билета, первоначально являются недопустимыми. При наступлении момента, когда требуется новый билет, клиент может сделать соответствующий билет действительным. При таком подходе клиент не будет повторно использовать свой билет, гарантирующий билет, для получения билета, гарантирующего сервис.

В версии 5 стало возможным, чтобы сервер являлся proxy для клиента, в результате чего устанавливаются верительные грамоты и привилегии клиента при запросе сервиса от другого сервера. Если клиент хочет использовать данный механизм, он требует билет, гарантирующий билет, с установленным флагом PROXIABLE. Когда такой билет предоставляется от TGS , TGS разрешает получать билет, гарантирующий сервис, с различных сетевых адресов; этот последний билет имеет установленный флаг PROXY. Приложение, получившее такой билет, может принять его или требовать дополнительной аутентификации с тем, чтобы обеспечить след аудита.

Концепция proxy является ограниченным случаем более сильной процедуры перенаправления. Если в билете установлен флаг FORWARDABLE, TGS может выдать запрашивающему билет, гарантирующий билет с различными сетевыми адресами, и установить флаг FORWARDED. Этот билет может затем быть представлен удаленному TGS . Такая возможность позволяет клиенту получить доступ к серверу из другой области без требования того, чтобы каждый Kerberos поддерживал секретный ключ с серверами Kerberos во всех других областях. Например, области могут быть структурированы иерархически. Тогда клиент может просматривать дерево вверх до общего узла и затем спускаться обратно до нужной целевой области. Каждый шаг прохода включает перенаправление билета, гарантирующего билет, к следующему TGS в пути.