На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

ФЛАГИ БИЛЕТА

Каждый билет Kerberos содержит набор флагов, с помощью которых члены сети
могут просмотреть различные атрибуты билета. Любой клиент может затребовать большинство из флагов. Сервер Kerberos автоматически устанавливает и сбрасы­вает некоторые флаги, в зависимости от своих текущих требований и того, как клиент получил этот билет. Далее я расскажу вам о некоторых из флагов, их предназначении и использовании.
НАЧАЛЬНЫЕ БИЛЕТЫ
Флаг INITIAL указывает на то, что билет создан сервером идентификации и что он создан не на основе билета для предоставления билета. Серверы приложений
могут потребовать от клиента подтверждение ключа (например, программа смены пароля). При этом такие программы могут потребовать, чтобы сервер Kerberos устанавливал флаг INITIAL во всех пересылаемых им билетах. Благодаря этому серверы приложений получат доказательство того, что клиент получил ключ от сервера идентификации.
БИЛЕТЫ
Флаги PRE-AUTHENTuHW-AUTIIENT предоставляю серверу приложений до­полнительную информацию о начальной идентификации. Эти сведения не зави­сят от того, издан ли текущий билет напрямую или после получения билета для предоставления билета. В первом случае сервер идентификации должен устано­вить флаг INITIAL, а флагам PRE-A UTHENTnEW-Aс^ШЁТУТбил ета присваива­ются те же значения, что и в билете для предоставления билета. Во втором случае флагам PRE-AUTHENTnJHV-AUTHENT6meraприсваиваются те же зна­чения, что и в первом случае, а флаг INITIAL должен быть сброшен.
НЕДЕЙСТВИТЕЛЬНЫЕ БИЛЕТЫ
Флаг inval11 указывает на то, что билет недействителен. Серверы приложений должны отбрасывать билеты с установленным флагом INVALID. Серверы иден­тификации обычно устанавливают этот флаг у досрочных билетов. Поэтому сер­вер идентификации должен ратифицировать билет до того, как клиент им смо­жет воспользоваться. Для этого клиенты пересылают недействительный билет серверу идентификации вместе с запросом, в котором указан параметр VALIDATE.
Сервер идентификации должен ратифицировать билеты лишь по прошествии на­чального времени действия. При этом подразумевается, что в запросе содержится досрочный билет, чье время действия еще не пришло. Такая проверка является гарантией того, что система может работать с украденными досрочными билетами как с недействительными (они будут зарегистрированы в «горячем» списке). Это может произойти в том случае, если хакер украл досрочные билеты до вре­мени вступления в силу. О досрочных билетах мы поговорим чуть позже.
ВОЗОБНОВЛЯЕМЫЕ БИЛЕТЫ
Приложению может понадобиться держать действительный билет долгое время. Всё-таки, долго хранящиеся билеты представляют достаточно серьезную опас­ность для системы. Дело в том, что за это время билет может быть украден, и хакер может использовать его в своих целях до тех пор, пока не истечет его время действия. Но вместо этого приложение может периодически получать у сервера новый краткосрочный билет. Однако этот способ подразумевает, что клиент дол­жен предоставить серверу долгосрочный ^достаточно частый доступ к совместно используемому ключу клиента. А это является еще большей опасностью, чем воровство билета. Возобновляемые билеты — вот средство от воровства. У возоб­новляемых билетов есть два срока годности. Первый срок годности применяется в том случае, когда истекает срок годности текущего экземпляра билета. Второй срок годности отражает наибольшее возможное значение первого срока годности. Клиент приложения должен периодически представлять серверу идентификации возобновляемый билет (до того, как истечет срок годности текущей проштампо­ванной копии билета). Выдавая билет, сервер идентификации должен установить параметр RENEW. В противном случае он не сможет обновить билет.
Сервер идентификации должен создать новый билет с новым одноразовым клю­чом и следующим сроком годности. Процесс обновления не затрагивает ника­ких других полей билета. При наступлении последнего возможного срока годно­сти билет становится недействительным. При каждом обновлении сервер иден­тификации может сверяться с горячим списком, чтобы определить, не сообщил ли кто-нибудь о краже билета. Если это так, то сервер идентификации откажет в обновлении билета и тем самым сделает его недействительным. В обычных ситуациях только служба предоставления билетов использует флаг RENEWABLE.
Серверы приложений чаще всего оставляют его без внимания. Однако некото­рые очень «дотошные» приложения могут запретить использование возобновляе­мых билетов.
Если клиент не обновил билет до окончания срока годности, то сервер иденти­фикации не будет больше обновлять его. Поэтому система Kerberos по умолча­нию переустанавливает флаг RENEWABLE. Однако клиент может попросить у сервера идентификации сделать билет возобновляемым - для этого сервер дол­жен установить параметр RENEWABLE кообщеяяи Kerberos Authentication Server Request (KRB AS REQ). Если флаг RENEWABLE установлен, то поле билета RENEW TILL содержит время, после которого сервер идентификации должен прекратить обновлять билет. показано, как сервер'идентифи­кации обновляет билет.
старый билет
клиент
обновленный билет
сервер идентификации обновляет билет
сервер
Сервер идентификации обновляет билет.
ДОСРОЧНЫЕ БИЛЕТЫ
Приложения должны время от времени получать билет для своих нужд на очень длительное время. Например, система группового подчинения (batch submission) должна получать билеты, которые будут действительны в течение всего периода выполнения работы. Однако хранение билетов в групповой очереди представля­ет собой значительную опасность. Дело в том, что такие билеты должны долгое время находиться в сети (on-line), а это повышает шансы злоумышленника.
Досрочные билеты предоставляют способ получить у сервера идентификации билеты с задержанным сроком действия. Во время простоя системы билеты бу­дут находиться в «замороженном» состоянии. Для активизации такого билета система должна послать серверу идентификации дополнительный запрос. Если кто-либо украдет досрочный билет, сервер идентификации может отказать в утвеждении билета. Тем самым он сможет расстроить планы злоумышленника. Обычно флаг MA Y-POSTDA ТЕ интерпретируется только сервером идентифика­ции, а серверы приложений игнорируют его. Прежде чем создать досрочный билет, сервер Kerberos должен установить флаг MAY-POSTDATE в билете для предоставления билета. По умолчанию сервер на каждый запрос должен обнов­лять дату только одному билету. Чтобы запросить использование этого флага в билете для предоставления билета, клиент должен установить параметр POSTDA ТЕ в сообщении KRBASREQ.
Клиент не может использовать флаг MAY-POSTDATE для получения досрочного билета для предоставления билета. Чтобы добиться этого, он должен послать
специальный запрос. Сервер идентификации установит срок годности досроч­ного билета (конечное время минус начальное) равным сроку годности билета
для предоставления билета на момент Если же клиент воспользуется параметром RENEWABLE, то сервер идентификации может установить срок год­ности досрочного билета равным полному сроку годности билета для предостав­ления билета на момент запроса (конечное время минус начальное). Кроме того,
сервер должен ограничить время, после которого он не будет продлевать срок действия билета. Этому существует достаточно простое объяснение: любой би­лет с достаточно большим сроком действия может быть получен хакером или нечестным служащим.
Флаг POSTDATED указывает на то, что сервер идентификации уже задал срок действия билета. Чтобы узнать, когда произошла первоначальная идентифика­ция, сервер приложений может просмотреть поле билета AUTHT1ME. Некото­рые службы могут игнорировать досрочные билеты или работать с ними только в
определенный период после первоначальной идентификации. При создании досрочного билета сервер идентификации помечает его как недействительный. Чтобы воспользоваться таким билетом, клиенты приложений должны предоста­вить его на ратификацию надежному серверу.
БИЛЕТЫ PROXY и Proxiabli-
Иногда члены сети должны разрешить службе выполнять действия от их имени. Поэтому такая служба должна уметь заменять клиента, но только для определен­ных целей. Член сети может позволить службе работать от его имени с помощью службы-посредника (proxy).
Обычно только сервер идентификации может интерпретировать флаг PROXIABLE, а серверы приложений игнорируют его. Ненулевое значение флага указывает
серверу идентификации на то, что он может создать новый билет (но не билет для предоставления билета) с другим сетевым адресом. При создании такого
билета нужно использовать информацию, хранящуюся в текущем билете. По умолчанию сервер Kerberos устанавливает флаг PROXIABLE в билетах для предо­ставления билета. С его помощью клиент может передать посредника серверу. Благодаря этому сервер сможет выполнить удаленный зарос от имени клиента.
Например, чтобы обслужить запрос на печать, клиент службы печати может передать посредника серверу печати. С его помощью сервер печати получит до­ступ к файлам клиента, расположенным на определенном файловом сервере.
Чтобы усложнить задачу хакерам, билет Kerberos действителен только тогда, когда он приходит из включенного в него адреса. (Можно создавать запросы или билеты и без адресов, однако это не рекомендуется в целях безопасности.) Пер­воначальный, замененный билет не будет содержать локальный адрес. Поэтому клиент, пожелавший предоставить удаленной службе посредника, должен за­просить новый билет, который должен соответствовать адресу службы сервера идентификации, получившего посредника. При создании билета для посредни­ка этот сервер идентификации устанавливает в билете флаг PROXY. Серверы приложений могут просмотреть этот флаг и потребовать от агента, предоставив­шего посредника, дополнительную идентификацию. Благодаря этому можно будет проследить следы хакера.
ПЕРЕДАВАЕМЫЕ БИЛЕТЫ
Пересылка идентификации используется в том случае, если система Kerberos хочет передать идентификатор клиента в полное распоряжение некоторой служ­бе. Этот метод чаще всего используется тогда, когда клиент зарегистрировался в удаленной системе и хочет, чтобы идентификация в ней происходила так, как
будто он является локальным членом этой системы.
Обычно только сервер идентификации интерпретирует флаг FORWARDABLE, а серверы приложений могут игнорировать его. Действие этого флага очень напо­минает действие флага PROXIABLE. Однако есть и различие. При использова­нии флага FORWARDABLE сервер идентификации может создавать билеты для
предоставления билета с различающимися сетевыми адресами. По умолчанию флаг FORWARDABLE сброшен. Однако пользователи могут запросить сервер Kerberos установить флаг. Для этого при запросе билета для предоставления би­лета они должны послать запрос KRB_authenticationserver_REQc установленным параметром FORWARDABLE. показано, как два сервера Kerberos из различных областей действия могут обработать передаваемый билет.
Флж FORWARDABLEпредусматрпвает пересылку идентификации. При этом пользователь не должен повторно вводить пароль. Если сервер еще не установил этот флаг в запросе билета, то он не разрешит пересылку идентификации. Од­нако пользователь может добиться этого, если пошлет сообщение KRB_AS_REQ, содержащее требуемые сетевые адреса, и предоставит пароль.
Допустим, клиент хочет попросить сервер идентификации установить флаг FORWARDED. Для этого он должен предоставить серверу идентификации билет с установленным флагом FORWARDABLE, воспользоваться параметром FORWARDED, а также поместить в этом запросе набор сетевых адресов для но­вых билетов. Кроме того, сервер идентификации установит флаг FORWARDED во всех билетах, созданных на основе билетов с уже установленным флагом. Серверы приложений могут потребовать обрабатывать передаваемые билеты от­дельно от остальных.
ОСТАЛЬНЫЕ ПАРАМЕТРЫ   СЕРВЕРА ИДЕНТИФИКАЦИИ
Клиенты могут установить в запросе еще два параметра: RENEWABLE-ОКя ENC-TGT-IN-SKEY.TlepBbm указывает на то, что если сервер не может предоста­вить билет с требуемым сроком действия, то клиент примет возобновляемый билет. В этом случае сервер идентификации может создать возобновляемый билет с параметром RENEW-TILL, равным запрошенному клиентом конечному сроку. На поле RENEW-TILL могут повлиять ограничения, связанные с сайтом, а также наложенные членом сети или сервером.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика