Протоколы безопасного сетевого взаимодействия

       

Флаги билета


Поле флагов, введенное в билеты в версии 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 в пути.

Таблица 20.1. Флаги билета
INITIALДанный билет получен с использованием AS-протокола и не получен на основе билета, гарантирующего билет
PRE-AUTHENTПри начальной аутентификации клиент был аутентифицирован прежде, чем был выдан билет
HW-AUTHENTПротокол, используемый для начальной аутентификации, требует использования аппаратуры, ожидая ввода исключительно имени клиента
RENEWABLEГоворит TGS о том, что данный используемый билет получен взамен билета, время действия которого истекло.
MAY-POSTDATEГоворит TGS о том, что просроченный билет мог быть получен на основании данного билета, гарантирующего билет
POSTDATEDОпределяет, что данный билет является просроченным; конечный сервер может проверить поле authtime, чтобы посмотреть, когда произошла первоначальная аутентификация.
INVALIDОпределяет, что данный билет является недействительным и что прежде чем он будет использоваться, его действительность должна быть подтверждена у TGS
PROXIABLEГоворит о том, что новый билет, гарантирующий сервис, с другим сетевым адресом может быть получен на основе существующего билета
PROXYОпределяет, что данный билет является агентом на другой сервис (proxy)
FORWARDABLEГоворит TGS, что новый билет, гарантирующий билет, может быть получен на основе данного билета, гарантирующего билет
FORWARDEDОпределяет, что данный билет является либо forwarded, либо получен на основе аутентификации, включающей forwarded билет, гарантирующий билет

Содержание раздела